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

[Ina Minei <[e-mail]>]

	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