MPLS Fault Management Operations, Administration, and Maintenance (OAM)
draft-ietf-mpls-tp-fault-07

[Ballot comment]
Section 2.1:

  The MPLS Alarm Indication Signal (AIS) message is generated in
  response to detecting faults in the server (sub-)layer.  The AIS
  message SHOULD be sent as soon as the condition is detected, but MAY
  be delayed owing to processing in an implementation, and MAY be
  suppressed if protection is achieved very rapidly.

Those "MAY"s aren't protocol options, they're exceptions to the SHOULD. How about instead, "The AIS message SHOULD be sent as soon as the condition is detected, with the obvious exceptions being delay owing to processing in an implementation or complete supression if protection is acheived rapidly."

  The primary purpose of the AIS message is to suppress alarms in the
  layer network above the level at which the fault occurs.  When the
  Link Down Indication is set, the AIS message MAY be used to trigger
  recovery mechanisms.

Do you really mean "MAY" here, or rather "can"? Who are you telling that they MAY use the AIS message as the trigger, the implementer of the recovery mechanism (in which case it might be right) or others who need to be aware that recovery mechanisms might be triggered (in which case it is wrong).

Section 2.2: Similar use of MAY as above. Please check.

[Ballot comment]
Section 8.4 indicates that it will use the term "Private Use", but doesn't. It does use "Experimental Use" - should the first paragraph have called that out instead?

[Ballot comment]
Hopefully IANA knows what to do, but the note in Section 8.1 is not clear to me.

>    [Note: An early codepoint allocation was made: 0x0058 Fault OAM
  (TEMPORARY - expires 2012-07-20)]

Do the authors request to transform this temporary codepoint allocation to a permanent one?

In any case the  Note needs to be taken out at document publication.

[Ballot comment]
Please specify whether the refresh timer can include fractional seconds.

Please specify the byte order of the longer fields; typically this is network byte order (i.e., most significant byte first), but not always.

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:  (MPLS Fault Management OAM) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'MPLS Fault Management OAM'
  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-09-16. 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 specifies Operations, Administration, and Maintenance
  messages to indicate service disruptive conditions for MPLS based
  Transport Network Label Switched Paths.  The notification mechanism
  employs a generic method for a service disruptive condition to be
  communicated to a Maintenance Entity Group End Point.  This document
  defines an MPLS OAM channel, along with messages to communicate
  various types of service disruptive conditions.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-fault/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-fault/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1460/

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
Hi,

I have performed my usual AD review before passing your document on for IETF last call and IESG review.

Unfortunately, I have found a remarkable number of nits and minor typos. Fortunately, most of them should be very easy to fix.

Mixed in, I have found a number of small issues and concerns. Where possible, I have supplied suggested resolution, and in all cases I do not believe that the way forward requires substantial change to the document.

Nevertheless, a new revision of the draft is needed before we can take it forward.

Thanks,
Adrian

===

Do you really need a normative reference to RFC 5920? Its use in
Section 7 does not appear normative to me.

---

Please replace /draft/document/ in the Abstract

---
   
The correct name for a MEP is
    MEP  Maintenance Entity Group End Point
as you capture in Section 1.1
So the Abstract is wrong.

Huub is in the process of fixing draft-ietf-mpls-tp-rosetta-stone to
be consistent in these definitions.

---

Please use the RFC 6291 expansion of OAM
    OAM - Operations, Administration, and Maintenance

In the Abstract you are missing the plural from "Operations"
In Section 1.1 you are missing the comma.

---

Please try to expand acronyms on first use.
In the Abstract you expand OAM on second use.
In Section 1 you use OAM unexpanded.

---

Please avoid the passive voice. In the Abstract...

  An MPLS Operation, Administration, and Maintenance
  (OAM) channel is defined along with messages to communicate various
  types of service disruptive conditions.

"Is defined" by whom and where?

I think you need: "This document defines..."

In Section 1

  This capability is being defined to meet
  the MPLS-TP requirements as defined in RFC 5654 [1], and the MPLS-TP
  Operations, Administration and Maintenance Requirements as defined in
  RFC 5860 [2].

Again, "This document defines FM capabilities..."

---

Section 1

  When an event that
  causes disruption occurs on any link or node along the path of such a
  transport circuit, OAM indications are generated which may in turn
  suppress alarms and/or activate a backup circuit.

Pedantically, but I think with some importance, the OAM indication does
not suppress the alarms and does not activate a backup circuit. The OAM
indication is an input to a control module and may act as a trigger for
these behaviors.

---

Fault and Defect

