[RFCs/IDs] [Plain] [Nits]
Versions: 00
Network Working Group S. Bryant, Ed.
Internet-Draft M. Morrow, Ed.
Intended status: Informational On behalf of the IAB
Expires: December 10, 2009 June 8, 2009
"Uncoordinated Protocol Development Considered Harmful"
draft-iab-mpls-tp-uncoord-harmful-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 10, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Bryant & Morrow Expires December 10, 2009 [Page 1]
Internet-Draft Uncoordinated Harmful June 2009
Abstract
This document identifies various types of damage that may occur
without formal coordination and joint development on protocols of
mutual interest between standards development organizations. The IAB
has selected T-MPLS as recent case study to describe hazard to both
the MPLS and Internet architecture as a result of uncoordinated
adaptation of a protocol.
This experience has resulted in a considerable improvement in the
relationship between the two organisations. In particular, this was
achieved via the establishment of the "Joint working team on MPLS-TP"
which was the first ever joint ITU/IETF group. In addition, the
leadership of the two organisations have agreed to improve inter-
organizational working practices so as to avoid conflict in future
between ITU-T Recommendations and IETF RFCs.
Bryant & Morrow Expires December 10, 2009 [Page 2]
Internet-Draft Uncoordinated Harmful June 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Protocol Safety . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Importance of Invariants . . . . . . . . . . . . . . . . . 5
2.2. Importance of Correct Identification . . . . . . . . . . . 5
2.3. The Role of the Design Authority . . . . . . . . . . . . . 6
2.4. Ships in the Night . . . . . . . . . . . . . . . . . . . . 6
3. T-MPLS As a Case Study . . . . . . . . . . . . . . . . . . . . 7
3.1. Multiple Definitions of Label 14 . . . . . . . . . . . . . 7
3.2. Redefinition of TTL Semantics . . . . . . . . . . . . . . 8
3.3. Reservation of Additional Labels . . . . . . . . . . . . . 8
3.4. Redefinition of MPLS EXP Bits . . . . . . . . . . . . . . 9
3.5. The Consequences for the Network Operators . . . . . . . . 9
3.6. The Consequences for the SDOs . . . . . . . . . . . . . . 9
4. MPLS-TP As Best Practice . . . . . . . . . . . . . . . . . . . 10
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. Generalization from this Case Study . . . . . . . . . . . . . 14
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative references . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Bryant & Morrow Expires December 10, 2009 [Page 3]
Internet-Draft Uncoordinated Harmful June 2009
1. Introduction
The uncoordinated adaptation of a protocol, parameter, or code-point
by a standards development organization (SDO), either through the
allocation of a code-point without following the formal registration
procedures, or by unilaterally modifying the semantics of the
protocol or intended use of the code-point itself, poses a risk of
harm to the Internet [RFC4775].
The purpose of this document is to describe the various types of
damages that may occur without formal coordination and joint
development on protocols of mutual interest between SDOs. In
particular, the IAB considers an essential principle of the protocol
development process that only one SDO maintains design authority for
a given protocol, with that SDO having ultimate authority over the
allocation of protocol parameter code-points; defining the intended
semantics, interpretation, and actions associated with those code-
points.
There is currently a joint IETF - ITU-T development effort underway,
known as MPLS Transport Profile (MPLS-TP), which is progressing
rapidly to extend MPLS in a way that is consistent with the MPLS
architecture, and fully satisfies the requirements of the transport
network provider [LS26]. By way of a case study we will refer to the
design and standardization process of the ITU-T protocol known as
Transport MPLS (T-MPLS). Development of T-MPLS was abandoned
[RFC5317] by ITU-T Study Group 15 due to inherent conflicts with the
IETF MPLS design and in particular with the Internet architecture.
These conflicts arose due to the lack of coordination with the IETF
as the design authority for MPLS.
The goal of this document is to demonstrate the importance of a
coordinated approach to successful collaboration between SDOs, and to
explain a model for inter-SDO collaborative protocol development that
is being used successfully by the ITU-T and IETF.
Bryant & Morrow Expires December 10, 2009 [Page 4]
Internet-Draft Uncoordinated Harmful June 2009
2. Protocol Safety
To understand the reasons why the IAB and the IETF regards
uncoordinated use of code-points and/or protocol modification as
posing a risk of harm to the Internet, it is necessary to recap some
important principles of protocol design in large scale networks such
as the Internet. Large scale networks represent significant economic
value. Any outage in a large scale network due to a protocol failure
will therefore result in significant commercial and political damage.
When two incompatible protocols, or forms of the same protocol, are
deployed without coordination, there is a serious risk that this may
be catastrophic to the stability or security of the network.
Furthermore, the scale and distributed nature of the Internet is such
that it is impossible to coordinate a network wide restart to rid the
network of the long- term consequences of the protocol
incompatibility. Therefore, the following issues are of critical
importance.
2.1. Importance of Invariants
Invariants are core properties that are consistent across the network
and do not change over extremely long time-scales. Protocol
designers use such invariants as axioms in designing protocols. A
protocol often places an absolute reliance on an invariant to resolve
a design corner case. One example of an invariance in IP that was
inherited in the design of MPLS is the invariant that a time to live
(TTL) value is monotonically decreased and that a packet with TTL<=1
will not be forwarded. This is a safety mechanism to mitigate the
damaging effects of packet forwarding loops. Another example is the
way that MPLS applies special semantics to the reserved label set
[RFC3032] (0..15), and the notion that a Label Switched Router (LSR)
is free to allocate labels with a value of 16 or greater for its own
use.
2.2. Importance of Correct Identification
A special type of invariant is the allocation of a code-point. A
code-point may be used to identify a packet type or a component
within a packet. Without these identifiers, a packet is an opaque
sequence of bits. A packet parser operates by first identifying the
code-point and then using the semantics associated with that code-
point to interpret other components within the packet. Once a code-
point is defined the interpretation of associated data and the
consequential actions becomes a protocol invariant. Subsequent
protocol development must adhere to those invariants. The semantics
for an allocated code point must never change. If a future
enhancement requires different semantics, interpretation, or action,
then a new code point must be obtained.
Bryant & Morrow Expires December 10, 2009 [Page 5]
Internet-Draft Uncoordinated Harmful June 2009
2.3. The Role of the Design Authority
A code-point such as an IEEE Ethertype is allocated to a design
authority such as the IETF. It is this design authority that
establishes how information identified by the code-point is to be
interpreted to associate appropriate invariants. Modification and
extension of a protocol requires great care. In particular it is
necessary to understand the exact nature of the invariants and the
consequences of modification. This may not always be the case when
protocols are modified by organizations without the experience of the
original designers, or the design authority expert pool.
Furthermore, since there can only safely be a single interpretation
of the information identified by a code-point, there must be a unique
authority responsible for authorizing and documenting the semantics
of the information and consequential protocol actions.
In the case of IP and MPLS technologies, the design authority is the
IETF. The IETF has an internal process for evolving and maintaining
the protocols for which it is the design authority. The IETF also
has change processes in place [RFC4929] to work with other SDOs that
require enhancements to its protocols and architectures. Similarly,
the ITU has design authority for Recommendation E.164 [E.164] and
allocates the relevant code points, even though the IETF has design
authority for the protocols ("ENUM") used to access E.164 numbers
through the Internet DNS [RFC3245].
2.4. Ships in the Night
It may be tempting for a designer to assert that the protocol
extensions it proposes are safe even though it breaks the invariants
of the original protocol because these protocol variants will operate
as ships in the night. That is, these protocol variants will never
simultaneously exist in the same network domain and will never need
to inter-work. This is a fundamentally unsound assumption for a
number of reasons. First, it is infeasible to ensure that the two
instances will never be interconnected under any circumstances.
Second, even if the operators that deploy the protocols apply
appropriate due diligence to ensure that the two instances do not
conflict, it is infeasible to ensure that such conflicting protocols
will not be interconnected under fault conditions.
This assumption of ships in the night is particularly hazardous when
the instances of the protocol share the same identifying code-point.
This is because a system is unable to determine which variant of the
protocol it has received, and hence how to correctly interpret the
associated information or to determine what protocol actions may be
safely executed.
Bryant & Morrow Expires December 10, 2009 [Page 6]
Internet-Draft Uncoordinated Harmful June 2009
3. T-MPLS As a Case Study
In order to illustrate the issues that arise from uncoordinated
protocol development called out above we will use the ITU-T T-MPLS
protocol as a recent example.
3.1. Multiple Definitions of Label 14
To appreciate why the use of MPLS Reserved Label 14 by the T-MPLS
protocol represented a safety concern to the Internet, it is
important to understand the current standards that use MPLS Reserved
Label 14.
The governing standard on the use of MPLS Reserved Label 14 is
[RFC3429], "Assignment of the 'OAM Alert Label' for Multi-protocol
Label Switching Architecture (MPLS) Operation and Maintenance (OAM)
Functions".
Label 14 is assigned to a specific protocol, namely, ITU-T
Recommendation [Y.1711-2002].
ITU-T Recommendation [Y.1711-2002] has been superseded by newer
versions, specifically: - [Y.1711-2004], [Y.1711cor1] and
[Y.1711am1].
All three documents are currently in-force as ITU-T Recommendations.
The problem is that the changes made to Y.1711 were never reflected
in an update to RFC 3429 which only defines the protocol as specified
by the now superseded 2002 Recommendation. So for example, MPLS
equipment responding to an MPLS packet containing Label 14 would
expect to see the 2002 version of Y.1711 [Y.1711-2002] protocol and
would not recognize any of the new function codes specified in Y.1711
Amendment 1. This problem arises because Y.1711 does not have a
version field, and RFC 3429 offers no other method to disambiguate
non-interoperable versions of Y.1711. Having a version number in the
protocol permits an implementer to codify non-interoperability.
Furthermore, the IETF as the authority over Label 14 semantics has
the final say over maintaining the interoperability of the protocol
employing that code-point, unless the IETF explicitly delegates such
authority.
With regard to T-MPLS there was a lack of coordination between the
ITU-T and the IETF over the redefinition of the semantics of MPLS
label 14, which resulted in protocol definitions that conflicted with
the IETF MPLS Architecture.
The MPLS architecture [RFC3031], defines a swap operation as an
Bryant & Morrow Expires December 10, 2009 [Page 7]
Internet-Draft Uncoordinated Harmful June 2009
atomic function that replaces the top label in an MPLS label stack
with another label which provides context for the next hop LSR.
However the ITU-T Recommendations that specified the new OAM
functions defined by Label 14 redefined the label swap operation as a
POP, followed by a PUSH, thereby causing all LSRs to inspect the
label stack for the presence of Label 14 at each hop. This proposed
new behaviour conflicts with the IETF definition of a swap operation.
The behaviour proposed in these specifications would have had major
consequences for deployed hardware designs. The outcome would have
been that the equipments built according to the two different
specifications would have been incompatible. It is important that
the atomic procedure defined in [RFC3031] is kept unchanged.
3.2. Redefinition of TTL Semantics
The standard method of delivering an OAM message to an entity on a
label switched path (LSP) such that the OAM message fate shares with
the data traffic is to use TTL expiry. The IETF's Internet Protocol
(IP) utilizes this mechanism for traceroute [RFC1393], as does MPLS
ping [RFC4379].
At one stage, the T-MPLS designers considered a multi-level OAM
design in which the OAM packet was steered to its target by a process
in which some nodes increased the TTL as they forwarded the OAM
packet to its next hop. TTL is a safety device in the IETF IP and
MPLS architecture that prevents a packet from continuously looping
under fault conditions. Thus the proposed extension to support an
enhanced OAM mechanism violated an MPLS design invariant specifically
introduced to ensure safe operation of the Internet by preventing
persistent forwarding loops.
3.3. Reservation of Additional Labels
The IETF MPLS protocol uses a small number of reserved labels
[RFC3032] as a mechanism to provide additional context and to trigger
some special processing operations in the forwarder. All other
labels used for forwarding use semantics defined by the forwarding
equivalence class (FEC). In an early implementation of T-MPLS the
designers determined that they needed some additional labels to alert
the forwarder that the packet needed special processing. Thus a
conflict was thereby introduced between the behaviour of an IETF MPLS
LSR, and LSRs that operate according to the specification in the
ITU-T Recommendation. Thus some LSRs would attribute special
semantics to labels 16..31, whist other LSRs would perform normal
forwarding on them.
Bryant & Morrow Expires December 10, 2009 [Page 8]
Internet-Draft Uncoordinated Harmful June 2009
3.4. Redefinition of MPLS EXP Bits
The early MPLS documents defined the form of the MPLS label stack
entry [RFC3032]. This includes a three-bit field called the "EXP
field". The exact use of this field was not defined by these
documents, except to state that it was to be "reserved for
experimental use".
Although the intended use of the EXP field was as a "Class of
Service" (CoS) field, it was not named a CoS field by these early
documents because the use of such a CoS field was not considered to
be sufficiently defined. Today a number of standards documents
define its usage as a CoS field [RFC3270], [RFC5129], and hardware is
deployed that assumes this exclusive usage.
The T-MPLS designers, unaware of the historic reason for the
"provisional" naming of this field assumed that they were available
for any experimental use and re-purposed them to indicate the
maintenance entity level (a hierarchical maintenance mechanism).
The intended use of the EXP field was subsequently carried in
[RFC5462], which reinforces this by formally changing the name to
Traffic Class (TC).
3.5. The Consequences for the Network Operators
Two consequences arose for the users of the T-MPLS protocol.
Firstly, those who deployed development versions of the protocol were
exposing their network to hazards explicitly guaranteed by the IETF
MPLS protocol suite to not occur. Indeed those operating T-MPLS in
production networks in anticipation of later adoption of the MPLS
Transport Profile (MPLS-TP) may still experience those hazards; and
vendors continuing to distribute T-MPLS equipment expose their
customers to the same hazards.
The second consequence was to delay the necessary enhancements to
MPLS to meet their needs [I-D.ietf-mpls-tp-requirements] as the IETF
and ITU-T executed a redevelopment of MPLS-based transport network
protocols.
3.6. The Consequences for the SDOs
The process of resolution required considerable resources and
introduced a great deal of conflict between the IETF and the ITU-T,
much of which was exposed to public scrutiny, to the detriment of
both organizations. In particular this conflict resolution process
consumed the very resources required to develop an optimal
architecture for MPLS in transport networks.
Bryant & Morrow Expires December 10, 2009 [Page 9]
Internet-Draft Uncoordinated Harmful June 2009
4. MPLS-TP As Best Practice
In order to bridge the gap between the two organizations, the IETF
and the ITU-T established a joint working team (JWT) to assess
whether it was possible to enhance existing MPLS standards to provide
a best in class solution for transport networks. The outcome of this
investigation is reported in [RFC5317].
The JWT proposed a design that was acceptable to both SDOs. This has
lead to the creation of the MPLS-TP project. This is a joint project
in which the ITU-T experts work with the IETF on protocol development
tasks; and IETF members work within the ITU-T to understand
requirements, and to assist in the creation of the ITU-T
recommendations that describe MPLS-TP in which the technical
definition is provided through normative references to IETF RFCs.
Bryant & Morrow Expires December 10, 2009 [Page 10]
Internet-Draft Uncoordinated Harmful June 2009
5. IANA considerations
There are no requests for IANA allocation of code-points in this
document, nor are any other IANA actions required.
Bryant & Morrow Expires December 10, 2009 [Page 11]
Internet-Draft Uncoordinated Harmful June 2009
6. Security considerations
The uncoordinated development of protocols is poses a risk of harm to
the Internet and must not be permitted. The enhancement or
modification of a protocol can increase attack surfaces considerably
and may therefore compromise the security or stability of the
Internet. The IETF has a review process that combines cross area
review with specialist security review by experts familiar with the
development and deployment context of the Internet protocol suite.
In particular, because of the Internet infrastructure's reliance on
the IP and MPLS protocol suites, this security review process must be
exercised with considerable diligence. Failure to apply this review
process exposes the Internet to increased risk along both security
and stability vectors.
Bryant & Morrow Expires December 10, 2009 [Page 12]
Internet-Draft Uncoordinated Harmful June 2009
7. Acknowledgments
The authors wish to acknowledge Loa Andersson and the members of the
2009/2010 Internet Architecture Board. Additionally we wish to
acknowledge Malcolm Johnson, Director, ITU Telecommunication
Standardization Bureau and Yoichi Maeda ITU-T Study Group 15 Chair,
for their review of this draft and their contribution of text.
Bryant & Morrow Expires December 10, 2009 [Page 13]
Internet-Draft Uncoordinated Harmful June 2009
8. Generalization from this Case Study
Although we have used T-MPLS as a case study, there is potential
conflict between other ongoing ITU-T projects and core IETF
specifications, for example [Y.2015] , [Q.Flowsig] . There are new
areas of potential conflict also emerging from the other work of
ITU-T SG13 Question 7, "IPv6" for example: [Y.ipv6split] and
[Y.ipv6migration].
Bryant & Morrow Expires December 10, 2009 [Page 14]
Internet-Draft Uncoordinated Harmful June 2009
9. Conclusion
It is important that all SDOs developing standards that effect the
operation of the Internet learn the lessons that arise from the
T-MPLS experience. Uncoordinated parallel work between SDOs creates
significant problems with potentially damaging operation impact to
those that deploy and use the Internet. SDOs need to work jointly on
new projects in such a way that the safety of the Internet is assured
and the expertise of the organizations concerned is applied
optimally.
Bryant & Morrow Expires December 10, 2009 [Page 15]
Internet-Draft Uncoordinated Harmful June 2009
10. References
10.1. Normative References
10.2. Informative references
[E.164] ITU-T, "ITU Recommendation E.164: The international public
telecommunication numbering plan", February 2005.
[I-D.ietf-mpls-tp-requirements]
Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "MPLS-TP Requirements",
draft-ietf-mpls-tp-requirements-08 (work in progress),
May 2009.
[LS26] ITU-T Study Group 15, "Cooperation Between IETF and ITU-T
on the Development of MPLS-TP, Geneva, 1-12 December 2008,
https://datatracker.ietf.org/documents/LIAISON/
file596.pdf".
[Q.Flowsig]
ITU-T Study Group 11, "ITU-T Study Group 11, Question 5,
Signalling protocols and procedures relating to flow state
aware access QoS control in an NGN; draft
Recommendation.".
[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393,
January 1993.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3245] Klensin, J. and IAB, "The History and Context of Telephone
Number Mapping (ENUM) Operational Decisions: Informational
Documents Contributed to ITU-T Study Group 2 (SG2)",
RFC 3245, March 2002.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002.
[RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for
Multiprotocol Label Switching Architecture (MPLS)
Bryant & Morrow Expires December 10, 2009 [Page 16]
Internet-Draft Uncoordinated Harmful June 2009
Operation and Maintenance (OAM) Functions", RFC 3429,
November 2002.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC4775] Bradner, S., Carpenter, B., and T. Narten, "Procedures for
Protocol Extensions and Variations", BCP 125, RFC 4775,
December 2006.
[RFC4929] Andersson, L. and A. Farrel, "Change Process for
Multiprotocol Label Switching (MPLS) and Generalized MPLS
(GMPLS) Protocols and Procedures", BCP 129, RFC 4929,
June 2007.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, January 2008.
[RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT)
Report on MPLS Architectural Considerations for a
Transport Profile", RFC 5317, February 2009.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, February 2009.
[Y.1711-2002]
ITU-T Study Group 13, "ITU-T Recommendation Y.1711 "OAM
mechanism for MPLS networks", November 2002".
[Y.1711-2004]
ITU-T Study Group 13, "ITU-T Recommendation Y.1711 "OAM
mechanism for MPLS networks", February 2004".
[Y.1711am1]
ITU-T Study Group 13, "ITU-T Recommendation Y.1711
Amendment 1, New Function Type Codes, October 2005.".
[Y.1711cor1]
ITU-T Study Group 13, "ITU-T Recommendation Y.1711 (2004)
corrigendum 1, February 2005.".
[Y.2015] ITU-T Study Group 13, "ITU-T Study Group 13, Question 5,
"General Requirements for ID/Locator Separation in NGN"".
[Y.ipv6migration]
ITU-T, "ITU draft Y.ipv6migration : Roadmap for IPv6
Bryant & Morrow Expires December 10, 2009 [Page 17]
Internet-Draft Uncoordinated Harmful June 2009
migration from NGN operators perspective", 2009.
[Y.ipv6split]
ITU-T, "ITU draft Y.ipv6split : Framework of ID/LOC
separation in IPv6-based NGN", 2009.
Bryant & Morrow Expires December 10, 2009 [Page 18]
Internet-Draft Uncoordinated Harmful June 2009
Authors' Addresses
Stewart Bryant (editor)
On behalf of the IAB
Phone:
Fax:
Email: stbryant@cisco.com
URI:
Monique Morrow (editor)
On behalf of the IAB
Phone:
Fax:
Email: mmorrow@cisco.com
URI:
Bryant & Morrow Expires December 10, 2009 [Page 19]
Html markup produced by rfcmarkup 1.76, available from
http://tools.ietf.org/tools/rfcmarkup/