Document: draft-ietf-mpls-tp-oam-framework-09 Reviewer: David L. Black Review Date: November 22, 2010 IETF LC End Date: November 22, 2010 IESG Telechat date: (if known) Summary: This draft is on the right track, but has open issues, described in the review. This draft describes the OAM framework for MPLS-TP. The draft's generally well written, but full understanding of the draft requires significant MPLS and PW expertise (which I do not have). There are no major issues, and the minor issues are relatively, but the primary reason that the summary is "open issues" instead of "nits" is acronym problems (see "Minor issues:" below). The draft is acronym rich in general, including acronym nesting that can be confusing. For example: LSME => LSP SPME ME => Label Switched Path Sub-path Maintenance Element Maintenance Entity Was "Maintenance Element Maintenance Entity" intended? More on this below at (B-2). Major issues: None. Minor issues: [A] There's no summary list of requirements (e.g., checklist) that an OAM solution needs to fulfill in order to be compatible with the framework. Should there be one? I'm not clear on the intended audience for this draft, so "no" with an explanation is an acceptable answer. [B] Unfortunately the draft has a couple of significant acronym problems that start in Section 2.1: (B-1) SME Section Maintenance Entity Group If a group was intended, SMEG should be used instead of SME, especially as the following occurs in Section 4: o A Section Maintenance Entity Group (SME), allowing monitoring and management of MPLS-TP Sections (between MPLS LSRs). o An LSP Maintenance Entity Group (LME), allowing monitoring and management of an end-to-end LSP (between LERs). o A PW Maintenance Entity Group (PME), allowing monitoring and management of an end-to-end SS/MS-PWs (between T-PEs). The acronyms in the second two bullets are wrong wrt Section 2.1 - they're defined in Section 2.1 as LMEG and PMEG, which suggests that the G suffix should be used uniformly. In addition, SME is referred to in Section 4.1: An MPLS-TP Section ME (SME) is an MPLS-TP maintenance entity It looks like the following needs to be done: - Define both SME and SMEG in Section 2.1 - Suffix a "G" to the SME, LME and SME acronyms in Section 4 - Scan for all other uses of Group and check that the correct acronym that ends in a G is used. (B-2) SPME Sub-path Maintenance Element It's unclear from the draft whether the E should stands for Element or Entity. While the expansion in Section 2.1 uses Element, Section 2.2 says: This document uses the term Sub Path Maintenance Entity (SPME) as defined in RFC 5921 [8]. Which is really peculiar because RFC 5921's acronym section says: SPME Sub-Path Maintenance Element Nonetheless, the word "Entity" is a better fit to this draft, so I would suggest adding text to equate the use of "Entity" in SPME with RFC 5921's use of "Element", and using "Entity" throughout this draft. That has a beneficial side-effect of simplifying many of the nested acronym expansions, for example: PSME PW SPME ME becomes PSME PW SPME because both instances of ME become "Management Entity", making one of them redundant. [C] Section 5.1.3 says: For statically provisioned transport paths the above parameters are statically configured; for dynamically established transport paths the configuration information are signaled via the control plane. This appears to assume that addition or removal of destinations on the mp side of any p2mp path while the path is in operation is always entirely statically configured or always entirely dynamically configured for. I'm not clear on what the situation is here, so there are at least 3 possibilities, the correct one of which ought to be added near the end of Section 3.1: - This is not possible: dynamic destination addition/removal for an operating p2mp path is not permitted, independent of whether the p2mp path was dynamically or statically configured. - The assumption is correct. If the p2mp path is dynamically configured, destination add/drop is dynamically configured; if the p2mp path is statically configured, destination add/drop is statically configured. - The assumption is incorrect. Each destination add/drop can be dynamically or statically configured independent of how the p2mp path was configured. [D] The security considerations section should include specific mention of injection of LKI request OAM packets as a vector for a denial-of-service attack (this is an obvious way for a man-in-the-middle to quickly cause serious havoc). That would be a good specific example to add to the end of the current security considerations paragraph that requires the network to be physically secure against man-in-the-middle attacks. Nits/editorial comments: Consider adding T-PE and S-PE to acronym list. The symbol legend at the bottom of Figure 5 is in an unexpected location and format. It might make more sense to the reader if it were moved above the TPE expansions and reformatted to 2 columns x 2 lines instead of 4 columns on 1 line. The reference in Section 4.2 back to Figure 5 is unfortunate. Each of Sections 4.3, 4.4 and 4.5 has a version of figure 5, suggesting that another version in Section 4.2 would be appropriate. The reference back to Figure 5 from Section 5.3 is even worse (longer distance). Section 5.1: the ICC-based format for MEP identification is used. Please define or expand ICC. Section 5.1.1.2 identifier or receives a CC or CC/CV OAM packet with an unexpected encapsulation. I think: "CC or CC/CV" should be changed to "CC-V" for consistency. OTOH, "CC or CC/CV" is clearer (IMHO) if there's a choice. Section 5.2 and beyond contain instances of "signal fail" that should be "a signal fail condition".