Subject: Label release for draft-martini

From: "Vach Kompella" <[email-masked]>
Date: Wed, 3 Apr 2002 12:17:50 -0800

In RFC3036, Receive Label Withdraw procedure in Appendix A.1.5, it says:

 Summary:

  When an LSR receives a label withdraw message for a FEC from an
  LDP peer, it responds with a label release message and it removes
  the label from any forwarding/switching use.  If ordered control
  is in use, the LSR sends a label withdraw message to each LDP peer
  to which it had previously sent a label mapping for the FEC.  If
  the LSR is using Downstream on Demand label advertisement with
  independent control, it then acts as if it had just recognized the
  FEC.

The sending of the label release is unconditional.  In my opinion, this is
overloading a Label Release message, and leads to race conditions where a FEC is
withdrawn and re-signaled with the same label, and the label release is received
right after the FEC is re-signaled.  The receiving LSR has to figure out whether
this is an "I just don't want labels for this FEC anymore" or "I'm responding to
your Label Withdraw."  If the intent of the label release was to say, "I got
your Label Withdraw" then that's what TCP is for.  Worst case, a Label Withdrawn
message should have been used.  Am I missing something?

In draft-martini-l2circuit-trans-mpls-08.txt, sec. 5.2.2, it says:

      Note that receiving a Label Withdraw should not cause a
      corresponding Label Release to be sent.

So what happens when an LSR gets a Label Withdraw, does it send a Label Release
or not?

-Vach

---

From: "Vach Kompella" <[email-masked]>
Date: Wed, 3 Apr 2002 15:57:55 -0800

Eric,

Thanks for the reply.  See inline.

-Vach

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Wednesday, April 03, 2002 1:52 PM
>
> Vach> leads to race conditions where a FEC is withdrawn and re-signaled with
> Vach> the same label, and the label  release is received right after the FEC
> Vach> is re-signaled.
>
> The purpose of  the Label Release is  to let you know that  the Withdraw was
> received and  acted upon by the peer.   If you don't know  that the Withdraw
> was received and acted  upon by the peer, you don't know  whether it is safe
> to reuse the label for a different FEC (unless you time it out).
>
> Bob Thomas tells me  that this race has been discussed on  the MPLS list and
> there is some thought of using a transaction id to match up the Withdraw and
> Release messages.
>

That would help, but only if the label is not re-used in the interim between the
transmission of the withdraw and the receipt of the release.

> Vach> If  the intent of  the label  release was  to say,  "I got  your Label
> Vach> Withdraw" then that's what TCP is for.
>
> TCP can't tell you whether the Withdraw operation actually took place at the
> peer.
>

But the RFC says you can remove the label from use in your switch when you send
the label withdraw, and does not say you can't use it for the same or some other
FEC before the label release arrives.  So you really aren't using the receive
label release event.  If the rfc says that, then it makes sense.

> Why does  the Martini draft specify that  the Release not be  sent after the
> Withdraw?  Perhaps to  avoid this race, so that you can  reuse the label for
> the same  FEC.  Then you  have to  make sure you  time the label  out before
> reusing it for a different FEC.

And which customer is going to be happy about that timeout value?  It's a
security breach waiting to happen.

I'd say the best thing is to have the label withdraw/label release sequence as
mandatory, with a specification that the label not be reused until the label
release is received (and make that change to the rfc also, although for IP
address FECs, the worst that reusing labels can do is probably loops or
blackholes).

---

From: Bob Thomas <[email-masked]>
Date: Thu, 04 Apr 2002 07:07:32 -0500

Vach,

> That would help, but only if the label is not re-used in the interim
> between the transmission of the withdraw and the receipt of the
> release.

The intent of the RFC3036 specification of label withdraw is to prevent
reuse of the label until the label release is received.

> But the RFC says you can remove the label from use in your switch
> when you send the label withdraw, and does not say you can't use it

I think the only place in RFC3036 that says this is Note 1 in
Section A.1.14:

      1. The LSR may remove the label from forwarding/switching use as
         part of this event or as part of processing the label release
         from the peer in response to the label withdraw.

This note is inconsistent with the rest of the LDP procedures dealing
with withdraw.  It needs to be corrected to require that the LSR
follow the withdraw/release procedure before reusing the advertised
label for some other purpose.

And, of course, the race condition that has been previously discussed
on the MPLS WG list also needs to be addressed by an update to RFC3036.

Bob

Bob

> for the same or some other FEC before the label release arrives.  So
> you really aren't using the receive label release event.  If the rfc
> says that, then it makes sense.
> 
> And which customer is going to be happy about that timeout value?
> It's a security breach waiting to happen.
> 
> I'd say the best thing is to have the label withdraw/label release
> sequence as mandatory, with a specification that the label not be
> reused until the label release is received (and make that change to
> the rfc also, although for IP address FECs, the worst that reusing
> labels can do is probably loops or blackholes).