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

[Attila Takacs <[e-mail]>]

Hi Greg,
Please see inline.
Thanks for your comments!
Attila

_____________________________________________
From:   Gregory Mirsky
Sent:   Thursday, December 01, 2011 2:17 AM
To:     Attila Takacs; [e-mail]; [e-mail]; [e-mail]
Subject:        Comments to draft-ietf-ccamp-oam-configuration-fwk

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.

This is correct, we tried to come up with a general "understandable" terminology influenced by the discussions around the TP OAM terminology, because we wanted to avoid a lengthily terminology overview. We will have a look to this specific question again and try to make it clearer, I would refer for ITU/IEEE/IETF terminology map to the technology specific documents.

*        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 ..."

Ok, will change.

*        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.

Yes, this relates to the terminology question above. Will consider.

*       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 ..."

Ok, will change.

*       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.

To adding MIPs after LSP configuration, one would set the "OAM MIP entities desired" bit along with keeping the "OAM MEP entities desired" bit set.

Regards,

Greg