An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks
draft-ietf-mpls-tp-oam-analysis-09

[Ballot comment]
- Thanks for this document, and specifically for the tables in section 4, as it's difficult to find his way in a world full of MPLS OAM RFCs (requirements, framework, Fault specific, Packet Loss and Delay, you name it ). Along the same lines, I welcome http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-06, which has got a broader scope.

-

  o  The OAM toolset developed for MPLS based transport networks needs
      to be fully inter-operable with existing MPLS OAM tools as
      documented in [RFC 5860].

Are you referring to http://tools.ietf.org/html/rfc5860#section-2.1.6

  When MPLS-TP is run with IP routing and forwarding capabilities, it
  MUST be possible to operate any of the existing IP/MPLS and PW OAM
  protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [5], and VCCV-BFD
  [14]).

The document would benefit from clearly identifying what you mean.

This is even more confusing because you mention just below:
  The MPLS-TP OAM toolset is based on the following existing tools:

  o  LSP-Ping as defined in [RFC 4379].

  o  Bidirectional Forwarding Detection (BFD) as defined in [RFC 5880]
      and refined in [RFC 5884].

  o  ITU-T OAM for Ethernet toolset as defined in [Y.1731].  This has
      been used for functionality guidelines for the performance
      measurement tools that were not previously supported in MPLS.

  It should be noted that certain extensions and adjustments have been
  specified relative to the existing MPLS tools, in order to conform to
  the transport environment and the requirements of MPLS-TP.  However,
  compatibility with the existing tools has been maintained.

"compatibility with the existing tools has been maintained" I guess that you meant the list above: LSP-Ping, BFD, Y.1731. So what about the delta from my previous point: VCCV, and VCCV-BFD?

[Ballot comment]

(Oops wrong button, I've no objection really:-)

- draft-ietf-mpls-tp-security-framework-02, May 2011 was
updated by a -03 in October 2011.

- weird references, the spaces muck up tools:
[MPLS TP ITU Idents]
[MPLS-TP Security Frwk]

- s/MPSL-TP/MPLS-TP/ maybe?

[Ballot comment]
- draft-ietf-mpls-tp-security-framework-02, May 2011 was
updated by a -03 in October 2011.

- weird references, the spaces muck up tools:
[MPLS TP ITU Idents]
[MPLS-TP Security Frwk]

- s/MPSL-TP/MPLS-TP/ maybe?

[Ballot comment]
Section 8., paragraph 3:

>    Thanks to Rui Costa for his review and comments which helped improve
>    this doecument.

  s/doecument/document/

[Ballot comment]
-- Section 7 --
  In addition to implement security protocol, tools, and mechanisms,
  following strict operation security procedures is very important,
  especially MPSL-TP static provisioning processes involve operator
  direct interactions with NMS and devices, its critical to prevent
  human errors and malicious attacks.

This paragraph needs to be turned into more understandable English.  I'd offer, but I don't understand what it's trying to say well enough to do it (hence, this comment).  I suggest that it needs to be two or three sentences, rather than just one, and the grammar needs to be corrected so it's clear what it's saying.  [I note that the rest of the document is fine to read; it's only this section that has any notable problem.]

The next paragraph also has a couple of minor grammatical errors, but it's understandable:
OLD
  Since MPLS-TP OAM uses G-ACh, the security risks and mitigation
  described in [RFC 5085] apply here.  In short, the G-ACh could be
  intercepted, or false G-ACh packets could be inserted.  DoS attack
  could happen by flooding G-ACh messages to peer devices.  To mitigate
  this type of attacks, throttling mechanisms can be used.  For more
  details, please see [RFC 5085].
NEW
  Since MPLS-TP OAM uses G-ACh, the security risks and mitigation
  described in [RFC 5085] apply here.  In short, the G-ACh could be
  intercepted, or false G-ACh packets could be inserted.  DoS attacks
  can be mounted by flooding G-ACh messages to peer devices.  To
  mitigate this type of attack, throttling mechanisms can be used.
  For more details, please see [RFC 5085].

[Ballot comment]
Muly Ilan raised the following points on the MPLS list. They should
be looked at:

> 1. Table 2, second row - only Lock Instruct is G-Ach based. Loopback
>    is a management command.
>
> 2. Table 2, second row - LSP Ping is not related to Lock Instruct or
>    loopback command.
>
> 3. Table 2, third row - Lock Instruct is not indicated by a flag in
>    AIS message and is not discussed in RFC6427.
>
> 4. Section 5.2, third paragraph - need rewriting, per RFC6435
>    there's no loopback request message nor loopback response message.

[Ballot comment]
Muly Ilan raised the following points on the MPLS list. They should be looked at:

