Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP)
draft-ietf-pwe3-mpls-tp-gal-in-pw-01

[Ballot comment]
Thanks for discussing my Discuss.
I am happy to move to "Yes" on this documnet, but encourage you to look at the comments.

---

Section 1

  [RFC5586] defines a generalized label-based exception mechanism using
  the Generic Associated Channel Label (GAL) to work together with the
  ACH for use with LSPs but places restrictions on GAL usage with PWs. 

  This document removes the restriction imposed by [RFC5586].

Please clarify one or more restrictions?

---

Section 3

  This indicates that the GAL can be used for MPLS-TP LSPs and Sections,
  but not for PWs using an MPLS-TP PSN.

What does it mean for a PW to use an MPLS-TP PSN?
Perhaps...

  but not for PWs in an MPLS-TP network.

---

Nits

Title
s/Pseudowire/Pseudowires/

---

Abstract
s/[RFC5586]/RFC 5586/

---

Section 1
s/associated control channel/Associated Channel/  (per RFC 5085)

---

Section 1
s/generalizes this for use in the/generalizes this for use as the/

---

Section 3 para 1

Delete "appropriate" or fix as suggested by Stephen

[Ballot comment]
Section 1

  [RFC5586] defines a generalized label-based exception mechanism using
  the Generic Associated Channel Label (GAL) to work together with the
  ACH for use with LSPs but places restrictions on GAL usage with PWs. 

  This document removes the restriction imposed by [RFC5586].

Please clarify one or more restrictions?

---

Section 3

  This indicates that the GAL can be used for MPLS-TP LSPs and Sections,
  but not for PWs using an MPLS-TP PSN.

What does it mean for a PW to use an MPLS-TP PSN?
Perhaps...

  but not for PWs in an MPLS-TP network.

---

Nits

Title
s/Pseudowire/Pseudowires/

---

Abstract
s/[RFC5586]/RFC 5586/

---

Section 1
s/associated control channel/Associated Channel/  (per RFC 5085)

---

Section 1
s/generalizes this for use in the/generalizes this for use as the/

---

Section 3 para 1

Delete "appropriate" or fix as suggested by Stephen

[Ballot discuss]
Thanks for this document. I will move to a Yes ballot once my simple
question has been answered

RFC 5586 updates RFCs 3032, 4385, and 5085.
Does this document update any of those directly?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Using the Generic Associated Channel Label for Pseudowire in MPLS-TP) to Proposed Standard


The IESG has received a request from the Pseudowire Emulation Edge to
Edge WG (pwe3) to consider the following document:
- 'Using the Generic Associated Channel Label for Pseudowire in MPLS-TP'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-08-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes the requirements for using the Generic
  Associated Channel Label (GAL) in Pseudowires (PWs) in MPLS-TP
  networks, and provides an update to the description of GAL usage in
  [RFC5586] by removing the restriction that is imposed on using GAL
  for PWs especially in MPLS-TP environments.

  .




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-tp-gal-in-pw/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-tp-gal-in-pw/


No IPR declarations have been submitted directly on this I-D.

draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt

Document Shepard Write-Up


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

Matthew Bocci (matthew.bocci@alcatel-lucent.com)
Yes, I have reviewed the document and I believe it is ready for
forwarding to the IESG.


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

Yes, the document has received adequate review. The document has
been through two working group last calls, and received a number
of comments demonstrating that it has been reviewed by a significant
number of WG participants. The MPLS WG was also notified of the
WG last call, since this document updates RFC5586 which was
produced by the MPLS WG.


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


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


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

I am comfortable that the document represents WG consensus and has
been reviewed by a reasonable number of active WG participants.
Although there were some comments during last call that expressed
disagreement with the basic principle of using a GAL on PWs, or
technical issues with the interaction of the GAL with ECMP and VCCV,
these were resolved.


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

None indicated.


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


Yes. There are a couple of minor I-D nits: one line too long and
One typo in a reference. There are no formal review criteria.

(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, the references are split appropriately.



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

The IANA considerations section exists and seems reasonable.


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

There are no sections that use a 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 the requirements for using the Generic
Associated Channel Label (GAL) in Pseudowires (PWs) in MPLS-TP
networks, and provides an update to the description of GAL usage
in [RFC5586] by removing the restriction that is imposed on using
GAL for PWs especially in MPLS-TP environments. This is required
to allow PWs that do not use a PW control word to be used in MPLS-TP
and for them to use the full range of MPLS-TP OAM supported by the G-ACh.

This document is a product of the PWE3 working group.

This document is STANDARDS TRACK.

Working Group Summary

Network transport service providers and their users are
seeking to rationalize their networks by migrating their
existing services and platforms onto IP or MPLS enabled
IP packet switched networks (PSN). This migration requires
communications services that can emulate the essential
properties of traditional communications links over a PSN.
Some service providers wish to use MPLS technology to
replace existing transport network infrastructure, relying
upon pseudowire technology is an integral component of
these network convergence architectures.

Pseudowire Emulation Edge to Edge (PWE3) will specify the
encapsulation, transport, control, management, interworking
and security of services emulated over IETF-specified PSNs.

Document Quality

There are no concerns with document quality.