Protocol Action: 'Updates to LDP for IPv6' to Proposed Standard (draft-ietf-mpls-ldp-ipv6-17.txt)

The IESG <> Wed, 04 March 2015 14:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 56D301A1B4B; Wed, 4 Mar 2015 06:02:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s5CWQ2RY2l3d; Wed, 4 Mar 2015 06:02:47 -0800 (PST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 33B761A1B86; Wed, 4 Mar 2015 06:02:29 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <>
To: IETF-Announce <>
Subject: Protocol Action: 'Updates to LDP for IPv6' to Proposed Standard (draft-ietf-mpls-ldp-ipv6-17.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 5.12.0.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <>
Date: Wed, 04 Mar 2015 06:02:29 -0800
Archived-At: <>
Cc: mpls mailing list <>, mpls chair <>, RFC Editor <>
X-Mailman-Version: 2.1.15
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Mar 2015 14:02:49 -0000

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

The IESG contact persons are Alia Atlas and Adrian Farrel.

A URL of this Internet Draft is:

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.


       Loa Andersson is the Document Shepherd.
       Adrian Farrel is the responsible AD.