Early Review of draft-ietf-mpls-tp-temporal-hitless-psm-09
review-ietf-mpls-tp-temporal-hitless-psm-09-rtgdir-early-sinicrope-2016-04-07-00

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

Attachment:

draft-ietf-mpls-tp-temporal-hitless-psm-09 - flattened.pdf

Description:

 draft-ietf-mpls-tp-temporal-hitless-psm-09 - flattened.pdf