The definitions here are at odds with draft-ietf-mpls-tp-rosetta-stone-
04 and are also a little confusing.

It looks like the definition of Fault that you have is identical to the
definition of Defect in the Rosetta Stone.

For Defect you have:

  Within the Fault class, a further category, Defect is identified.  A
  defect is the inability of a function to perform a required action.
  A defect is a persistent fault.

I am not clear what it means for "a function to perform a required
action" as distinct from "the ability to perform a required function
has been interrupted." Are functions performed, or do functions perform
actions?

Anyway, "A defect is a persistent fault" would be very clear if I didn't
wonder about the meaning of "persistent".

---
                                                                     
Section 1.1

LSR and S-PE are not used in the document

---

Section 2
                                                                                               
  This document defines messages to indicate service disruptive
  conditions.  Two messages are defined, Alarm Indication Signal, and
  Lock Report.

A few superfluous words.

---

What purpose is served by the last paragraph of section 2?
As far as I can see this text is an attempt to include a piece of ITU-T
architecture. Do we need it?
                                                                         
The question comes up because I am very uncomfortable with the
architectural concept! It is a bit of squirming developed in order that
a MIP should not originate messages, but it is a layer violation in one
way or another. There are two possibilities: the adaptation function is
part of the client layer or part of the server layer. If it is part of
the server layer, then the server layer is aware of the client payload
type and is not performing a transport function (i.e., it is not
completely unaware of the payload). If the adaptation function is part
of the client layer then the MEP does not contain the adaptation
function since the MEP is in the server layer.
                                                                       
I think, in practice, the server layer MEP generates an indication to
the client layer, and the client layer is responsible for generating the
appropriate OAM message and inserting it into the stream.

Maybe this debate is best avoided in this document. Frankly, who cares
which piece of the architecture is responsible for this function? This
is a protocol specification. Let's just stick to stating which node
builds what message.

Unfortunately, some of this issue percolates into other sections of the
document where it is stated that the server MEP generates client layer
messages.


---

Section 2.1

I quote the whole section

  The MPLS Alarm Indication Signal (AIS) message is generated in
  response to detecting faults in the server (sub-)layer.  The AIS
  message SHOULD be sent as soon as the condition is detected.  For
  example, an AIS message may be sent during a protection switching
  event and would cease being sent (or cease being forwarded by the
  protection switch selector) if the protection switch was successful
  in restoring the link.

  The primary purpose of the AIS message is to suppress alarms in the
  layer network above the level at which the fault occurs.  When the
  Link Down Indication is set, the AIS message MAY be used to trigger
  recovery mechanisms.

1. "SHOULD be sent as soon as..."
  Under what circumstances MAY the message not be sent as soon as...

2. "an AIS message may be sent during"
  Is that "MAY"?

3. "an AIS message may be sent during a protection switching
  event and would cease being sent (or cease being forwarded by the
  protection switch selector) if the protection switch was successful         
  in restoring the link."
  What do you mean "during a protection switching event"? Are you trying
  to say that if server layer protection switching is in place it is
  possible that a server layer fault will be detected and AIS will be
  sent, but that the server layer may repair the server layer connection
  (perhaps through protection switching) causing the defect to clear and
  AIS messages to cease being sent? If this is what you are trying to
  say, you should probably explain why it is interesting (because the
  client layer might want to soak associated events such as CC failures,
  before undertaking its own recovery actions).

4. "The primary purpose of the AIS message is to suppress alarms in the
  layer network above the level at which the fault occurs."
  This statement (and others about alarm suppression in the document) is
  entirely without context. Probably you need to include a brief
  statement somewhere in Section 1 about what is going on, viz.
  The server layer detects a fault and reports it as an alarm to the
  management system and as a fault to the client layer. Each client
  layer LSP will also detect a fault at the client layer and would
  normally raise an alarm leading to a storm of client layer alarms.
  The AIS message, sent as a result of the server layer fault report, is
  delivered to the client layer MEPs on each client layer LSP before or
  within a short period after the client layer LSPs each detect their
  own faults, and so the client layer alarms can be suppressed. In this
  model, a storm of client layer alarms is traded for a storm of client
  layer AIS messages.

---

Section 2.1.1 has some icky passive voice.
L flag is set by whom?

  For example during a
  protection switching event the L-flag is not set

Can you clarify that as a server layer protection switching event?
                                                                         
---
                                                                                     
Section 2.1.1

  Note again
  that the L-flag is not until a defect has been declared.

s/is not/is not set/

---
                                                                   
What can you tell me about a manual switch-over or a protected server
layer connection? Does this use AIS with L-bit clear, or does it use
LKR? In either case, the fault would be cleared pretty fast.

