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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

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-03-14
IETF LC End Date: 2017-03-03
IESG Telechat date: 2017-03-16

Summary: Given that the implications for the MPLS architecture and the feasibility of a solution are currently unknown, the IESG needs to decide whether publication at this stage is appropriate, or whether a feasible solution should first be identified.

Major issues:

I previously raised the following two issues:

"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?"

and 

"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."

The authors responded by adding the following text:

"Further works are required to evaluate how proposed requirements match with current MPLS architecture and to	identify possibile solutions."

When RFC6371 was written the problems cited in this text were known, and despite much work no one could identify a solution at the time.

The key question for the IESG is whether it is appropriate to publish this requirements text when  no one has any idea of the impact on the MPLS architecture or if there are any practical solutions to the problems raised.

In response to the issue:

"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.

The authors add text:

As an example,increasing the packet lenght may impact on packet loss due to MTU	 settings, modifying the label stack may introduce packet loss or it may fix packet loss depending on the configuration status so modifying network conditions.  Such changes influence packets delay too even if, from a practical point of view, it is likely that only a few services will experience a practical impact.

Again it is for the IESG to decide whether in the light of the architectural and practical issues noted earlier, the problem  is severe enough to warrant publication of this document at this stage.