Re: [RTG-DIR] RTG-DIR Review: draft-ietf-opsawg-oam-overview-08.txt

["Adrian Farrel" <[e-mail]>]

Resending to correct address.
 
Thanks Sasha for the review.
 
Authors: we asked Sasha to look at this document again (in addition to Carlos'
review) because he had provided a review of a previous version of the document.
 
Thanks,
Adrian
 
From: Alexander Vainshtein [mailto:[e-mail]] 
Sent: 24 January 2013 07:15
To: [e-mail]
Cc: [e-mail]; '[e-mail]'
Subject: RTG-DIR Review: draft-ietf-opsawg-oam-overview-08.txt
 
Hello,
 
I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review. The purpose of the review is
to provide assistance to the Routing ADs. For more information about the Routing
Directorate, please see http://www.ietf.org/iesg/directorate/routing.html 
 
Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft. 
 
Document: draft-ietf-opsawg-oam-overview-08.txt
Reviewer: Alexander ("Sasha") Vainshtein    
Review date: 23-Jan-13
IETF LC End Date: Not known
Intended status: Informational
 
Summary:
 
I have significant concerns about this document and recommend that the Routing
ADs discuss these issues further with the authors.
 
To some extent these concerns reflect my personal and potentially biased
position with regard to OAM. 
 
In addition, I'd like note that this is my second review of this draft. The
previous one has been done in August 2011 and dealt with the -05 version of the
draft (the review is attached). Following this review I've hold a series of
email exchanges and off-line meetings with some of the authors in an attempt to
resolve the issues I've raised; but this process has not ever been completed.
 
My current review hence is mainly focused on resolution (or lack thereof) of the
concerns I've raised in the previous review round. This can be also considered
as a bias (of a kind). Hence I ask - again - the Routing ADs to take my comments
with a grain of salt.
 
Comments:
 
The needs of the assumed target audience are not fully addressed in the draft:
 
Just as in the previous reviewing cycle, I assume that the intended target
audience of the draft consists of various "beginner" groups.  
The current version does not contain any indications that this assumption is
wrong (actually I did not find anything special about target audience in the
draft). Taking into account ongoing OAM-related activities at the IETF (e.g.,
draft-mmm-bfd-on-lags), a good overview document would be indeed most useful for
these groups.
 
Based on this assumption I've then suggested that in order to provide
appropriate guidance to the target audience, the draft should:
 
1.       Include a section on historical background of OAM - not addressed in
the reviewed version of the draft.
a.       The single sentence "OAM was originally used in the world of telephony,
and has been adopted in packet based networks" that has served as a somewhat
short background section has disappeared in this version of the draft
b.      IMHO and FWIW absence of such a section makes it difficult for, say, a
reader with the background in OAM in SONET/SDH and/or OTN networks to understand
why OAM in packet networks is so different.
2.       Present a clear view of OAM functionality and its relationship to
various "planes" of networking - at best, partially addressed in Section 1.2.
However, the new text seems potentially misleading to me, e.g.:
a.       The statement "often the on-demand tools may be activated by the
management" seems to suggest that on-demand OAM tools can be also activated in
some other way. If the intention has been activation of such tools via the
control plane, clarification would be very much in place
b.      Connectivity Verification (CV) is mentioned as one of the "OAM building
blocks" (in Section 1.1), and the draft explains that CV is used to verify that
it is used "to verify that the OAM messages are received through the expected
path". However, the draft does not explain that the expected path is defined
either by the management or by the control plane, so that the entire CV function
does not make much sense without this interaction.
3.       Explain the importance of fate-sharing of OAM and user traffic flows in
packet networks - at best, partially addressed by the current version of the
draft: 
a.       The term "fate-sharing" does not appear in the draft at all
b.      The draft mentions that in MPLS-TP "OAM packets and the user traffic are
required to be congruent" (Section 3.4.1). However, this is not extended to OAM
tools for other IETF-owned technologies (IP, IP/MPLS).
A side note: I am not sure that "congruent flows" and "fate-sharing flows" mean
exactly the same thing. E.g., in IP/MPLS networks LSPs created by LDP are
supposed to be congruent with IP flows, but they are not fate-sharing. 
4.       Explicitly map the notions, terms and methods that have been adopted
from technologies owned by other SDOs (ITU-T and IEEE 802) to IETF-owned
technologies - not addressed. E.g.:
a.       The term "interface" that is, from my point of view one of the basic
notions in the IETF networking, appears in the draft just 3 times:
                                                      i.      Two of the search
hits are in the title of RFC 5837 (which is listed in the draft as one of the
OAM tools without any explanation and then again as a normative reference)
                                                     ii.      The remaining hit
is in Section  2.2.3 in the context of differences in MEP definitions between
ITU-T Y.1731 and IEEE 802.1ag and deals with bridge interfaces, i.e., out of
scope
 
A side note: At the same time the draft mentioned the importance of placement of
an MP (ingress, egress or forwarding function) in Section 2.2.3. I will present
my concerns regarding this text later.
 
b.      The draft mentions ICMP ping and Traceroute as an "OAM tools", but it
does not even try to explain:
                                                      i.      What constitutes