---

2.3.  Propagation of MPLS Fault Messages

  If the CC function is disabled, a MEP SHOULD generate AIS messages
  toward any client when either the AIS or LKR indication is raised.
  Note that the L-flag is not automatically propagated.  The rules of
  Section 2.1.1 apply.  In particular, the L-flag is not set until a
  defect has been declared.

Is this talking about CC in the client or server layer?
How would the MEP (in the server layer) or a MIP in the client layer
know the status of CC in the client layer?
I think this text is ambiguous (and possibly unhelpful).
Can you rewrite or delete?

---

Section 3

  code point = 0xHH

You use 0xHH notation several times, but Section 8.1 uses 0xHHHH

----

Section 3

  Note: An early codepoint
  allocation has made: 0x0058 Fault OAM (TEMPORARY - expires
  2012-07-20)]

Can you move this to Section 8.1
s/has/was/

---

Section 4

It would be nice to order the text in the same way as the fields in the
message.

---

Section 4

It seems to me really odd to be having a version within a version.
Couldn't a new version simply burn a new ACH Type?

---

Section 4

  Total TLV Length

      The total TLV length is the total of all included TLVs.

In bytes?                                 

---

Section 4

      R-flag

        The R-flag is normally set to zero.  A setting of one indicates
        the removal of a previously sent FM condition.

Normal depends on your frame of reference. Some people come from rural
West Virginia!

Can you say:

      R-flag

        The R-flag is clear t indicate the presence of an FM condition
        and is to one to indicate the removal of a previously sent FM
        condition.

---

Section 5.2

  Ceasing to send FM messages will clear the indication after 3.5 times
  the refresh timer.  To clear an indication more quickly, the
  following procedure is used.  The R-flag of the FM message is set to
  one.  Other fields of the FM message SHOULD NOT be modified.  The
  message is sent immediately and then retransmitted two more times at
  an interval of one second.

Ouch!

Suppose the fault recurs before the last retransmission has been sent?
Since you are not using fault sequence numbers or timestamps, you MUST
stop retransmitting the fault clear indication if the fault reappears.

Similarly, when clearing a fault, you MUST stop sending any fault
indication retransmissions.

This is "obvious to one skilled in the art" but your spec actually
appears to say otherwise.

---

Section 5.3

Unless you retire the Ver field (see above) its section needs to say what
to do if the version is not supported.

---

Section 5.3

  If the R-flag is set to zero, the MEP checks to see if a condition
  matching the message type and IF_ID exists.  If it does not, the
  condition to the message type is entered.  An expiration-timer is set
  to 3.5 times the refresh timer.  If the message type and IF_ID match
  an existing condition, message is considered a refresh and the
  expiration-timer is reset.

s/condition to the message/condition specific to the message/

s/message is/the message is/

Note that you said that IF_ID is an optional TLV if the R-flag
procedures are not going to be used. Should you describe what happens if
the IF_ID is not included? Or maybe you should cut out one of the
options such that either R-flag is always used or (more likely) IF_ID is
always mandatory.

Or, perhaps the check is actually on the tuple
{source node, LSP, message type, [IF_ID]}

---                                   

Section 6

  The following items are optional to implement.

s/optional/OPTIONAL/

---

Section 6

  2.  Support of setting the L-flag to indicated a defect.

s/indicated/indicate/

---

Section 6

OLD
  1.  Sending AIS and LKR message with other values of the Refresh
      Timer other than 1 second.
NEW
  1.  Sending AIS and LKR message with values of the Refresh Timer
      other than 1 second.

---

Section 7

OLD
  Thus, there is no simple way of
  preventing any traffic being carried between in the G-ACh consenting
  nodes.
NEW
  Thus, there is no simple way of
  preventing any traffic being carried in the G-ACh between consenting
  nodes.

---

Section 7

  It should be noted that the G-ACh is essentially connection-oriented
  so injection or modification of control messages specified in this
  document require the subversion of a transit node.

s/require/requires/

---

Section 7

  However, since these messages are carried in a control
  channel, except of one case discussed below

s/of/for/

---

Section 7

  If external MPLS traffic is mapped to an LSP via a PHP forwarding
  operation, it is possible to insert a GAL label followed by a fault
  OAM message.  In such a situation an operator SHOULD filter any fault
  OAM messages with the GAL label at the top of the label stack.

s/GAL label/GAL/  (twice)
s/SHOULD filter/SHOULD protect against this attack by filtering/

---

Section 8

Shouldn't you have a registry for MPLS Fault Management Message flags?
       
---

