Transcript PPT Version

T-MPLS Update
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
• 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.
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
• 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.
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
From RFC 3032: “Label values may be assigned by IANA, based on IETF consensus”
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
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
ITU-T Y.1711
(02/04) In Force
ITU-T G.8112/Y.1371
(10/2006) In Force
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)
ITU-T G8114/Y.1373
(in AAP)
G.8114/Y.1373 Operation and
Maintenance Mechanisms for T-MPLS
Layer Networks (AAP)
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 TMPLS 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?