Subject: [mpls] FW: Gen-ART review of draft-ietf-mpls-tp-oam-framework-09

From: Adrian Farrel <[email-masked]>
Date: Tue, 23 Nov 2010 09:28:21 +0000

Hi authors,

Obviously, you also need to consider Dave's GenArt review as part of the IETF
last call and handle his comments as well.

Thanks,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 22 November 2010 23:14
> To: [email-masked]; [email-masked];
[email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> 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
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------