Skip to main content

Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP)
RFC 6423

Revision differences

Document history

Date Rev. By Action
2015-10-14
01 (System) Notify list changed from pwe3-chairs@ietf.org, draft-ietf-pwe3-mpls-tp-gal-in-pw@ietf.org to (None)
2012-08-22
01 (System) post-migration administrative database adjustment to the Yes position for Adrian Farrel
2011-11-01
01 Cindy Morgan State changed to RFC Published from RFC Ed Queue.
2011-11-01
01 (System) RFC published
2011-10-07
01 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Radia Perlman.
2011-09-28
01 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2011-09-27
01 (System) IANA Action state changed to No IC from In Progress
2011-09-27
01 (System) IANA Action state changed to In Progress
2011-09-27
01 Amy Vezza IESG state changed to Approved-announcement sent
2011-09-27
01 Amy Vezza IESG has approved the document
2011-09-27
01 Amy Vezza Closed "Approve" ballot
2011-09-27
01 Amy Vezza Approval announcement text regenerated
2011-09-23
01 Stewart Bryant Ballot writeup text changed
2011-09-23
01 Stewart Bryant Ballot writeup text changed
2011-09-22
01 Amy Vezza Removed from agenda for telechat
2011-09-22
01 Amy Vezza State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation.
2011-09-22
01 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded
2011-09-22
01 Dan Romascanu [Ballot comment]
OAM is defined in the terminology section but never used. I suggest to drop it.
2011-09-22
01 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2011-09-22
01 Adrian Farrel
[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. …
[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
2011-09-22
01 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to Yes from Discuss
2011-09-21
01 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded
2011-09-21
01 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2011-09-21
01 Adrian Farrel
[Ballot comment]
Section 1

  [RFC5586] defines a generalized label-based exception mechanism using
  the Generic Associated Channel Label (GAL) to work together …
[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
2011-09-21
01 Adrian Farrel
[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, …
[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?
2011-09-21
01 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded
2011-09-21
01 Stewart Bryant Ballot writeup text changed
2011-09-21
01 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-09-21
01 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-09-20
01 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2011-09-18
01 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded
2011-09-16
01 Stephen Farrell [Ballot comment]
typo: s/architectures appropriate/architectures as appropriate/
in section 3
2011-09-16
01 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded
2011-09-12
01 Stewart Bryant State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-09-02
01 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-09-02
01 Stewart Bryant Telechat date has been changed to 2011-09-22 from 2011-09-08
2011-08-31
01 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2011-08-30
01 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2011-08-30
01 Stewart Bryant Ballot writeup text changed
2011-08-26
01 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-08-24
01 Amanda Baber We understand that this document doesn't require any IANA actions.
2011-08-19
01 Samuel Weiler Request for Last Call review by SECDIR is assigned to Radia Perlman
2011-08-19
01 Samuel Weiler Request for Last Call review by SECDIR is assigned to Radia Perlman
2011-08-12
01 Amy Vezza Last call sent
2011-08-12
01 Amy Vezza
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: …
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.


2011-08-12
01 Stewart Bryant Placed on agenda for telechat - 2011-09-08
2011-08-12
01 Stewart Bryant [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant
2011-08-12
01 Stewart Bryant Ballot has been issued
2011-08-12
01 Stewart Bryant Created "Approve" ballot
2011-08-12
01 Stewart Bryant Ballot writeup text changed
2011-08-12
01 Stewart Bryant Last Call was requested
2011-08-12
01 (System) Ballot writeup text was added
2011-08-12
01 (System) Last call text was added
2011-08-12
01 (System) Ballot approval text was added
2011-08-12
01 Stewart Bryant State changed to Last Call Requested from Publication Requested.
2011-08-12
01 Stewart Bryant Last Call text changed
2011-08-05
01 Amy Vezza
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, …
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.
2011-08-05
01 Amy Vezza Draft added in state Publication Requested
2011-08-05
01 Amy Vezza [Note]: 'Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd.' added
2011-08-05
01 Matthew Bocci Changed protocol writeup
2011-08-05
01 Matthew Bocci Consensus reached at IETF81
2011-08-05
01 Matthew Bocci IETF state changed to Submitted to IESG for Publication from In WG Last Call
2011-06-10
01 Matthew Bocci WG LC closes on 24th June 2011
2011-06-10
01 Matthew Bocci IETF state changed to In WG Last Call from WG Document
2011-05-10
01 (System) New version available: draft-ietf-pwe3-mpls-tp-gal-in-pw-01.txt
2010-11-09
00 (System) New version available: draft-ietf-pwe3-mpls-tp-gal-in-pw-00.txt