1. 1 MPLS Architectural Considerations for a Transport Profile ITU-T - IETF Joint Working Team Dave Ward, Malcolm Betts, ed. April 16, 2008

2. 2 Table of Contents Executive Overview –Recommendation Introduction and Background Material High Level Architecture OAM Requirements OAM Mechanisms and Baseline Use Cases Associated Channel Level (ACH) Forwarding and OAM –LSP/PW OAM –Use Case Scenario and Label Stack Diagrams –Use of TTL for MIP OAM alert –Packet Context Control Plane Survivability Network Management Summary

3. 3 Executive Summary

4. 4 Recommendation  Consensus on recommendation of Option 1 –Jointly agree to work together and bring transport requirements into the IETF and extend IETF MPLS forwarding, OAM, survivability, network management and control plane protocols to meet those requirements through the IETF Standards Process –The Joint Working Team believes this would fulfill the mutual goal of improving the functionality of the transport networks and the internet and guaranteeing complete interoperability and architectural soundness –Therefore, we recommended that the work on the MPLS “Transport Profile” and on T-MPLS must be kept aligned  The technical feasibility analysis demonstrated there were no “show stopper” issues in the recommendation of Option 1 and that the IETF MPLS and Pseudowire architecture could be extended to support transport functional requirements –Therefore the team believed that there was no need for the analysis of any other option

5. 5 Future inter-SDO organizational structure  It is proposed that the MPLS interop design team, JWT and ad hoc T-MPLS groups continue as described in SG15 TD515/PLEN with the following roles: –Facilitate the rapid exchange of information between the IETF and ITU-T –Ensure that the work is progressing with a consistent set of priorities –Identify gaps/inconsistencies in the solutions under development Propose solutions for consideration by the appropriate WG/Question –Provide guidance when work on a topic is stalled or technical decision must be mediated  None of these groups has the authority to create or modify IETF RFCs or ITU-T Recommendations –Any such work will be progressed via the normal process of the respective standards body –Direct participation in the work by experts from the IETF and ITU-T is required

6. 6 Role for the IETF MPLS Interoperability Design Team  The IETF MPLS Interoperability Design Team should be chartered to produce an MPLS-TP architectural documentation hierarchy –All documents would progress in appropriate IETF WGs according to the normal process –The list of specific documents to be written in the IETF will be created by the DT No additional work on MPLS-TP will be taken on until the architectural foundation documents have progressed into WG LC –The Design Team is the group sponsored by the Routing Area Directors to facilitate rapid communication and coherent and consistent decision making on the Transport Profile for MPLS –An example of such a tree (by functional area) is below: Requirements (MPLS WG) Transport Profile Architectural Framework (MPLS WG) Alert Label Definition (MPLS WG) ACH Definition (PWE3 WG) Survivability (MPLS WG) Control Plane (CCAMP WG) Network Management (MPLS WG) Italo Busi: Where are the required OAM protocols (e.g. CV, PM, AIS) defined? Italo Busi: Where are the required OAM protocols (e.g. CV, PM, AIS) defined? Italo Busi: This sentence is not clear to me: “No additional work on MPLS-TP will be taken on until the architectural foundation documents have progressed into WG LC” Italo Busi: This sentence is not clear to me: “No additional work on MPLS-TP will be taken on until the architectural foundation documents have progressed into WG LC”

7. 7 Development of RFCs on MPLS-TP  Work areas will be assigned to the appropriate IETF Working Groups to develop the RFCs –Working group charters and milestones will be updated to reflect the new work Expected to be completed before IETF 72 (July 2008) This will include the list of documents in the architectural hierarchy –WGs will appoint authors and where appropriate form design teams to develop the RFCs It is assumed that ITU-T participants will be active members of these design teams The draft will be reviewed by the ITU-T prior to completion of WG last call –Apply for early allocation of RFC numbers and IANA codepoints once a document has completed IESG review –ITU-T review will be by correspondence, the results of this review will be conveyed via a liaison statement »Review by correspondence will avoid delaying WG last call to align with an ITU-T SG/experts meeting

8. 8 Development of ITU-T Recommendations on MPLS-TP  Work areas will be assigned to the Questions as defined in COM 15 - C1 (Questions allocated to SG15) – Work will be progressed in each question Direct participation by interested parties from the IETF is strongly encouraged Draft versions of Recommendations will be provided to the IETF for review via a liaison to a WG and/or via the JWT –It is anticipated that approval will be using AAP as defined in Recommendation A.8 Interim WP meetings may be required to allow timely consent of Recommendations that rely on normative references to RFCs Final text for consent will be provided to the IETF for review –Member companies can base AAP comments on a WG consensus view of the text

9. 9 Documentation dependencies  The normative definition of the MPLS TP will be captured in IETF RFCs –ITU-T Recommendations will be developed to allow MPLS-TP to be integrated with current transport equipment and networks. IEFT may delegate ITU-T to develop some specific functionalities (e.g. APS) –It is anticipated that Recommendations addressing the following areas will be updated or created. The actual Recommendations will be identified by the questions responsible for the topic areas. Architecture (e.g. G.8110.1) Equipment (e.g. G.8121) Protection (e.g. G.8131, G.8132) OAM (e.g. G.8113, G.8114) Network management (e.g. G.7710, G.7712, G.8151, G.8152) Control plane (e.g. G.7713, G.7715, G.7715.1) –ITU-T Recommendations will make normative references to the appropriate RFCs

10. 10 Documentation schedule  First draft of the Transport Profile Architectural Framework –IETF 72 (July 2008)  Draft to request new reserved label for MPLS TP alert –IETF 72 (July 2008)  RFCs on Alert Label and ACH definition –WG last call completion Q2/2009  Updated ITU-T Recommendations –Q2/2009 (may need to schedule experts meeting/WP plenary to avoid delaying consent to the October 2009 meeting of SG 15) A significant amount of work is required to achieve these milestones We need to start now (May 2008) Need a commitment from interested parties to edit and drive the drafts A significant amount of work is required to achieve these milestones We need to start now (May 2008) Need a commitment from interested parties to edit and drive the drafts Italo Busi: What about the RFCs defining the required OAM protocols (e.g. CV, PM, AIS)? What about WG LC for other RFCs (e.g. transport profile architectural framework)? Italo Busi: What about the RFCs defining the required OAM protocols (e.g. CV, PM, AIS)? What about WG LC for other RFCs (e.g. transport profile architectural framework)?