Section 8.2

  This sections details the MPLS Fault OAM TLV Registry, a new name
  spaces to be managed by IANA.

s/sections/section/
s/spaces/space/

---

Section 8.2                                                               
                                                                         
  MPLS Fault OAM Message Types take values in the range 0-255.
  Assignments in the range 0-251 are via Standards Action; values in
  the range 251-255 are for Private Use, and MUST NOT be allocated.

  Message Types defined in this document are:

      Msg Type          Description
      --------          -----------------------------
        0x0              Reserved

1. What does "Reserved" mean?
  IANA will need to know whether this is available for allocation or
  not. If it is not available I suggest you write...
  "Reserved (not available for allocation)"
  But, if this is the case, you need to explain to me why the range is
  0-255 and why zero is not available.

2. I am *extremely" wary of "private use" in this context. This is an
  end-to-end (or at least middle-to-end) protocol, yet you are
  suggesting site-specific usage. There is no way for the receiver of
  one of these messages to easily work out which site has transmitted.

  Can you explain what you have in mind?

---

Section 8.3

  This sections details the MPLS Fault OAM TLV Registry, a new name
  spaces to be managed by IANA.

s/sections/section/
s/spaces/space/

---

Section 8.3

  MPLS Fault OAM TLVs which take values in the range 0-255.
  Assignments in the range 0-191 are via Standards Action; assignments
  in the range 192-248 are made via "Specification Required"; values in
  the range 248-255 are for Private Use, and MUST NOT be allocated.

  TLVs defined in this document are:

      Value    TLV Name
      -----    -------
          0    Reserved
          1    Interface Identifier TLV
          2    Global Identifier

Same questions as for the message types with the additional question of
why you felt the need for Specification Required code points.

(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.
He has reviewed the document and believes it is ready to be
forwarded 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?

The document has been through the review process for mpls-tp
documents, meaning that in addition to the reviewed in the mpls
working group, it has also been reviewed the ITU-T SG15. All
comments in the working group last has been addressed by the authors
and a one week call held to verify that the comments been correctly
understood and addressed.

The shephered is convinced that this is sufficient review for this
framework document.


(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 such concerns. There is one IPR claim for this draft, this should
be pointed out in the IETF last call.

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

There is a good consensus around this draft, it has been through working
group last call. The last call was brought to the notice of SG15 in ITU-T
who reviewed the document. It has also passed a working group call to verify
that LC comments were correctly with minor comments. The comments has been
carefully discussed between the authors and people making the comments and
has been 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.)

No threats or extreme discontent.

(1.g) Has the Document Shepherd personally verified that the
    document satisfies all ID nits? (See the Internet-Drafts Checklist
    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?

check!!

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

References are correctly split.

All documents that are normatively referenced are in IESG review or
published RFCs.


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

There is a clear and concise IANA section in this document. Two new
IANA registries are defined and one new Associated Channel Type is
requested from the Pseudowire Associated Channel Type registry.


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

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

  In traditional transport networks, circuits such as T1 lines are
  typically provisioned on multiple switches. When an event that
  causes disruption occurs on any link or node along the path of
  such a transport circuit, OAM indications are generated which may
  suppress alarms and/or activate a backup circuit. The MPLS based
  Transport Network requiremetns states that mechanisms equivalent
  to traditional transport circuits. Therefore a Fault Management
  (FM) capability is defined for MPLS. This capability is being
  defined to meet the MPLS-TP requirements in RFC 5654 [1], and the
  MPLS-TP Operations, Administration and Maintenance Requirements
  in RFC 5860 [2]. These mechanisms are intended to be applicable
  to other aspects of MPLS as well. However, this is beyond the
  scope of this document.

  Two broad classes of service disruptive conditions are identified.

  1.  Fault: the situation in which the density of anomalies has
      reached a level where the ability to perform a required
      function has been interrupted.

  2.  Lock: an administrative status in which it is expected that
      only test traffic, if any, and OAM (dedicated to the LSP) can
      be sent on an LSP.

  This document specifies an MPLS OAM channel called an "MPLS-OAM
  Fault Management (FM)" channel.  A single message format and a
  set of procedures are defined to communicate service disruptive
  conditions from the location where they occur to the endpoints
  of LSPs which are affected by those conditions. Multiple message
  types and flags are used to indicate and qualify the particular
  condition.

Working Group Summary

  This document is a MPLS working group document, and part of the joint
  IETF - ITU.T MPLS-TP project. It has been reviewed in both organizations
  and there is a solid support for the document.

Document Quality

  The document has been carefuly reviewed in the MPLS working group and
  the ITU-T.