Subject: [mpls] Comments on draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-01

From: Greg Mirsky <[email-masked]>
Date: Fri, 18 Mar 2011 14:01:15 -0700

Dear Editors, Authors, and All,
please kindly consider my comments to the document:

   - perhaps second para on Introduction can be re-worded as

Because the Transport Profile of MPLS, by definition [RFC5654], must be
capable of operating without a control plane, there are two options
for *configuring
and controlling *in-band OAM: by using an NMS or by using LSP Ping.

   - it might be useful to mention in the Introduction the obvious
   dependency when using LSP Ping to configure, enable, and control in-band
   MPLS OAM. Proactive OAM cannot be configured, enabled before the LSP itself
   is operational. So, we configure OAM on implicitly specified LSP. I think
   that it might be useful to configure OAM for explicitly specified LSP as
   well.
   - last sentence of 3rd para in the Introduction might be edited to
   reflect the scope of draft-ietf-mpls-tp-cc-cv-rdi to

BFD can be used to track the liveliness and detect data plane failures of
MPLS-TP point-to-point *bi-directional* and might also be extended to p2mp *and
p2p uni-directional *connections.

   - first sentence in 5th para in the Introduction might be edited to
   reflect that pro-active OAM tool set is not limited by CC/CV/RDI mechanism
   that in MPLS-TP is based on BFD. PM (LM/DM), and FMS as well are pro-active
   or could be used as pro-active but in MPLS-TP OAM they don't use BFD as
   their principle of operation.
   - Section 3.2 As I understand, the head-end MEP indicates set of OAM
   functions it expects remote MEP to support. If not all functions can be
   supported, how the set can be negotiated? Is it expected the the tail-end
   MEP includes OAM Functions TLV in LSP Echo Reply with its set of supported
   functions? If sets are not matching but have an overlap, should Return Code
   be set to 0 or new proposed "MPLS OAM Unsupported Functionality"? In the
   latter case, how to identify which of MPLS OAM functions is not supported?
   - Section 3.2.1 If Symmetric session cannot be supported, then how that
   will be indicated? Note that Section 3.1 has forward reference "Section
   3.3.1 includes a detailed explanation of such configuration" but the Section
   3.3.1 doesn't exist in the current text. Though there's explanation of
   operation with S-bit in Section 3.2.1.2. One option - use LSP Echo reply to
   negotiate timer increase. Any other options?
   - Sections 3.2.2 and 3.2.3 LM and DM might be run not only between MEPs
   but between MEP and MIP (as suggested in Section 2.7.4 Intermediate Nodes in
   draft-ietf-mpls-loss-delay-01). Then there's possible scenario when
   addressee of OAM configuration by LSP Echo request is not only MEP but a MIP
   on the given LSP. Hence there's need, in my opinion, to have MIP-ID sub-TLV.
   Such sub-TLV can be used to configure MPLS OAM on a MIP. (Discussion of
   nodal, in- or out- MIP addressing is in
   draft-farrel-mpls-tp-mip-mep-map-03).
   - Section 3.2.3 I support inclusion of Delay Measurement Timestamp Format
   indication/negotiation in the MPLS OAM PM Delay sub-TLV
   - Section 4 OAM Configuration Errors doesn't mention referred in Section
   3.2.1 "OAM Problem/Unsupported OAM Version" error.

Regards,
Greg