[mpls] Review of draft-ietf-mpls-tp-temporal-hitless-psm-12

[Stewart Bryant <[e-mail]>]

Reviewer: Stewart Bryant
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-mpls-tp-temporal-hitless-psm-??
Reviewer: Stewart Bryant
Review Date: 2017-02-28
IETF LC End Date: 2017-03-03
IESG Telechat date: 2017-03-16

Summary:

This document is a valid critique of the existing MPLS SPM design, and
sets out a list of requirements that were called up at the time of its
design but not met. As such this is a valid set of requirements. What
is unclear is whether it is feasible to meet the requirements set out
in this document, and if so whether or not this will require a change
to the MPLS architecture. It would be useful to the reader to clarify
the feasibility of a solution in order not to set false expectations.

Major issues:

The title is "Hitless path segment monitoring".  I read the document
hoping to find that this was a solution. It is not, it is a
requirements text and really ought to be titled as such.

Whilst this text describes a list of issues with the existing IETF
design, it should be remembered that the design was the best that
could be accomplished at the time within the constraints of the MPLS
architecture. So that leaves the reader with a question: do the
authors now have an insight into how a solution can now be designed to
meet the requirement,  or do the authors intend to propose a change to
the MPLS architecture, or is the intention to publish this to state
the requirements in the hope that someone will eventually propose a
solution?

The text  says:

"In particular, performance monitoring measurements (e.g.  Delay
Measurement and Packet Loss  Measurement) are sensitive to these
changes."

Whilst technically true, I am not sure the impact on delay is
significant in any engineering sense. We are talking four bytes per
packet over a service that is going at 1 to 400 Gb/s. Again it is hard
to imagine a significant impact on loss. If this is a key point it
need some justification from an engineering perspective.

In Figure 5 it is unclear what the difference between the first and
second on-demand point is. Is this a reference to input and output
interface monitoring. If  so I think that this should be made clear,
together with a note that a lot of MPLS forwarding designs find this
difficult to achieve. 

The text around Figure 8 explains the deficiency in TTL based section
of an OAM monitoring point in MPLS. However the authors give no
indication of a feasible alternative. Do they have one in mind?

Minor issues: None

Nits/editorial comments: 
     From ID-Nits: The abstract seems to contain references
([RFC6371]), which it
     shouldn't.  Please replace those with straight textual mentions
of the
     documents in question.

For exampla in OTN, TCM allows the insertion - Typo example