[mpls] Fwd: RtgDir review: draft-ietf-mpls-tp-temporal-hitless-psm

[David Sinicrope <[e-mail]>]

Per request.


Begin forwarded message:

From: David Sinicrope <[e-mail]<mailto:[e-mail]>>
Date: March 9, 2016 at 13:46:23 EST
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RtgDir review: draft-ietf-mpls-tp-temporal-hitless-psm

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-mpls-tp-temporal-hitless-psm-09
Reviewer: Dave Sinicrope
Review Date: 8 March 2016
IETF LC End Date: 15 Nov 2015
Intended Status: Standards Track

Summary:
I have some concerns about this document that I think should be resolved before publication.

The document appears to be proposing changes to the MPLS-TP OAM requirements and rationalizing an alternative OAM solution but is written in a context of "considerations".   An alternative OAM solution should be founded on a requirements discussion more concrete than considerations.  Also, given the MPLS-TP requirements in question were developed in conjunction with ITU-T SG 15, it is logical to include their input into such a discussion.  See the ADs comments on relevant liaisons.

Some of the problems noted were never raised as issues with the original requirements or solutions developed to meet those requirements. This leads back to a thorough requirements discussion noted above.

It's been noted by the responsible AD that extensions to MPLS-TP OAM were to be pursued as extensions for MPLS and MPLS-TP in general.  Yet these considerations suggest requirement changes and solutions for MPLS-TP specifically.  Has applicability to MPLS been considered?

I'd be happy to discuss these comments with the authors to expedite resolution.

Detailed Comments:

See file attached to this message:
File: draft-ietf-mpls-tp-temporal-hitless-psm-09 - flattened.pdf

Annotation summary:

--- Page 1 ---

Note (yellow), Feb 27, 2016, 06:13, Dave Sinicrope:
Abstract, P1:  "The most attractive"... This is a subjective statement.  The rationalization for MPLS-TP was to provide a simplified profile of MPLS with less IP dependency for packet transport use.  Change "the most attractive" to "Key".

Tag G1 - In general tone down and/or drop the subjective and promotional language.  This will also shorten the abstract and document.  This comment applies to several places thought the text.

Note (yellow), Feb 27, 2016, 06:04, Dave Sinicrope:
Abstract P2: this document provides... - in providing this these are new requirements for MPLS-TP.  The original requirements were done in concert with the ITU-T.  Changes to those requirements should also involved the ITU-T.

Note (yellow), Feb 27, 2016, 06:04, Dave Sinicrope:
Abstract, P2: MS-PW -to the best of my knowledge MS-PWs are not part of MPLS-TP.  - they are: comment withdrawn

Note (yellow), Feb 27, 2016, 06:04, Dave Sinicrope:
Abstract, P2, last sentence:  This sentence, which highlights the purpose of the document, is unclear.  It talks about providing "... considerations for the  specification of new requirements to consider a new improved  mechanism ..."  I suspect the document is providing new requirements but hard to tell with the considerations context. Please clarify in the document body what the purpose of this document is and briefly summarize the purpose in the abstract.



Note (yellow), Mar 6, 2016, 19:45, Dave Sinicrope:
Gen: I have read the AD comments sent on Feb 26. I agree with all comments.  I will not repeat all of them here for the sake of expediency.

Gen: in line with the AD comments the term temporal or temporary is causing confusion.  On-demand seems a better choice.

Gen: same issue with "hitless".  I'm assuming you mean no traffic impact or performance degradation.  If not please clarify.  If so please consider a term change.

Gen: I'm note sure what this doc is trying to do.  It's self described as considerations for specification of new requirements.  So is it a requirements spec?  Or a start to a requirements spec? It makes reference to the MPLS-TP OAM requirements but indicates they are faulty or insufficient.  It seems that this would better be framed as a proposed update to the existing requirements pointing out deficiencies.

Gen: the document asserts there are issues with the existing MPLS-TP requirements.  Those requirements were developed jointly with the ITU-T SG15.  I would assume any shortcomings and/or alternative requirements should be conveyed to SG15 for comment and input.




--- Page 3 ---

Note (yellow), Feb 27, 2016, 06:13, Dave Sinicrope:
Introduction, first 2 paragraphs:  These paragraphs don't introduce any more than the 3rd and distract from the point of the document.  You can start with P3 and remove these two.

Note (yellow), Mar 6, 2016, 17:03, Dave Sinicrope:
Sec 1., Para 2, "Similar to ...": This statement needs clarification.  I believe is that it is meant to convey that MPLS-TP OAM does scale when invoked a priori at each possible use point in the network.  Let's leave the legacy tech out of the discussions.

Note (yellow), Mar 6, 2016, 17:03, Dave Sinicrope:
Sect 1, 3rd Para., 3rd sentence: change "in fact" to "in that" and make part of precious sentence.

Note (yellow), Mar 6, 2016, 17:03, Dave Sinicrope:
Sect 1, para 4: the existing, while not dedicated, can do this, why is another needed?

