Skip to main content

An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks
draft-ietf-mpls-tp-oam-analysis-09

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    mpls mailing list <mpls@ietf.org>,
    mpls chair <mpls-chairs@tools.ietf.org>
Subject: Document Action: 'An Overview of the OAM Tool Set for MPLS based Transport Networks' to Informational RFC (draft-ietf-mpls-tp-oam-analysis-09.txt)

The IESG has approved the following document:
- 'An Overview of the OAM Tool Set for MPLS based Transport Networks'
  (draft-ietf-mpls-tp-oam-analysis-09.txt) as Informational RFC

This document is the product of the Multiprotocol Label Switching Working
Group.

The IESG contact persons are Adrian Farrel and Stewart Bryant.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-analysis/


Ballot Text

Technical Summary

   This document provides an overview of the OAM toolset for MPLS based Transport
   Networks.  The toolset consists of a comprehensive set of fault management and
   performance monitoring capabilities (operating in the data-plane) which are
   appropriate for transport networks as required in RFC 5860 and support the
   network and services at different nested levels.  This overview includes a brief
   recap of MPLS-TP OAM requirements and functions, and of generic mechanisms
   created in the MPLS data plane to allow the OAM packets run in-band and share
   their fate with data packets.  The protocol definitions for each of the MPLS-TP
   OAM tools are defined in separate documents (RFCs or Working Group drafts) which
   are referenced by this document.

Working Group Summary 

   This informational document has passed working group last call with clear
   consensus in favor of publication.

Document Quality 

   This is an informational document which is not subject to be implemented. It
   provides description of and pointers to other documents, for which there are 
   multiple current implementations and/or implementations in progress.

Personnel

   Ross Callon (rcallon@juniper.net) is the Document Shepherd
   Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD

RFC Editor Note

Section 1.1
OLD
   o  The OAM toolset developed for MPLS based transport networks needs
      to be fully inter-operable with existing MPLS OAM tools as
      documented in [RFC 5860].
NEW
   o  The OAM toolset developed for MPLS based transport networks needs
      to be fully inter-operable with existing MPLS OAM tools as
      documented in section 2.1.5. of [RFC 5860].
END

---

Section 1.1
OLD
However, compatibility with the existing tools has been maintained.
NEW
However, compatibility with the existing MPLS tools has been maintained.
END

---

Section 4 Table 2

OLD
   +------------------------+---------------------------------+--------+
   | OAM Functions          | OAM Tools/Protocols             | RFCs   |
   +------------------------+---------------------------------+--------+
   | Connectivity           | LSP Ping                        | [RFC   |
   | Verification           |                                 | 6426]  |
   +------------------------+---------------------------------+--------+
   | Diagnostic: Loopback   | (1) G-ACh based Loopback and    | [RFC   |
   | and Lock Instruct      | Lock Instruct, (2) LSP Ping     | 6435]  |
   +------------------------+---------------------------------+--------+
   +------------------------+---------------------------------+--------+
   | Lock Instruct(LI)      | Flag in AIS message             | [RFC   |
   |                        |                                 | 6427]  |
   +------------------------+---------------------------------+--------+
NEW
   +------------------------+---------------------------------+--------+
   | OAM Functions          | OAM Tools/Protocols             | RFCs   |
   +------------------------+---------------------------------+--------+
   | Connectivity           | LSP Ping                        | [RFC   |
   | Verification           |                                 | 6426]  |
   +------------------------+---------------------------------+--------+
   | Lock Instruct (LI)     | (1) G-ACh based Loopback,       | [RFC   |
   |                        | (2) Lock Instruct (LI)          | 6435]  |
   +------------------------+---------------------------------+--------+
   | Lock Report (LKR)      | Flag in AIS message             | [RFC   |
   |                        |                                 | 6427]  |
   +------------------------+---------------------------------+--------+
END

---

Section 5.2, third paragraph
OLD
  The Lock operation instruction is carried in an MPLS Loopback request
  message sent from a MEP to a trail-end MEP of the LSP to request that
  the LSP be taken out of service.  In response, the Lock operation 
  reply is carried in a Loopback response message sent from the trail-
  end MEP back to the originating MEP to report the result.
NEW
  [RFC6435] defines a mechanism where a lock instruction is sent by a
  management application to both ends of a point-to-point LSP requesting
  them to take the LSP out-of-service. When an endpoint gets the 
  management request, it locks the LSP and sends a Lock Instruct message
  to the other end of the LSP. The Lock Instruct message is carried in a 
  Generic ACH message and is sent periodically. The time between 
  successive messages is no longer than the value set in the Refresh 
  Timer field of the Lock Instruct message. An LSP end point keeps the 
  LSP locked while it is either receiving the periodic Lock Instruct 
  messages or has an in-force lock instruction from the management 
  application. 

  Note that since the management application will receive a management 
  plane response from both ends of the LSP confirming that the LSP has
  been locked, there is no requirement for the Lock Instruct message to
  have a response. Therefore, [RFC6435] does not define a Lock Instruct
  response message. 
END

---

Section 7,paragraph 3

OLD
  OAM in general is always an area where the security risk is high,
  e.g. confidential information may be intercepted for attackers to
  again access to the networks, therefore authentication, authorization,
  and encryption need to be enforced for prevent security breach.
NEW
  OAM in general is always an area where the security risk is high. For 
  example, confidential information may be intercepted by attackers to 
  gain access to networks, therefore authentication, authorization, and
  encryption need to be enforced to prevent security breaches.
END

---

Section 7, paragraph 4:

OLD
  In addition to implement security protocol, tools, and mechanisms, 
  following strict operation security procedures is very important, 
  especially MPSL-TP static provisioning processes involve operator 
  direct interactions with NMS and devices, its critical to prevent 
  human errors and malicious attacks.
NEW
  It is also important to strictly follow operational security
  procedures. For example, in the case of MPLS-TP static provisioning,
  the operator interacts directly with the NMS and devices, and it is 
  critical to prevent human errors as well as malicious attacks.
END

---

Section 7, final paragraph

OLD
  Since MPLS-TP OAM uses G-ACh, the security risks and mitigation 
  described in [RFC 5085] apply here.  In short, the G-ACh could be
  intercepted, or false G-ACh packets could be inserted.  DoS attack
  could happen by flooding G-ACh messages to peer devices.  To mitigate
  this type of attacks, throttling mechanisms can be used.  For more
  details, please see [RFC 5085].
NEW
  Since MPLS-TP OAM uses G-ACh, the security risks and mitigations 
  described in [RFC 5085] also apply here.  In short, messages on the
  G-ACh could be intercepted, or false G-ACh packets could be inserted. 

  Additionally DoS attacks can be mounted by flooding G-ACh messages to
  peer devices.  To mitigate this type of attack, throttling mechanisms
  or rate limits can be used. For more details, please see [RFC 5085].
END

---

Section 8., paragraph 3:

s/doecument/document/

---

Section 9.2
OLD
              ID draft-ietf-mpls-tp-security-framework-02, May 2011.
NEW
              draft-ietf-mpls-tp-security-framework-03, October 2011.
END

---

Spaces in reference tags.Please feel free to change any and all reference
tags so that they do not contain space characters.

RFC Editor Note