-----Original Message-----
From: Ina Minei [mailto:ina@juniper.net]
Sent: 07 October 2004 16:31
To: Nick Weeds
Cc: mpls@ietf.org (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
[tiruveedhula@avici.com] 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: mpls-bounces@lists.ietf.org
[mailto:mpls-bounces@lists.ietf.org]On
Behalf Of Ina Minei
Sent: 27 September 2004 19:31
To: mpls@ietf.org
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: Nick.Weeds@dataconnection.com
Web: http://www.dataconnection.com