Transcript PPT Version
T-MPLS Update (abridged) IETF70 December 2007 Stewart Bryant [email protected] 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 The Liaison • Concern that the T-MPLS design is detrimental to the Internet. • MPLS Ethertypes MUST only to point to a label space defined by the MPLS RFCs. • ITU claim disjoint networks but talks about Interoperability. • Network elements rarely remain disjoint in practice. • 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. Liaison - Options Presented 1. 2. 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. 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 ITU-Action on Liaison Statement ITU management referred the liaison to four ITU-T questions: • SG15Q12* - Transport network architectures – This group has met and made a proposal. • SG15Q11 - Signal structures, interfaces and interworking for transport networks – This group endorsed the SG15Q12 proposal • SG15Q9 - Transport equipment and network protection/restoration – This group endorsed the SG15Q12 proposal • SG13Q5 - OAM and network management for NGN – Not yet met - see label 14 concerns Note that SG15Q14 is also doing work on TMPLS. *ITU would write this as SG12/15, however it is pronounced in the pneumonic form used in these slides. The Stuttgart Proposal • Option 2 (codepoint separation) 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. 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. 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. • 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. 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. Reciprocal arrangement for IETF documents that reference ITI work. ITU SG13 • RFC3429 defines the semantics of MPLS label14 • G8113 and G8114 runs on MPLS reserved label 14 and thereby amend the definition of definition of that label. • G8114 (T-MPLS OAM) redefines the MPLS EXP and TTL bits. • It also defines a new P router behavior. • 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. 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. 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 [email protected] Questions?