Subject: [CCAMP] Comments to draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-07

From: Gregory Mirsky <[email-masked]>
Date: Thu, 1 Dec 2011 16:43:46 -0500

Dear Authors, Editors, et al.,
Please find my comments to the document below:
*       Introduction, first para s/at and points/at maintenance points/ and s/runnineg/running/
*       Introduction, second para "Therefore there are three options for configuring MPLS-TP OAM ... or with a control plane using GMPLS (specifically RSVP-TE)". GMPLS can not be used to configure as it is a paradigm, model of switching label. In fact, signaling protocols, RSVP-TE and T-LDP, can be used to configure MPLS-TP OAM. Perhaps the following wording can be used "Therefore there are three options for configuring MPLS-TP OAM ... or with a control plane using signaling protocols RSVP-TE and/or T-LDP. Use of T-LDP for configuration of MPLS-TP OAM is outside of scope of this document."
*       Introduction, 3rd para. Strictly speaking, CC/CV is extension of the BFD as it specifies changes to RFC 5880 in regard to initialization and state machine for Independent mode (bi-directional associated LSP) and CV in G-ACh encapsulation. I suggest changing reference to RFC 6428 Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile.
*       Section 3.1 If OAM functions are enabled via RSVP-TE  then default values associated with each OAM function must be specified in the document or referenced in other documents. In case there are no default values, then use of sub-TLV should be mandatory.
*       Section 3.1.1 "Unidirectional mode" of BFD is not yet well defined. It might be mentioned but OAM configuration for it is for further sturdy.
*       Section 3.1.1, 2nd and 3rd para overloaded with references to how LSP Ping used to bootstrap BFD session. I think that operation of LSP Ping is outside of scope of this document.
*       Section 3.2 "Moreover, if the CV or CC flag is set, the CC flag MUST be set at the same time" perhaps should be re-worded into "Moreover, if the CV flag is set, then the CC flag MUST be set as well".
*       Section 3.2, p. 7, discusses Unique MEP-ID without reference to IETF or ITU conventions. If ITU-based IDs required, then ITU-T Carrier Code and Country Code must be signaled by sub-TLV(s). If support of ITU's IDs is out-of-scope need to mention that explicitly.
*       Section 3.2, p.8, first para. In case of bi-directional associated LSP is composed of LSP numbers that are unique within Tunnel_ID. Is configuration of MPLS OAM for bi-directional associated LSP in scope of the document?
*       Section 3.3 Flags G, U, and B are not reflected in ASCII-art presentation of the BFD Configuration sub-TLV
*       Section 3.3 "- the N flag is cleared and the S flag is set and a timing interval larger than the one received needs to be used" perhaps is missing "or" and clarification of what is the received timing interval being referenced.
*       Reserved field usually is set to 0 on transmit and ignored on receive.
*       Section 3.3.2 I think that there's disconnect between ASCII-art presentation of the Negotiation Timer Parameters sub-TLV and suggestion that its length is 20 bytes. ASCII-art presents TLV with length of 16 bytes.
*       Section 3.3.2 what suggestion procedure if remote LER considers Acceptable Min. Asynchronous TX/RX values as too big? Should it send an Error?
*       Section 3.3.x - a missing section to configure Detect Multiplier value.
*       Section 3.4 What is proposed value of Perf Monitoring Type field? It cannot be 1, as 1 is proposed as value of PM Loss Type.
*       Section 3.4 Interpretation of Length field is missing. I suggest to add "Length: indicates the TLV total length in octets" to make it consistent with interpretation of the Length field in BFD configuration (sub-)TLVs.
*       Section 3.4.1 value of PM Loss Type in ASCII-art figure is 1 but Section 4 suggests IANA to allocate 3
*       Section 3.4.1 Length in MPLS OAM PM Loss sub-TLV reflects length of parameters whereas Length in BFD configuration sub-TLVs indicates the length of the total TLV. I think that there must be consistency in interpretation of Length in sub-TLVs used to configure MPLS OAM.
*       Section 3.4.2 value of PM Delay Type in figure is 2 while Section 4 suggests IANA to allocate 4
*       Section 3.4.2 What is encoding of OTF field to present 1558 type 1 format?
*       Section 3.4.2 What happens if any LSR along the path can not support requested intervals?
*       Section 4 Do we need to request IANA allocation of Performance Monitoring Type?
*       Section 5 how Error Code OAM Problem/Unsupported CC Interval from [ETH-OAM] is related to OAM Problem/Unsupported TX rate interval?
*       Section 5 I think there should be "OAM Problem/Unsupported RX rate interval" Error Code
*       Section 5 How unsupported Authentication Type and/or mismatch of Authentication Key ID reported in Error message?
*       General question. Is configuration of MIP, even per-node MIP, outside-of-scope?

Thank you for your kind consideration.

        Regards,
                Greg