Last Call Review of draft-ietf-mpls-tp-temporal-hitless-psm-12
review-ietf-mpls-tp-temporal-hitless-psm-12-genart-lc-bryant-2017-02-28-00

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