Packet Pseudowire Encapsulation over an MPLS PSN
draft-ietf-pwe3-packet-pw-04

[Ballot comment]
1. In the Abstract s/is the case/in the case/

2. In Section 6 - VLANs, 802.1p and 802.1Q are not Ethernet but bridging fucntions

So I suggest the following changes:

in the title s/Ethernet/Ethernet and IEEE 802.1/

and:

OLD:

The use and applicability of Ethernet VLANs, 802.1p, and 802.1Q
  between PEs is not supported.


NEW:

The use and applicability of VLANs, IEEE 802.1p, and IEEE 802.1Q
  between PEs is not supported.

Maybe adding 'tagging' after 802.1Q would help if this is the intent.

[Ballot comment]

Sometimes I feel like people do fun things with 2119 language entirely for my entertainment when it's a document outside of my area. :-)

Seriously, these are all simply comments that I think will improve the comprehensibility of the document. I hope they help.

Section 1:

  Where the client equipment is connected to the server equipment via a
  physical interface, the same data-link type MUST be used to attach
  the clients to the Provider Edge equipments (PE)s, and a pseudowire
  (PW) of the same type as the data-link MUST be used [RFC3985].

Something is odd here. RFC3985 is Informational and is not a normative reference, and it doesn't include any MUSTs, so those requirements can't be coming from 3985 per se. And I suspect they are not new requirements in this document at all. Do you actually mean the following?

  The architecture in [RFC3985] says that, where the client equipment
  is connected to the server equipment via a physical interface, the
  same data-link type will be used to attach the clients to the Provider
  Edge (PE) equipment, and a pseudowire (PW) of the same type as
  the data-link will be used.

Also in Section 1:

  Non-normative Appendix Appendix A provides information...

This verbal tic of inserting the words "non-normative" I find completely silly. It is absolutely clear from the contents of the appendix that it is non-normative, and we're heading down the path where sections will be titled, "Non-normative Table of Contents" and "Non-normative Acknowledgements". Please remove those words.

Section 5:

  The PEs MAY use a local Ethernet address for the Ethernet header used
  to encapsulate the client network layer packet.  Alternatively the
  PEs may use the following procedure.

I found the above confusing. The first "procedure" after this is an IANA procedure, and the "may" there looks like it should be a "MAY". Perhaps instead:

  The PEs MAY use a local Ethernet address for the Ethernet header used
  to encapsulate the client network layer packet, or MAY use one of the
  special Ethernet addresses "PacketPWEthA" or "PacketPWEthB" as
  described below.

Also in section 5:

  IANA are requested to allocate two unicast Ethernet addresses
  [RFC5342] to this protocol (PacketPWEthA and PacketPWEthB).
  PacketPWEthA is the value lower Ethernet address and PacketPWEthB is
  the higher value Ethernet address.  Where [RFC4447] signalling is
  used to set up the PW, the LDP peers compare IP addresses and with
  the PE with the higher IP address uses PacketPWEthA, whilst the LDP
  peer with the lower IP address uses PacketPWEthB.

Very awkwardly worded and confusing to me. Instead maybe:

  IANA is requested to allocate [ed note: RFC Editor will change to
  "has allocated"] two unicast Ethernet addresses [RFC5342] for use
  with this protocol, referred to as "PacketPWEthA" and
  "PacketPWEthB". Where [RFC4447] signalling is used to set up the PW,
  the LDP peers numerically compare their IP addresses. The LDP PE
  with the higher value IP address will use PacketPWEthA, whilst the
  LDP peer with the lower value IP address uses PacketPWEthB.

Also in section 5:

  Not withstanding the fact that this PW represents a point-to-point
  connection, some client layer protocols require the use of a
  destination multicast address in the Ethernet encapsulation.  This
  mode of operation MUST be supported.

The passive voice in the last sentence is problematic. Do you mean, "Peers MUST be prepared to handle a destination mulitcast address in the Ethernet encapsulation"?

Section 6:

  Thus, for example, the Ethernet OAM is NOT REQUIRED.

"NOT REQUIRED" is not a 2119 term. I think you might mean "Thus, for example, a server LSR MAY choose not to use Ethernet OAM". Or you might simply mean "not required".

Appendix A:

  This appendix is non-normative.

Please strike.

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:  (Packet Pseudowire Encapsulation over an MPLS PSN) to Proposed Standard


