Re: [OPSAWG] Last Call: <draft-ietf-opsawg-oam-overview-08.txt> (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC

[Benoit Claise <[e-mail]>]

Hi Tal,

AFAICT, this issue below is the only one left on the draft. The draft 
improved much, thanks.
Please post a new version with the change, and I'll put it on the IESG 
table.

Regards, Benoit
>
> Hi Tom,
>
> Thanks for the prompt response.
>
> We will apply this change in the next draft.
>
> Thanks,
>
> Tal.
>
> *From:*Thomas Nadeau [mailto:[e-mail]]
> *Sent:* Tuesday, January 28, 2014 5:38 PM
> *To:* Tal Mizrahi
> *Cc:* [e-mail]; [e-mail]; 
> [e-mail]; Benoit Claise; joel jaeggli 
> ([e-mail]); Scott O. Bradner ([e-mail])
> *Subject:* Re: Last Call: <draft-ietf-opsawg-oam-overview-08.txt> (An 
> Overview of Operations, Administration, and Maintenance (OAM) 
> Mechanisms) to Informational RFC
>
> The changes look ok except for one minor one:
>
> One of the changes in 4.4.2 BFD for MPLS states the following:
>
> The advantage of BFD is that it can
>
> 	
>
> 	
> 	
>
>
> 	
>
>    provide faster failure detection, and scales better to a large number
>
> 	
>
> 	
> 	
>
>
> 	
>
>    of LSPs
>
> 	
>
> That is a popular misconception. When I at a previous gig we were able 
> to actually figure out how to make them both perform
>
> equally well for CV operations, but we just decided to not implement 
> it that way. I'd suggest removing that sentence altogether.
>
> They are two tools with different implementations, some more optimal 
> than others.
>
>     Hi Tom,
>
>     Thanks again for your comments.
>
>     A link to the updated draft:
>
>     http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-13
>
>     We believe the current draft addresses all the comments below.
>
>     We have replied to every single comment below (search for [TM]).
>
>     Please let us know if you believe something is still amiss.
>
>     Thanks,
>
>     Tal.
>
>     *From:*Thomas Nadeau [mailto:[e-mail]]
>     *Sent:* Monday, January 20, 2014 5:29 PM
>     *To:* Benoit Claise
>     *Cc:* [e-mail]
>     <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>; IETF Disgust
>     *Subject:* Re: Last Call: <draft-ietf-opsawg-oam-overview-08.txt>
>     (An Overview of Operations, Administration, and Maintenance (OAM)
>     Mechanisms) to Informational RFC
>
>     Reviewing the current version of the draft (12), many of the
>     comments below are still not addressed.
>
>     --Tom
>
>         Here is Tom Nadeau's feedback, forwarded with permission:
>
>         Regards, Benoit
>
>         ==============
>
>         Some general comments:
>
>          1. I did not find any discussion around use of configuration
>             within OAM mechanisms. This is clearly something that is
>             happening in groups like PWE3 and CCAMP. The motivation
>             for this should be explained and documented to at least
>             guide these efforts.
>
>         */[TM] The current draft includes a significantly clearer
>         explanation, up front  in the abstract and introduction, that
>         this document focuses on OAM tools, i.e., on the data plane of
>         OAM. That is why, for example we do not discuss configuration
>         contexts such as CCAMP./*
>
>         2. There is no real discussion around the security aspects of
>         these tools. Should there be?
>
>         *//*
>
>         */[TM] We received a similar comment from other reviewers, as
>         well as the SecDir review in the previous IETF last call.
>         After some discussion between our AD at the time (Ron Bonica)
>         and the Sec AD (Sean Turner), the current phrasing of the
>         "Security Considerations" section was agreed. It is mainly an
>         issue of where you draw the line between which content to
>         include and which content not to include in the draft, and
>         security is currently out of scope. /*
>
>         3. While the document provides a nice taxonomy of various OAM
>         tools, it does not really discuss the techniques for using
>         them. I do not expect anything in detail, but it is not
>         obvious that many of these tools can be orchestrated to form a
>         "toolset" that can be used to do multi-layer OAM functions for
>         services such as carrier Ethernet over VPLS over MPLS, for
>         example.
>
>         *//*
>
>         */[TM] Following your comment, we added quite a bit of text to
>         the introduction to explain this multi-layer orchestration.
>         You can take full credit for the fact that this doll IETF
>         draft now includes an ASCII art figure (Figure 1). :)/*
>
>         4. It might be useful to at least mention in the performance
>         metrics section, a discussion around the accuracy of these
>         tools and how it depends on scale, implementation and network
>         configurations.
>
>         */[TM] Following your comment we added a note about this in
>         section 4.7.1. See the paragraphs beginning with "It should be
>         noted that while [OWAMP]..."./*
>
>         My detailed comments inline starting with TOM:
>
>         --Tom
>
>             Expires: July 2013                          Nokia Siemens
>             Networks
>
>                                              E. Bellagamba
>
>             Ericsson
>
>                                              Y. Weingarten
>
>                                            January 9, 2013
>
>                 An Overview of
>
>                     Operations, Administration, and Maintenance (OAM)
>             Mechanisms
>
>              draft-ietf-opsawg-oam-overview-08.txt
>
>             Abstract
>
>                Operations, Administration, and Maintenance (OAM) is a
>             general term
>
>                that refers to a toolset that can be used for fault
>             detection and
>
>                isolation, and for performance measurement. OAM
>             mechanisms have been
>
>                defined for various layers in the protocol stack, and
>             are used with a
>
>                variety of protocols.
>
>                This document presents an overview of the OAM
>             mechanisms that have
>
>                been defined and are currently being defined by the IETF.
>
>             Status of this Memo
>
>                This Internet-Draft is submitted to IETF in full
>             conformance with the
>
>                provisions of BCP 78 and BCP 79.
>
>                Internet-Drafts are working documents of the Internet
>             Engineering
>
>                Task Force (IETF), its areas, and its working groups.
>              Note that
>
>                other groups may also distribute working documents as
>             Internet-
>
>                Drafts.
>
>                Internet-Drafts are draft documents valid for a maximum
>             of six months
>
>                and may be updated, replaced, or obsoleted by other
>             documents at any
>
>                time.  It is inappropriate to use Internet-Drafts as
>             reference
>
>                material or to cite them other than as "work in progress."
>
>                The list of current Internet-Drafts can be accessed at
>
>             http://www.ietf.org/ietf/1id-abstracts.txt.
>
>                The list of Internet-Draft Shadow Directories can be
>             accessed at
>
>             http://www.ietf.org/shadow.html.
>
>                This Internet-Draft will expire on July 9, 2013.
>
>             Mizrahi, et al. Expires July 9, 2013                  [Page 1]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>             Copyright Notice
>
>                Copyright (c) 2013 IETF Trust and the persons
>             identified as the
>
>                document authors. All rights reserved.
>
>                This document is subject to BCP 78 and the IETF Trust's
>             Legal
>
>                Provisions Relating to IETF Documents
>
>                (http://trustee.ietf.org/license-info) in effect on the
>             date of
>
>                publication of this document. Please review these documents
>
>                carefully, as they describe your rights and
>             restrictions with respect
>
>                to this document. Code Components extracted from this
>             document must
>
>                include Simplified BSD License text as described in
>             Section 4.e of
>
>                the Trust Legal Provisions and are provided without
>             warranty as
>
>                described in the Simplified BSD License.
>
>             Table of Contents
>
>                1. Introduction
>             ................................................. 3
>
>                   1.1. The Building Blocks of OAM
>             .............................. 3
>
>                   1.2. Forwarding Plane vs. Management Plane
>             ................... 4
>
>                   1.3. The OAM toolsets
>             ........................................ 4
>
>                   1.4. IETF OAM Documents
>             ...................................... 6
>
>                   1.5. Non-IETF OAM Documents
>             ................................. 10
>
>                2. Basic Terminology
>             ........................................... 12
>
>                   2.1. Abbreviations
>             .......................................... 12
>
>                   2.2. Terminology used in OAM Standards
>             ...................... 13
>
>                      2.2.1. General Terms
>             ..................................... 13
>
>                      2.2.2. OAM Maintenance Entities
>             .......................... 13
>
>                      2.2.3. OAM Maintenance Points
>             ............................ 14
>
>                      2.2.4. Proactive and On-demand activation
>             ................ 15
>
>                      2.2.5. Connectivity Verification and Continuity
>             Checks ... 15
>
>                      2.2.6. Failures
>             .......................................... 15
>
>                3. OAM Tools
>             ................................................... 16
>
>                   3.1. IP Ping and Traceroute
>             ................................. 16
>
>                      3.1.1. Ping
>             .............................................. 16
>
>                      3.1.2.
>             Traceroute......................................... 16
>
>                   3.2. Bidirectional Forwarding Detection (BFD)
>             ............... 17
>
>                      3.2.1. Overview
>             .......................................... 17
>
>                      3.2.2. BFD Control
>             ....................................... 17
>
>                      3.2.3. BFD Echo
>             .......................................... 18
>
>                   3.3. MPLS OAM
>             ............................................... 18
>
>                   3.4. MPLS-TP OAM
>             ............................................ 19
>
>                      3.4.1. Overview
>             .......................................... 19
>
>                      3.4.2. Generic Associated Channel
>             ........................ 19
>
>                      3.4.3. MPLS-TP OAM Toolset
>             ............................... 20
>
>                         3.4.3.1. Continuity Check and Connectivity
>             Verification 20
>
>             Mizrahi, et al. Expires July 9, 2013                  [Page 2]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                         3.4.3.2. Route Tracing
>             ................................ 21
>
>                         3.4.3.3. Lock Instruct
>             ................................ 21
>
>                         3.4.3.4. Lock Reporting
>             ............................... 21
>
>                         3.4.3.5. Alarm Reporting
>             .............................. 21
>
>                         3.4.3.6. Remote Defect Indication
>             ..................... 22
>
>                         3.4.3.7. Client Failure Indication
>             .................... 22
>
>                         3.4.3.8. Packet Loss Measurement (LM)
>             ................. 22
>
>                         3.4.3.9. Packet Delay Measurement (DM)
>             ................ 22
>
>                   3.5. PWE3 OAM
>             ............................................... 23
>
>                      3.5.1. PWE3 OAM using Virtual Circuit
>             Connectivity Verification
>
>                      (VCCV)
>             ................................................... 23
>
>                      3.5.2. PWE3 OAM using G-ACh
>             .............................. 24
>
>                   3.6. OWAMP and
>             TWAMP......................................... 24
>
>                      3.6.1. Overview
>             .......................................... 24
>
>                      3.6.2. Control and Test Protocols
>             ........................ 24
>
>                      3.6.3. OWAMP
>             ............................................. 25
>
>                      3.6.4. TWAMP
>             ............................................. 26
>
>                   3.7. Summary of OAM Functions
>             ............................... 26
>
>                4. Security Considerations
>             ..................................... 27
>
>                5. IANA Considerations
>             ......................................... 27
>
>                6. Acknowledgments
>             ............................................. 27
>
>                7. References
>             .................................................. 28
>
>                   7.1. Normative References
>             ................................... 28
>
>                   7.2. Informative References
>             ................................. 31
>
>             1. Introduction
>
>                OAM is a general term that refers to a toolset for
>             detecting,
>
>                isolating and reporting connection failures and performance
>
>                degradation.
>
>                This document summarizes the OAM tools and mechanisms
>             defined in the
>
>                IETF.
>
>                The term OAM in this document refers to Operations,
>             Administration
>
>                and Maintenance [OAM-Def], focusing on the forwarding
>             plane of OAM.
>
>                Hence, management aspects are outside the scope of this
>             document.
>
>         TOM: This is a curious sentence to me since to me, OAM is
>         management, or a subset of it.   Also, if you look at the
>         referenced documents, there are many indirect references to
>         MIBs, Netconf, etc... making this sentence further confusing.
>         It might be helpful to explain more clearly that the authors
>         here intended to not cover those things explicitly rather than
>         grouping them arbitrarily under the definition of "management
>         aspects"  Further, to clarify, it might be useful to expand on
>         what "forwarding plane" is here just to be clear.   That is,
>         is this "in band" or "out-of band" or both? Some of the tools
>         referred to here also are part of the control AND data planes.
>
>         */[TM] We significantly improved the distinction between the
>         different planes: data plane, control plane, management plane.
>         We added a definition of each of the terms, and we now
>         explicitly explain that the draft focuses on the data plane.
>         We also explain in the current draft that we adopt the OAM
>         acronym as recommended in RFC 6291: Operations, Administration
>         and Maintenance (without Management...). Please let us know if
>         you think something is still missing here./*
>
>             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).
>
>                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.
>
>             Mizrahi, et al. Expires July 9, 2013                  [Page 3]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                o Continuity Checking (CC):
>
>                   Used for verifying the liveness of a connection
>             between two MPs.
>
>                o Connectivity Verification (CV):
>
>                   Allows an MP to check whether it is connected to a
>             peer MP, and to
>
>                   verify that messages from the peer MP are received
>             through the
>
>                   expected path.
>
>                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.
>
>         TOM: The definition calls this "path discovery" but then talks
>         about tracing routes. A better way of describing this in the
>         paragraph would be that there I a use of path tracing in order
>         to discover (or re-discover) paths that have been changed,
>         created or destroyed.
>
>         */[TM] We rephrased this paragraph, and hopefully it is
>         clearer and more accurate now./*
>
>                o Performance Monitoring:
>
>                   Consists of 3 main functions
>
>                     o Loss Measurement (LM) - monitors the packet loss
>             rate of a
>
>                       connection.
>
>                     o Delay Measurement (DM) - monitors the delay and
>             delay
>
>                       variation between MPs.
>
>                     o Throughput measurement - monitors the throughput
>             of a
>
>                       connection.
>
>         TOM: Along with the discussion above around path
>         trace/discovery, it is imperative that paths be discovered
>         (one way or another) in order to successfully d performance
>         monitoring on those paths.
>
>         */[TM] True. However this section presents a short list of
>         typical OAM functions, and we would rather stick with succinct
>         descriptions in this section. /*
>
>             1.2. Forwarding Plane vs. Management Plane
>
>                While the OAM tools may, and quite often do, work in
>             conjunction with
>
>                a control-plane or management plane, they are usually
>             defined to be
>
>                independent of the control-plane.  The OAM tools
>             communicate with the
>
>                management plane to raise alarms, and often the
>             on-demand tools may
>
>                be activated by the management, e.g. to locate and
>             localize problems.
>
>                The considerations of the control-plane maintenance
>             tools or the
>
>                functionality of the management-plane are out of scope
>             for this
>
>                document, which will concentrate on presenting the
>             forwarding-plane
>
>                tools that are used for OAM.
>
>         TOM: What about the data plane? For example, the GACH OAM type
>         is such an example. VCCV also operates within the data plane
>         after its configuration capabilities have been signaled.  It
>         should also be mentioned that it is imperative that when
>         required, OAM tools are capable of testing the actual data
>         plane in as much accuracy as possible, but that they all
>         should note how accurate.   Not all OAM tools are created equal.
>
>         */[TM] We rephrased this subsection, and now have a much
>         clearer definition of each plane in "2.2.4. Data Plane,
>         Control Plane and Management Plane". We also added specific
>         text about the importance of fate-sharing (see section 1.4),
>         which addresses the second part of your comment./*
>
>             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. The
>             set of OAM
>
>                mechanisms described in this memo are applicable to IP
>             unicast, MPLS,
>
>                pseudowires, and MPLS for the transport environment
>             (MPLS-TP). While
>
>                OAM mechanisms that are applicable to other
>             technologies exist, they
>
>             Mizrahi, et al. Expires July 9, 2013                  [Page 4]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                are beyond the scope of this memo. This document
>             focuses on IETF
>
>                documents that have been published as RFCs, while other
>             ongoing OAM-
>
>                related work is outside the scope.
>
>                The IETF has defined OAM protocols and mechanisms in
>             several
>
>                different fronts:
>
>                o IP Ping and Traceroute:
>
>                   Ping is a very simple and common application for
>             failure diagnosis
>
>         TOM: I am not sure the term "common" is necessary.
>
>         */[TM] Removed./*
>
>                   that uses ICMP Echo requests, as defined in
>             [ICMPv4], and
>
>                   [ICMPv6].
>
>                   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.
>
>                o BFD:
>
>                   Bidirectional Forwarding Detection (BFD) is defined
>             in [BFD] as a
>
>                   framework for a lightweight generic OAM mechanism.
>              The intention
>
>                   is to define a base mechanism that can be used with
>             various
>
>                   encapsulation types, network environments, and in
>             various medium
>
>                   types.
>
>                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.
>
>                o MPLS-TP OAM:
>
>                   MPLS-TP OAM is defined in a set of RFCs. The OAM
>             requirements for
>
>                   MPLS Transport Profile (MPLS-TP) are defined in
>             [MPLS-TP-OAM].
>
>                   Each of the tools in the OAM toolset is defined in
>             its own RFC, as
>
>                   specified in Section 1.4.
>
>                o PWE3 OAM:
>
>                   The PWE3 OAM architecture defines control channels
>             that support
>
>                   the use of existing IETF OAM tools to be used for a
>             pseudowire
>
>                   (PW).  The control channels that are defined in
>             [VCCV] and [PW-G-
>
>                   ACH] may be used in conjunction with ICMP Ping, LSP
>             Ping, and BFD
>
>                   to perform CC and CV functionality.  In addition the
>             channels
>
>                   support use of any of the MPLS-TP based OAM tools
>             for completing
>
>                   their respective OAM functionality for a PW.
>
>                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.
>
>             Mizrahi, et al. Expires July 9, 2013                  [Page 5]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                This document summarizes the OAM mechanisms defined by
>             the IETF. We
>
>                first present a comparison of the terminology used in
>             various OAM
>
>                standards, and then summarize the OAM functions that
>             each OAM
>
>                standard provides.
>
>             1.4. IETF OAM Documents
>
>                Table 1 summarizes the IETF OAM related RFCs discussed
>             in this
>
>                document.
>
>                The table includes a "Type" column, specifying the
>             nature of each of
>
>                the listed documents:
>
>                o Tool: documents that define an OAM tool or mechanism.
>
>                o Prof.: documents that define a profile or a variant
>             for an OAM
>
>                   tool that is defined in other documents.
>
>                o Inf.: documents that define an infrastructure that is
>             used by OAM
>
>                   tools.
>
>                o Misc.: other OAM related documents, e.g., OAM
>             requirement and
>
>                   framework documents.
>
>              +-----------+--------------------------------------+-----+----------+
>
>                |           | 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]                             |  
>               |  |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | A Primer On Internet and TCP/IP    
>              |Tool | RFC 2151 |
>
>                |           | Tools and Utilities [TCPIP-Tools]    |  
>               |    |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | FYI on a Network Management Tool    
>             |Tool | RFC 1147 |
>
>                |           | Catalog: Tools for Monitoring and    |  
>               |  |
>
>                |           | Debugging TCP/IP Internets and       |  
>               |          |
>
>                |           | Interconnected Devices [NetTools]    |  
>               |          |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | Extended ICMP to Support Multi-Part
>              |Tool | RFC 4884 |
>
>             Mizrahi, et al. Expires July 9, 2013                  [Page 6]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                |           | Messages [ICMP-MP]                   |  
>               |  |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | ICMP Extensions for Multiprotocol  
>              |Tool | RFC 4950 |
>
>                |           | Label Switching [ICMP-Ext]           |  
>               |    |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | Extending ICMP for Interface and    
>             |Tool | RFC 5837 |
>
>                |           | Next-Hop Identification [ICMP-Int]   |  
>               |  |
>
>              +-----------+--------------------------------------+-----+----------+
>
>                |BFD        | Bidirectional Forwarding Detection  
>             |Tool | RFC 5880 |
>
>                |           | [BFD]                              |     |  |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | Bidirectional Forwarding Detection  
>             |Prof.| RFC 5881 |
>
>                |           | (BFD) for IPv4 and IPv6 (Single Hop) |  
>               |    |
>
>                |           | [BFD-IP]                             |  
>               |  |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | Generic Application of Bidirectional
>             |Misc.| RFC 5882 |
>
>                |           | Forwarding Detection [BFD-Gen]       |  
>               |          |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | Bidirectional Forwarding Detection  
>             |Prof.| RFC 5883 |
>
>                |           | (BFD) for Multihop Paths [BFD-Multi] |  
>               |    |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | Bidirectional Forwarding Detection  
>             |Prof.| RFC 5884 |
>
>                |           | for MPLS Label Switched Paths (LSPs) |  
>               |  |
>
>                |           | [BFD-LSP]                            |  
>               |          |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | Bidirectional Forwarding Detection  
>             |Prof.| RFC 5885 |
>
>                |           | for the Pseudowire Virtual Circuit   |  
>               |  |
>
>                |           | Connectivity Verification (VCCV)     |  
>               |          |
>
>                |           | [BFD-VCCV]                           |  
>               |          |
>
>              +-----------+--------------------------------------+-----+----------+
>
>                |MPLS OAM   | Operations and Management (OAM)    
>              |Misc.| RFC 4377 |
>
>                |           | Requirements for Multi-Protocol Label|  
>               |          |
>
>                |           | Switched (MPLS) Networks [MPLS-OAM]  |  
>               |  |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | A Framework for Multi-Protocol      
>             |Misc.| RFC 4378 |
>
>                |           | Label Switching (MPLS) Operations    |  
>               |    |
>
>                |           | and Management (OAM) [MPLS-OAM-FW]   |  
>               |      |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | Detecting Multi-Protocol Label      
>             |Tool | RFC 4379 |
>
>                |           | Switched (MPLS) Data Plane Failures  |  
>               |  |
>
>                |           | [LSP-Ping]                           |  
>               |          |
>
>             Mizrahi, et al. Expires July 9, 2013                  [Page 7]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                | +--------------------------------------+-----+----------+
>
>                |           | Operations and Management (OAM)    
>              |Misc.| RFC 4687 |
>
>                |           | Requirements for Point-to-Multipoint |  
>               |          |
>
>                |           | MPLS Networks [MPLS-P2MP]            |  
>               |      |
>
>              +-----------+--------------------------------------+-----+----------+
>
>                |MPLS-TP    | Requirements for OAM in MPLS-TP    
>              |Misc.| RFC 5860 |
>
>                |OAM        | [MPLS-TP-OAM]                        |  
>               |          |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | MPLS Generic Associated Channel    
>              |Inf. | RFC 5586 |
>
>                |           | [G-ACh]                              |  
>               |  |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | MPLS-TP OAM Framework              
>              |Misc.| RFC 6371 |
>
>                |           | [TP-OAM-FW]                          |  
>               |          |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | Proactive Connectivity Verification,
>             |Tool | RFC 6428 |
>
>                |           | Continuity Check, and Remote Defect  |  
>               |          |
>
>                |           | Indication for the MPLS Transport    |  
>               |          |
>
>                |           | Profile [TP-CC-CV]                   |  
>               |  |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | MPLS On-Demand Connectivity        
>              |Tool | RFC 6426 |
>
>                |           | Verification and Route Tracing       |  
>               |          |
>
>                |           | [OnDemand-CV]                        |  
>               |          |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | MPLS Fault Management Operations,  
>              |Tool | RFC 6427 |
>
>                |           | Administration, and Maintenance (OAM)|  
>               |          |
>
>                |           | [TP-Fault]                           |  
>               |          |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | MPLS Transport Profile Lock Instruct
>             |Tool | RFC 6435 |
>
>                |           | and Loopback Functions [Lock-Loop]   |  
>               |      |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | Packet Loss and Delay Measurement
>             for|Tool | RFC 6374 |
>
>                |           | MPLS Networks [MPLS-LM-DM]           |  
>               |      |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | A Packet Loss and Delay Measurement
>              |Prof.| RFC 6375 |
>
>                |           | Profile for MPLS-Based Transport     |  
>               |  |
>
>                |           | Networks [TP-LM-DM]                  |  
>               |  |
>
>              +-----------+--------------------------------------+-----+----------+
>
>                |PWE3 OAM   | Pseudowire Virtual Circuit          
>             |Inf. | RFC 5085 |
>
>                |           | Connectivity Verification (VCCV):    |  
>               |          |
>
>                |           | A Control Channel for Pseudowires    |  
>               |        |
>
>                |           | [VCCV]                             |     |  |
>
>             Mizrahi, et al. Expires July 9, 2013                  [Page 8]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                | +--------------------------------------+-----+----------+
>
>                |           | Bidirectional Forwarding Detection  
>             |Prof.| RFC 5885 |
>
>                |           | for the Pseudowire Virtual Circuit   |  
>               |  |
>
>                |           | Connectivity Verification (VCCV)     |  
>               |          |
>
>                |           | [BFD-VCCV]                           |  
>               |          |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | Using the Generic Associated Channel
>             |Inf. | RFC 6423 |
>
>                |           | Label for Pseudowire in the MPLS     |  
>               |    |
>
>                |           | Transport Profile (MPLS-TP)          |  
>               |          |
>
>                |           | [PW-G-ACh]                           |  
>               |          |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | Pseudowire (PW) Operations,        
>              |Misc.| RFC 6310 |
>
>                |           | Administration, and Maintenance (OAM)|  
>               |          |
>
>                |           | Message Mapping [PW-Map]             |  
>               |  |
>
>              +-----------+--------------------------------------+-----+----------+
>
>                |OWAMP and  | A One-way Active Measurement
>             Protocol|Tool | RFC 4656 |
>
>                |TWAMP      | [OWAMP]                              |  
>               |  |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | A Two-Way Active Measurement
>             Protocol|Tool | RFC 5357 |
>
>                |           | [TWAMP]                              |  
>               |  |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | Framework for IP Performance Metrics
>             |Misc.| RFC 2330 |
>
>                |           | [IPPM-FW]                            |  
>               |          |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | IPPM Metrics for Measuring          
>             |Misc.| RFC 2678 |
>
>                |           | Connectivity [IPPM-Con]              |  
>               |          |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | A One-way Delay Metric for IPPM    
>              |Misc.| RFC 2679 |
>
>                |           | [IPPM-1DM]                           |  
>               |          |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | A One-way Packet Loss Metric for
>             IPPM|Misc.| RFC 2680 |
>
>                |           | [IPPM-1LM]                           |  
>               |          |
>
>                | +--------------------------------------+-----+----------+
>
>                |           | A Round-trip Delay Metric for IPPM  
>             |Misc.| RFC 2681 |
>
>                |           | [IPPM-2DM]                           |  
>               |          |
>
>              +-----------+--------------------------------------+-----+----------+
>
>                              Table 1 Summary of IETF OAM Related RFCs
>
>             Mizrahi, et al. Expires July 9, 2013                  [Page 9]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>             1.5. Non-IETF OAM Documents
>
>                In addition to the OAM mechanisms defined by the IETF,
>             the IEEE and
>
>                ITU-T have also defined various OAM mechanisms that
>             focus on
>
>                Ethernet, and various other transport network
>             environments. These
>
>                various mechanisms, defined by the three standard
>             organizations, are
>
>                often tightly coupled, and have had a mutual effect on
>             each other.
>
>                The ITU-T and IETF have both defined OAM mechanisms for
>             MPLS LSPs,
>
>                [ITU-T-Y1711] and [LSP-Ping]. The following OAM
>             standards by the IEEE
>
>                and ITU-T are to some extent linked to IETF OAM
>             mechanisms listed
>
>                above and are mentioned here only as reference material:
>
>                o OAM mechanisms for Ethernet based networks have been
>             defined by
>
>                   both the ITU-T in [ITU-T-Y1731], and by the IEEE in
>             [IEEE802.1ag].
>
>                   The IEEE 802.3 standard defines OAM for one-hop
>             Ethernet links
>
>                   [IEEE802.3ah].
>
>                o The ITU-T has defined OAM for MPLS LSPs in
>             [ITU-T-Y1711], and
>
>                   MPLS-TP OAM in [ITU-G8113.1] and [ITU-G8113.2].
>
>                Table 2 summarizes the OAM standards mentioned in this
>             document. This
>
>                document focuses on IETF OAM standards, but these
>             non-IETF standards
>
>                are referenced where relevant.
>
>              +-----------+--------------------------------------+---------------+
>
>                |           | Title                            
>              |Standard/Draft |
>
>              +-----------+--------------------------------------+---------------+
>
>                |ITU-T      | Operation & Maintenance mechanism    |
>             ITU-T Y.1711  |
>
>                |MPLS OAM   | for MPLS networks [ITU-T-Y1711]      | |
>
>                | +--------------------------------------+---------------+
>
>                |           | Assignment of the 'OAM Alert Label'  |
>             RFC 3429      |
>
>                |           | for Multiprotocol Label Switching    |     |
>
>                |           | Architecture (MPLS) Operation and    |  
>                   |
>
>                |           | Maintenance (OAM) Functions          |  
>                   |
>
>                |           | [OAM-Label]                          |  
>                   |
>
>                |           |                              | |
>
>                |           |  Note: although this is an IETF      |   |
>
>                |           |  document, it is listed as one of the|  
>                   |
>
>                |           |  non-IETF OAM standards, since it    |  
>                   |
>
>                |           |  was defined as a complementary part |     |
>
>                |           |  of ITU-T Y.1711.                    |     |
>
>              +-----------+--------------------------------------+---------------+
>
>                |ITU-T      | Operations, administration and      
>             |ITU-T G.8113.2 |
>
>                |MPLS-TP OAM| Maintenance mechanisms for MPLS-TP   |  
>                   |
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 10]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                |           | networks using the tools defined for | |
>
>                |           | MPLS [ITU-G8113.2]                   |     |
>
>                |           |                              | |
>
>                |           |  Note: this document describes the   |   |
>
>                |           |  OAM toolset defined by the IETF for |     |
>
>                |           |  MPLS-TP, whereas ITU-T G.8113.1     |  
>                   |
>
>                |           |  describes the OAM toolset defined   |  
>                   |
>
>                |           |  by the ITU-T.                       | |
>
>                | +--------------------------------------+---------------+
>
>                |           | Operations, Administration and      
>             |ITU-T G.8113.1 |
>
>                |           | Maintenance mechanism for MPLS-TP in |  
>                   |
>
>                |           | Packet Transport Network (PTN)       |   |
>
>                | +--------------------------------------+---------------+
>
>                |           | Allocation of a Generic Associated   |
>             RFC 6671      |
>
>                |           | Channel Type for ITU-T MPLS Transport| |
>
>                |           | Profile Operation, Maintenance, and  | |
>
>                |           | Administration (MPLS-TP OAM)         |  
>                   |
>
>                |           | [ITU-T-CT]                           |  
>                   |
>
>                |           |                              | |
>
>                |           |  Note: although this is an IETF      |   |
>
>                |           |  document, it is listed as one of the|  
>                   |
>
>                |           |  non-IETF OAM standards, since it    |  
>                   |
>
>                |           |  was defined as a complementary part |     |
>
>                |           |  of ITU-T G.8113.1.                  |     |
>
>              +-----------+--------------------------------------+---------------+
>
>                |ITU-T      | OAM Functions and Mechanisms for
>             |[ITU-T-Y1731]  |
>
>                |Ethernet   | Ethernet-based Networks              |  
>                   |
>
>                |OAM        |                              | |
>
>              +-----------+--------------------------------------+---------------+
>
>                |IEEE       | Connectivity Fault Management        |
>             IEEE 802.1ag  |
>
>                |CFM        | [IEEE802.1ag]                        |  
>                   |
>
>                |           |                              | |
>
>                |           |  Note: CFM was originally published  |   |
>
>                |           |  as IEEE 802.1ag, but is now         | |
>
>                |           |  incorporated in the 802.1Q standard.|  
>                   |
>
>              +-----------+--------------------------------------+---------------+
>
>                |IEEE       | Media Access Control Parameters,     |
>             IEEE 802.3ah  |
>
>                |802.3      | Physical Layers, and Management      | |
>
>                |link level | Parameters for Subscriber Access     |  
>                   |
>
>                |OAM        | Networks [IEEE802.3ah]               | |
>
>                |           |                              | |
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 11]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                |           |  Note: link level OAM was originally |   |
>
>                |           |  defined in IEEE 802.3ah, and is now | |
>
>                |           |  incorporated in the 802.3 standard. |  
>                   |
>
>              +-----------+--------------------------------------+---------------+
>
>                      Table 2 Non-IETF OAM Standards Mentioned in this
>             Document
>
>             2. Basic Terminology
>
>             2.1. Abbreviations
>
>                ACH    Associated Channel Header
>
>                AIS    Alarm Indication Signal
>
>                BFD    Bidirectional Forwarding Detection
>
>                CC     Continuity Check
>
>                CV     Connectivity Verification
>
>                DM     Delay Measurement
>
>                FEC    Forwarding Equivalence Class
>
>                GAL    Generic Associated Label
>
>                ICMP   Internet Control Message Protocol
>
>                LDP    Label Distribution Protocol
>
>                LM     Loss Measurement
>
>                LSP    Label Switched Path
>
>                ME     Maintenance Entity
>
>                MEG    Maintenance Entity Group
>
>                MEP    MEG End Point
>
>                MIP    MEG Intermediate Point
>
>                MP     Maintenance Point
>
>                MPLS   Multiprotocol Label Switching
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 12]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                MPLS-TP MPLS Transport Profile
>
>                MTU    Maximum Transmission Unit
>
>                OAM    Operations, Administration, and Maintenance
>
>                PW     Pseudowire
>
>                PWE3   Pseudowire Emulation Edge-to-Edge
>
>                RDI    Remote Defect Indication
>
>                TTL    Time To Live
>
>                VCCV   Virtual Circuit Connectivity Verification
>
>         TOM: Why is this section not at the top of this document, as
>         is customary for RFCs?
>
>         */[TM] The introduction is now significantly shorter than it
>         was when you sent this comment, which means that the
>         terminology section is now much closer to the beginning of the
>         document./*
>
>             2.2. Terminology used in OAM Standards
>
>             2.2.1. General Terms
>
>                A wide variety of terms is used in various OAM
>             standards. Each of the
>
>                OAM standards listed in the reference section includes
>             a section that
>
>                defines terms relevant to that tool. A thesaurus of
>             terminology for
>
>                MPLS-TP terms is presented in [TP-Term], and provides a
>             good summary
>
>                of some of the OAM related terminology.
>
>                This section presents a comparison of the terms used in
>             various OAM
>
>                standards, without fully quoting the definition of each
>             term. For a
>
>                formal definition of each term, refer to the references
>             at the end of
>
>                this document.
>
>             2.2.2. OAM Maintenance Entities
>
>                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.
>
>                The following related terms are also quoted from
>             [TP-OAM-FW]:
>
>                o MEP: The two points that define a maintenance entity.
>
>                o MEG: The collection of one or more MEs that belongs
>             to the same
>
>                   transport path and that are maintained and monitored
>             as a group
>
>                   are known as a Maintenance Entity Group (MEG).
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 13]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                o MIP: In between MEPs, there are zero or more
>             intermediate points,
>
>                   called Maintenance Entity Group Intermediate Points
>             (MIPs).
>
>                A pair of MEPs engaged in an ME are connected by a
>             communication
>
>                link, which may be one of several types of connection,
>             e.g. a single
>
>                physical connection, a set of physical connections, or
>             a virtual link
>
>                such as an MPLS LSP.
>
>                The term Maintenance Entity (ME) is used in ITU-T
>             Recommendations
>
>                (e.g. [ITU-T-Y1731]), as well as in the MPLS-TP
>             terminology ([TP-OAM-
>
>                FW]). 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.
>
>                MPLS-TP has defined the terms ME and Maintenance Entity
>             Group (MEG)
>
>                in [TP-OAM-FW], similar to the terms defined by ITU-T.
>              A MEG allows
>
>                the monitoring of a compound set of MEs, for example
>             when monitoring
>
>                a p2mp MEG that is considered to be the set of MEs
>             between the root
>
>                and each individual destination MEP.
>
>             2.2.3. OAM Maintenance Points
>
>                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. A MIP in MPLS-TP identifies
>             OAM packets
>
>                destined to it by the value of the TTL field in the OAM
>             packet. The
>
>                term Maintenance Point is a general term for MEPs and MIPs.
>
>                The 802.1ag defines a finer distinction between Up MPs
>             and Down MPs.
>
>                An MP is a bridge interface, that is monitored by an
>             OAM protocol
>
>                either in the direction facing the network, or in the
>             direction
>
>                facing the bridge. A Down MP is an MP that receives OAM
>             packets from,
>
>                and transmits them to the direction of the network. An
>             Up MP receives
>
>                OAM packets from, and transmits them to the direction
>             of the bridging
>
>                entity.
>
>                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.
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 14]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>             2.2.4. Proactive and On-demand activation
>
>                The different OAM tools may be used in one of two basic
>             types of
>
>                activation:
>
>                o Proactive activation - indicates that the tool is
>             activated on a
>
>                   continual basis periodically, where messages are
>             sent between the
>
>                   two MEPs, and errors are detected when a certain
>             number of
>
>                   expected messages are not received.
>
>                o On-demand activation - indicates that the tool is
>             activated
>
>                   "manually" to detect a specific anomaly.  In this
>             activation a
>
>                   small number of OAM messages are sent by a MEP and
>             the reply
>
>                   message is received.
>
>             2.2.5. Connectivity Verification and Continuity Checks
>
>                Two distinct classes of failure management functions
>             are used in OAM
>
>                protocols, connectivity verification and continuity
>             checks. The
>
>                distinction between these terms is defined in
>             [MPLS-TP-OAM], and is
>
>                used similarly in this document.
>
>                Continuity checks are used to verify the liveness of a
>             connection or
>
>                a path between two MPs, and are typically sent
>             proactively, though
>
>                they can be invoked on-demand as well.
>
>                A connectivity verification function allows an MP to
>             check whether it
>
>                is connected to a peer MP or not. This function also
>             allows the MP to
>
>                verify that messages from the peer MP are received
>             through the
>
>                correct path, thereby verifying not only that the two
>             MPs are
>
>                connected, but also that they are connected through the
>             expected
>
>                path. This allows detection of unexpected topology
>             changes. A
>
>                connectivity verification (CV) protocol typically uses
>             a CV message,
>
>                followed by a CV reply that is sent back to the
>             originator. A CV
>
>                function can be applied proactively or on-demand.
>
>                Connectivity verification and continuity checks are
>             considered
>
>                complementary mechanisms, and are often used in
>             conjunction with each
>
>                other.
>
>             2.2.6. Failures
>
>                The terms Failure, Fault, and Defect are used
>             interchangeably in the
>
>                standards, referring to a malfunction that can be
>             detected by a
>
>                connectivity or a continuity check. In some standards,
>             such as
>
>                [IEEE802.1ag], there is no distinction between these
>             terms, while in
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 15]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                other standards each of these terms refers to a
>             different type of
>
>                malfunction.
>
>                The terminology used in IETF MPLS-TP OAM takes after
>             the ITU-T, which
>
>                distinguishes between these terms in [ITU-T-G.806]; The
>             term Fault
>
>                refers to an inability to perform a required action,
>             e.g., an
>
>                unsuccessful attempt to deliver a packet. The term
>             Defect refers to
>
>                an interruption in the normal operation, such as a
>             consecutive period
>
>                of time where no packets are delivered successfully.
>             The term Failure
>
>                refers to the termination of the required function.
>             While a Defect
>
>                typically refers to a limited period of time, a failure
>             refers to a
>
>                long period of time.
>
>             3. OAM Tools
>
>             3.1. IP Ping and Traceroute
>
>             3.1.1. Ping
>
>                Ping is a common network diagnosis application for IP
>             networks that
>
>                uses ICMP. The ICMP Echo request/reply exchange is a
>             connectivity
>
>                verification function for the Internet Protocol. The
>             originator
>
>                transmits an ICMP Echo request packet, and the receiver
>             replies with
>
>                an Echo reply. ICMP ping is defined in two variants,
>             [ICMPv4] is used
>
>                for IPv4, and [ICMPv6] is used for IPv6.
>
>             3.1.2. Traceroute
>
>                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
>
>                three packets (the number of packets is configurable in
>             most
>
>                Traceroute implementations), each with an IP
>             Time-To-Live (TTL) value
>
>                of one to the destination. These packets expire as soon
>             as they reach
>
>                the first router in the path. That router responds by
>             sending three
>
>                ICMP Time Exceeded Messages to the Traceroute
>             application. Traceroute
>
>                now sends another three UDP packets, each with the TTL
>             value of 2.
>
>                These messages cause the second router to return ICMP
>             messages. This
>
>                process continues, with ever increasing values for the
>             TTL field,
>
>                until the packets actually reach the destination.
>             Because no
>
>                application listens to port 33434 at the destination,
>             the destination
>
>                returns ICMP Destination Unreachable Messages indicating an
>
>                unreachable port. This event indicates to the
>             Traceroute application
>
>                that it is finished.  The Traceroute program displays
>             the round-trip
>
>                delay associated with each of the attempts.
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 16]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                Note that IP routing may be asymmetric. While
>             Traceroute reveals the
>
>                path between a source and destination, it may not
>             reveal the reverse
>
>                path.
>
>                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.
>
>             3.2. Bidirectional Forwarding Detection (BFD)
>
>             3.2.1. Overview
>
>                While multiple OAM mechanisms have been defined for
>             various protocols
>
>                in the protocol stack, Bidirectional Forwarding
>             Detection [BFD],
>
>                defined by the IETF BFD working group, is a generic OAM
>             mechanism
>
>                that can be deployed over various encapsulating
>             protocols, and in
>
>                various medium types. The IETF has defined variants of
>             the protocol
>
>                for IP ([BFD-IP], [BFD-Multi]), for MPLS LSPs
>             [BFD-LSP], and for PWE3
>
>                [BFD-VCCV]. The usage of BFD in MPLS-TP is defined in
>             [MPLS-TP-CC-
>
>                CV].
>
>                BFD includes two main OAM functions, using two types of
>             BFD packets:
>
>                BFD Control packets, and BFD Echo packets.
>
>             3.2.2. BFD Control
>
>                BFD supports a bidirectional continuity check, using
>             BFD control
>
>                packets, that are exchanged within a BFD session. BFD
>             sessions
>
>                operate in one of two modes:
>
>                o Asynchronous mode (i.e. proactive): in this mode BFD
>             control
>
>                   packets are sent periodically. When the receiver
>             detects that no
>
>                   BFD control packet have been received during a
>             predetermined
>
>                   period of time, a failure is detected.
>
>                o Demand mode: in this mode, BFD control packets are
>             sent on-demand.
>
>                   Upon need, a system initiates a series of BFD
>             control packets to
>
>                   verify the liveness of the session. BFD control
>             packets are sent
>
>                   independently in each direction.
>
>                Each of the end-points of the monitored path maintains
>             its own
>
>                session identification, called a Discriminator, both of
>             which are
>
>                included in the BFD Control Packets that are exchanged
>             between the
>
>                end-points.  At the time of session establishment, the
>             Discriminators
>
>                are exchanged between the two-end points.  In addition, the
>
>                transmission (and reception) rate is negotiated between
>             the two end-
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 17]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                points, based on information included in the control
>             packets.  These
>
>                transmission rates may be renegotiated during the session.
>
>                During normal operation of the session, i.e. no
>             failures are
>
>                detected, the BFD session is in the Up state.  If no
>             BFD Control
>
>                packets are received during a fixed period of time,
>             called the
>
>         TOM: Fixed, pre-configured or negotiated period of time (i.e.:
>         BFD interval)
>
>         */[TM] We rephrased this sentence./*
>
>                Detection Time, the session is declared to be Down. The
>             detection
>
>                time is a function of the negotiated transmission time,
>             and a
>
>                parameter called Detect Mult. Detect Mult determines
>             the number of
>
>                missing BFD Control packets that cause the session to
>             be declared as
>
>                Down. This parameter is included in the BFD Control packet.
>
>             3.2.3. BFD Echo
>
>                A BFD echo packet is sent to a peer system, and is
>             looped back to the
>
>                originator. The echo function can be used proactively,
>             or on-demand.
>
>                The BFD echo function has been defined in BFD for IPv4
>             and IPv6
>
>                ([BFD-IP]), but is not used in BFD for MPLS LSPs, PWs,
>             or in BFD for
>
>                MPLS-TP.
>
>             3.3. MPLS OAM
>
>                The IETF MPLS working group has defined OAM for MPLS
>             LSPs. The
>
>                requirements and framework of this effort are defined
>             in [MPLS-OAM-
>
>                FW] and [MPLS-OAM], respectively. The corresponding OAM
>             mechanism
>
>                defined, in this context, is LSP Ping [LSP-Ping].
>
>                LSP Ping is based on ICMP Ping and just like its
>             predecessor may be
>
>                used in one of two modes:
>
>                o "Ping" mode: In this mode LSP ping is used for end-to-end
>
>                   connectivity verification between two LERs.
>
>                o "Traceroute" mode: This mode is used for hop-by-hop fault
>
>                   isolation.
>
>                LSP Ping extends the basic ICMP Ping operation (of
>             data-plane
>
>                connectivity verification) with functionality to verify
>             data-plane
>
>                vs. control-plane consistency for a Forwarding
>             Equivalence Class
>
>                (FEC) and also Maximum Transmission Unit (MTU)
>             problems. The
>
>                traceroute functionality may be used to isolate and
>             localize the MPLS
>
>                faults, using the Time-to-live (TTL) indicator to
>             incrementally
>
>                identify the sub-path of the LSP that is successfully
>             traversed
>
>                before the faulty link or node.
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 18]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                It should be noted that LSP Ping supports unique
>             identification of
>
>                the LSP within an addressing domain. The identification
>             is checked
>
>                using the full FEC identification. LSP Ping is easily
>             extensible to
>
>                include additional information needed to support new
>             functionality,
>
>                by use of Type-Length-Value (TLV) constructs. The usage
>             of TLVs is
>
>                typically not easy to perform in hardware, and is thus
>             typically
>
>                handled by the control plane.
>
>                LSP Ping supports both asynchronous, as well as, on-demand
>
>                activation.
>
>             3.4. MPLS-TP OAM
>
>             3.4.1. Overview
>
>                The MPLS working group is currently working on defining
>             the OAM
>
>                toolset that fulfills the requirements for MPLS-TP OAM.
>             The full set
>
>                of requirements for MPLS-TP OAM are defined in
>             [MPLS-TP-OAM], and
>
>                include both general requirements for the behavior of
>             the OAM
>
>                mechanisms and a set of operations that should be
>             supported by the
>
>                OAM toolset.  The set of mechanisms required are
>             further elaborated
>
>                in [TP-OAM-FW], which describes the general
>             architecture of the OAM
>
>                system as well as giving overviews of the functionality
>             of the OAM
>
>                toolset.
>
>                Some of the basic requirements for the OAM toolset for
>             MPLS-TP are:
>
>                o MPLS-TP OAM must be able to support both an IP based
>             and non-IP
>
>                   based environment. If the network is IP based, i.e.
>             IP routing and
>
>                   forwarding are available, then the MPLS-TP OAM
>             toolset should rely
>
>                   on the IP routing and forwarding capabilities. On
>             the other hand,
>
>                   in environments where IP functionality is not
>             available, the OAM
>
>                   tools must still be able to operate without
>             dependence on IP
>
>                   forwarding and routing.
>
>                o OAM packets and the user traffic are required to be
>             congruent
>
>                   (i.e. OAM packets are transmitted in-band) and there
>             is a need to
>
>                   differentiate OAM packets from user-plane ones.
>             Inherent in this
>
>                   requirement is the principle that MPLS-TP OAM be
>             independent of
>
>                   any existing control-plane, although it should not
>             preclude use of
>
>                   the control-plane functionality.
>
>             3.4.2. Generic Associated Channel
>
>                In order to address the requirement for in-band
>             transmission of MPLS-
>
>                TP OAM traffic, MPLS-TP uses a Generic Associated
>             Channel (G-ACh),
>
>                defined in [G-ACh] for LSP-based OAM traffic. This
>             mechanism is based
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 19]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                on the same concepts as the PWE3 ACH and VCCV
>             mechanisms.  However,
>
>                to address the needs of LSPs as differentiated from PW,
>             the following
>
>                concepts were defined for [G-ACh]:
>
>                o An Associated Channel Header (ACH), that uses a
>             format similar to
>
>                   the PW Control Word, is a 4-byte header that is
>             prepended to OAM
>
>                   packets.
>
>                o A Generic Associated Label (GAL). The GAL is a
>             reserved MPLS label
>
>                   value (13) that indicates that the packet is an ACH
>             packet and the
>
>                   payload follows immediately after the label stack.
>
>             3.4.3. MPLS-TP OAM Toolset
>
>                To address the functionality that is required of the
>             OAM toolset, the
>
>                MPLS WG conducted an analysis of the existing IETF and
>             ITU-T OAM
>
>                mechanisms and their ability to fulfill the required
>             functionality.
>
>                The conclusions of this analysis are documented in
>             [OAM-Analys]. The
>
>                MPLS working group currently plans to use a mixture of
>             OAM mechanisms
>
>                that are based on various existing standards, and adapt
>             them to the
>
>                requirements of [MPLS-TP-OAM]. Some of the main
>             building blocks of
>
>                this solution are based on:
>
>                o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for
>
>                   proactive continuity check and connectivity
>             verification.
>
>                o LSP Ping as defined in [LSP-Ping] for on-demand
>             connectivity
>
>                   verification.
>
>                o New protocol packets, using G-ACH, to address different
>
>                   functionality.
>
>                o Performance measurement protocols that are based on the
>
>                   functionality that is described in [ITU-T-Y1731].
>
>                The following sub-sections describe the OAM tools
>             defined for MPLS-TP
>
>                as described in [TP-OAM-FW].
>
>             3.4.3.1. Continuity Check and Connectivity Verification
>
>                Continuity Check and Connectivity Verification are
>             presented in
>
>                Section 2.2.5. of this document.  As presented there,
>             these tools may
>
>                be used either proactively or on-demand.  When using
>             these tools
>
>                proactively, they are generally used in tandem.
>
>                For MPLS-TP there are two distinct tools, the proactive
>             tool is
>
>                defined in [TP-CC-CV] while the on-demand tool is
>             defined in
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 20]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>              [OnDemand-CV].Proactively [MPLS-TP-OAM] states that the
>             function
>
>                should allow the MEPs to monitor the liveness and
>             connectivity of a
>
>                transport path. In on-demand mode, this function should
>             support
>
>                monitoring between the MEPs and, in addition, between a
>             MEP and MIP.
>
>                [TP-OAM-FW] highlights,  when performing Connectivity
>             Verification,
>
>                the need for the CC-V messages to include unique
>             identification of
>
>                the MEG that is being monitored and the MEP that
>             originated the
>
>                message.
>
>                The proactive tool [TP-CC-CV] is based on extensions to
>             BFD (see
>
>                Section 3.2. ) with the additional limitation that the
>             transmission
>
>                and receiving rates are based on configuration by the
>             operator.  The
>
>                on-demand tool [OnDemand-CV] is an adaptation of LSP
>             Ping (see
>
>                Section 3.3. ) for the required behavior of MPLS-TP.
>
>             3.4.3.2. Route Tracing
>
>                [MPLS-TP-OAM] defines that there is a need for
>             functionality that
>
>                would allow a path end-point to identify the
>             intermediate and end-
>
>                points of the path. This function would be used in
>             on-demand mode.
>
>                Normally, this path will be used for bidirectional PW,
>             LSP, and
>
>                sections, however, unidirectional paths may be
>             supported only if a
>
>                return path exists.  The tool for this is based on the
>             LSP Ping (see
>
>                Section 3.3. ) functionality and is described in
>             [OnDemand-CV].
>
>             3.4.3.3. Lock Instruct
>
>                The Lock Instruct function [Lock-Loop] is used to
>             notify a transport
>
>                path end-point of an administrative need to disable the
>             transport
>
>                path.  This functionality will generally be used in
>             conjunction with
>
>                some intrusive OAM function, e.g. Performance
>             measurement, Diagnostic
>
>                testing, to minimize the side-effect on user data traffic.
>
>             3.4.3.4. Lock Reporting
>
>                Lock Reporting is a function used by an end-point of a
>             path to report
>
>                to its far-end end-point that a lock condition has been
>             affected on
>
>                the path.
>
>             3.4.3.5. Alarm Reporting
>
>                Alarm Reporting is a function used by an intermediate
>             point of a
>
>                path, that becomes aware of a fault on the path, to
>             report to the
>
>                end-points of the path. [TP-OAM-FW] states that this
>             may occur as a
>
>                result of a defect condition discovered at a server
>             sub-layer. This
>
>                generates an Alarm Indication Signal (AIS) that
>             continues until the
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 21]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                fault is cleared. The consequent action of this
>             function is detailed
>
>                in [TP-OAM-FW].
>
>             3.4.3.6. Remote Defect Indication
>
>                Remote Defect Indication (RDI) is used proactively by a
>             path end-
>
>                point to report to its peer end-point that a defect is
>             detected on a
>
>                bidirectional connection between them. [MPLS-TP-OAM]
>             points out that
>
>                this function may be applied to a unidirectional LSP
>             only if there a
>
>                return path exists.  [TP-OAM-FW] points out that this
>             function is
>
>                associated with the proactive CC-V function.
>
>             3.4.3.7. Client Failure Indication
>
>                Client Failure Indication (CFI) is defined in
>             [MPLS-TP-OAM] to allow
>
>                the propagation information from one edge of the
>             network to the
>
>                other. The information concerns a defect to a client,
>             in the case
>
>                that the client does not support alarm notification.
>
>             3.4.3.8. Packet Loss Measurement (LM)
>
>                Packet Loss Measurement is a function used to verify
>             the quality of
>
>                the service. This function indicates the ratio of
>             packets that are
>
>                not delivered out of all packets that are transmitted
>             by the path
>
>                source.
>
>                There are two possible ways of determining this
>             measurement:
>
>                o Using OAM packets, it is possible to compute the
>             statistics based
>
>                   on a series of OAM packets. This, however, has the
>             disadvantage of
>
>                   being artificial, and may not be representative
>             since part of the
>
>                   packet loss may be dependent upon packet sizes.
>
>         TOM: Not just packet sizes. Things like implementation (as I
>         mentioned above with the comment about the accuracy or
>         truthfulness of the data plane processing of OAM packets).
>          Doing very accurate RTT as a simple example, with just IP
>         Pings, is a tricky thing to make work.  Also, it is important
>         to mention that the scale in terms of number of packets,
>         number of tests, etc... can and will impact these parameters too.
>
>         */[TM] Following your comment we rephrased this sentence./*
>
>                o Sending delimiting messages for the start and end of
>             a measurement
>
>                   period during which the source and sink of the path
>             count the
>
>                   packets transmitted and received. After the end
>             delimiter, the
>
>                   ratio would be calculated by the path OAM entity.
>
>             3.4.3.9. Packet Delay Measurement (DM)
>
>                Packet Delay Measurement is a function that is used to
>             measure one-
>
>                way or two-way delay of a packet transmission between a
>             pair of the
>
>                end-points of a path (PW, LSP, or Section). Where:
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 22]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                o One-way packet delay is the time elapsed from the
>             start of
>
>                   transmission of the first bit of the packet by a
>             source node until
>
>                   the reception of the last bit of that packet by the
>             destination
>
>                   node.
>
>                o Two-way packet delay is the time elapsed from the
>             start of
>
>                   transmission of the first bit of the packet by a
>             source node until
>
>                   the reception of the last bit of the loop-backed
>             packet by the
>
>                   same source node, when the loopback is performed at
>             the packet's
>
>                   destination node.
>
>                Similarly to the packet loss measurement this could be
>             performed in
>
>                either of the two ways outlined above.
>
>             3.5. PWE3 OAM
>
>             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).
>
>                VCCV currently supports the following OAM mechanisms:
>             ICMP Ping, LSP
>
>                Ping, and BFD. ICMP and LSP Ping are IP encapsulated
>             before being
>
>                sent over the PW ACH. BFD for VCCV [BFD-VCCV] supports
>             two modes of
>
>                encapsulation - either IP/UDP encapsulated (with IP/UDP
>             header) or
>
>                PW-ACH encapsulated (with no IP/UDP header) and
>             provides support to
>
>                signal the AC status. The use of the VCCV control
>             channel provides
>
>                the context, based on the MPLS-PW label, required to
>             bind and
>
>                bootstrap the BFD session to a particular pseudo wire
>             (FEC),
>
>                eliminating the need to exchange Discriminator values.
>
>                VCCV consists of two components: (1) signaled component to
>
>                communicate VCCV capabilities as part of VC label, and
>             (2) switching
>
>                component to cause the PW payload to be treated as a
>             control packet.
>
>                VCCV is not directly dependent upon the presence of a
>             control plane.
>
>                The VCCV capability negotiation may be performed as
>             part of the PW
>
>                signaling when LDP is used. In case of manual
>             configuration of the
>
>                PW, it is the responsibility of the operator to set
>             consistent
>
>                options at both ends.
>
>         TOM: Might be helpful to note that the static mode was created
>         specifically to handle the MPLS-TP cases where no control
>         plane was a requirement. However, new use cases such as pure
>         mobile backhaul, etc... find this functionality useful too.
>
>         */[TM] Following your comment we added some text to explain
>         this./*
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 23]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>             3.5.2. PWE3 OAM using G-ACh
>
>                As mentioned above, VCCV enables OAM for PWs by using a
>             control
>
>                channel for OAM packets. When PWs are used in MPLS-TP
>             networks,
>
>                rather than the control channels defined in VCCV, the
>             G-ACh can be
>
>                used as an alternative control channel. The usage of
>             the G-ACh for
>
>                PWs is defined in [PW-G-ACh].
>
>             3.6. OWAMP and TWAMP
>
>             3.6.1. Overview
>
>                The IPPM working group in the IETF defines common
>             criteria and
>
>                metrics for measuring performance of IP traffic
>             ([IPPM-FW]). Some of
>
>                the key RFCs published by this working group have
>             defined metrics for
>
>                measuring connectivity [IPPM-Con], delay ([IPPM-1DM],
>             [IPPM-2DM]),
>
>                and packet loss [IPPM-1LM].
>
>                Alternative protocols for performance measurement are
>             defined, for
>
>                example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and
>             in Ethernet
>
>                OAM [ITU-T-Y1731].
>
>                The IPPM working group has defined not only metrics for
>             performance
>
>                measurement, but also protocols that define how the
>             measurement is
>
>                carried out. The One-way Active Measurement Protocol
>             [OWAMP] and the
>
>                Two-Way Active Measurement Protocol [TWAMP] define a
>             method and
>
>                protocol for measuring delay and packet loss in IP
>             networks.
>
>                OWAMP [OWAMP] enables measurement of one-way
>             characteristics of IP
>
>                networks, such as one-way packet loss and one-way
>             delay.  For its
>
>                proper operation OWAMP requires accurate time of day
>             setting at its
>
>                end points.
>
>                TWAMP [TWAMP] is a similar protocol that enables
>             measurement of two-
>
>                way (round trip) characteristics.  TWAMP does not
>             require accurate
>
>                time of day, and, furthermore, allows the use of a
>             simple session
>
>                reflector, making it an attractive alternative to OWAMP.
>
>                OWAMP and TWAMP use two separate protocols: a Control
>             plane protocol,
>
>                and a Test plane protocol.
>
>             3.6.2. Control and Test Protocols
>
>                OWAMP and TWAMP control protocols run over TCP, while
>             the test
>
>                protocols run over UDP.  The purpose of the control
>             protocols is to
>
>                initiate, start, and stop test sessions, and for OWAMP
>             to fetch
>
>                results.  The test protocols introduce test packets
>             (which contain
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 24]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                sequence numbers and timestamps) along the IP path
>             under test
>
>                according to a schedule, and record statistics of
>             packet arrival.
>
>                Multiple sessions may be simultaneously defined, each
>             with a session
>
>                identifier, and defining the number of packets to be
>             sent, the amount
>
>                of padding to be added (and thus the packet size), the
>             start time,
>
>                and the send schedule (which can be either a constant
>             time between
>
>                test packets or exponentially distributed
>             pseudo-random). Statistics
>
>                recorded conform to the relevant IPPM RFCs.
>
>                OWAMP and TWAMP test traffic is designed with security
>             in mind.  Test
>
>                packets are hard to detect because they are simply UDP
>             streams
>
>                between negotiated port numbers, with potentially
>             nothing static in
>
>                the packets.  OWAMP and TWAMP also include optional
>             authentication
>
>                and encryption for both control and test packets.
>
>             3.6.3. OWAMP
>
>                OWAMP defines the following logical roles:
>             Session-Sender, Session-
>
>                Receiver, Server, Control-Client, and Fetch-Client.
>              The Session-
>
>                Sender originates test traffic that is received by the
>             Session-
>
>                Receiver.  The Server configures and manages the
>             session, as well as
>
>                returning the results.  The Control-Client initiates
>             requests for
>
>                test sessions, triggers their start, and may trigger their
>
>                termination.  The Fetch-Client requests the results of
>             a completed
>
>                session.  Multiple roles may be combined in a single
>             host - for
>
>                example, one host may play the roles of Control-Client,
>             Fetch-Client,
>
>                and Session-Sender, and a second playing the roles of
>             Server and
>
>                Session-Receiver.
>
>                In a typical OWAMP session the Control-Client
>             establishes a TCP
>
>                connection to port 861 of the Server, which responds
>             with a server
>
>                greeting message indicating supported
>             security/integrity modes. The
>
>                Control-Client responds with the chosen communications
>             mode and the
>
>                Server accepts the modes.  The Control-Client then
>             requests and fully
>
>                describes a test session to which the Server responds
>             with its
>
>                acceptance and supporting information.  More than one
>             test session
>
>                may be requested with additional messages.  The
>             Control-Client then
>
>                starts a test session and the Server acknowledges.  The
>             Session-
>
>                Sender then sends test packets with pseudorandom
>             padding to the
>
>                Session-Receiver until the session is complete or until
>             the Control-
>
>                client stops the session.  Once finished, the
>             Fetch-Client sends a
>
>                fetch request to the server, which responds with an
>             acknowledgement
>
>                and immediately thereafter the result data.
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 25]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>             3.6.4. TWAMP
>
>                TWAMP defines the following logical roles:
>             session-sender, session-
>
>                reflector, server, and control-client.  These are
>             similar to the
>
>                OWAMP roles, except that the Session-Reflector does not
>             collect any
>
>                packet information, and there is no need for a
>             Fetch-Client.
>
>                In a typical TWAMP session the Control-Client
>             establishes a TCP
>
>                connection to port 862 of the Server, and mode is
>             negotiated as in
>
>                OWAMP.  The Control-Client then requests sessions and
>             starts them.
>
>                The Session-Sender sends test packets with pseudorandom
>             padding to
>
>                the Session-Reflector which returns them with insertion of
>
>                timestamps.
>
>             3.7. Summary of OAM Functions
>
>                Table 3 summarizes the OAM functions that are supported
>             in each of
>
>                the categories that were analyzed in this section.
>
>              +-----------+-------+--------+--------+-----------+-------+--------+
>
>                | Standard  |Continu|Connecti|Path    |Defect
>             |Perform|Other   |
>
>                |           |ity  |vity    |Discover|Indications|ance
>             |Function|
>
>                |           |Check  |Verifica|y       |          
>             |Monitor|s     |
>
>                |           | |tion    |        |           |ing    |    |
>
>              +-----------+-------+--------+--------+-----------+-------+--------+
>
>                |IP Ping    | |Echo    |        |           |       |    |
>
>                + --------- + ----- + ------ + ------ + --------- +
>             ----- + ------ +
>
>                |IP         |       |        |Tracerou|           |    
>               |  |
>
>                |Traceroute |       |        |te      |           |    
>               |  |
>
>                + --------- + ----- + ------ + ------ + --------- +
>             ----- + ------ +
>
>                |BFD        |BFD  |BFD     |        |           |      
>             |    |
>
>                | |Control|Echo    |        |           |   |        |
>
>                + --------- + ----- + ------ + ------ + --------- +
>             ----- + ------ +
>
>                |MPLS OAM   | |"Ping"  |"Tracero|           |       |    |
>
>                |(LSP Ping) | |mode    |ute"    |           |       |    |
>
>                |           |       |        |mode    |           |    
>               |  |
>
>                + --------- + ----- + ------ + ------ + --------- +
>             ----- + ------ +
>
>                |MPLS-TP    |CC |CV/pro- |Route   |-Alarm     |-LM
>              |-Diagnos|
>
>                |OAM        | |active  |Tracing | Reporting |-DM    |
>             tic Tes|
>
>                |           | |or on-  |        |-Client    |       | t
>                |
>
>                |           | |demand  |        | Failure   |      
>             |-Lock   |
>
>                |           |       |        |        | Indication|    
>               |  |
>
>                |           |       |        |        |-Remote    |    
>               |  |
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 26]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                |           |       |        |        | Defect    |    
>               |  |
>
>                |           |       |        |        | Indication|    
>               |  |
>
>                + --------- + ----- + ------ + ------ + --------- +
>             ----- + ------ +
>
>                |PWE3 OAM   |BFD  |-BFD    |LSP-Ping|           |      
>             |    |
>
>                |           | |-ICMP   |        |           |       |    |
>
>                |           |       | Ping   |        |           |    
>               |  |
>
>                |           | |-LSP-   |        |           |       |    |
>
>                |           |       | Ping   |        |           |    
>               |  |
>
>                + --------- + ----- + ------ + ------ + --------- +
>             ----- + ------ +
>
>                |OWAMP and  |       |        |        |          
>             |-Delay |  |
>
>                |TWAMP      |       |        |        |           |
>             measur|  |
>
>                |           |       |        |        |           |
>             ement |  |
>
>                |           |       |        |        |          
>             |-Packet|  |
>
>                |           |       |        |        |           |
>             loss  |  |
>
>                |           |       |        |        |           |
>             measur|  |
>
>                |           |       |        |        |           |
>             ement |  |
>
>              +-----------+-------+--------+--------+-----------+-------+--------+
>
>              Table 3 Summary of OAM Functions
>
>             4. Security Considerations
>
>                This memo presents an overview of existing OAM
>             mechanisms, and
>
>                proposes no new OAM mechanisms. Therefore, this
>             document introduces
>
>                no security considerations. However, the OAM mechanism
>             reviewed in
>
>                this document can and do present security issues. The
>             reader is
>
>                encouraged to review the Security Considerations
>             section of each
>
>                document reference by this memo.
>
>             5. IANA Considerations
>
>                There are no new IANA considerations implied by this
>             document.
>
>             6. Acknowledgments
>
>                The authors gratefully acknowledge Sasha Vainshtein, Carlos
>
>                Pignataro, David Harrington, Dan Romascanu, Ron Bonica
>             and other
>
>                members of the OPSAWG mailing list for their helpful
>             comments.
>
>                This document was prepared using 2-Word-v2.0.template.dot.
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 27]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>             7. References
>
>             7.1. Normative References
>
>                [LSP-Ping]  Kompella, K., Swallow, G., "Detecting
>             Multi-Protocol
>
>                              Label Switched (MPLS) Data Plane
>             Failures", RFC 4379,
>
>                              February 2006.
>
>                [MPLS-OAM]    Nadeau, T., Morrow, M., Swallow, G.,
>             Allan, D.,
>
>              Matsushima, S., "Operations and Management (OAM)
>
>              Requirements for Multi-Protocol Label Switched (MPLS)
>
>              Networks", RFC 4377, February 2006.
>
>                [MPLS-OAM-FW] Allan, D., Nadeau, T., "A Framework for
>             Multi-Protocol
>
>                              Label Switching (MPLS) Operations and
>             Management
>
>                              (OAM)", RFC 4378, February 2006.
>
>                [OAM-Label]   Ohta, H., "Assignment of the 'OAM Alert
>             Label' for
>
>              Multiprotocol Label Switching Architecture (MPLS)
>
>              Operation and Maintenance (OAM) Functions", RFC 3429,
>
>                              November 2002.
>
>                [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M.,
>             "Requirements for
>
>                              OAM in MPLS Transport Networks", RFC
>             5860, May 2010.
>
>                [G-ACh]       Bocci, M., Vigoureux, M., Bryant, S.,
>             "MPLS Generic
>
>              Associated Channel", RFC 5586, June 2009.
>
>                [VCCV]        Nadeau, T., Pignataro, C., "Pseudowire
>             Virtual Circuit
>
>              Connectivity Verification (VCCV): A Control Channel
>
>                              for Pseudowires", RFC 5085, December 2007.
>
>                [PW-ACH]      Bryant, S., Swallow, G., Martini, L.,
>             McPherson, D.,
>
>              "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word
>
>                              for Use over an MPLS PSN", RFC 4385,
>             February 2006.
>
>                [ICMPv4]      Postel, J., "Internet Control Message
>             Protocol", STD 5,
>
>                              RFC 792, September 1981.
>
>                [ICMPv6]      Conta, A., Deering, S., and M. Gupta,
>             "Internet Control
>
>                              Message Protocol (ICMPv6) for the
>             Internet Protocol
>
>                              Version 6 (IPv6) Specification", RFC
>             4443, March 2006.
>
>                [MPLS-P2MP] Yasukawa, S., Farrel, A., King, D., Nadeau, T.,
>
>              "Operations and Management (OAM) Requirements for
>
>              Point-to-Multipoint MPLS Networks", RFC 4687,
>
>              September 2006.
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 28]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                [ICMP-Ext]    Bonica, R., Gan, D., Tappan, D.,
>             Pignataro, C., "ICMP
>
>              Extensions for Multiprotocol Label Switching", RFC
>
>                              4950, August 2007.
>
>                [ICMP-MP]     Bonica, R., Gan, D., Tappan, D.,
>             Pignataro, C.,
>
>              "Extended ICMP to Support Multi-Part Messages", RFC
>
>                              4884, April 2007.
>
>                [ICMP-Int]    Atlas, A., Bonica, R., Pignataro, C.,
>             Shen, N., Rivers,
>
>                              JR., "Extending ICMP for Interface and
>             Next-Hop
>
>              Identification", RFC 5837, April 2010.
>
>                [TCPIP-Tools] Kessler, G., Shepard, S., "A Primer On
>             Internet and
>
>                              TCP/IP Tools and Utilities", RFC 2151,
>             June 1997.
>
>                [NetTools]    Stine, R., "FYI on a Network Management
>             Tool Catalog:
>
>                              Tools for Monitoring and Debugging TCP/IP
>             Internets
>
>                              and Interconnected Devices", RFC 1147,
>             April 1990.
>
>                [IPPM-FW]     Paxson, V., Almes, G., Mahdavi, J., and
>             Mathis, M.,
>
>              "Framework for IP Performance Metrics", RFC 2330, May
>
>                              1998.
>
>                [IPPM-Con]    Mahdavi, J., Paxson, V., "IPPM Metrics
>             for Measuring
>
>              Connectivity", RFC 2678, September 1999.
>
>                [IPPM-1DM]    Almes, G., Kalidindi, S., Zekauskas, M.,
>             "A One-way
>
>                              Delay Metric for IPPM", RFC 2679,
>             September 1999.
>
>                [IPPM-1LM]    Almes, G., Kalidindi, S., Zekauskas, M.,
>             "A One-way
>
>                              Packet Loss Metric for IPPM", RFC 2680,
>             September
>
>                              1999.
>
>                [IPPM-2DM]    Almes, G., Kalidindi, S., Zekauskas, M.,
>             "A Round-trip
>
>                              Delay Metric for IPPM", RFC 2681,
>             September 1999.
>
>                [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote,
>             J., and
>
>              Zekauskas, M., "A One-way Active Measurement Protocol
>
>              (OWAMP)", RFC 4656, September 2006.
>
>                [TWAMP]       Hedayat, K., Krzanowski, R., Morton, A.,
>             Yum, K., and
>
>                              Babiarz, J., "A Two-Way Active
>             Measurement Protocol
>
>              (TWAMP)", RFC 5357, October 2008.
>
>                [BFD]         Katz, D., Ward, D., "Bidirectional
>             Forwarding Detection
>
>                              (BFD)", RFC 5880, June 2010.
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 29]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                [BFD-IP]      Katz, D., Ward, D., "Bidirectional
>             Forwarding Detection
>
>                              (BFD) for IPv4 and IPv6 (Single Hop)",
>             RFC 5881, June
>
>                              2010.
>
>                [BFD-Gen]     Katz, D., Ward, D., "Generic Application of
>
>              Bidirectional Forwarding Detection (BFD)", RFC 5882,
>
>                              June 2010.
>
>                [BFD-Multi]   Katz, D., Ward, D., "Bidirectional
>             Forwarding Detection
>
>                              (BFD) for Multihop Paths", RFC 5883, June
>             2010.
>
>                [BFD-LSP] Aggarwal, R., Kompella, K., Nadeau, T., and
>             Swallow,
>
>                              G., "Bidirectional Forwarding Detection
>             (BFD) for MPLS
>
>                              Label Switched Paths (LSPs)", RFC 5884,
>             June 2010.
>
>                [BFD-VCCV]    Nadeau, T., Pignataro, C., "Bidirectional
>             Forwarding
>
>              Detection (BFD) for the Pseudowire Virtual Circuit
>
>              Connectivity Verification (VCCV)", RFC 5885, June
>
>                              2010.
>
>                [TP-OAM-FW]   Busi, I., Allan, D., "Operations,
>             Administration and
>
>              Maintenance Framework for MPLS-based Transport
>
>                              Networks ", RFC 6371, September 2011.
>
>                [TP-CC-CV]    Allan, D., Swallow, G., Drake, J., "Proactive
>
>              Connectivity Verification, Continuity Check and Remote
>
>                              Defect indication for MPLS Transport
>             Profile", RFC
>
>                              6428, November 2011.
>
>                [OnDemand-CV] Gray, E., Bahadur, N., Boutros, S.,
>             Aggarwal, R. "MPLS
>
>              On-Demand Connectivity Verification and Route
>
>              Tracing", RFC 6426, November 2011.
>
>                [MPLS-LM-DM]  Frost, D., Bryant, S., "Packet Loss and Delay
>
>              Measurement for MPLS Networks", RFC 6374, September
>
>                              2011.
>
>                [TP-LM-DM]    Frost, D., Bryant, S., "A Packet Loss and
>             Delay
>
>              Measurement Profile for MPLS-Based Transport
>
>              Networks", RFC 6375, September 2011.
>
>                [TP-Fault]    Swallow, G., Fulignoli, A., Vigoureux,
>             M., Boutros, S.,
>
>                              "MPLS Fault Management Operations,
>             Administration, and
>
>              Maintenance (OAM)", RFC 6427, November 2011.
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 30]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                [Lock-Loop]   Boutros, S., Sivabalan, S., Aggarwal, R.,
>             Vigoureux,
>
>                              M., Dai, X., "MPLS Transport Profile Lock
>             Instruct and
>
>                              Loopback Functions", RFC 6435, November 2011.
>
>                [ITU-T-CT]    Betts, M., "Allocation of a Generic
>             Associated Channel
>
>                              Type for ITU-T MPLS Transport Profile
>             Operation,
>
>              Maintenance, and Administration (MPLS-TP OAM)", RFC
>
>                              6671, November 2012.
>
>                [PW-Map]      M. Aissaoui, P. Busschbach, L. Martini,
>             M. Morrow, T.
>
>                              Nadeau, "Pseudowire (PW) Operations,
>             Administration,
>
>                              and Maintenance (OAM) Message Mapping",
>             RFC 6310, July
>
>                              2011.
>
>                [PW-G-ACh]    Li, H., Martini, L., He, J., Huang, F.,
>             "Using the
>
>                              Generic Associated Channel Label for
>             Pseudowire in the
>
>                              MPLS Transport Profile (MPLS-TP)", RFC
>             6423, November
>
>                              2011.
>
>             7.2. Informative References
>
>                [OAM-Def] Andersson, L., Van Helvoort, H., Bonica, R.,
>             Romascanu,
>
>                              D., Mansfield, S., "Guidelines for the
>             use of the OAM
>
>                              acronym in the IETF ", RFC 6291, June 2011.
>
>                [OAM-Analys]  Sprecher, N., Fang, L., "An Overview of
>             the OAM Tool
>
>                              Set for  MPLS based Transport Networks",
>             RFC 6669,
>
>                              July 2012.
>
>                [TP-Term]     Van Helvoort, H., Andersson, L.,
>             Sprecher, N., "A
>
>              Thesaurus for the Terminology used in Multiprotocol
>
>                              Label Switching Transport Profile (MPLS-TP)
>
>              drafts/RFCs and ITU-T's Transport Network
>
>              Recommendations", work-in-progress, draft-ietf-mpls-
>
>              tp-rosetta-stone, July 2012.
>
>                [IEEE802.1ag] IEEE 802.1Q, "IEEE Standard for Local and
>             metropolitan
>
>                              area networks - Media Access Control
>             (MAC) Bridges and
>
>                              Virtual Bridged Local Area Networks",
>             October 2012.
>
>                [ITU-T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM
>             Functions and
>
>              Mechanisms for Ethernet-based Networks", July 2011.
>
>                [ITU-T-Y1711] ITU-T Recommendation Y.1711, "Operation &
>             Maintenance
>
>              mechanism for MPLS networks", February 2004.
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 31]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                [IEEE802.3ah] IEEE 802.3, "IEEE Standard for
>             Information technology -
>
>                              Local and metropolitan area networks -
>             Carrier sense
>
>                              multiple access with collision detection
>             (CSMA/CD)
>
>                              access method and physical layer
>             specifications",
>
>                              clause 57, December 2008.
>
>                [ITU-T-G.806] ITU-T Recommendation G.806,
>             "Characteristics of
>
>              transport equipment - Description methodology and
>
>                              generic functionality", January 2009.
>
>                [ITU-G8113.2] ITU-T Recommendation G.8113.2/Y.1372.2,
>             "Operations,
>
>              administration and maintenance mechanisms for MPLS-TP
>
>                              networks using the tools defined for
>             MPLS", November
>
>                              2012.
>
>                [ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372.1,
>             "Operations,
>
>              Administration and Maintenance mechanism for MPLS-TP
>
>                              in Packet Transport Network (PTN)",
>             November 2012.
>
>             Authors' Addresses
>
>                Tal Mizrahi
>
>                Marvell
>
>                6 Hamada St.
>
>                Yokneam, 20692
>
>                Israel
>
>                Email: [e-mail] <mailto:[e-mail]>
>
>                Nurit Sprecher
>
>                Nokia Siemens Networks
>
>                3 Hanagar St. Neve Ne'eman B
>
>                Hod Hasharon,   45241
>
>                Israel
>
>                Email: [e-mail]
>             <mailto:[e-mail]>
>
>                Elisa Bellagamba
>
>                Ericsson
>
>                6 Farogatan St.
>
>                Stockholm,   164 40
>
>                Sweden
>
>             Mizrahi, et al. Expires July 9, 2013                 [Page 32]
>
>             Internet-Draft Overview of OAM Mechanisms          
>             January 2013
>
>                Phone: [phone]
>
>                Email: [e-mail]
>             <mailto:[e-mail]>
>
>                Yaacov Weingarten
>
>                34 Hagefen St.
>
>                Karnei Shomron, 4485500
>
>                Israel
>
>                Email: [e-mail] <mailto:[e-mail]>
>
>             draft-ietf-opsawg-oam-overview authors,
>
>             Here is my feedback on this document.
>
>             1.
>             Is this document in line with
>             http://tools.ietf.org/html/draft-ietf-trill-oam-req-04?
>             * For example, the following definitions could be reused.
>
>                 Fault: The term Fault refers to an inability to perform a required
>
>                 action, e.g., an unsuccessful attempt to deliver a packet.
>
>               
>
>                 Defect: The term Defect refers to an interruption in the normal
>
>                 operation, such that over a period of time no packets are delivered
>
>                 successfully.
>
>               
>
>                 Failure: The term Failure refers to the termination of the required
>
>                 function over a longer period of time. Persistence of a defect for a
>
>                 period of time is interpreted as a failure.
>
>               
>
>             * For example, on the basic abstract
>
>             Abstract
>
>               
>
>                 Operations, Administration, and Maintenance (OAM) is a general term
>
>                 that refers to a toolset that can be used for fault detection and
>
>                 isolation, and for performance measurement. OAM mechanisms have been
>
>                 defined for various layers in the protocol stack, and are used with a
>
>                 variety of protocols.
>
>               
>
>             Abstract (draft-ietf-trill-oam-req-04)
>
>               
>
>                 OAM (Operations, Administration and Maintenance) is a general term
>
>                 used to identify functions and toolsets to troubleshoot and monitor
>
>                 networks. This document presents, OAM Requirements applicable to
>
>                 TRILL.
>
>               
>
>             So, as an example: does OAM include function?
>
>             I advice to review draft-ietf-trill-oam-req-04
>
>               
>
>             2.
>
>             draft-ietf-trill-oam is not mentioned, while the abstract mentions:
>
>                 This document presents an overview of the OAM mechanisms that have
>
>                 been defined and are currently being defined by the IETF.
>
>             Search for OAM in the current draft names (https://datatracker.ietf.org/), and you will find many references.
>
>             Ok, I see later on:
>
>                 This document focuses on IETF
>
>                 documents that have been published as RFCs, while other ongoing OAM-
>
>                 related work is outside the scope.
>
>             Ok, fine then: we don't need a reference to all the drafts.
>
>             However, draft-ietf-trill-oam is closed to be a RFC, and should be mentioned.
>
>               
>
>               
>
>             3.
>
>             Section 1
>
>                 The term OAM in this document refers to Operations, Administration
>
>                 and Maintenance [OAM-Def  <http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#ref-OAM-Def>], focusing on the forwarding plane of OAM.
>
>             What does it mean "focusing on the forwarding plane of OAM"?
>
>             Do you take a subset of the definition for this document?
>
>             Btw, I don't see a definition in the terminology section.
>
>             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.
>
>             Which plane is MP?
>
>               
>
>             4.
>
>             Section 1, Introduction
>
>             "Hence, management aspects are outside the scope of this document."
>
>             I don't understand which management aspects we speak about here.
>
>             5.
>             Clarifying question regarding 1.2
>             If speak about OWAMP or TWAMP 'synthetic traffic), is that
>             data plane, control plane, or management plane?
>             Note that I found later on in the draft:
>
>                 OWAMP and TWAMP use two separate protocols: a Control plane protocol,
>
>                 and a Test plane protocol.
>
>             Interestingly enough, after reading the document, I
>             reviewed
>             http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/,
>             and saw the same feedback from Stewart Bryant:
>
>             Provide a clear view of OAM functionality and its relationship
>
>             to various "planes" of networking (data plane, control plane,
>
>             management plane). In particular, the importance of
>
>             fate-sharing of OAM and user traffic flows in packet networks
>
>             should be explained.
>
>             6.
>
>             I see a multiplication of "plane" terms in the IETF document, and in this document in particular.
>
>             I could find: forwarding plane, management plane, control plane, data plane, user plane, and test plane.
>
>             Way too many.
>
>             Please be consistent
>
>             7.
>
>                 Table 1 summarizes the IETF OAM related RFCs discussed in this
>
>                 document.
>
>               
>
>                 Table 2 summarizes the OAM standards mentioned in this document.
>
>               
>
>             You need to change the Table 2 description. Do you want to say something along the lines of:
>
>                 Table 2 summarizes the OAM standards specified by other Standard Development Organization
>
>                 (SDO) than the IETF, along with IETF references where applicable.
>
>               
>
>               
>
>             8.
>
>             Section 2.2.1
>
>                 For a formal definition of each term, refer to the references at the end of
>
>                 this document.
>
>             Without a reference to a specific RFC, this is the type of statement which is not useful: you have 5 pages of references.
>
>             You position this document as "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", but you tell the reader: "if you want to know about the terms,
>
>             just read first all references!"
>
>               
>
>             9.
>
>             You specify some terms and some OAM categories,
>
>                 2.2.2  <http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#section-2.2.2>. OAM Maintenance Entities ..........................13  <http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#page-13>
>
>                       2.2.3  <http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#section-2.2.3>. OAM Maintenance Points ............................14  <http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#page-14>
>
>                       2.2.4  <http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#section-2.2.4>. Proactive and On-demand activation ................15  <http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#page-15>
>
>                       2.2.5  <http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#section-2.2.5>. Connectivity Verification and Continuity Checks ...15  <http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#page-15>
>
>                       2.2.6  <http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#section-2.2.6>. Failures ..........................................15  <http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#page-15>
>
>             ... but you don't use them in the section 3
>
>               
>
>             Just_one_example with section 3.2.2
>
>             -
>
>                 o Demand mode: in this mode, BFD control packets are sent on-demand.
>
>                    Upon need, a system initiates a series of BFD control packets to
>
>                    verify the liveness of the session
>
>             Instead of liveness, you have defined Connectivity Verification and Continuity Checks in section 2.2.5
>
>             - OLD:
>
>                 Each of the end-points of the monitored path maintains its own
>
>                 session identification
>
>             NEW:
>
>                 Each of the MEP maintains its own session identification
>
>             OR NEW (actually I don't know)
>
>                 Each of the MP maintains its own session identification
>
>             - OLD
>
>                 A BFD echo packet is sent to a peer system
>
>             Peer system = MEP, MP, or something else?
>
>             - etc...
>
>               
>
>             10.
>
>             This document is composed of a list of OAM content and references, but I'm really missing the document "scope and target audience".
>
>             When we did RFC 6632, which is the companion document, we hadhttp://tools.ietf.org/html/rfc6632#section-1.1
>
>               
>
>                 The target audience of the document is, on the one hand, IETF working
>
>                 groups, which aim to select appropriate standard management protocols
>
>                 and data models to address their needs concerning network management.
>
>                 On the other hand, the document can be used as an overview and
>
>                 guideline by non-IETF Standards Development Organizations (SDOs)
>
>                 planning to use IETF management technologies and data models for the
>
>                 realization of management applications.  The document can also be
>
>                 used to initiate a discussion between the bodies with the goal to
>
>                 gather new requirements and to detect possible gaps.  Finally, this
>
>                 document is directed to all interested parties that seek to get an
>
>                 overview of the current set of the IETF network management protocols
>
>                 such as network administrators or newcomers to the IETF.
>
>               
>
>             You should have something similar.
>
>               
>
>               
>
>             11.
>
>             Section 3.6.1, put the paragraph 2 at the end of the section. The "alternative" in the following sentence would then make sense
>
>                 Alternative protocols for performance measurement are defined, for
>
>                 example, in MPLS-TP OAM ([MPLS-LM-DM  <http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#ref-MPLS-LM-DM>], [TP-LM-DM  <http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#ref-TP-LM-DM>]), and in Ethernet
>
>                 OAM [ITU-T-Y1731  <http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#ref-ITU-T-Y1731>].
>
>               
>
>               
>
>             My conclusions: this document still needs some work
>
>               
>
>             Regards, Benoit
>
>               
>
>                 The IESG has received a request from the Operations and Management Area
>
>                 Working Group WG (opsawg) to consider the following document:
>
>                 - 'An Overview of Operations, Administration, and Maintenance (OAM)
>
>                     Mechanisms'
>
>                    <draft-ietf-opsawg-oam-overview-08.txt> as Informational RFC
>
>                   
>
>                 The IESG plans to make a decision in the next few weeks, and solicits
>
>                 final comments on this action. Please send substantive comments to the
>
>                 [e-mail]  <mailto:[e-mail]>  mailing lists by 2013-01-25. Exceptionally, comments may be
>
>                 sent [e-mail]  <mailto:[e-mail]>  instead. In either case, please retain the
>
>                 beginning of the Subject line to allow automated sorting.
>
>                   
>
>                 Abstract
>
>                   
>
>                   
>
>                     Operations, Administration, and Maintenance (OAM) is a general term
>
>                     that refers to a toolset that can be used for fault detection and
>
>                     isolation, and for performance measurement. OAM mechanisms have been
>
>                     defined for various layers in the protocol stack, and are used with a
>
>                     variety of protocols.
>
>                   
>
>                     This document presents an overview of the OAM mechanisms that have
>
>                     been defined and are currently being defined by the IETF.
>
>                   
>
>                   
>
>                   
>
>                   
>
>                 The file can be obtained via
>
>                 http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/
>
>                   
>
>                 IESG discussion can be tracked via
>
>                 http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/
>
>                   
>
>                   
>
>                 No IPR declarations have been submitted directly on this I-D.
>
>                   
>
>                   
>
>                   
>