> 1. Table 2, second row – only Lock Instruct is G-Ach based. Loopback is a management command.
>
> 2. Table 2, second row – LSP Ping is not related to Lock Instruct or loopback command.
>
> 3. Table 2, third row – Lock Instruct is not indicated by a flag in AIS message and is not discussed in RFC6427.
>
> 4. Section 5.2, third paragraph – need rewriting, per RFC6435 there’s no loopback request message nor
>      loopback response message.

[Ballot comment]
Muly Ilan raised the following points on the MPLS list. They should be looked at:

> 1. Table 2, second row – only Lock Instruct is G-Ach based. Loopback is a management command.
> 2. Table 2, second row – LSP Ping is not related to Lock Instruct or loopback command.
> 3. Table 2, third row – Lock Instruct is not indicated by a flag in AIS message and is not discussed in RFC6427.
> 4. Section 5.2, third paragraph – need rewriting, per RFC6435 there’s no loopback request message nor
>      loopback response message.

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:  (An Overview of the OAM Tool Set for MPLS based Transport Networks) to Informational RFC





The IESG has received a request from the Multiprotocol Label Switching WG

(mpls) to consider the following document:

- 'An Overview of the OAM Tool Set for MPLS based Transport Networks'

  as an Informational RFC



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-23. 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 provides an overview of the OAM toolset for MPLS based

  Transport Networks.  The toolset consists of a comprehensive set of

  fault management and performance monitoring capabilities (operating

  in the data-plane) which are appropriate for transport networks as

  required in RFC 5860 and support the network and services at

  different nested levels.  This overview includes a brief recap of

  MPLS-TP OAM requirements and functions, and of generic mechanisms

  created in the MPLS data plane to allow the OAM packets run in-band

  and share their fate with data packets.  The protocol definitions for

  each of the MPLS-TP OAM tools are defined in separate documents (RFCs

  or Working Group drafts) which are referenced by this document.





The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-analysis/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-analysis/ballot/





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

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
AD review

---------------

Hello,

I have done my AD review of your draft. I have a list of small edits
I would like you to make before we issue the IETF last call.

I will wait for a new revision.

Thanks,
Adrian

---

You have included the pre-November 2008 copyright statement. The first
version was posted after November 2008. Do you really need this
statement?

---

Please clean up the unused reference [RFC 4385]

---

In Section 2

  It is recommended that any protocol solution, meeting one or more                                     
  functional requirement(s), be the same for PWs, LSPs, and Sections.

Is this recommendation made by this document or by the referenced
RFC 5860? If the latter, can you make this clear. If the former, I am
not sure of the context for your recommendation.

---

In Section 2

  The following document-set addresses the basic requirements listed
  above:

The third bullet does not seem to cite a document.

---
         
Section 4

This section contains

  Editor's note:
   
      Only RFCs will be referenced in the final version of the document.

Can you remove this now?

You then have...

  The following table (Table 1) provides the summary of proactive
  MPLS-TP OAM Fault Management toolset functions, associated tool/
  protocol, and the corresponding IETF RFCs or Internet drafts where
  they are defined.

There are no I-Ds in the table. Same applies to the text about each of
other tables.

Also, in the three tables you have a column headed "RFCs / Internet
Drafts". Again, there are no I-Ds in the tables.

---

Section 5.4

  The protocols for Alarm Indication Signal (AIS) and A Link Down
  Indication (LDI) are defined in [RFC 6427].

s/A/a/

---

Section 5.5

  The RDI OAM function is supported by the use of Bidirectional
  Forwarding Detection (BFD) Control Packets [RFC 6428???].  RDI is
  only used for bidirectional connections and is associated with
  proactive CC-CV activation.

Please resolve "???"

---

Section 7

I think you might summarise the security available for the different OAM
mechanisms and the issues that don't need to be addressed because of the
OAM running on the ACH.

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

Ross Callon is the document shepherd for this document. He has read the most recent -07 version, and feels that the document 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? 

No concerns. This informational document has been extensively reviewed, and has been updated in response to comments received including WG last call comments.

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

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

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

The document has broad support in the working group.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?

No threats.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits?

The document passes nits with no problems.

  (1.h) Has the document split its references into normative and
        informative?

References are split appropriately. All normative references are already published as RFCs. Since this document is informational, downrefs are not applicable.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document?

The document contains a null IANA section, which is appropriate.

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

Not Applicable (there are no such sections).

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. The approval announcement contains
        the following sections:

    Technical Summary

This document provides an overview of the OAM toolset for MPLS based Transport Networks.  The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data-plane) which are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels.  This overview includes a brief recap of MPLS-TP OAM requirements and functions, and of generic mechanisms created in the MPLS data plane to allow the OAM packets run in-band and share their fate with data packets.  The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group drafts) which are referenced by this document.

    Working Group Summary

This informational document has passed working group last call with clear consensus in favor of publication.

    Document Quality

This is an informational document which is not subject to be implemented. It provides description of and pointers to other documents, for which there are multiple current implementations and/or implementations in progress.