Note (yellow), Mar 6, 2016, 17:03, Dave Sinicrope:
Sect 1, para 6: need to find better terms than temporary and gutless and define them


--- Page 4 ---

Note (yellow), Mar 6, 2016, 18:35, Dave Sinicrope:
Sec 3: could be incorporated  to section 4


--- Page 5 ---

Note (yellow), Mar 6, 2016, 19:45, Dave Sinicrope:
Sec 4, P-1:  more explanation is needed here. A single extra label is negligible in bandwidth efficiency.  However if these labels are added such that several segments are monitored at once or nested in their monitoring, this may impact bandwidth efficiency.  If this is the case it should be spelled out. If not how is label stacking a significant impact?

RfC 5860 notes that an arbitrary label stack must be dealt with, implying label depth is not an issue.

Note (yellow), Mar 6, 2016, 17:03, Dave Sinicrope:
Sec 4, P-2: more explanation is needed here.  Configuration of the MEPs, MIPs and sub layer is required regardless of mechanism.  How is this a "problem" vs a necessary fact of implementing a network?

P-2 Nit: place this problem statement above its explanation.

Caret, Mar 6, 2016, 17:03, Dave Sinicrope:
,

Caret, Mar 6, 2016, 17:03, Dave Sinicrope:
an

Strikeout (red), Mar 6, 2016, 17:03, Dave Sinicrope:
for

Caret, Mar 6, 2016, 17:03, Dave Sinicrope:
to administer

Strikeout (red), Mar 6, 2016, 17:03, Dave Sinicrope:
in a similar  manner as Tandem Connection Monitoring (TCM) in the Optical Transport  Networks (OTN) and Ethernet transport networks

Caret, Mar 6, 2016, 17:03, Dave Sinicrope:
<move to after point is made>

Strikeout (red), Mar 6, 2016, 17:03, Dave Sinicrope:
/TCMs

Caret, Mar 6, 2016, 17:03, Dave Sinicrope

Note (yellow), Mar 6, 2016, 17:03, Dave Sinicrope:
Sec 4, para 6: I was under the impression that having the identification and addressing of the management/maintenance entities established a priori allowed:
1. Faster diagnosis of network problems in that establishing identification of monitoring and localization points was already done when a problem arose,
2. Allowed consistent reference points for predictable, repeated diagnostics and comparison.

Note (yellow), Mar 6, 2016, 17:03, Dave Sinicrope:
Sec 4, para 7: this pint is not clear and seemingly contradicts the statement in the paragraph above.  Please elaborate on the comparison to TCM

Note (yellow), Mar 6, 2016, 17:03, Dave Sinicrope:
Sec 4, para 8: this contradicts the point in paragraph 6 noting problems setting them up permanently. If one doesn't want to establish them permanently or temporarily what is left?


--- Page 6 ---

Note (yellow), Mar 6, 2016, 18:43, Dave Sinicrope:
Sec 4, P-3: Nit: move description under problem statements

Sec 4 P-3 and P-4:

Note (yellow), Mar 6, 2016, 19:45, Dave Sinicrope:
Sec 4, para 12: refer to AD comments of Feb 26


--- Page 7 ---

Note (yellow), Mar 6, 2016, 19:45, Dave Sinicrope:
Sec 4, para 15:  how is make before break limited to control plane?  The observation concerning the management system contradicts this statement and could not be the case if the function was based on control plane.


--- Page 8 ---

Note (yellow), Mar 6, 2016, 19:45, Dave Sinicrope:
Sec 4, para 16:  this point has already been made in P-4

Note (yellow), Mar 6, 2016, 19:45, Dave Sinicrope:
Sec 4, para 16:  issues described here always need to be considered and aren't unique to OAM or these requirements.  How is this relevant to these requirements?

Note (yellow), Mar 6, 2016, 19:45, Dave Sinicrope:
Sec 4, para 17:  the assertion that SPMEs are limited to inter carrier is not supported.  This may be an opinion of their practical value vs the asserted overhead of their a priori configuration, but it is not stated in this way.  Consider restating this as an opinion.

Note (yellow), Mar 6, 2016, 19:45, Dave Sinicrope:
Sec 4, para 18: this alludes to a solution.  Not appropriate in a Req document


--- Page 9 ---

Strikeout (red), Mar 6, 2016, 19:45, Dave Sinicrope:
is

Caret, Mar 6, 2016, 19:45, Dave Sinicrope:
it

Note (yellow), Mar 6, 2016, 19:45, Dave Sinicrope:
Sec 6.2:  multilevel is a req that has no aforementioned problem to be solved.  Levels haven't entered into the discussion at all to this point. It should be removed from the text.

Note (yellow), Mar 6, 2016, 19:45, Dave Sinicrope:
Sec 6.1, M-2: why would the provisioning of ESPM change the traffic. Wouldn't it be the invocation of the function that needs to leave the traffic as is?

Note (yellow), Mar 6, 2016, 19:45, Dave Sinicrope:
Sc 6.1





[cid:[e-mail]]