[mpls] Comments regarding draft-ietf-mpls-tp-fault-04.txt

["Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[e-mail]>]

Hi all,

I have some comments concerning the I-D on Fault Management for MPLS-TP

Editorial comments:
1. In section 1:  Change "When a disruption occurs on any link or node
along the path of such a transport circuit, OAM are generated ..." to
read "OAM indications are generated" (Note: OAM is a class of
functionality and I don't think that they are generated, either OAM
messages or indications could be generated)

2.In section 2.1.1 third paragraph: "...the LDI flag may be ignored."
Shouldn't this be a normative MAY? (considering that in the next
sentence you use a normative SHOULD)

3.Section 2.2: "...has been administratively locked to communicated that
condition ..." Not sure what the intention was - either change
/communicated/communication,/ or change /locked to communicated/locked,
to communicate/

4.Section 3: change "The FM Channel does not use ACH TLVs and MUST
not..." to "and MUST NOT ..."

5.Section 5.3 change "to ensure that that" to "to ensure that"

6. Section 6: change "are optional to implement" to "are OPTIONAL to
implement"

7. Section 8.1: change "0xHHHH" to "0xHH" to align with the other
occurrences (even though this will eventually be changed by the RFC
Editor)

Questions for clarification:
1.  In section 2 it states that "The messages are sent to the client
MEPs by inserting them in the affected LSPs in the direction opposite to
the detecting MEP's peer server MEP(s)."  While I know that this has
been discussed between the IETF and the ITU-T, I am not sure that I
understand how the client MIP that is actually sending the OAM message
knows which direction is "opposite to the detecting..." is there some
indication that is included in the indication (or is this out-of-scope
to this I-D and part of some external document?).

2. Section 2.1.1 It is unclear to me from reading this section when you
are referring to protection switching at the Server layer and when to
protection/recovery at the Client level.  For example, in reference to
the LDI flag you state - "However if the protection switch was
unsuccessful in restoring the link ..., the LDI flag MUST be set." Which
level is performing the protection switch that was unsuccessful?
Earlier (at the end of Section 2.1) you state that "When the LDI is set,
... to trigger recovery mechanisms"  is this at the Client layer?  Later
you speak of the LDI flag being dependent upon whether the Server layer
is protected or not.

3. Section 4.1.1-3 deal with the encoding of different identifier TLVs -
wouldn't it be safer to just reference the mpls-tp-identifiers draft?
In light of the recent discussion shouldn't section 4.1.3 be clarified
regarding the use of Country Codes in the Global ICC?

4. Section 5.2 states that "Other fields of the FM message SHOULD NOT be
modified." Yet in section 5.3 it states that a FM message with the
R-flag set is ignored if the Msg Type field and Interface Identifier TLV
do not match an existing condition.  In light of this, shouldn't it be
stated that these two fields SHALL NOT be modified?  Also shouldn't
there be more normative text in the second paragraph of section 5.3?

Thanx and Best regards,
Yaacov

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
ext [e-mail]
Sent: Thursday, May 05, 2011 9:30 PM
To: [e-mail]
Cc: [e-mail]
Subject: [mpls] I-D ACTION:draft-ietf-mpls-tp-fault-04.txt

A new Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Multiprotocol Label Switching Working
Group of the IETF.

    Title         : MPLS Fault Management OAM
    Author(s)     : G. Swallow, et al
    Filename      : draft-ietf-mpls-tp-fault-04.txt
    Pages         : 15
    Date          : 2011-04-26
    
   This draft specifies OAM messages to indicate service disruptive
   conditions for MPLS Transport Profile (MPLS-TP) Label Switched Paths
   (LSPs).  The notification mechanism employs a generic method for a
   service disruptive condition to be communicated to a Maintenance End
   Point (MEP).  An MPLS Operation, Administration, and Maintenance
   (OAM) channel is defined along with messages to communicate various
   types of service disruptive conditions.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-fault-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.