I received (as shepherding AD) the following review comments on
this document which seem polite and relevant. I am putting them
on the list so that the authors can consider them with the other
comments.
Adrian
===
The document is quite well written.
The structure of the document is appropriate. The place of
Section 1.2. is however questionable. Wouldn't it better fit
incorporated in Section 7?
While the Introduction contains the following sentence:
"This document sets out the reasons for selecting a single,
coherent set of OAM solutions for standardization."
the intent of the document is quite clear:
"This document is intended to explain why it would be unwise
to standardize multiple solutions for MPLS-TP OAM, and to
show how the existence of multiple solutions would
complicate MPLS-TP development and deployment making
networks more expensive to build, less stable, and more
costly to operate."
"This document focuses on an examination of the consequences
of the existence of two MPLS-TP OAM solutions."
As a result, the document nearly only focuses on the drawbacks of
having multiple solutions rather than on the advantages on having
a single one. This leave a considerable hole in the overall
argumentation, hole which should be filled.
Also, the argumentation does not rely on a lot of technical
arguments, most of the arguments put forward are of business/
financial/organizational/... type. Combined to that, only
qualitative arguments are given. No numbers/figures are given to
illustrate the argumentation. Finally, it might sometimes be
difficult for the reader to understand the precise conditions in
which an identified event could materialize (e.g., "the protocols
rules of one protocol require the packets of the other protocol
to be discarded and may result in the LSP or PW being torn down";
Section 6.1) or simply the link between a root cause and its
potential consequences (e.g., how protocol incompatibility leads
to "disruption or corruption of user data", "connection failure";
Section 6.1).
Overall, the reasoning and thus the conclusions drawn appear to be
arguable. It is suggested to strengthen the argumentation, by
focusing on technical and scientific arguments, by providing
numbers (absolute, comparative, probabilistic, ...), and by being
more precise/detailed in the reasoning, to the extent possible.
Note: In relation to the impossible co-existence of multiple
solutions, Section 4.2 describes a situation where two or more
solutions exist, together with a rule (one default and mandatory
solution, the other optional) for managing the duality. This seems
contradictory with the objective of the document.
The scope of the document would benefit from being clarified.
The document is a written version of the history and of some
reasons that participated to the decision taken by the MPLS
Working Group concerning the development of the MPLS-TP OAM
functionality. It does not make any recommendation. This should
be stated clearly.
It should also be made clear that the document does not forbid,
from that point on, the IETF community and more specifically the
MPLS Working Group to be at the origin of, and to define, a new
set of MPLS OAM functions, or to extend the existing one, or to
propose any other evolution of the technology it is responsible
of.
Nits:
Abstract and Introduction
"MPLS-TP is a set of functions and features selected from the
wider MPLS toolset".
This sentence would benefit from some additional information and
context. It lacks a notion of time-line or at least of
development.
It might be the reality today that MPLS-TP is part of MPLS but
MPLS had to grow to incorporate MPLS-TP tool set.
A change to capture that would by the way lead to a greater
coherence with the language used in the paragraphs below (e.g.,
"additions", "extensions").
Similarly, the following change is suggested:
s/These additions were motivated by MPLS-TP, but form part of the
wider MPLS toolset such that any of them could be used in any
MPLS deployment./These additions were motivated by MPLS-TP, and
now form part of the wider MPLS toolset such that any of them
could be used in any MPLS deployment./
It is unclear to which requirements the word "these" refers to in
the following sentence:
"Many solutions and protocol extensions have been proposed to
address these OAM requirements."
1.1. Background
As per RFC 5317, the IETF and ITU-T commissioned the JWT to
evaluate the issues that arose from the development of t-mpls
and to make a recommendation on the way forward.
A sentence restating this, and replacing the first sentence of
the section, would be more appropriate.
The 4th paragraph mentions "an agreement on the principles of
the design and the direction for the development of an MPLS-TP
OAM toolset".
It would be worth detailing the agreement i.e., what were the
principles and direction the teem agreed on.
A list of OAM features is given. It includes Linear Protection
Control. I am unsure this feature has ever been considered as an
OAM feature.
At least, the authors of draft-ietf-mpls-tp-linear-protection do
not seem to refer to the mechanism they define, as being an OAM
feature, nor does it seem to satisfy an OAM requirement (RFC 5860).
It is suggested to remove the item from the list.
Section 1.2
Next to last paragraph.
It should be noted that the construction of an NMS also depends
on the way the OAM functions are operated and configured.
s/mechanisms that have already been defined and that are currently/
mechanisms that have already been defined or that are currently/
Section 3
The motivation for a single OAM solution in MPLS-TP is ... not to
have two. This is a bit odd as an introductory text. (c.f. general
comment)
Section 3.1
s/and indeed with their first attempt/
and indeed their first attempt/
The last portion (after the comma) of the following sentence is
difficult to understand:
In MPLS-TP, MPLS was extended to satisfy the transport network
requirements in a way that was both compatible with MPLS as has
already been deployed, and MPLS and with the IETF envisioned it
would develop in the future.
Section 3.5
s/particularly give the ultra-pedantic/
particularly given the ultra-pedantic/
Section 6.1
Both the 2nd and 3rd paragraphs describe the case of protocol
packets being recognized as "unknown" yet different levels of
incompatibility seems to be associated to each.
This should be clarified.
4th paragraph states that there are "obvious" issues with
incompatibility, but then only vaguely lists some and does so
independently of the incompatibility grade of seriousness.
If issues are obvious then it is preferable to clearly state
these obvious issues and to associate each to the corresponding
grade of seriousness. (c.f. general comment)
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf