Embed Size (px)
Citation preview
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
• 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".
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.
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
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 NGNNote 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.
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.
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.
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.
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.
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.
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.
SG15Q11 & 9
• SG15 Q11 endorsed the Stuttgart recommendation with a minor concern on traffic rates
• SG15 Q9 endorsed the Stuttgart recommendation
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.
MPLS Reserved Label 14
IETF RFC 3429Assignment of the 'OAM Alert Label' for
Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM)
Functions (11/2002)
ITU-T Y.1711Operation 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 TransportMPLS (T-MPLS) hierarchy (10/2006)
G.8114/Y.1373 Operation and Maintenance Mechanisms for T-MPLSLayer Networks (AAP)
From RFC 3032: “Label values may be assigned by IANA, based on IETF consensus”
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.
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?
