1. T-MPLS Update IETF70 December 2007 Stewart Bryant stbryant@cisco.com

2. IETF69 At IETF69 concerns were raised that by redefining many aspects of the IETF MPLS and PWE3 design, TMPLS would be harmful to the Internet. As a result of these concerns the IAB and the IESG sent a joint liaison to the ITU-T TSB, SG13 and SG15 management. This liaison can be found at: https://datatracker.ietf.org/documents/LIAISON/file470.txt

3. The Liaison - Concern Concern that the T-MPLS design is detrimental to mutual goal of reliable global communications. ”…decision to use the MPLS Ethertypes to point to a label space other than as defined by the MPLS RFCs to be architecturally unsound and ultimately will prove to be limiting to … MPLS and T-MPLS".

4. Liaison - Separation ITU claim is that IETF MPLS and T-MPLS will only be deployed in disjoint networks, but there is evidence of desire for complete interoperability of the forwarding, control and OAM planes of T-MPLS and IETF MPLS….using identical codepoints. Network elements rarely remain disjoint in practice. Accidental misconfiguration occurs and is significant factor in serious network outages. Disjoint networks and expectation that T-MPLS is or will remain a profile of IETF MPLS is unrealistic. Only way of assuring that separation is maintained is through mutual exclusivity of codepoints.

5. Liaison - Options Presented 1.Work together. Bring T-MPLS requirements into the IETF and extend IETF MPLS forwarding, OAM and control plane protocols to meet those requirements through the IETF Standards Process. This is IETF preferred solution. 2.State that T-MPLS is a desired duplication of IETF MPLS technology. ITU-T SG 15 make the necessary changes for complete codepoint separation of T-MPLS and IETF MPLS. Not IETF preferred solution. Changes must happen before wide deployment of TMPLS

6. ITU-Action on Liaison Statement ITU management referred the liaison to four ITU-T questions: SG15Q12* - Transport network architectures SG15Q11 - Signal structures, interfaces and interworking for transport networks SG15Q9 - Transport equipment and network protection/restoration SG13Q5 - OAM and network management for NGN Note that SG15Q14 is also doing work on TMPLS. *ITU would write this as SG12/15, however it is usually pronounced in the pneumonic used in these slides.

7. SG15Q12 Stuttgart ITU SG15 Question 12 has been the question that has done most of the work on TMPLS. The meeting was attended by 3ADs and one IAB member, plus myself in the role of IETF liaison on MPLS. Other IETF members also made significant contributions. Many hours of work went into addressing the issues raised in the IETF liaison, and a working method was proposed.

8. The Stuttgart Proposal Option 2 (codepoint separation) should be rejected. The IETF and ITU-T should to ensure MPLS/T-MPLS compatibility, consistency, and coherence. Sole design authority for MPLS resides in the IETF Domain of expertise for Transport Network Infrastructure resides in ITU-T SG15. The work under consideration on T-MPLS and MPLS includes: Forwarding Plane OAM Control Plane Network survivability (e.g. Protection Switching, restoration) Transport equipment and network management.

9. Proposed Joint Working Team Joint IETF and ITU-T working team to be established to propose how to progress the various aspects of the requirements, solutions, and architecture for the T-MPLS work. Regularly report to both ITU-T and IETF on its progress. The working team will examine existing approved or consented ITU-T Recommendations, and will report on the results of their review. If inconsistencies, incompatibilities or omissions are identified with the use of IETF MPLS technology, then they will be resolved either by amending ITU-T Recommendations or by generating new work in the IETF. Amendments to ITU-T Recommendations will be implemented via the normal ITU-T process. Any necessary functionality not supported by current RFC will be brought to the IETF for progression.

10. Future Work Working team to analyze requirements and desired functionality WT identify and recommend what aspects of the requirements, solutions and architecture should be formally documented in IETF RFCs using the IETF Standards Process or, ITU-T Recommendations using the ITU-T process. The IETF Standards Process will be used for extensions or modifications of IETF MPLS Technology.

