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/ 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 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
