Technical Summary
The LDP [RFC5036] specification defines procedures and messages for
exchanging FEC-label bindings over either IPv4 or IPv6 or networks deploying
both types of technologies (e.g. dual-stack networks).
Although LDP is defined in RFC5036 so that it may be used over IPv4
and/or IPv6, RFC 5036 really does not really allow for interoperable
implementations of LDP over IPv6. In this respect RFC 5036 is too
under-specified to be implemented over IPv6.
Consequently, this document list 7 deficiencies in RFC5036 (see the Introduction)
that needs to be addressed to allow interoperable LDP implementations in
IPv6 networks
.
The document and also specifies how these deficiencies should be addressed
in regards to IPv6 usage. In general there can be said that RFC 5036 lack
in detail, rules and procedures for using LDP in IPv6 enabled networks
(IPv6-only or Dual-stack networks).
This document corrects and clarifies the LDP behavior when IPv6 network is
used (with or without IPv4). This document updates RFC 5036 and RFC 6720.
Working Group Summary
This document has a rather long history even though it is a document that is
focused to address a limited scope of issues - some of the issues are in
themselves of considerable complexity
The first individual version of this draft was published in February 2008,
it was well received, but the timing was a bit unfortunate: it was about the same
time as the start of the MPLS-TP work and the MPLS WG was a bit swamped
by a large number of MPLS-TP drafts.
However, we had a good discussion on the list and the document was accepted
as a working group document in November 2010. Followed by a good discussion,
and the WGLC in Aug 2011 were uneventful due to the fact that issues had been
addressed. However after reposting a new version there were some questions
put to the working group and that generated further comments. One of these
comments turned out to be hard to resolve given the disagreement between the
authors and reviewers.. It had to do with the number of LDP Hello
adjacencies needed to be kept and maintained on the receiver side between
a pair LSRs with both IPv4 and IPv6 stacks, it took us quite a long time to
resolve this.
When we had the resolution we did a short working group last call on the
changes that been introduced between the two working group last calls.
This short WGLC call only received supportive comments. The document
was agreed upon by all parties.
However it would not be this document if we had not received a new set of
comments outside the scope of the short working group last call. The comments
were supportive and will improve the document. A new version was been posted
addressing these comments.
The document was returned to the WG and the authors due to comments during
AD Evaluation and further late comments from the community.
These comments were resolved and were verified in a further short WGLC.
However there were comments claiming that "some" implementations were not
RFC 5036 compatible and started to flap LDP sessions. In one case we have been
able to verify that this was a temporary issue (i.e. a bug) that has been resolved.
It was proposed that this document should be changed to support both RFC 5036
compatible and non-compatible implementations. The document shepherd and WG
chairs believe that implementations should be RFC 5036 compatible and that there
is no need to support non-compatible implementations. However, some text has been
added to this document to address the comments.
Maybe it wasn't a surprise that there were still more comments raised in the working
group during IETF last call. These have been thoroughly discussed on the mailing
list and the updated version has been confirmed by all as addressing the issues.
Document Quality
A mail has been sent to the working group asking for implementations.
We are aware of at least two implementations of this draft.
The key reviewers are all mentioned in the acknowledgment section.
There are significant vendor and operator interest in this draft.
No MIB Doctor or Media Type reviews are necessary.
Personnel
Loa Andersson is the Document Shepherd.
Adrian Farrel is the responsible AD.