Review of draft-ietf-mpls-tp-temporal-hitless-psm-13

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Reviewer: Stewart Bryant
Review result: Ready with Issues

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.






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]