[mpls] Gen-ART review of draft-ietf-mpls-tp-oam-framework-10

[<[e-mail]>]

Summary:
This draft is basically ready for publication, but has nits that should be fixed before publication.

The authors have addressed most of the items noted in the Gen-ART review of the -09 version, but there is one item that could still use some attention.  From the original review:

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

This has not been done.  While the security considerations section does cover the countermeasures necessary to prevent this attack, I prefer security considerations sections that include examples of things that can go badly wrong when implementers don't pay attention when the examples are simple.  That preference is a matter of style/taste that I'll leave to the responsible AD's judgment [Adrian, I think that's your cue ;-) ].

idnits 2.12.05 ran clean.

Thanks,
--David

-----Original Message-----
From: Black, David 
Sent: Monday, November 22, 2010 6:14 PM
To: [e-mail]; [e-mail]; General Area Review Team
Cc: Black, David; George Swallow; Loa Andersson; Martin Vigoureux; Adrian Farrel; [e-mail]
Subject: Gen-ART review of draft-ietf-mpls-tp-oam-framework-09

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

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

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------