MPLS Generic Associated Channel
RFC 5586

[Ballot comment]
In the Gen-ART Review, Miguel Garcia points out that the following
  sentnece in the first paragraph of Section 3.1 cn be interpretted in
  mre than one way:
  >
  > The structure of ACH TLVs that MAY follow an ACH TLV Header is
  > defined and described in the following sections.
  >
  Rewording to add clarity is desirable.

[Note]: 'This I-D was last called in MPLS and PWE3
It has been approved by the ITU-T
IANA comments have been answered satisfactorily
Loa Andersson (loa@pi.nu) is the document shepherd
' added by Adrian Farrel

[Note]: 'This I-D was last called in MPLS and PWE3
It has been approved by the ITU-T
IANA comments have been answered satisfactorily
' added by Adrian Farrel

IANA comments:

- NOTE: per RFC5226, the registration procedure for Associated
Channel Header TLVs should be "IETF Review" rather than "IETF
Consensus."

- QUESTION: in the Pseudowire Associated Channel Types registry,
should the "TLV Follows" column be left blank for the Experimental
Use range?

Action 1:

Upon approval of this document, IANA will make the following
assignments in the "Multiprotocol Label Switching Architecture
(MPLS) Label Values" registry at
http://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml

Value Description Reference
----- ----------- ---------
tbd(13) GAL Label [RFC-mpls-tp-gach-gal-04]


Action 2:

Upon approval of this document, IANA will make the following
changes in the "Pseudowire Associated Channel Types" registry at
http://www.iana.org/assignments/pwe3-parameters

OLD:

Value Description Reference
----- ------------------------------------------ ---------
0x21 Associated Channel carries an IPv4 packet [RFC4385]
0x57 Associated Channel carries an IPv6 packet [RFC4385]

NEW:

Value Description TLV Follows Reference
----- ---------------------------- ----------- ---------
0x21 ACH carries an IPv4 packet No [RFC4385]
0x57 ACH carries an IPv6 packet No [RFC4385]
0x7ff8-
0x7fff Experimental Use ?? [RFC-mpls-tp-gach-gal-04]


Action 3:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/TBD

Registry Name: Associated Channel Header TLVs
Registration Procedure: IETF Consensus
Initial contents of this registry will be:

Name Type Length Description Reference
(octets)
---- ---- ------- ----------- ---------
0-65535 Available for registration [RFC-mpls-tp-gach-gal-04]


We understand the above to be the only IANA Actions for this document.

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Loa Andersson (loa@pi.nu) is the document shepherd. The shephered thinks that
the document is ready to be published as a RFC on the standards track.

Note: This is the first of the MPLS-TP documents! We had expected that
      the requirements docuemnt should have gone first, but it came out
      that this one is first, it should not be a problem since the reuirements
      for the G-ACh is well understood.


  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document is very well reviewed, by the MEAD team, the MPLS and PWE3
woking groups and the ITU-T ad hoc team on MPLS-TP. No concerns.
We have received a liaison form the ITU-T that they accept publication
of the document.


  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

No concerns.


  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

No, there is no such issues with this document.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

THe consensus is very strong.


  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No.

We debated the number of experimental code points, and converge on 8 as
a reasonalbe number.


  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

The nits has been reviewed.

The nit tool says>

  == There are 2 instances of lines with non-RFC3330-compliant IPv4 addresses
    in the document.  If these are example addresses, they should be changed.

These are not examples, but normative address ranges for v4 and v6.

and

  -- Looks like a reference, but probably isn't: 'RFC4385' on line 667

Well, it is actually a reference, only that it is put into a table.


  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

Yes.


  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

Yes, the IANA section exists and request the allocation of label 13 as
the label indicating the presence of the G-ACh.


  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

No part of the document is written in formal language.


  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:


          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

This document generalizes the applicability of the pseudowire (PW)
Associated Channel Header (ACH), enabling the realization of a
control channel associated to MPLS Label Switched Paths (LSPs) and
MPLS Sections in addition to MPLS pseudowires.  In order to identify
the presence of this Associated Channel Header in the label stack,
this document also assigns one of the reserved MPLS label values to
the Generic Associated Channel Label (GAL), to be used as a label
based exception mechanism.



          Working Group Summary
            Was there anything in WG process that is worth noting?  For
            example, was there controversy about particular points or
            were there decisions where the consensus was particularly
            rough?

No real controversies, though quite a bit of discussion on the number of
experimental code points.


          Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type or other expert review,
            what was its course (briefly)?  In the case of a Media Type
            review, on what date was the request posted?

The level of the review is very good. The document has been reviewed by the
ITU-T ad hoc Team on MPLS-TP.


          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?

Loa Andersson is the document shepherd.
Adrian Farrel is the responsible AD.