Skip to main content

Gap Analysis for Operating IPv6-Only MPLS Networks
draft-ietf-mpls-ipv6-only-gap-04

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    mpls mailing list <mpls@ietf.org>,
    mpls chair <mpls-chairs@tools.ietf.org>
Subject: Document Action: 'Gap Analysis for Operating IPv6-only MPLS Networks' to Informational RFC (draft-ietf-mpls-ipv6-only-gap-04.txt)

The IESG has approved the following document:
- 'Gap Analysis for Operating IPv6-only MPLS Networks'
  (draft-ietf-mpls-ipv6-only-gap-04.txt) as Informational RFC

This document is the product of the Multiprotocol Label Switching Working
Group.

The IESG contact persons are Adrian Farrel and Alia Atlas.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-only-gap/


Ballot Text

Technical Summary

   This document reviews the Multiprotocol Label Switching (MPLS)
   protocol suite in the context of IPv6 and identifies gaps that must
   be addressed in order to allow MPLS-related protocols and
   applications to be used with IPv6-only networks.  This document is
   intended to focus on gaps in the standards defining the MPLS suite,
   and not to highlight particular vendor implementations (or lack
   thereof) in the context of IPv6-only MPLS functionality.

   In the data plane, MPLS fully supports IPv6 and MPLS labeled packets
   can be carried over IPv6 packets in a variety of encapsulations.
   However, support for IPv6 among MPLS control plane protocols, MPLS
   applications, MPLS Operations, Administration, and Maintenance (OAM),
   and MIB modules is mixed, with some protocols having major gaps.  For
   most major gaps work is in progress to upgrade the relevant
   protocols.

Working Group Summary

   There is a good support in the working group for this draft, and it is needed
   to figure out the gaps that needs to be filled to run MPLS in a IPv6 only
   network; the draft point to several issues that needs to be addressed.

   There were comments during wglc that has been addressed.

   This document were one of the first documents that did go through the new
   Quality Assurance(QA)  that is started for Rtg Area documents. This review 
   was done in parallel with the wglc. The QA review concluded that this is a
   very useful document of good quality.   There were a set  of technical and 
   editorial comments that were addressed in the process to resolve the wglc
   comments.
 
  The QA also resulted in a comment that said that this document is a gap
   analysis and as such gives a description at one point in time, and ask if
   this should be published as a living document instead.

   This was discussed but the working group and the working group chairs
   called consensus in a mail to the working group.

        http://www.ietf.org/mail-archive/web/mpls/current/msg12752.html

   Saying:
   "The working group chairs find that the working group have consensus to 
     move ahead with the document (version -02) as it has been updated after
     the wglc and reviews.

     The value in having  the document publish by far outweigh not having it
     published. The benefits in moving the reference to an appendix (or
     removing them) is not comparable to have easily at hand when reading
     the document."

   That  said the wg chairs are agreeable to, as soon as the RFC is published
   start following the process of filling the MPLS/IPv6 gaps, we believe that this
   eventually cover more than the MPLS specification and that it is a job that 
   will be relevant for the entire rtg area.

Document Quality

   This is an informational and a gap analysis document, no implementations
   are expected. On the other hand there are already activities and drafts
   looks to filling the gaps identified in the document. 

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

   Loa Andersson is the Document Shepherd.
   Adrian Farrel is the Responsible Area Director.

RFC Editor Note