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, and sometimes on special
request. 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: Carlos Pignataro
Review Date: 18 January 2013
IETF LC End Date: 25 January 2013
Intended Status: Informational
Summary:
I have significant concerns about this document and recommend that the Routing
ADs discuss these issues further with the authors.
Comments:
This document presents an overview of Operations, Administration, and
Maintenance (OAM) mechanisms in the IETF. This is a very useful document that
uses OAM consistently with the definition in RFC6291, and further explains the
acronym by presenting a wider scope and a more concrete view.
However, the taxonomy in which all these "mechanics" are presented is
confusing, because they seem to intertwine the terms functions, tools, and
protocols. These terms are used quite loosely in this document, which is
counter to its goal of providing clarity. "The beginning of wisdom is a
definition of terms", and for example, this document defines the "Continuity
Check" OAM functionality as a tool, and the ICMPv4 protocol as a tool.
The overall organization of the document does not seem to help sometimes, with
a "Basic Terminology" section after all tools and documents are described and
cited.
Major Issues:
The main major set of issues that I found have to do with terminology used,
which is critical for a document that attempts to bring clarity with an
overview of OAM mechanisms. This is described in the preceding comments.
Additionally, the taxonomy in which these OAM mechanisms are presented seems to
have gaps and gross overlaps. Section 1.3 groups "OAM toolsets" with a network
on which OAM is used (MPLS), a protocol used for OAM (BFD), a tool (Ping and
Traceroute), etc. Different protocols (e.g., both ICMPv4 and BFD) can be use on
different networks (MPLS, IPv4, PW); they can be used in different tools for
different utilities. ICMPv4 can be used in VCCV, Traceroute for MPLS can use
ICMP or LSP Ping, BFD can be used for IP and MPLS for CC, etc. All these
different categorization vectors seem to be intertwined.
This then is reflected taking Table 1, "Summary of IETF Related RFCs", as an
example; it is not clear what is the categorization criteria. The indexes into
the table are "IP Ping and Traceroute" (these are tools -- does this mean that
there are the only OAM mechanisms for IP networks?), "BFD" (a protocol which
applies to IP, MPLS, Pseudowires, Tunnels, and others), "MPLS OAM" (OAM for a
particular packet switched network, some of which are BFD, but are already
covered in the previous meta-row), "OWAMP and TWAMP: (another protocol for IP
performance metrics), and so on.
A potential large amount of minor issues could compound as a major one as well.
Some more specific inlined comments follow.
1. Introduction
…
This document summarizes the OAM tools and mechanisms defined in the
IETF.
If the scope is "IETF", it should be reflected in the title. However, this
seems to contradict the whole Section 1.5, "Non-IETF OAM Documents".
1.2. Forwarding Plane vs. Management Plane
This section and intended scope seems to be underspecified. In fact, the
document later speaks about other planes, including "user-plane", "Data plane",
and "Test plane". Perhaps an architectural scope depiction would simplify this
description and localize the "planes" with more precision.
Minor Issues:
1. Introduction
OAM is a general term that refers to a toolset for detecting,
isolating and reporting connection failures and performance
degradation.
OAM, as defined in RFC6291 (see Section 3), seems to be more broadly defined
than this first paragraph.
1.1. The Building Blocks of OAM
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).
Is this generic OAM terminology
...
This subsection provides a brief summary of the common tools used by
OAM protocols. An OAM protocol typically supports one or more of the
tools described below.
o Continuity Checking (CC):
Are these "OAM tools" of "OAM functions" supported by "OAM protocols"?
…
o Path Discovery / Fault Localization:
An MP uses this mechanism to trace the route to a peer MP, i.e.,
to identify the nodes along the path to the peer MP. When a
connection fails, this mechanism also allows the MP to detect the
location of the failure.
"the path" assumes there is a single path and not potential multi-path. Some
OAM mechanisms included in this document support multi-path tree tracing. There
are also implications of connection-less vs. connection-oriented protocols and
paths, which are seemingly not covered.
1.3. The OAM toolsets
This memo provides an overview of the different sets of OAM
mechanisms defined by the IETF. It is intended for those with little
or no familiarity with the described mechanisms.
Only defined by the IETF? This contradicts a subsequent section
The set of OAM
mechanisms described in this memo are applicable to IP unicast, MPLS,
pseudowires, and MPLS for the transport environment (MPLS-TP).
"transport environments", or "Transport Profile"?
While
OAM mechanisms that are applicable to other technologies exist, they
are beyond the scope of this memo.
How where these chosen, and others left out then?
This document focuses on IETF
documents that have been published as RFCs, while other ongoing OAM-
related work is outside the scope.
IETF only (contradicting Section 1.5), and now limited to published RFCs? The
scope could be defined before in the document, once only, and more deliberately.
The IETF has defined OAM protocols and mechanisms in several
different fronts:
>From the list that follows, which one is a protocol versus a mechanism, and
>why are those different qualifiers mixed together in a flat list instead of
>matrixed in?
o IP Ping and Traceroute:
Ping is a very simple and common application for failure diagnosis
that uses ICMP Echo requests, as defined in [ICMPv4], and
[ICMPv6].
Five issues on this first part of this bullet:
1. Is "failure diagnostic" a new function?
2. What is defined in those two RFCs? Only ICMP and not Ping and Traceroute.
However, it is not clearly articulated.
3. It would be useful to describe where Ping with much more historical context,
for example:
RFC1208 ("A Glossary of Networking Terms") defines:
ping: Packet internet groper. A program used to test reachability of
RFC 1122 as:
* Active probes such as "pinging" (i.e., using an ICMP
4. Ping for IPv4 uses ICMPv4 Echo (not Echo Request) and Echo Reply. Ping for
IPv6 uses Echo Request *and* Echo Reply.
5. "simple" and "common" are in relationship to which baseline? In what network?
Traceroute ([TCPIP-Tools], [NetTools]) is an application that
allows users to trace the path between an IP source and an IP
destination, i.e., to identify the nodes along the path.
There is some asymmetry of definitions where Ping is defined based on ICMP (and
not its function of reachability/CC), but traceroute is not defined based on
the protocols used.
Also, I have another concern on a potential over-simplification: "to trace the
path between an IP source and an IP destination", implicitly assumes there is
only one path. This is not the case generally, and frankly it highlights the
potential need of distinction in OAM for connection-less protocols versus
connection-oriented protocols (clps, cops) and implications on path tree trace.
o MPLS OAM:
MPLS LSP Ping, as defined in [MPLS-OAM], [MPLS-OAM-FW] and [LSP-
Ping], is an OAM mechanism for point to point MPLS LSPs. It
includes two main functions: Ping and Traceroute.
To me, bullets like this one are quite misleading. MPLS LSP Ping is one
protocol and function to perform "MPLS OAM". But BFD is also used for "MPLS
OAM", and so is "ICMPv4 Echo"
o OWAMP and TWAMP:
The One Way Active Measurement Protocol (OWAMP) and the Two Way
Active Measurement Protocols (TWAMP) are two protocols defined in
the IP Performance Metrics (IPPM) working group in the IETF. These
protocols allow delay and packet loss measurement in IP networks.
These allow for more performance measurements (duplication, reordering, etc).
It is not totally clear, consequently, if the enumeration is Section 1.1 is
inclusive enough.
1.4. IETF OAM Documents
The table includes a "Type" column, specifying the nature of each of
the listed documents:
…
o Inf.: documents that define an infrastructure that is used by OAM
tools.
Infrastructure for OAM tools seems to not have been defined.
Table 1 needs to be consistent with what is a Tool, Protocol, etc, and how to
categorize (as per comments above). For example:
+-----------+--------------------------------------+-----+----------+
| | Title |Type | RFC |
+-----------+--------------------------------------+-----+----------+
|IP Ping and| Internet Control Message Protocol |Tool | RFC 792 |
|Traceroute | [ICMPv4] | | |
| +--------------------------------------+-----+----------+
| | Internet Control Message Protocol |Tool | RFC 4443 |
| | (ICMPv6) for the Internet Protocol | | |
| | Version 6 (IPv6) Specification | | |
| | [ICMPv6] | | |
| +--------------------------------------+-----+----------+
These two RFCs do not define "Tools" (as indicated by the table). Further,
traceroute can use UDP (or any IP protocol really) and ICMP errors in addition
to ICMP.
| +--------------------------------------+-----+----------+
| | ICMP Extensions for Multiprotocol |Tool | RFC 4950 |
| | Label Switching [ICMP-Ext] | | |
| +--------------------------------------+-----+----------+
Is this IP traceroute, MPLS OAM, both?
Table 2 summarizes the OAM standards mentioned in this document.
Table 2 seems to summarize something different. This sentence should read
similar to the legend of the Table.
2. Basic Terminology
Basic terminology and abbreviations should have taken place before all the
previous discussion.
FEC Forwarding Equivalence Class
LDP Label Distribution Protocol
The document says that control-plane OAM functions are out of scope. However,
some control plane functions are explained (and others are not). LSP Ping, for
example, compares forwarding with control plane. LDP here is control plane.
3.1.1. Ping
3.1.2. Traceroute
Please note that the comments about PING and traceroute already mentioned apply
equality to these sections.
Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows
users to discover the path between an IP source and an IP
destination. Traceroute sends a sequence of UDP packets to UDP port
33434 at the destination. By default, Traceroute begins by sending
This is describing a specific implementation of traceroute. Some stacks use
ICMP probes in traceroute. tcptraceroute uses, well, TCP SYNs as probes,
because it is more friendly to detecting the final hop destination if it is for
example a web server. traceroute-nanog and others allow to specify which IP
protocol and which ports.
Traceroute implementations), each with an IP Time-To-Live (TTL) value
[and hop limit for IPv6]
the first router in the path. That router responds by sending three
ICMP Time Exceeded Messages to the Traceroute application. Traceroute
This, as written, seems misleading. It does not "respond by sending three ICMP
time exceeded messages"…
Note that IP routing may be asymmetric. While Traceroute reveals the
path between a source and destination, it may not reveal the reverse
path.
See above, this also assumes "the one and only path". This reveals the path for
that specific flow used in the probes.
A few ICMP extensions ([ICMP-Ext], [ICMP-MP], [ICMP-Int]) have been
defined in the context of Traceroute. These extensions augment the
ICMP Destination Unreachable message, and can be used by Traceroute
applications.
Some extensions, for example ICMP-Int, are not only defined in the context of
Traceroute.
They also augment many other ICMPs beyond dest unreach.
3.3. MPLS OAM
LSP Ping is based on ICMP Ping and just like its predecessor may be
used in one of two modes:
3.4.2. Generic Associated Channel
The G-ACh section is a sub-section of MPLS-TP. However, this is a generic MPLS
mechanism.
3.4.3.5. Alarm Reporting
Is this a management plane function?
3.5.1. PWE3 OAM using Virtual Circuit Connectivity Verification (VCCV)
VCCV, as defined in [VCCV], provides a means for end-to-end fault
detection and diagnostics tools to be extended for PWs (regardless of
the underlying tunneling technology). The VCCV switching function
provides a control channel associated with each PW (based on the PW
Associated Channel Header (ACH) which is defined in [PW-ACH]), and
allows transmitting the OAM packets in-band with PW data (using CC
Type 1: In-band VCCV).
This describes Type 1 VCCV CC Type. However it does not describe Types 2 and 3…
3.7. Summary of OAM Functions
OWAMP and TWAMP also support CC and CV.
4. Security Considerations
I would think that for a document chartered with providing an overview of OAM
mechanisms, a discussion of security considerations of OAM functions
(abstracted from the protocols and tools) would be most useful, much than the
current "check every RFC we point to".
Nits:
idnits calls out a couple nits about the References:
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-opsawg-oam-overview-08.txt
Section 1.2:
The considerations of the control-plane maintenance tools or the
functionality of the management-plane are out of scope for this
:s/or/and/ ?
Ping], is an OAM mechanism for point to point MPLS LSPs. It
point-to-point ?
An MP is a bridge interface, that is monitored by an OAM protocol
:s/,// ?
3.2. Bidirectional Forwarding Detection (BFD)
Has the BFD WG reviewed these sections?
3.3. MPLS OAM
LSP Ping is based on ICMP Ping and just like its predecessor may be
used in one of two modes:
LSP Ping is not "based" on ICMP Ping. It is modeled after the ping/traceroute
paradigm, which is quite different!
o "Ping" mode: In this mode LSP ping is used for end-to-end
connectivity verification between two LERs.
IP Ping is not used for connectivity verification -- it is used for continuity
check, however the text implies they are used equivalently.
3.4.3.2. Route Tracing
The document seems to use interchangeably "route trace", "path trace", and
other variations.
I hope these are clear and useful!
Thank you,
Carlos Pignataro.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