the ME in which these tools operate
                                                     ii.      What are its MEPs
and MIPs etc. (see also some comments below)
c.       The draft effectively ignores recent OAM-related activities as RFC 5837
(see above) and draft-ietf-mpls-tp-mep-mip-map. IMHO and FWIW, these documents
are triggered by real-life operational concerns on one hand and implicitly  (as
in RFC 5837) or even explicitly deal with relationships between interfaces and
nodes on one hand and MPs on the other hand. The caveat about dealing just with
published RFCs may or may not be valid per se, but it definitely does not
justify lack of any explanations/details regarding RFC 5387.
5.       Expose, rather than avoid, known points of contention in a neutral way
- I do not see this as a serious issue now.
 
The bottom line is that the current version of the draft did not meet my
expectations in this regard. This -again - may be because my expectations have
been exaggerated or even completely unrealistic, or because the authors had in
mind a different target audience and a different purpose. (I've said in my first
review that explicitly specifying these (the purpose and the target audience) in
the Introduction section would be helpful - but this has not been done either.)
 
Readability of the draft:
 
>From my point of view the draft still is not easily readable. I'd like to pint
specifically to the following:
not in the least because it contains quite a few inaccurate and/or controversial
statements. E.g.:
1.       Some terms and notions are introduced in the draft as if they were
quite important, only to be forgotten later. E.g.:
a.       Section 1.1 mentions "Throughput measurement" as one of the 3 main
functions of the performance monitoring which, in its turn, is defined as one of
the OAM building blocks. However, throughput measurement is not mentioned
anywhere else in the draft. 
b.      "Communication link" mentioned in Section 2.2.2 is another such example
c.       The first statement in Section 1.1 states that "An OAM protocol is run
in the context of a Maintenance Domain,   consisting of two or more nodes that
run the OAM protocol, referred to as Maintenance Points (MP)", but, again,
Maintenance Domain is not mentioned anywhere else in the draft, leaving the
reader to wonder how it is related to MEs, MEGs and the rest of the acronym
soup.
2.       Some referenced IETF documents are misrepresented. E.g.,:
a.       MPLS LSP Ping is mentioned in Section 1.3 as an "OAM mechanism for
point to point MPLS LSPs". In fact, LSP ping works just fine with LSPs created
by LDP, and these are MP2P
b.       In Section 2.2.3 the draft claims that MPLS-TP "uses ... Up/Down MPs"
and refers to RFC 6371 as its source. However, the corresponding text in RFC
6371 only mentions Up/Down MEPs. (In this regard it is fully consistent with
both IEEE 802.1ag and ITU-T Y.1731). 
3.       There are internal inconsistencies in the draft. E.g.:
a.       The naive interpretation of the already quoted statement from section
1.1 (see 1c above) is that "MPs are nodes"
b.      At the same time Section 2.3.3 states that "A Maintenance Point (MP) is
a functional entity that is defined at a node in the network, and either
initiates or reacts to OAM messages".
 
Major Issues:
 
 
1.       OAM and its relationship to various network planes: In spite of the
authors' attempt to resolve this issue, the concepts of data plane, control
plane and management plane still are not properly explored in the draft:  
a.       The term "data-plane" (with some modifications) is only found in
Section 4.3 when discussing LSP-Ping ("data plane" is also found in the title of
RFC 4379)
b.      An additional term "forwarding plane" appears in section 1.2, but
nowhere else. The draft does not explain whether it means the same as data plane
or not
c.       The terms "control-plane" ("control plane") are a bit more popular.
They can be found:
                                                                  i.      In
Section 1.2 (which states that "OAM tools are defined independent of control
plane" and that considerations of the control plane maintenance tools are out of
scope)
                                                                 ii.      In
Section 3.3 (MPLS OAM) that explains that LSP Ping verifies "data-plane vs.
control-plane consistency for FEC". This statement is correct, but IMO
inconsistent with the previous one (see also my comment about CV above)
                                                               iii.      In
Section 3.4 (MPLS-TP OAM) - mainly to explain that control plane is neither
mandatory nor precluded in  MPLS-TP
d.      The term "management plane" (with or without dash) appears only in
Section 1.2. In addition to the already mentioned ability to operate on-demand
OAM tools, ability of these tools to raise alarms is mentioned 
                                                                  i.      This
is definitely a step forward vs. the -05 version
                                                                 ii.      While
RFC 6427 is now referenced in the draft (it was missing in the previous
version), the draft does not mention alarm suppression function. And while it
mentions AIS in MPLS-TP it only points to RFC 6327 for the explanation of the
consequent actions of AIS. 
                                                               iii.      For the
sake of completeness, ability to clear alarms should also be mentioned IMO - but
this is a very minor issue.
e.      The term "test plane" appears in Section 4.5, but, as already mentioned
above,  specific test plane protocols are not discussed in the draft
2.       OAM in connectionless vs. connection-oriented networks
a.       The first sentence in Section 1 states that "OAM is a general term that
refers to a toolset for detecting, isolating and reporting connection failures
and performance degradation". To me this suggests that OAM is applicable only to
connection-oriented networks (if you do not have connections, connection
problems do not exist by definition).
b.      The term "connection" appears in some other places in the draft, e.g.,
the connectivity check "is used to verify the liveness of a connection" (Section
1.1).
c.       At the same time, the draft discusses:
                                                                  i.      ICMP