11. Joint Interest Some areas of technology (e.g. OAM and network survivability) straddle the interests and technology of both groups. WT to create an agreement on leadership roles and the modifications necessary to develop an architecture that it is compatible, coherent and consistent between both transport and IETF MPLS technologies. In these areas both standards processes will be used in order to create an environment that will complement and validate each other. In all cases, work should be progressed (in cooperation) under the process of the appropriate organization.

12. Normative IETF References ITU-T T-MPLS documents will include appropriate normative reference to IETF RFCs. Restatement of protocol specifics to be minimized. ITU-T document will include a statement that makes clear: 1.No intention to change the normative behavior of the referred to IETF RFC. 2.If any conflicts are discovered after publication, the IETF RFC is the authoritative source for resolution.

13. Normative ITU References IETF documents will include appropriate normative reference to ITU documents. Restatement of protocol specifics to be minimized. IETF document will include a statement that makes clear: 1.No intention to change the normative behavior of the referred to ITU document 2.If any conflicts are discovered after publication, the ITU document is the authoritative source for resolution.

14. SG15Q11 & 9 SG15 Q11 endorsed the Stuttgart recommendation with a minor concern on traffic rates SG15 Q9 endorsed the Stuttgart recommendation

15. ITU SG13 ITU SG13 will discuss the IETF liaison at their Plenary in January 2008. However G8113 and G8114 (T-MPLS OAM) are already consented and are set to be approved by SG13 in January. These specifications are the cause of some concern.

16. MPLS Reserved Label 14 IETF RFC 3429 Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions (11/2002) ITU-T Y.1711 Operation and Maintenance for MPLS Networks (11/02) - SUPERCEDED IANA assigned use of Label 14 to the now superceded (11/02) version of Y.1711 based on IETF consensus as documented in RFC 3429 ITU-T Y.1711 (02/04) In Force ITU-T G.8112/Y.1371 (10/2006) In Force ITU-T G8114/Y.1373 (in AAP) Label 14 is used by all of the below ITU-T Recommendations but IANA has not assigned this usage and an IETF consensus does not exist Y.1711 Operation and Maintenance for MPLS Networks (02/04) Y.1711 Corrigendum 1 (02/05) Y.1711 Amendment 1 New Function Type codes (10/05) G.8112/Y.1371 Interfaces for Transport MPLS (T-MPLS) hierarchy (10/2006) G.8114/Y.1373 Operation and Maintenance Mechanisms for T-MPLS Layer Networks (AAP) From RFC 3032: “Label values may be assigned by IANA, based on IETF consensus”

17. ITU SG13 G8114 redefine the MPLS EXP and TTL bits. It also defines a new P router behavior. G8113 and G8114 runs on MPLS reserved label 14 and thereby amend the definition of definition of that label. However Label 14 is defined by RFC3429. Since changes to the definition of Label 14 require IETF Standards Action to amend RFC3429, it seems premature to publish G8113 and G8114 prior to the IETF Standards Process approving the redefinition of label 14. We have sent a liaison on this, but we should send a stronger liaison.

18. ITU SG15Q14 SG15Q14 was not forwarded the IETF liaison. Met last week, and accepted a contribution that proposed to use the MPLS label 14 OAM channel as an IP and OSI messaging Channel, i.e. uses the label 14 OAM channel to create a management VPN.

19. Interim IETF Work Big challenge is understanding the existing and proposed ITU T- MPLS specifications and determining their consistency with IETF MPLS & PWE3. Different terminology and use of G805 modeling language make this particularly challenging. A small IAB analysis team established with the purpose of: Identifying an action list for the IETF –Identifying incompatibles and inconsistencies between IETFand ITU-T documents –IETF decisions to be revisited –Organisation to take care of ITU-T mpls/pwe3 requirements They have a lot of reading to do! When the “Joint Team” becomes established, this work will move there. The team can be contacted at t-mpls-dt@testbed.se

20. Questions?