Subject: RE: [mpls] For your review - Issues/errors/clarifications in RFC3 036

From: Nick Weeds <[email-masked]>
Date: Thu, 7 Oct 2004 17:37:33 +0100

Ina,

Sorry I didn't explain this clearly.

The problem arises in window cases where the upstream (U,B) and downstream
(D,A) routers happen to 
send LDP messages at the same time.  The likelihood of this is low, but it
is possible.

                !                       !
                !              /---<----! Label Mapping
                !             /         !
                !            /          !
                !           /           !
                !          /            !
                !         /             !
                !<-------/              !
                !                       !
  Label Release !---->---\              !
                !         \             !
                !          \            ! <-- ROUTE CHANGE
                !           \           !
                !            \ /---<----! Label Mapping (update)
                !             X         !
                !            / \------->!
                !           /           !
                !          /            !
                !         /             !
                !<-------/              !
                !                       !

The Label Release is initiated by the upstream router.  It is not a response
to a Label Withdraw.  For example, the upstream router might send the Label
Release because it is using conservative retention.

The downstream router sends the 2nd Label Mapping before receiving the Label
Release.  For example, a route change might cause the downstream router to
signaling a change of hop count or a change of MTU.

At the end of this sequence the downstream router has sent two Label
Mappings and received a Label Release, so it considers the label to be
released.  The upstream router has sent a Label Release and received a
subsequent Label Mapping, so it considers the label to be valid.  In most
cases the upstream router would send another Label Release, but if the route
has changed then the upstream router might install the label for
forwarding/switching use.  If so then any data sent using the label will be
dropped by the downstream router.  This isn't a transient condition, it can
continue indefinitely.

As I said, the likelihood of this happening is low.  I believe typical LDP
usage would avoid this problem by avoiding loop detection, MTU signaling
etc.  Nevertheless, RFC 3036 allows such usage, describes hop count
behaviour that can lead to the problem, and fails to mention or prevent the
problem.

Is that clearer?

	Nick.

