Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping
draft-ietf-pwe3-oam-msg-map-16

[Ballot comment]
I have updated my Comment for revision 15. Thank you for addressing the nits I had raised.

I have one new Comment that is moved here from a former Discuss...

I appreciate the change wrt MS-PW
I would prefer
OLD
  While this document is worded in terms of single segment PWs, its
  content also applies to T-PEs for MS-PWs ([RFC5254]).  Section 10 of
  [RFC6073] details procedures for generating or relaying PW status by
  an S-PE.
NEW
  This document is scoped only to single segment PWs. The mechanisms
  described in this document could also be applied to T-PEs for MS-PWs
  ([RFC5254]).  Section 10 of [RFC6073] details procedures for generating
  or relaying PW status by an S-PE.
END

[Ballot discuss]
I have updated my Discuss for revision 15. Thanks for the work so far: significant improvements that clear all but one point in my Discuss.

---

idnits still reports an old license statement). I think the license statement should be fixed and posted (to reflect the authors' intent) before the document is approved.

> == You're using the IETF Trust Provisions' Section 6.b License Notice from
>    12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
>    http://trustee.ietf.org/license-info/)

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:  (Pseudowire (PW) OAM Message Mapping) to Proposed Standard


The IESG has received a request from the Pseudowire Emulation Edge to
Edge WG (pwe3) to consider the following document:
- 'Pseudowire (PW) OAM Message Mapping'
  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-01-24. 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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-oam-msg-map/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-oam-msg-map/

This is a second IETF Last call.

The purpose of this second last call is to draw the attention of the IETF to the IPR disclosures. There are two disclosures: #863 (https://datatracker.ietf.org/ipr/863/) and #1311 https://datatracker.ietf.org/ipr/1311/

IPR disclosure #1311 states that this particular disclosure "has been removed at the submitter's request."
IPR disclosure #863 is still active.

[Ballot comment]
Section 3                 
s/whereby/where/

---

The Introduction uses a number of acronyms without prior expansion.
On the other hand, having defined acronyms in Section 4.1, you don't
gave to expand them in subsequent sections.

---

Section 4.1
Several acronyms are not used in the rest of the document.
BDI
CPCS
IWF

s/label Switched Path/Label Switched Path/
s/Operations, Administration and Maintenance/
  Operations, Administration, and Maintenance/

---

Section 4.2

  The words "defect" and "fault" are used interchangeably to mean any
  condition that obstructs forwarding of user traffic between the CE
  endpoints of the PW service.

I'm fine with this, but I think "obstructs" is ambiguous. Do you mean
"impose a complete blockage", or do you mean to include degradation in
some form? Perhaps you could add a clarification.

---

Section 4.2

  If BFD is run over a PW as
  described in [RFC5885], it will be referred to as "VCCV-BFD".

Add a reference to [RFC5880]

---

Section 4.2

  A "transmit defect" is any defect that impacts traffic that is meant
  to be sent or relayed by the observing PE.  A "receive defect" is any
  defect that impacts traffic that is meant to be received by the
  observing PE.

While "meant to be" is appropriate for the reception of data, I don't
think it necessarily applies to transmission. Consider that the defect
may be somewhat downstream of (and not yet notfied to) the upstream PE
such that the traffic that is impaced is that which *has* been sent or
relayed by the observing PE.

Additionally, the term "observing PE" has not been defined and may
clarify or complicate the meaning of the text.

---

I had a few problems with Section 8.1. I think my issue is with the
use of the control plane as an OAM exchange mechanism (this also shows
up in Appendix B). I believe the section could benefit from some
polishing.

  For MPLS and MPLS/IP PSNs, a PE that establishes a PW using Label
  Distribution Protocol [RFC3036] MUST use the LDP status TLV as the
  mechanism for AC and PW status and defect notification, as explained
  in [RFC4447].

I don't think that this "MUST" is good or consitent with:
- the text in Section 7 that is relaxed in saying "LDP or in the ACH"
- the work in MPLS-TP

It sounds like 3036 (or rather 5036) is a normative reference.

While conveying PW status in LDP per 4447 is fine, it is not OAM with
the utility of rapid propagation of fault notifications. LDP, reliant
as it is on TCP, is not suitable to that purpose.

Wouldn't it be better to require the use of the ACH for OAM fault
notification messages, and (if you must :-) mandate the use of LDP
for status information propagation when LDP is present (but not as a
replacement for real OAM).

Additionally...

  Additionally, a PE MAY use VCCV-BFD Connectivity
  Verification (CV) for fault detection only (CV types 0x04 and 0x10
  [RFC5885]) but SHOULD notify the remote PE using the LDP Status TLV.
                                                                               
The "SHOULD" here seems to be in conflict with te previous "MUST"

And it goes on...

  A PE that establishes a PW using means other than LDP, e.g., by
  static configuration or by use of BGP, MAY use VCCV-BFD CV (CV types
  0x08 and 0x20 [RFC5885]) for AC and PW status and defect
  notification.  Note that these CV types SHOULD NOT be used when the
  PW is established with the LDP control plane.

If you supply only a "MAY" you should probably describe how else the
fault notification might work.

As to the "SHOULD NOT" in the last sentence. Well, see my previous
comments. And what possible harm could it do?

--- 

Section 6

  Generally, a PE cannot detect transmit defects directly and will
  therefore need to be notified of AC transmit or PW transmit defects
  by other devices.

I think you mean s/directly/direct/

---

Section 8.1.1
                                                                         
  [RFC4447] specifies that the "Pseudowire forwarding" code point is
  used to clear all faults.  It also specifies that the "Pseudowire Not
  Forwarding" code is used to convey any defect that cannot be
  represented by the other code points.

The language seems rather week.
The use of the code point does not clear the faults. It is used to
report (notify) that the faults have been cleared.
Likewise, defects are not conveyed by the use of a control points, but
existence of the defect can be reported (or conveyed, if you like).

[Ballot discuss]
There are a couple of nits reported by idnits (an out of date reference,
an old license statement). I think the license statement should be
fixed and posted (to reflect the authors' intent) before the document is
approved.

---

I see IPR disclosed at http://datatracker.ietf.org/ipr/863/
I don't see this declared in the proto write-up. More important, it is
not present in the IETF last call announcement in datatracker.

---
                                                                                           
What is the situation wrt multi-segment PWs? I can understand that this
document was developed before the WG turned to MS-PWs, but we now have
RFC 5254 and RFC 5659.

I would prefer that this document fully addressed MS-PWs. That would not
be hard because each PW segment at an S-PE regards the adjacent segments
as ACs, so it could probably be addressed in just one or two paragraphs
in a new section.

However, an option is to declare MS-PW out of scope, and provide a
forward reference to work being done on OAM message mapping for MS-PWs
in the PWE3 WG.                                                                 

---

Section 4.2

  If LSP-Ping [RFC4379] is run over a PW as described in [RFC4377], it
  will be referred to as "VCCV-Ping".

I believe s/RFC4377/RFC5085/

---

Section 5
                                                                                                         
You should add a note to explain why the CE ends of the ACs are not
considered as possible defect locations. They are part of the emulated
service, so a naif reader might expect to see them listed. Possibly you
will want to explicitly include it in case (a).

Additionally, your text does not match the figure:
  c. Defect on a PE1 PSN interface.
But (c) also appears on the PE2-PSN interface in the figure.

Furthermore, (e) and (f) appear tbe reversed in the figure compared to
the text.

---

Section 13

RFC 5085 and RFC 4447 should be presented as references.

I will let Security experts comment further, but:

It seems to me that facilitating end-to-end coordination of PW status
and fualt reporting provides an extra tool for attackers. I would
expect this to be pointed out and held up as a reason for ensuring the
use of the security mechanisms.

I think that there are security coordination issues. Perhaps these are
already mentioned in the references. Consider carrying NS OAM from CE
to CE across the PSN in Single Emulated OAM Loop mode or Coupled OAM
Loops mode. The security relationship perceived by the CEs would
presumably be between each other, but doesn't the PE need to
participate?

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:  (Pseudowire (PW) OAM Message Mapping) to Proposed Standard


The IESG has received a request from the Pseudowire Emulation Edge to
Edge WG (pwe3) to consider the following document:
- 'Pseudowire (PW) OAM Message Mapping'
  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 2010-12-13. 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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-oam-msg-map/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-oam-msg-map/

Document Shepherd Write-Up for draft-ietf-pwe3-oam-msg-map-14.txt

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

Andrew Malis, andrew.g.malis@verizon.com

Yes, I have reviewed the document and I believe it is ready for forwarding
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?

Yes, the document has received adequate discussion and review. The document
went through two last calls in the PWE3 working group, the second to review
changes made from the first last call, and no comments were received on the
second 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 concerns or issues.

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

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize 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?

The id-nits service on the tools site is broken as I write this, so I'm
unable to personally test for id-nits. However, the draft was uploaded
successfully by the author, so it must have passed id-nits at that time.
This document is not subject to MIB doctor or other reviews.

(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. All of the normative references
are to published RFCs and ITU-T recommendations, with no downrefs.

(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. It does not request any IANA
actions.

(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 specifies the mapping and notification of defect states
between a pseudowire (PW) and the Attachment Circuits (ACs) of the
end-to-end emulated service. It standardizes the behavior of Provider Edges
(PEs) with respect to PW and AC defects. It addresses ATM, Frame Relay, TDM,
and SONET/SDH PW services, carried over MPLS, MPLS/IP and L2TPV3/IP Packet
Switched Networks (PSNs).

This document is a product of the PWE3 working group.

This document is intended for the standards track.

Working Group Summary

One of the work items in the PWE3 Working Group Charter is to "Specify
Operations and Management (OAM) mechanisms for all PW types, suitable for
operation over both IP/L2TPv3 and MPLS PSNs, and capable of providing the
necessary interworking with the OAM mechanisms of the emulated service."
This document addresses this work item for ATM, Frame Relay, TDM, and
SONET/SDH pseudowires. A separate document will address Ethernet
pseudowires.

Document Quality

There are no concerns about document quality.

Personnel

Who is the Document Shepherd for this document?

Andrew Malis, andrew.g.malis@verizon.com

Who is the Responsible Area Director?

Stewart Bryant