The IESG has received a request from the Pseudowire Emulation Edge to
Edge WG (pwe3) to consider the following document:
- 'Packet Pseudowire Encapsulation over an MPLS PSN'
  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 2012-03-09. 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 a pseudowire mechanism that is used to
  transport a packet service over an MPLS PSN is the case where the
  client Label Switching Router (LSR) and the server Provider Edge
  equipments are co-resident in the same equipment.  This pseudowire
  mechanism may be used to carry all of the required layer 2 and layer
  3 protocols between the pair of client LSRs.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-packet-pw/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-packet-pw/


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

Updated write-up to reflect the change in intended status of the draft from BCP to 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?

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
received significant review by the WG and received a number
of comments during WG last call.


(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 was an alternative proposal for a mechanism to
support Packet PWs presented at a number of IETFs, that proposal has
not been adopted by the working group.


(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 related to a copyright date
and a missing reference. These should be fixed before publication.
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 a pseudowire mechanism that is used to
transport a packet service over an MPLS PSN is the case where the
client LSR and the server PE are co-resident in the same equipment.
This pseudowire mechanism may be used to carry all of the required
layer 2 and layer 3 protocols between the pair of client LSRs.

This document is a product of the PWE3 working group.

This document is Standards Track.

Working Group Summary

This draft presents a number of alternative encapsulations for a generic packet PW
that were investigated by the authors and discussed in the WG over a period of time
(these are documented in the appendix), and reaches a conclusion about which one to
use. However, an alternative approach was also proposed to the PWE3 working group by
a different set of authors in a separate draft, and progressed over a period
of a number of IETFs. A consensus call was conducted by the chairs to try to reach
agreement on how to proceed. This resulted in the Ethernet PW encapsulation
approach, specified in draft-ietf-pwe3-packet-pw-03, being adopted. WG consensus
could not be reached on the alternative approach at that time. Since
this draft documents a new way to use an existing encapsulation, the draft was
originally progressed as a BCP rather than standards track. However, it was
subsequently noted in AD review that the document makes IANA requests and therefore
version 3, which is the subject of this proto write up, has been promoted to a
standards track draft.

Document Quality

The draft uses an existing Ethernet PW type that is widely deployed. As
well as being used for interconnecting Ethernet attachment circuits, there are
implementations that directly terminate the Ethernet PW on an IP interface e.g.
on a VRF, which represents a subset of the proposal in the draft. However, direct
termination on an LSR, as shown in the draft, is not known to be widely implemented/
deployed yet, although such as model has been requested by service providers.

There are no further concerns with document quality.

The document does not specify any MIB changes or additions which would need review.

    (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 at 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
        received significant review by the WG and received a number
        of comments during WG last call.


    (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 was an alternative proposal for a mechanism to
      support Packet PWs presented at a number of IETFs, that proposal has
      not been adopted by the working group.


    (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 related to a copyright date
      and a missing reference. These should be fixed before publication.
      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 a pseudowire mechanism that is used to
  transport a packet service over an MPLS PSN is the case where the
  client LSR and the server PE are co-resident in the same equipment.
  This pseudowire mechanism may be used to carry all of the required
  layer 2 and layer 3 protocols between the pair of client LSRs.

  This document is a product of the PWE3 working group.

  This document is BCP.

Working Group Summary

  This draft presents a number of alternative encapsulations for a generic packet PW
  that were investigated by the authors and discussed in the WG over a period of time
  (these are documented in the appendix), and a reaches a conclusion about which one to
  use. However, an alternative approach was also proposed to the working group by a
  different set of authors in a separate draft, and progressed over a period
  of a number of IETFs. A consensus call was conducted by the chairs to try to reach
  agreement on how to proceed. This resulted in the Ethernet PW encapsulation
  approach, specified in draft-ietf-pwe3-packet-pw-02, being adopted and, since
  this is documenting a new way to use an existing encapsulation, it was progressed
  as a BCP rather than standards track. WG consensus could not be reached on the
  alternative approach at that time.

Document Quality

  The draft uses an existing Ethernet PW type that is widely deployed. As
  well as being used for interconnecting Ethernet attachment circuits, there are
  implementations that directly terminate the Ethernet PW on an IP interface e.g.
  on a VRF, which represents a subset of the proposal in the draft. However, direct
  termination on an LSR, as shown in the draft, is not known to be widely implemented/
  deployed yet, although such as model has been requested by service providers.

  There are no further concerns with document quality.

  The document does not specify any MIB changes or additions which would need review.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation::Point Raised - writeup needed.
AD review
====
Hi,

In addition to a question about the shepherd write-up which I sent to Matthew separately, I have a collection of small questions and nits for the authors. I think the nits are many enough to warrant a revision, and the questions might require a revision depending on the answers.

Thanks,
Adrian

---

I started reading this in the belief that this is truly a BCP and I
wrote the following:

I think it would be helpful if both the Abstract and the Introduction
(to a lesser and greater extent, respectively) noted that:
- this document does not define any new procedures or protocol elements
- this document indicates how a specific function is provided using
  existing tools and mechanisms
- this document advises the Internet community on the best current
  practice for providing a packet service over an MPLS network

However, when it comes to it, you are making to code point requests to
IANA. This isn't a BCP is it? Shouldn't it be Standards Track?

---

LSR needs to be expanded in the Abstract and para 3 of the Introduction.

---

Section 1

s/via physical interface/via a physical interface/

---

Throughout the doc

s/point to point/point-to-point/
s/point to multipoint/point-to-multipoint/
s/multipoint to multipoint/multipoint-to-multipoint/

---

Section 2

s/network is shown/network as shown/

---

Figure 1 is missing a title

---

Section 2
It is not necessary to expand PSN, but if you want to, you should do it
on first use (in section 1)

---

Section 3
                                                                   
s/layer two/layer 2/  for consistency with the rest of the doc

--

Section 7

  congestion considerations being developed for PWs apply [RFC3985],
  [RFC5659].

I think you can delete "being"

---

Section 9

I found what you have written a little open to (wilful)
misinterpretation. Which code point has which name? Couldn't you have
written:


  Dotted Decimal          Description                      Reference
  -----------------------  --------------------------------  ---------

  000.00x.000              PacketPWEthA                      [This RFC]
  000.00x.001              PacketPWEthB                      [This RFC]


Do you want to make it clear that x is open for IANA to choose?

---

Appendix A

I can see some good reasons to preserve the history of discussion,
although this is not normally done with IETF documents that are
concerned with setting out a specification on which consensus has been
reached. If you want to carry on including the Appendix, you need to do
several things:

1. Refer to it in the body of the text. I think this is most easily done
  from the Introduction.

2. State in the Appendix why it is included. You do a good job of saying
  what is in the Appendix, but not why the Appendix is there and what
  the reader is supposed to gain from it.

3. Make it clear (in the Appendix) that it is non-normative.

    (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
        received significant review by the WG and received a number
        of comments during WG last call.


    (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 was an alternative proposal for a mechanism to
      support Packet PWs presented at a number of IETFs, that proposal has
      not been adopted by the working group.


    (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 related to a copyright date
      and a missing reference. These should be fixed before publication.
      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 a pseudowire mechanism that is used to
  transport a packet service over an MPLS PSN is the case where the
  client LSR and the server PE are co-resident in the same equipment.
  This pseudowire mechanism may be used to carry all of the required
  layer 2 and layer 3 protocols between the pair of client LSRs.

  This document is a product of the PWE3 working group.

  This document is BCP.

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.

Document shepherd write-up:

draft-ietf-pwe3-packet-pw-02.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
        received significant review by the WG and received a number
        of comments during WG last call.


    (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 was an alternative proposal for a mechanism to
      support Packet PWs presented at a number of IETFs, that proposal has
      not been adopted by the working group.


    (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 related to a copyright date
      and a missing reference. These should be fixed before publication.
      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 a pseudowire mechanism that is used to
  transport a packet service over an MPLS PSN is the case where the
  client LSR and the server PE are co-resident in the same equipment.
  This pseudowire mechanism may be used to carry all of the required
  layer 2 and layer 3 protocols between the pair of client LSRs.

  This document is a product of the PWE3 working group.

  This document is BCP.

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.

Document shepherd write-up:

draft-ietf-pwe3-packet-pw-02.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
        received significant review by the WG and received a number
        of comments during WG last call.


    (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 was an alternative proposal for a mechanism to
      support Packet PWs presented at a number of IETFs, that proposal has
      not been adopted by the working group.


    (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 related to a copyright date
      and a missing reference. These should be fixed before publication.
      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 a pseudowire mechanism that is used to
  transport a packet service over an MPLS PSN is the case where the
  client LSR and the server PE are co-resident in the same equipment.
  This pseudowire mechanism may be used to carry all of the required
  layer 2 and layer 3 protocols between the pair of client LSRs.

  This document is a product of the PWE3 working group.

  This document is BCP.

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.