[CCAMP] Comments to draft-ietf-ccamp-oam-configuration-fwk

Gregory Mirsky <gregory.mirsky@ericsson.com> Thu, 01 December 2011 01:17 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 41AAB21F8B39 for <ccamp@ietfa.amsl.com>; Wed, 30 Nov 2011 17:17:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.577
X-Spam-Level:
X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.021, 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 PCilvnfz7qkr for <ccamp@ietfa.amsl.com>; Wed, 30 Nov 2011 17:17:46 -0800 (PST)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB2221F8B36 for <ccamp@ietf.org>; Wed, 30 Nov 2011 17:17:46 -0800 (PST)
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pB11HM7Z024194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Nov 2011 19:17:22 -0600
Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 30 Nov 2011 20:17:21 -0500
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: Attila Takacs <Attila.Takacs@ericsson.com>, "donald.fedyk@alcatel-lucent.com" <donald.fedyk@alcatel-lucent.com>, "hejia@huawei.com" <hejia@huawei.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Date: Wed, 30 Nov 2011 20:17:20 -0500
Thread-Topic: Comments to draft-ietf-ccamp-oam-configuration-fwk
Thread-Index: Acyvxvj5Qp/kavLxQ3y6Nqi5MQWefA==
Message-ID: <FE60A4E52763E84B935532D7D9294FF132293B45F0@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_FE60A4E52763E84B935532D7D9294FF132293B45F0EUSAACMS0715e_"
MIME-Version: 1.0
Subject: [CCAMP] Comments to draft-ietf-ccamp-oam-configuration-fwk
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 01:17:47 -0000

Dear Authors, et al.,
Please find my comments to the document below. Your kind consideration is appreciated.

*        General comment - combining OAM for SONET/SDH, Ethernet, and MPLS(-TP) creates terminology problem. Perhaps a section can be added to map ITU, IEEE, and IETF terms and set some common understanding for Maintenance-Foo terms.
*        Section 3 "MEPs reside at the ends of an LSP ..." It is not the case for SONET/SDH and Ethernet. AFAIK, it is only the case for MPLS-TP. Perhaps the following wording would be accurate without going into too much specifics: "MEPs define scope of actively managed and monitored element of maintenance ..."
*        Section 3 "Maintenance Entity (ME) refers to an association of MEPs and MIPs that are provisioned to monitor an LSP." Association MEPs and MIPs are not always referred as ME. In CFM MPs on the same ME Level referred as Maintenance Association. Maintenance Entity, in CFM, is p2p relationship between MA. Even more, CFM MPs configured on all MD levels represent Maintenance Domain.
*       Section 3.1 "When the Path message arrives at the receiver, the remote end MUST establish and configure OAM entities according to the OAM information provided in the Path message". I'm concerned that "the remote end" implies far end LER and thus process excludes configuration of MIPs, enclosed MD Levels and MEPs and MIPS per MD Level. I'd suggest to remove "the remote end" replacing it with less specific "it" "When the Path message arrives at the receiver, it MUST ..."
*       Section 4.1, fourth para "This bit (OAM MIP entities desired) can only be set if the "OAM MEP entities desired" bit is set in." I believe that this is too restrictive as a MIP might be added on after an LSP and MEPs been configured.

Regards,

Greg