> -----Original Message-----
> From: Ina Minei [mailto:[email-masked]]
> Sent: 07 October 2004 16:31
> To: Nick Weeds
> Cc: [email-masked] (E-mail)
> Subject: RE: [mpls] For your review - Issues/errors/clarifications in
> RFC3 036
> 
> 
> 
> 	Nick,
> 
> 	I think I am missing something... The label release is sent by
> router B in response to a label withdraw it received from router A.
> A should  wait for the release before attempting to send a label map
> again. In the meantime, the label is considered dead on A, and
> if A wants to resurrect it, A should wait until receiving the release.
> 
> 	Are you suggesting that A can resurrect the label it just killed
> before waiting for the release to come?
> 
> 				Thank you,
> 
> 					Ina
> 
> On Thu, 7 Oct 2004, Nick Weeds wrote:
> 
> > Ina,
> >
> > Just a couple of points on the update to RFC 3036...
> >
> > First, the list of issues not addressed says that RFC 3036 
> already says that
> > loop detection should not be used in DU mode.  I can't find 
> this statement
> > in RFC 3036.  Which section is it in?
> >
> > Second, the LDP protocol can fail if a Label Mapping 
> crosses with a Label
> > Release.
> > This was raised by Kishore Tiruveedhula 
> [[email-masked]] on 25th
> > August in connection with loop detection, but it is a more 
> general problem
> > with the protocol.
> >
> > The problem arises with the following sequence:
> > (1) Router D sends a Label Mapping
> > (2) Router U sends a Label Release
> > (3) Independently router D sends an updated Label Mapping 
> (same FEC and
> > label, different details).
> >
> > If messages (2) and (3) cross in transit then the label mapping is
> > programmed on U (on receipt of the updated Label Mapping) 
> but released on D
> > (on receipt of the Label Release).  Any data sent using the 
> label will be
> > lost.
> >
> > The problem can occur whenever the downstream router sends 
> a Label Mapping
> > message to update an existing mapping.  This is probably unusual in
> > practice, but RFC 3036 allows it and indeed describes it 
> for hop count
> > changes when using independent control (see Kishore's 
> email).  From a quick
> > check, the MTU signaling extension
> > (draft-ietf-mpls-ldp-mtu-extensions-03.txt) also seems to 
> require Label
> > Mapping updates.  I am not aware of other examples, but the 
> problem is a
> > potential trap for any LDP protocol extension.
> >
> > It is unclear how to proceed on this, as potential fixes 
> are likely to
> > require protocol changes.  Perhaps it would be sufficient 
> to explain the
> > problem and suggest how to avoid it.
> >
> > (This problem was drawn to my attention in discussions of 
> C-bit negotiation
> > in draft-ietf-pwe3-control-protocol-xx.txt.  This 
> negotiation takes care to
> > avoid Label Release messages in response to Label Withdraw 
> "Wrong C-bit".
> > The protocol problem in RFC 3036 was suggested as one 
> reason for suppressing
> > the Label Release, but there are probably other reasons too.)
> >
> > 	Nick.
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]On
> > > Behalf Of Ina Minei
> > > Sent: 27 September 2004 19:31
> > > To: [email-masked]
> > > Subject: [mpls] For your review - Issues/errors/clarifications in
> > > RFC3036
> > >
> > >
> > >
> > >    As part of the effort to move RFC3036 to draft 
> standard, here is an
> > > annotated version of RFC3036, with the changes enclosed by ###.
> > > There is a separate section summarizing all changes towards
> > > the end of the
> > > document.
> > >
> > >    Please review the changes and send comments to the 
> list by October
> > > 11th.
> > >
> > >    At the end of this mail is a list of issues that were 
> raised but
> > > were not included in the annotated RFC (with an explanation of
> > > why).
> > >
> > >    Please review both the RFC changes and the list of issues not
> > > included. Also let me know if I forgot to include any other issues
> > > that were raised on the list.
> > >
> > >    Many thanks to all who contributed, and in particular 
> to Bob Thomas
> > > for maintaining an extensive list of errors/issues over the years.
> > >
> > >
> > >     		Thank you,
> > >
> > > 			Ina
> > >
> > >
> > > Issues that were raised but not included in the annotated RFC
> > > =============================================================
> > >
> > > - Issue: discussion on the merits/drawbacks of 
> independent-control and
> > > ordered-control
> > > - Issue: discussion on which FECs should be advertised
> > > Reason why not included: The above two issues are either for the
> > > applicability doc or for the "experiences with the 
> protocol" document.
> > >
> > > - Issue:  minor optimization: if A is a stub node, i.e., 
> only one LDP
> > > session, does it really have to send a label mapping for
> > > every FEC that
> > > it has, or can it do it lazily, e.g., when it has a second
> > > LDP session?
> > > Reason why not included : It is not clear what problem 
> this change in
> > > behavior brings, and what would be the added benefit,the 
> issue must
> > > be discussed on the list first.
> > >
> > > - Issue: the ldp loop detection mechanisms don't make sense in DU.
> > > We should add something explicitly that
> > > says that these TLVs should not be used in DU mode. ( This is the
> > > current practice in all implementations that I know of )
> > > Why not included: RFC 3036 already states this in the section
> > > describing these TLVs, when it talks about the usage of the TLVs.
> > >
> > > - Issue: the rfc should specifically say that  a  wildcard release
> > > message should be sent only in response to a wildcard
> > > withdraw message.
> > > Reason not included: it is covered in the rules in the appendix.
> > >
> > > - There is a long list of issues that was added to the "for future
> > > study" area of the RFC. The list is quite long, we could probably
> > > remove some of the items.
> > >
> >
>
> Nick Weeds
> Software Developer
> Network Protocols Group
> Data Connection Ltd
> Tel:	+44 1244 305200
> Fax:	+44 1244 312422
> Email:	[email-masked]
> Web:	http://www.dataconnection.com
>

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Kishore Tiruveedhula" <[email-masked]>
Date: Thu, 7 Oct 2004 16:05:03 -0400

