An In-Band Data Communication Network For the MPLS Transport Profile
RFC 5718

Received changes through RFC Editor sync (changed abstract to 'The Generic Associated Channel (G-ACh) has been defined as a generalization of the pseudowire (PW) associated control channel to enable the realization of a control/communication channel that is associated with Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between adjacent MPLS-capable devices.

The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS architecture that identifies elements of the MPLS toolkit that may be combined to build a carrier-grade packet transport network based on MPLS packet switching technology.

This document describes how the G-ACh may be used to provide the infrastructure that forms part of the Management Communication Network (MCN) and a Signaling Communication Network (SCN). Collectively, the MCN and SCN may be referred to as the Data Communication Network (DCN). This document explains how MCN and SCN messages are encapsulated, carried on the G-ACh, and demultiplexed for delivery to the management or signaling/routing control plane components on an MPLS-TP node. [STANDARDS-TRACK]')

[Ballot discuss]
I have reviewed draft-ietf-mpls-tp-gach-dcn-06, and have one question
that I'd like to discuss before recommending approval of the document:

This looks a lot like IPv4/v6-over-FOO document (for link layer or
tunneling technology FOO). Normally, such a document would say
something about MTUs/fragmentation, and for IPv6, interface
identifiers, link-local addresses, the overall link model (point-to-
point, NBMA, etc.), multicast, and neighbor discovery/router
advertisements/etc.

Is something about this topics needed in this document? (And if not,
why not -- where would those details be?)

IANA comments:

- QUESTION: Can you verify that the 'TLV Follows' field should read 'no' for both entries?

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


Value Description TLV Follows Reference
------------- ----------------------------- ----------- ---------
TBD Management Communication Channel (MCC) No
[RFC-mpls-tp-gach-dcn-06]
TBD Signaling Communication Channel (SCC) No
[RFC-mpls-tp-gach-dcn-06]


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

The MPLS WG requests that:
An Inband Data Communication Network For the MPLS Transport Profile

is published as an RFC on the standards track.



> (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 is the Document Shepherd.
He has reviewed the codument and believes it is ready to be
forwarded to the IESG for publication.

> (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 review has been substantial.
Considerable input to early revisions was received from MPLS WG
participants, from participants in the MPLS-TP project and from
a detailed review by members of ITU-T Study Group 15.

The WG last call was liaised to the ITU-T, and the final revision
(including resolution to WG last call comments) was supported by
the ITU-T in a liaison.

The WG last call was notified to the PWE3 and CCAMP working groups.

> (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. The document specifies details of an inband MCC/SCC for MPLS_TP
and was authored and reviewed by many people active in the designing
protocols and with experience from network management.

> (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.

> (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?

Development of the document was performed within the MPLS-TP design
team (c. 20 people) that strongly supports the work. There has also
been discussion on the MPLS-TP (open) mailing list, and there
were no objections raised.

The issue of whether we should use 16-bit or 32-bit alignment for the
MCC/SCC header was discussed, and it was agred that a 16-bit alignment
does not have any effect on protocol efficiency.

> (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 threats or extreme discontent.

> (1.g) Has the Document Shepherd personally verified that the
> document satisfies all ID nits? (See the Internet-Drafts Checklist
> 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?

All checks are clean.

> (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].

References are correctly split.

> (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 [RFC5226]. 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?

There IANA section is present.

The IANA sections requests allocation of of two new channel types;
MCC and SCC according the specification in RFC4446 and s updated in
and as updated in RFC5586.

> (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 such 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

This document describes how the G-ACh may be used to provide the
infrastructure that forms part of the Management Communication
Network (MCN) and a Signaling Communication Network (SCN).
Collectively, the MCN and SCN may be referred to as the Data
Communication Network (DCN). This document explains how MCN and SCN
messages are encapsulated, carried on the G-ACh, and demultiplexed
for delivery to the management or signaling/routing control plane
components on an MPLS-TP node.

Working Group Summary

The document is part of the MPLS-TP project, the cooperation
between IETF and ITU-T to specify an MPLS transport profile.
The working group has consensus on the document, and the ITU-T
has indicated that it supports the publication

Document Quality

The document specification of an MPLS-TP MCC or SCC, we have seen
test implementations of the G-ACh and received feedback, but we
know of no current implementations of the MCC or SCC. We have been
informed by two vendors of their intent to implement soon.