doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc5704.txt b/doc/rfc/rfc5704.txt
new file mode 100644
index 0000000..e0c413a
--- /dev/null
+++ b/doc/rfc/rfc5704.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                     S. Bryant, Ed.
+Request for Comments: 5704                                M. Morrow, Ed.
+Category: Informational                                      For the IAB
+                                                           November 2009
+
+
+         Uncoordinated Protocol Development Considered Harmful
+
+Abstract
+
+   This document identifies problems that may result from the absence of
+   formal coordination and joint development on protocols of mutual
+   interest between standards development organizations (SDOs).  Some of
+   these problems may cause significant harm to the Internet.  The
+   document suggests that a robust procedure is required prevent this
+   from occurring in the future.  The IAB has selected a number of case
+   studies, such as Transport MPLS (T-MPLS), as recent examples to
+   describe the hazard to the Internet architecture that results from
+   uncoordinated adaptation of a protocol.
+
+   This experience has resulted in a considerable improvement in the
+   relationship between the IETF and the ITU-T.  In particular, this was
+   achieved via the establishment of the "Joint working team on
+   MPLS-TP".  In addition, the leadership of the two organizations
+   agreed to improve inter-organizational working practices so as to
+   avoid conflict in the future between ITU-T Recommendations and IETF
+   RFCs.
+
+   Whilst we use ITU-T - IETF interactions in these case studies, the
+   scope of the document extends to all SDOs that have an overlapping
+   protocol interest with the IETF.
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+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
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+
+
+
+Bryant, et al.               Informational                      [Page 1]
+
+RFC 5704                 Uncoordinated Harmful             November 2009
+
+
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Protocol Design Rules ...........................................3
+      2.1. Protocol Safety ............................................3
+      2.2. Importance of Invariants ...................................4
+      2.3. Importance of Correct Identification .......................4
+      2.4. The Role of the Design Authority ...........................4
+      2.5. Ships in the Night .........................................5
+   3. Examples of Miscoordination .....................................6
+      3.1. T-MPLS as a Case Study .....................................6
+      3.2. PPP over SONET/SDH (Synchronous Optical Network /
+           Synchronous Digital Hierarchy ..............................6
+   4. Managing Information Flow .......................................7
+      4.1. Managing Information Flow within an SDO ....................7
+      4.2. Managing Information Flow between SDOs .....................7
+   5. MPLS-TP as Best Practice ........................................7
+   6. IETF Change Process .............................................8
+   7. Security Considerations .........................................8
+   8. Acknowledgments .................................................8
+   9. IAB Members at the Time of This Writing .........................8
+   10. Emerging Issues ................................................9
+   11. Conclusion .....................................................9
+   12. Informative References .........................................9
+   Appendix A.  A Review of the T-MPLS Case ..........................12
+     A.1.  Multiple Definitions of Label 14 ..........................12
+     A.2.  Redefinition of TTL Semantics .............................13
+     A.3.  Reservation of Additional Labels ..........................13
+     A.4.  Redefinition of MPLS EXP Bits .............................14
+     A.5.  The Consequences for the Network Operators ................14
+     A.6.  The Consequences for the SDOs .............................15
+
+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].
+
+
+
+
+
+
+Bryant, et al.               Informational                      [Page 2]
+
+RFC 5704                 Uncoordinated Harmful             November 2009
+
+
+   The purpose of this document is to describe the various problems that
+   may occur without formal coordination and joint development on
+   protocols of mutual interest between SDOs.  Some of the problems that
+   arise may cause significant harm to the Internet.  In particular, the
+   IAB considers it 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 and over 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 the 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.
+
+2.  Protocol Design Rules
+
+   This section describes a number of protocol design rules needed to
+   ensure the safe operation of a network.  Whilst these rules will be
+   familiar to many protocol designers, the rules are restated here to
+   ensure that assumptions are clear and consistent.  Differing
+   assumptions have been at the root of many miscoordinations and
+   miscommunications between SDOs in the past.
+
+2.1.  Protocol Safety
+
+   To understand the reasons why the IAB and IETF regard 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.  Many end users and businesses have come to rely on the
+   Internet as part of their critical infrastructure, thus large-scale
+   networks, such as the Internet, 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.
+
+
+
+Bryant, et al.               Informational                      [Page 3]
+
+RFC 5704                 Uncoordinated Harmful             November 2009
+
+
+   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 may be difficult or impossible to rid the network of the
+   long-term consequences of the protocol incompatibility.  Therefore,
+   the following issues are of critical importance.
+
+2.2.  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
+   (0..15) [RFC3032], 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.3.  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 become protocol invariants.  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.
+
+2.4.  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
+
+
+
+Bryant, et al.               Informational                      [Page 4]
+
+RFC 5704                 Uncoordinated Harmful             November 2009
+
+
+   consequences of modification.  Such understanding may not always be
+   possible when protocols are modified by organizations that don't have
+   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-T 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].
+
+   It is a recommendation of this document that the IETF introduces
+   additional change mechanisms to encompass all of the technical areas
+   for which it has design authority.
+
+2.5.  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, et al.               Informational                      [Page 5]
+
+RFC 5704                 Uncoordinated Harmful             November 2009
+
+
+3.  Examples of Miscoordination
+
+   There are a variety of examples where lack of inter-SDO coordination
+   has led to the publication of flawed protocol designs.  This section
+   describes a number of case studies that illustrate coordination
+   issues.
+
+3.1.  T-MPLS as a Case Study
+
+   A recent example where another SDO created a protocol based on
+   misunderstandings of IETF protocols is T-MPLS.  T-MPLS was created in
+   ITU-T in an attempt to design a packet-transport method for
+   transport-oriented networks.  This is an example of the success that
+   IETF protocols have enjoyed, and ITU-T's interest and selection of
+   MPLS is a compliment to the IETF work.  Quite late in the ITU-T
+   design and specification cycle, there were a number of liaison
+   exchanges between the ITU-T and the IETF, where the IETF became
+   increasingly concerned about incompatibility of IETF MPLS procedures
+   and technologies with ITU-T T-MPLS [RFC5317].  Extensive discussions
+   took place regarding interpretation, definition, and
+   misunderstandings regarding aspects such as MPLS Label 14, MPLS swap
+   operation, TTL semantics, reservation of additional labels, and EXP
+   bits.  If ITU-T had worked with IETF from the start in developing
+   T-MPLS, these problems could have been avoided.  A detailed analysis
+   of the T-MPLS case is provided in Appendix A.
+
+3.2.  PPP over SONET/SDH (Synchronous Optical Network / Synchronous
+      Digital Hierarchy)
+
+   An example of where the IETF failed to coordinate with the ITU-T is
+   [RFC1619], which defined PPP over SONET.  In the text dealing with
+   the SONET/SDH Synchronous Payload Envelope (SPE), the document
+   erroneously stated that "no scrambling is needed during insertion
+   into the SPE."  It was later determined by SONET experts operating in
+   the ITU-T and in ANSI that this error arose due to an incomplete
+   understanding of the SONET scrambler.  By not using a scrambler, the
+   protocol was attempting to transport non-transparent data over SONET.
+   This resulted in lost or misinterpreted data in the Packet over SONET
+   (PoS) network.  This impacted routing, signaling, and end-user data
+   traffic.  Details of this work are described in [PPPoSONET].  This
+   problem would have been prevented if the IETF had worked with ITU-T
+   and ANSI in initially developing [RFC1619] .  The problem was
+   resolved by working jointly with ITU-T and ANSI experts to publish
+   [RFC2615], which mandated the use of scrambling.
+
+   Note that [RFC1619] was developed four years before the IETF and
+   ITU-T agreed on formal procedures for cooperation, as documented in
+   [RFC2436] (which was later obsoleted by [RFC3356]).
+
+
+
+Bryant, et al.               Informational                      [Page 6]
+
+RFC 5704                 Uncoordinated Harmful             November 2009
+
+
+4.  Managing Information Flow
+
+   This section recommends that intra- and inter-SDO information flows
+   require careful management in order to prevent the accidental
+   extension of protocols without complete coordination of the work with
+   the relevant design authority.
+
+4.1.  Managing Information Flow within an SDO
+
+   One cannot assume that an SDO is completely familiar with the
+   internal structure, information exchange, or internal processes of
+   another SDO.  Hence, the initial contact point and the subgroup with
+   which a long-term working relationship is formed has a duty to ensure
+   that the work is fully notified and coordinated to all relevant
+   parties within the SDO.
+
+4.2.  Managing Information Flow between SDOs
+
+   A recommendation is that, as part of their document-approval process,
+   SDOs should confirm that all protocol parameters, code-points, TLV
+   identifiers, etc., have been authorized by the appropriate design
+   authority (e.g., IANA, IETF, etc. in this case) and that SDO approval
+   from the design authority has been obtained prior to publishing
+   protocol extensions.  This confirmation should be an integral part of
+   the approval or consent process as verifying that the normative
+   references are qualified.
+
+5.  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
+   led 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 ITU-T recommendations
+   that describe MPLS-TP in which the technical definition is provided
+   through normative references to IETF RFCs.
+
+   Although the JWT approach allowed the IETF and the ITU-T to agree on
+   a method of resolving the T-MPLS problem, this approach had a
+   significant resource cost.  The JWT required considerable protocol-
+   design expertise and IETF management time to agree on a suitable
+   technical solution.  A lightweight process, starting with close
+
+
+
+Bryant, et al.               Informational                      [Page 7]
+
+RFC 5704                 Uncoordinated Harmful             November 2009
+
+
+   coordination during the requirements phase and continuing during the
+   development phase, would likely reduce the resources needed to an
+   acceptable level in the future.
+
+6.  IETF Change Process
+
+   There is an MPLS-change-process [RFC4929] .  However, the IETF has
+   not yet defined a change process that is applicable to all of its
+   work areas.  The problems described in this document indicate that
+   the IETF needs to develop a universal change process.  The MPLS-
+   change-process would seem to be a suitable starting point.
+
+7.  Security Considerations
+
+   The uncoordinated development of protocols 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.
+
+8.  Acknowledgments
+
+   The authors wish to acknowledge Loa Andersson for his contribution to
+   this work.
+
+9.  IAB Members at the Time of This Writing
+
+   Marcelo Bagnulo
+   Gonzalo Camarillo
+   Stuart Cheshire
+   Vijay Gill
+   Russ Housley
+   John Klensin
+   Olaf Kolkman
+   Gregory Lebovitz
+   Andrew Malis
+   Danny McPherson
+   David Oran
+   Jon Peterson
+   Dave Thaler
+
+
+
+
+Bryant, et al.               Informational                      [Page 8]
+
+RFC 5704                 Uncoordinated Harmful             November 2009
+
+
+10.  Emerging Issues
+
+   Although we have used T-MPLS as a case study, there are other ongoing
+   ITU-T projects and core IETF specifications that could be the subject
+   of either improved coordination or new conflicts, depending on
+   whether or not the principles outlined in this document are adhered
+   to by the IETF and ITU.  Two current examples are [Y.2015] and
+   [Q.Flowsig].  New areas with potential for cooperation or conflict
+   are emerging from the work of ITU-T SG13 Question 7, "IPv6" -- for
+   example: [Y.ipv6split] and [Y.ipv6migration].
+
+   Improved coordination, of course, is not limited to the relationship
+   between IETF and ITU-T.  This issue is present between a set of SDOs.
+   The IETF - ITU-T relationship has simply been used because there is a
+   recent example where a potential disaster was, through much hard
+   work, not only prevented but turned into a net gain for all.
+
+11.  Conclusion
+
+   It is important that all SDOs developing standards that affect the
+   operation of the Internet learn the lessons that arise from cases
+   cited in this document.  Uncoordinated parallel work between SDOs
+   creates significant problems with potentially damaging operation
+   impact to those that deploy and use the Internet.  Both inter- and
+   intra-SDO information flow needs to be well managed to ensure that
+   all impacted parties are aware of work items.  Finally, the IETF
+   needs to develop a universal change process that encompasses all of
+   its work areas.
+
+12.  Informative References
+
+   [E.164]       ITU-T, "ITU Recommendation E.164: The international
+                 public telecommunication numbering plan",
+                 February 2005.
+
+   [LS26]        ITU-T Study Group 15, "Cooperation Between IETF and
+                 ITU-T on the Development of MPLS-TP", Geneva,
+                 December 2008, <https://datatracker.ietf.org/
+                 documents/LIAISON/file596.pdf>.
+
+   [PPPoSONET]   Manchester, J., et al., "PPP over SONET/SDH", Work in
+                 Progress, October 1997.
+
+   [Q.Flowsig]   ITU-T Study Group 11, Question 5, "Signalling protocols
+                 and procedures relating to flow state aware access QoS
+                 control in an NGN", Draft Recommendation.
+
+
+
+
+
+Bryant, et al.               Informational                      [Page 9]
+
+RFC 5704                 Uncoordinated Harmful             November 2009
+
+
+   [RFC1393]     Malkin, G., "Traceroute Using an IP Option", RFC 1393,
+                 January 1993.
+
+   [RFC1619]     Simpson, W., "PPP over SONET/SDH", RFC 1619, May 1994.
+
+   [RFC2436]     Brett, R., Bradner, S., and G. Parsons, "Collaboration
+                 between ISOC/IETF and ITU-T", RFC 2436, October 1998.
+
+   [RFC2615]     Malis, A. and W. Simpson, "PPP over SONET/SDH",
+                 RFC 2615, June 1999.
+
+   [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.
+
+   [RFC3356]     Fishman, G. and S. Bradner, "Internet Engineering Task
+                 Force and International Telecommunication Union -
+                 Telecommunications Standardization Sector Collaboration
+                 Guidelines", RFC 3356, August 2002.
+
+   [RFC3429]     Ohta, H., "Assignment of the 'OAM Alert Label' for
+                 Multiprotocol Label Switching Architecture (MPLS)
+                 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.
+
+
+
+
+Bryant, et al.               Informational                     [Page 10]
+
+RFC 5704                 Uncoordinated Harmful             November 2009
+
+
+   [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.
+
+   [RFC5654]     Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher,
+                 N., and S. Ueno, "Requirements of an MPLS Transport
+                 Profile", RFC 5654, September 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, Question 5, "General Requirements
+                 for ID/Locator Separation in NGN".
+
+   [Y.ipv6migration]
+                 ITU-T, "ITU draft Y.ipv6migration: Roadmap for IPv6
+                 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, et al.               Informational                     [Page 11]
+
+RFC 5704                 Uncoordinated Harmful             November 2009
+
+
+Appendix A.  A Review of the T-MPLS Case
+
+   T-MPLS was created in ITU-T in an attempt to design an MPLS-based
+   packet-transport method for transport-oriented networks.  This
+   appendix describes the technical issues that the IETF identified with
+   the T-MPLS documents and their consequences.
+
+A.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 Multiprotocol
+   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 the 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.
+
+
+
+
+
+Bryant, et al.               Informational                     [Page 12]
+
+RFC 5704                 Uncoordinated Harmful             November 2009
+
+
+   The MPLS architecture [RFC3031], defines a swap operation as an
+   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.
+
+A.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 shares its fate
+   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.
+
+A.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, whilst other LSRs would perform normal forwarding on
+   them.
+
+
+
+
+Bryant, et al.               Informational                     [Page 13]
+
+RFC 5704                 Uncoordinated Harmful             November 2009
+
+
+A.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 use by formally changing the name to
+   Traffic Class (TC).
+
+A.5.  The Consequences for the Network Operators
+
+   Transport network operators need a way to realize the statistical
+   gain inherent in packet networking while retaining the familiar
+   operational structure of their SONET/SDH networks.  T-MPLS was an
+   attempt to provide that functionality.  However, creating an
+   incompatible variant of MPLS without tight coordination with IETF
+   created a number of problems for network operators.
+
+   Firstly, those operators that deployed T-MPLS in production networks
+   will need to address the risk and complexity of transitioning their
+   network to MPLS-TP.  Secondly, there has been a consequential delay
+   of the necessary enhancements to MPLS to meet their needs [RFC5654]
+   as the IETF and ITU-T executed a redevelopment of MPLS-based
+   transport network protocols.
+
+   Fortunately, the two organizations are now working together to design
+   the necessary enhancements
+
+   The resulting technology, MPLS-TP, brings significant benefits to
+   all.  However, this has not been without cost.  Had things continued,
+   we are not sure what would have happened -- at the least, the larger
+
+
+
+
+
+Bryant, et al.               Informational                     [Page 14]
+
+RFC 5704                 Uncoordinated Harmful             November 2009
+
+
+   MPLS community would have been denied the benefit of better OAM, and
+   the transport community would have been denied the many benefits of
+   an interoperable solution.
+
+A.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.
+
+Authors' Addresses
+
+   Stewart Bryant (editor)
+
+   EMail: stbryant@cisco.com
+
+
+   Monique Morrow (editor)
+
+   EMail: mmorrow@cisco.com
+
+
+   Internet Architecture Board
+
+   EMail: iab@iab.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryant, et al.               Informational                     [Page 15]
+