1. MPLS-TP OAM Analysis draft-ietf-mpls-tp-oam-analysis-00.txt
Nurit Sprecher / Nokia Siemens Networks
Huub van Helvoort / Huawei
Yaacov Weingarten / Nokia Siemens Networks
Elisa Bellagamba / Ericsson
IETF 76, Hiroshima

2. 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
Provide input to the decision process
Continue to track information, analysis, and decisions about OAM

3. Organization of the Document
Provide an overview on the existing OAM tools
The existing tools are evaluated based on the different OAM requirements, and gaps (if they exist) are identified.
Recommendations and guidelines are provided.
Report the conclusions of the discussions concerning the MPLS-TP OAM tools and the organization of the OAM documents at IETF75.
Add new sections reporting conclusions of further discussions of OAM

4. Guidelines
RFC 5654 requires that “the The MPLS-TP design SHOULD as far as reasonably possible reuse existing MPLS standards” and that “mechanisms and capabilities MUST be able to interoperate with existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and data planes where appropriate”
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, (2) includes only relevant information, and (3) extensible.
Adapt Y.1731 functionality where applicable (mainly for performance monitoring).

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.

6. Draft Status
Authors updated the document to include a report of the conclusions of the discussions concerning the MPLS-TP OAM tools and the organization of the OAM documents at IETF75.
Authors addressed comments received from the design team and from individuals on the mailing list.
The document is now an MPLS WG document.

7. Next Steps
Authors plan to work further on the text and address comments recently received on the MPLS-TP mailing list.
Keep it as a living document, keep revisiting the document as the OAM solutions are developed, and update it as needed.
Ultimately, the intention is to progress the document to provide a reference for the issues, considerations and the agreed decisions (informational or historic document).

8. Questions

9. Thanks

10. Backup Slides

11. Recommendations (1) Recommendation Function
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

12. Recommendations (2) Recommendation Function
Extend BFD. Signal will be passed via BFD.
Remote Defect Indication (RDI)
Extend LSP-Ping
Route Tracing
Lock 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)

13. Recommendations (3) Recommendation Function
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
Requires more study.
Diagnostics, on-demand (verify bandwidth throughput, bit errors, loopback, etc. )