Subject: RE: Label release for draft-martini

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 7 Apr 2002 17:28:04 +0200

Hi all,
AFAIK, RFC 3036 defines that an LSR may free a label that has been once 
bound to a FEC with the binding distributed to peers only after a Label
Release
message for that label has been received from all the peers to which the
binding
has been distributed (A.1.4, LRl.12). If this rule is followed,  the race
condition 
mentioned by Vach cannot occur.
(Dan Tappan has explained to me some time ago that it was exactly for that
purpose that the requirement to respond with the Label Release message
to every received Label Withdraw (Section 3.5.10 and A.1.5/LWd.2) has been
added to LDP - it did not originally exist in Cisco TDP.)

Requirement/recommendation NOT to respond with the Label Release
message to a received Label Withdraw message with some status codes
in Section 5.2.2. of draft-martini looks to me like a violation of the 
LDP procedures.

IMHO, C-bit in draft-martini is used by each peer in order to indicate
its preference to receive or not to receive a CW. It also seems reasonable 
to assume that an LSR that does not support transmission of the 
control word does not also support its reception; and, of course, every LSR
supporting a service with an optional CW MUST be able to do without a CW
(draft -martini says that).

Hence, if the upstream LSR (for the given direction of the PW) 
receives a Label Mapping message telling it to send an 
optional CW that it does not support, it should RELEASE the received 
label with the appropriate status code TLV in the Label Release message, 
not to WITHDRAW its own label. The downstream LSR would then 
advertise another label mapping (with the same or other label) for the same
VC FEC, this time  without requesting the CW. This mapping would not be
released
(at least, not with that status code), and this would fix the problematic 
direction of the PW. The other direction would be OK from the beginning, and
there is no need to disrupt it.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: Yiou Deng [mailto:[email-masked]]
> Sent: Monday, March 04, 2002 11:59 AM
> To: Vach Kompella
> Cc: [email-masked]
> Subject: Re: [PWE3] Label release for draft-martini
> 
> 
> Hi Vach,
> See my comments in line. 
> Hope this helps.
> 
> regards
> Yiou
> ----- Original Message ----- 
> From: "Vach Kompella" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, April 04, 2002 4:17 AM
> Subject: [PWE3] Label release for draft-martini
> 
> 
> > 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?
> General procedure should be:
> LSR-A                                                         
>               LSR-B
> ----------withdraw msg with "wrong c-bit"--------------->
> <---------------------release msg-------------------------
> -----------------new mapping msg----------------------->
> 
> But draft Martini shortened this procedure to:
> LSR-A                                                         
>               LSR-B
> ----------withdraw msg with "wrong c-bit"--------------->
> -----------------new mapping msg----------------------->
> 
> In this case, if LSR-B send a release, LSR-A will be confused.
> 
> So, when LSR receive a Label Withdraw with "wrong c-bit" 
> status code, do nothing but waiting
> for a mapping msg.
> > 
> > -Vach
> > 
> > 
> > 
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>