Skip to main content

MPLS Fault Management Operations, Administration, and Maintenance (OAM)
draft-ietf-mpls-tp-fault-07

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: Protocol Action: 'MPLS Fault Management OAM' to Proposed Standard (draft-ietf-mpls-tp-fault-07.txt)

The IESG has approved the following document:
- 'MPLS Fault Management OAM'
  (draft-ietf-mpls-tp-fault-07.txt) as a Proposed Standard

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-fault/


Ballot Text

Technical Summary

  In traditional transport networks, circuits such as T1 lines are
  typically provisioned on multiple switches. When an event that
  causes disruption occurs on any link or node along the path of 
  such a transport circuit, Operations, Administration, and
  Maintenance (OAM) indications are generated which may
  suppress alarms and/or activate a backup circuit. These OAM
  messages are called Fault Management (FM) messages.

  The MPLS-TP requirements demand mechanisms equivalent
  to traditional transport circuits. Therefore an FM capability is
  needed in MPLS. This capability must meet the MPLS-TP 
  requirements set out in RFC 5654, and the MPLS-TP OAM
  requirements in RFC 5860. 

  This document specifies OAM messages to indicate service 
  disruptive conditions for MPLS transport Network Label Switched
  Paths.  The notification mechanism employs a generic method for a
  service disruptive condition to be communicated to a Maintenance
  Entity Group End Point.  This document defines an MPLS OAM 
  channel, along with messages to communicate various types of 
  service disruptive conditions.

  These mechanisms are intended to be applicable to other
  aspects of MPLS (beyond MPLS-TP), however, this is beyond
  the scope of this document.

Working Group Summary

  This document is a MPLS working group document, and part of the joint
  IETF - ITU.T MPLS-TP project. It has been reviewed in both organizations
  and there is a solid support for the document.

  There has been robust discussion about the technical solution and that
  has resulted in plenty of revisions to the text, but all changes were
  confirmed with the WG before the publication request was made. Changes
  as a result of AD review were plentiful, but editorial in nature.

  The IPR disclosure was notified to the mailing list and did not result in
  any suggestions to change the content of the document.

Document Quality

  The document has been carefuly reviewed in the MPLS working group and 
  the ITU-T. The last call was brought to the notice of SG15 in ITU-T who
  reviewed the document. It has also passed a working group call to verify 
  that LC comments were correctly with minor comments. 

  Several vendors are implementing this document.

Personnel

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

RFC Editor Note

   Section 2.1
   The primary purpose of the AIS message is to suppress alarms in the
   layer network above the level at which the fault occurs.  When the
   Link Down Indication is set, the AIS message MAY be used to trigger
   recovery mechanisms.

   s/MAY/can/

---

   Section 2.2

   While the primary purpose
   of the LKR message is to suppress alarms, similar to AIS with the LDI
   (L-flag set), the receipt of an LKR message MAY be treated as the
   equivalent of loss of continuity at the client layer.

   s/MAY/can/

---

   Section 8.1
   Please remove the note from the end of this section before publication.

---

   Section 8.4 para 1
   s/"Private Use"/"Experimental Use"/

IANA Note

   Please also note the Note in Section 8.1. IANA is requested to make the temporary allocation permanent. 

   Please see RFC Editor Note for Section 8.4

RFC Editor Note