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

Gregory Mirsky <gregory.mirsky@ericsson.com> Thu, 01 December 2011 21:46 UTC

Return-Path: <gregory.mirsky@ericsson.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5501F0CCD for <ccamp@ietfa.amsl.com>; Thu, 1 Dec 2011 13:46:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.582
X-Spam-Level:
X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvZftMBDk2Km for <ccamp@ietfa.amsl.com>; Thu, 1 Dec 2011 13:46:11 -0800 (PST)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id F25061F0CB4 for <ccamp@ietf.org>; Thu, 1 Dec 2011 13:43:59 -0800 (PST)
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pB1LhrvD023840; Thu, 1 Dec 2011 15:43:55 -0600
Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 1 Dec 2011 16:43:47 -0500
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: Elisa Bellagamba <elisa.bellagamba@ericsson.com>, Loa Andersson <loa.andersson@ericsson.com>, "pontus.skoldstrom@acreo.se" <pontus.skoldstrom@acreo.se>, "dward@juniper.net" <dward@juniper.net>, Attila Takacs <Attila.Takacs@ericsson.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Date: Thu, 01 Dec 2011 16:43:46 -0500
Thread-Topic: Comments to draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-07
Thread-Index: Acywck29GgsX0sbMQTqDAJpIa1MuCQ==
Message-ID: <FE60A4E52763E84B935532D7D9294FF132295FFDD2@EUSAACMS0715.eamcs.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF132295FFDD2EUSAACMS0715e_"
MIME-Version: 1.0
Subject: [CCAMP] Comments to draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-07
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2011 21:46:14 -0000

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