Ping (Section 3.1.1) operating in connectionless IP networks
                                                                 ii.
LSP-Ping in MPLS networks (Section 3.3). Since LSP-Ping as defined in RFC 4379
is applicable to LSPs set up by LDP, I'd say that it operates in connectionless
environment
                                                               iii.
Ethernet OAM (1.5) operating in connectionless Ethernet networks etc.
3.       The Mess of MEs, MPs, MEPs and MIPs. 
a.       Please consider the following text fragments
                                                                  i.      (In
section 2.2.2) OAM tools are designed to monitor and manage a Maintenance Entity
(ME).  An ME, as defined in [TP-OAM-FW], defines a relationship between two
points of a transport path to which maintenance and monitoring operations apply.

                                                                 ii.
(ibid.) Various terms are used to refer to an ME. For example, BFD does not
explicitly use a term that is equivalent to ME, but rather uses the term
"session", referring to the relationship between two nodes using a BFD protocol.
The MPLS LSP Ping ([LSP-Ping]) terminology simply uses the term "LSP" in this
context
                                                               iii.      (In
Section 2.2.3) A Maintenance Point (MP) is a functional entity that is defined
at a node in the network, and either initiates or reacts to OAM messages. A
Maintenance End Point (MEP) is one of the end points of an ME, and can initiate
OAM messages and respond to them. A Maintenance Intermediate Point (MIP) is an
intermediate point between two MEPs, that does not generally initiate OAM frames
(one exception to this is the use of AIS notifications), but is able to respond
to OAM frames that are destined to it.
                                                               iv.      (Ibid.)
MPLS-TP ([TP-OAM-FW]) uses a similar distinction on the placement of the MP -
either at the ingress, egress, or forwarding function of the node (Down / Up
MPs).  This placement is important for localization of a connection failure.
b.      The last of these statements seems to hint that with just two  mutually
exclusive types of MPs (UP/DOWN) it is possible to associated an MP with one of
3 possible placements (ingress, egress or forwarding function).
c.       IMHO and FWIW combining these statements can result in some unexpected
(and undesirable) conclusions. E.g., 
                                                                  i.
Premises:
.         An MPLS LSP is an ME in the case of LSP Ping
.         An ME defines a point-to-point relationship between two points on a
transport path
.         These points are defined at nodes
Conclusion: An MPLS LSP can cross only two nodes (because in IP/MPLS LSP Ping
can be initiated from any node participating in an LSP).
                                                                 ii.
Premises:
.         BFD as defined in RFC 5880 is an OAM tool (it is listed as such in
Table 1 in section 1.4)  
.         OAM tools are designed to monitor MEs
.         In the case of a BFD  a BFD session (there are no other sessions in
RFC 5880) is an ME
Conclusion: BFD is designed to monitor its own sessions (and hence is completely
useless).
 
 
A Side Note: The majority of problematic definitions in the draft are based on
RFC 6371. IMHO and FWIW this results in 3 types of problems:
.         The authors misinterpret RFC 6371. E.g., it only speaks about UP and
DOWN MEPs, not about UP and DOWN MPs , and it does not discuss
ingress/egress/forwarding engine placement
.         The authors have tried to extend the definitions from 6371 to other
IETF technologies (IP and IP/MPLS). E.g., in MPLS-TP sending LSP-Ping packets
from an intermediate node of a co-routed bi-directional LSP towards one of its
endpoints is possible, but the responses would not be received by the
initiator... 
.         Some of the original definitions in 6371 are problematic (among other
things, this applies to UP and DOWN MEPs).
 
Minor Issues:
1.       Limited coverage of performance measurement. 
a.       The draft mentions packet loss, delay/delay variation and the
(undisclosed) throughput measurement. 
b.      At the same time it ignores such issues as duplication and reordering
(and does not mention RFC 4347 and RFC 5560 respectively)
c.       Connectivity measurement (RFC 2678) is referenced and mentioned in the
text. But it is not mapped to any of the main performance measurements functions
2.       Proposed classification of the IETF documents (into tools, profiles,
infrastructure and miscellaneous) could be useful but is not consistently
applied. E.g.,
a.       I do not think that RFC 792 defines an OAM Tool
b.      I have serious doubts that RFC 4556 and RFC 5337 (defining the control
plane for the IPPM mechanisms) are "OAM Tools" while all the referenced specific
measurement protocols are "Miscellaneous" etc.
 
Unfortunately could not provide any useful information regarding nits, typos
etc. My review is incomplete in this regard, and I owe apologies to Routing ADs,
my colleagues in the Routing Directorate and the authors. 
 
Regards,
     Sasha
 
 
 
This e-mail message is intended for the recipient only and contains information
which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
received this transmission in error, please inform us by e-mail, phone or fax,
and then delete the original and all copies thereof.