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