1. MPLS-TP OAM Analysis draft-sprecher-mpls-tp-oam-analysis-03.txt Nurit Sprecher / Nokia Siemens Networks Huub van Helvoort / Huawei Yaacov Weingarten / Nokia Siemens Networks Elisa Bellagamba / Ericsson

2. Draft Status The design team f2f meeting last week, worked on the OAM design. This presentation reflects the outcome of the design team meeting. The draft will be updated to reflect the recommendations of that meeting.

3. Purpose of the Document Analyze whether existing IETF/ITU-T OAM tools can fulfill the functional requirements Identify which tools may be extended in order to support the functional requirements Identify whether new tools need to be defined to fulfill certain functional requirements MPLS-TP OAM Requirements Draft (draft-ietf-mpls-tp-oam- requirements-02.txt) IETF existing OAM Tools for LSPs: - LSP Ping - MPLS BFD IETF existing OAM tools for PWs: VCCV supporting ICMP Ping VCCV supporting LSP Ping VCCV supporting BFD (with and without IP/UDP encapsulation ) ITU-T Y.1731

4. Remote Defect Indication Alarm Suppression Organization of the Document The existing tools are evaluated based on the different OAM requirements and gaps (if they exist) are identified. Recommendations and guidelines are provided. Architectural Requirements General Principles of Operations Connectivity Verification Continuity & Connectivity Verification Requirements for the OAM Functions Analysis of OAM Requirements

5. Findings LSP-Ping can easily be extended to support some of the functions between MEP-to-MEP and MEP-to-MIP. BFD can be extended to support some of the functions between MEP-to-MEP Some of the OAM functions defined in Y.1731 (especially for performance monitoring) can be adapted. The PDU format of Y.1731 includes many fields that are not relevant to the MPLS-TP environment. Using Y.1731 PDU for MPLS- TP OAM messages, will be densely populated with zero bits.

6. Guidelines Re-use/extend existing IETF protocols where applicable (fault management) Define new message format for each of the rest of the OAM functions, which are (1) aligned with the ACH and ACH TLV definitions, and (2) includes only relevant information. Adapt Y.1731 functionality where applicable (mainly for performance monitoring).

7. Recommendations (1) RecommendationFunction Extend BFD (e.g. maintenance entities, unique global identification, G-ACH, P2MP, etc.) Proactive Continuity Check & Connectivity Verification (CC&V) Extend LSP-Ping (e.g. maintenance entities, identifiers other than IP, G-ACH, MIP identification, bypass of CP/DP verification, etc.) On-demand Connectivity Verification (CV) For data-plane implementation, define a new PDU and use G-ACH. Support in control-plane and management-plane should also be described. Alarm Reporting Define a new PDU and use G-ACH. Use the same procedures as for Alarm Reporting Lock Reporting

8. Recommendations (2) RecommendationFunction Extend BFD. Signal will be passed via BFD.Remote Defect Indication (RDI) Extend LSP-PingRoute Tracing Extend LSP-PingLock Instruct (MEP-to-MEP) Use PWE3 tool to transmit the indication via ACH. Two proposed tools in PWE3: draft-martini-pwe3- static-pw-status-01.txt and draft-he-mpls-tp-csf- 00.txt Client Fault Indication (CFI) Define a new PDU, use G-ACH. We intend to base the functionality on Y.1731. Packet Loss (pro-active and on- demand)

9. Recommendations (3) RecommendationFunction Define a new PDU, use G-ACH. We intend to base the functionality on Y.1731. Requires expertise in time synchronization (as one- way delay measurement is dependent upon a certain degree of synchronization between the time clocks of the two-ends of the transport path) Delay Measurement (pro-active and on-demand), one-way and two-way Define a new PDU, use G-ACH. Requires more study. Diagnostics, on-demand (verify bandwidth throughput, bit errors, loopback, etc. )

10. Next Steps Update the document to reflect the design team review Progress the document to provide a reference for the considerations and the agreed decisions

11. Questions