Telechat Review of draft-ietf-mpls-tp-temporal-hitless-psm-13
review-ietf-mpls-tp-temporal-hitless-psm-13-genart-telechat-bryant-2017-03-14-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 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.