Updates to LDP for IPv6
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: RFC Editor <firstname.lastname@example.org>, mpls mailing list <email@example.com>, mpls chair <firstname.lastname@example.org> Subject: Protocol Action: 'Updates to LDP for IPv6' to Proposed Standard (draft-ietf-mpls-ldp-ipv6-17.txt) The IESG has approved the following document: - 'Updates to LDP for IPv6' (draft-ietf-mpls-ldp-ipv6-17.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Alia Atlas and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/
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.