Yes. This problem happens if the the downstream router re-sends Label
Mapping to upstream router to update the parameters like hop count or path
vectors and if the receiving label release message is on the wire.
There is no one-to-one mapping between Label Mapping and Label Release
messages.

And one more issue:
******************
Note 1 of A.1.4 says, When the label Release Message is received from
upstream peer,  the router shouldn't send Label Mapping until the upstream
router requests it.
Is it make sense for not sending the Mapping until the MsgSource requests it
??

**************************************************
A.1.4. Receive Label Release

   Notes:

      1. If LSR is using Downstream Unsolicited label distribution, it
         should not re-advertise a label mapping for FEC to MsgSource
         until MsgSource requests it.
*****************************************************

Thanks,
Kishore

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Nick Weeds
Sent: Thursday, October 07, 2004 12:38 PM
To: 'Ina Minei'
Cc: [email-masked] (E-mail)
Subject: RE: [mpls] For your review - Issues/errors/clarifications in
RFC3 036

Ina,

                !                       !

Is that clearer?

	Nick.

---

From: Eric Gray <[email-masked]>
Date: Thu, 07 Oct 2004 19:26:27 -0400

Nick,

    Thanks for filling in the details. Please see one comment below.

>                !              /---<----! Label Mapping
Not if the downstream router sends a label withdraw as an appropriate
recovery response to getting a packet with a label that is invalid.

---

From: Rama Ramakrishnan <[email-masked]>
Date: Thu, 07 Oct 2004 16:50:01 -0700

> recovery response to getting a packet with a label that is invalid.
But there may be a problem if the downstream router allocates the same label
for a different FEC (may be for a different protocol like RSVP)

Regards,

Rama

> ------------------------------------------------------------------------
>

---

From: Ina Minei <[email-masked]>
Date: Thu, 7 Oct 2004 19:05:58 -0700 (PDT)

Check out Venkata's pointer to the previous discussion, it refers
to the note in the appendix.
http://www.cell-relay.com/mhonarc/mpls/2002-Jan/msg00120.html

			Ina

---

From: Eric Gray <[email-masked]>
Date: Fri, 08 Oct 2004 00:03:54 -0400

Rama,

    Yes, Bob Thomas and I talked about this problem _years_ ago (:-))

    Bob seemed to feel that there are several way that an implementation
can avoid re-issuing the same label too soon after it "becomes available".
Since he and I were both working on separate LDP implementations at
the time, I couldn't really find a hole in that argument. Therefore, 
this is a
"race" condition where you can hobble the competition.

    One other comment in response - the protocol that issues a label should
be irrelevant in the sense that you're addressing. Either the multiple 
signaling
protocols are getting the labels from the same pool or they're not. If 
they're
not, the problem does not exist. If they are, then a sensible 
implementation
would benefit from using a common under-lying label allocation scheme.

--
Eric

Rama Ramakrishnan wrote:

>>> (D,A) routers happen to send LDP messages at the same time.  The 
>>> likelihood of this is low, but it
>>> is possible.
>>>
>>>                !                       !

---

From: Rama Ramakrishnan <[email-masked]>
Date: Fri, 08 Oct 2004 10:46:07 -0700

> would benefit from using a common under-lying label allocation scheme.

One clarification. The reason I mentioned RSVP is just to stress the point
that the old label is currently used for a different purpose.

Regards,

Rama

---

From: Eric Gray <[email-masked]>
Date: Fri, 08 Oct 2004 18:31:39 -0400

Rama,

    Actually, it is still used for the same purpose - to decide how to 
forward packets.
It is just associated with a different decision.  My point is that it is 
not impossible (or
even hard) to avoid the problem we are blasting away at.

--
Eric

Rama Ramakrishnan wrote:

>> be irrelevant in the sense that you're addressing. Either the 
>> multiple signaling
>> protocols are getting the labels from the same pool or they're not. 
>> If they're