[OPSAWG] RtgDir review: draft-ietf-opsawg-oam-overview-08.txt

["Carlos Pignataro (cpignata)" <[e-mail]>]

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.