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