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

From: Nick Weeds <[email-masked]>
Date: Thu, 7 Oct 2004 15:53:21 +0100

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: Ina Minei <[email-masked]>
Date: Thu, 7 Oct 2004 08:31:04 -0700 (PDT)

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

---

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

Nick,

    See in line.

>in RFC 3036.  Which section is it in?

I'm pretty sure discussed this on the list, and determined that it is more
appropriate to address when a feature should or should not be used in
an applicability document - such as RFC 3037.

I don't know that there is universal agreement that loop detection is not
used in the DU mode, nor is it relevant from a specification perspective
whether or not it "should" be used - as long as there is agreement that it
either is or is not required to be supported.

>potential trap for any LDP protocol extension.
This is not a problem with any reasonably robust implementation.
A "reasonably robust" implementation does something intelligent
with the knowledge that it is getting packets with labels it does not
know how to handle.  Something obvious, like sending a (possibly
redundant) label release to the router from which it receives them.

This is not as simple, if the labels it is getting are the result of PHP.
But even this can be dealt with.

>problem and suggest how to avoid it.
There is no "potential fix", and this has been discussed before. It is
not the task of the author(s) of an RFC to tell their competitors how
to build an implementation that works.

No number of messages - where each message is intended to be
an acknowledgement of the one it is  response to - can ever ensure
that two parties to an exchange are in possession of exactly the same
awareness of the state of a particular exchange token. This is known
variously as the "two generals" or "common knowledge" problem.

---

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

Eric raises a very good point - the issue of the
interaction of DU and loop-detection mechanisms should be discussed as
part of an applicability document, not part of the protocol specification.
Which means that in any case it should continue to stay in the "not
included" list.

				Ina