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

[Ina Minei <[e-mail]>]

	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

On Thu, 7 Oct 2004, Kishore Tiruveedhula wrote:

> 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: [e-mail] [mailto:[e-mail]]On
> Behalf Of Nick Weeds
> Sent: Thursday, October 07, 2004 12:38 PM
> To: 'Ina Minei'
> Cc: [e-mail] (E-mail)
> Subject: RE: [mpls] For your review - Issues/errors/clarifications in
> RFC3 036
>
>
> 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:[e-mail]]
> > Sent: 07 October 2004 16:31
> > To: Nick Weeds
> > Cc: [e-mail] (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
> > [[e-mail]] 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: [e-mail]
> > > > [mailto:[e-mail]]On
> > > > Behalf Of Ina Minei
> > > > Sent: 27 September 2004 19:31
> > > > To: [e-mail]
> > > > 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:	[phone]
> > Fax:	[phone]
> > Email:	[e-mail]
> > Web:	http://www.dataconnection.com
> >
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mpls
>

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