idnits 2.17.1 draft-iab-mpls-tp-uncoord-harmful-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 24, 2009) is 5290 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1393 (Obsoleted by RFC 6814) -- Obsolete informational reference (is this intentional?): RFC 1619 (Obsoleted by RFC 2615) -- Obsolete informational reference (is this intentional?): RFC 2436 (Obsoleted by RFC 3356) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bryant, Ed. 3 Internet-Draft M. Morrow, Ed. 4 Intended status: Informational On behalf of the IAB 5 Expires: March 28, 2010 September 24, 2009 7 "Uncoordinated Protocol Development Considered Harmful" 8 draft-iab-mpls-tp-uncoord-harmful-02.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 28, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document identifies problems that may result from the absence of 47 formal coordination and joint development on protocols of mutual 48 interest between standards development organizations. Some of these 49 problems may cause significant harm to the Internet. The document 50 suggests that a robust procedure is required prevent this from 51 occurring in the future. The IAB has selected a number of case 52 studies, such as T-MPLS, as recent examples to describe hazard to the 53 Internet architecture as a result of uncoordinated adaptation of a 54 protocol. 56 This experience has resulted in a considerable improvement in the 57 relationship between the IETF and the ITU-T. In particular, this was 58 achieved via the establishment of the "Joint working team on MPLS-TP" 59 . In addition, the leadership of the two organisations agreed to 60 improve inter-organizational working practices so as to avoid 61 conflict in the future between ITU-T Recommendations and IETF RFCs. 63 Whilst we use ITU-T - IETF interactions in these case studies, the 64 scope of the document extends to all SDO that have an overlapping 65 protocol interest with the IETF. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Protocol Design Rules . . . . . . . . . . . . . . . . . . . . 5 71 2.1. Protocol Safety . . . . . . . . . . . . . . . . . . . . . 5 72 2.2. Importance of Invariants . . . . . . . . . . . . . . . . . 5 73 2.3. Importance of Correct Identification . . . . . . . . . . . 6 74 2.4. The Role of the Design Authority . . . . . . . . . . . . . 6 75 2.5. Ships in the Night . . . . . . . . . . . . . . . . . . . . 7 76 3. Examples of Miscoordination . . . . . . . . . . . . . . . . . 8 77 3.1. T-MPLS As a Case Study . . . . . . . . . . . . . . . . . . 8 78 3.2. PPP over Sonet/SDH . . . . . . . . . . . . . . . . . . . . 8 79 4. Managing Information Flow . . . . . . . . . . . . . . . . . . 9 80 4.1. Managing Information Flow within an SDO . . . . . . . . . 9 81 4.2. Managing Information Flow between SDOs . . . . . . . . . . 9 82 5. MPLS-TP As Best Practice . . . . . . . . . . . . . . . . . . . 10 83 6. IETF Change Process . . . . . . . . . . . . . . . . . . . . . 11 84 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 85 8. Security considerations . . . . . . . . . . . . . . . . . . . 13 86 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 87 10. Emerging Issues . . . . . . . . . . . . . . . . . . . . . . . 15 88 11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 12. Informative references . . . . . . . . . . . . . . . . . . . . 17 90 Appendix A. A Review of the T-MPLS Case . . . . . . . . . . . . . 20 91 A.1. Multiple Definitions of Label 14 . . . . . . . . . . . . . 20 92 A.2. Redefinition of TTL Semantics . . . . . . . . . . . . . . 21 93 A.3. Reservation of Additional Labels . . . . . . . . . . . . . 21 94 A.4. Redefinition of MPLS EXP Bits . . . . . . . . . . . . . . 22 95 A.5. The Consequences for the Network Operators . . . . . . . . 22 96 A.6. The Consequences for the SDOs . . . . . . . . . . . . . . 23 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 99 1. Introduction 101 The uncoordinated adaptation of a protocol, parameter, or code-point 102 by a standards development organization (SDO), either through the 103 allocation of a code-point without following the formal registration 104 procedures, or by unilaterally modifying the semantics of the 105 protocol or intended use of the code-point itself, poses a risk of 106 harm to the Internet [RFC4775]. 108 The purpose of this document is to describe the various problems that 109 may occur without formal coordination and joint development on 110 protocols of mutual interest between SDOs. Some of the problems that 111 arise may cause significant harm to the Internet. In particular, the 112 IAB considers an essential principle of the protocol development 113 process that only one SDO maintains design authority for a given 114 protocol, with that SDO having ultimate authority over the allocation 115 of protocol parameter code-points; defining the intended semantics, 116 interpretation, and actions associated with those code-points. 118 There is currently a joint IETF - ITU-T development effort underway, 119 known as MPLS Transport Profile (MPLS-TP), which is progressing 120 rapidly to extend MPLS in a way that is consistent with the MPLS 121 architecture, and fully satisfies the requirements of the transport 122 network provider [LS26]. By way of a case study we will refer to the 123 design and standardization process of the ITU-T protocol known as 124 Transport MPLS (T-MPLS). Development of T-MPLS was abandoned 125 [RFC5317] by ITU-T Study Group 15 due to inherent conflicts with the 126 IETF MPLS design and in particular with the Internet architecture. 127 These conflicts arose due to the lack of coordination with the IETF 128 as the design authority for MPLS. 130 The goal of this document is to demonstrate the importance of a 131 coordinated approach to successful collaboration between SDOs, and to 132 explain a model for inter-SDO collaborative protocol development that 133 is being used successfully by the ITU-T and IETF. 135 2. Protocol Design Rules 137 This section describes a number of protocol design rules needed to 138 ensure the safe operation of a network. Whilst these rules will be 139 familiar to many protocol designers the rules are restated here, to 140 ensure that assumptions are clear and consistent. Differing 141 assumptions have been at the root of may mis-coordinations and 142 miscommunication between SDOs in the past. 144 2.1. Protocol Safety 146 To understand the reasons why the IAB and the IETF regards 147 uncoordinated use of code-points and/or protocol modification as 148 posing a risk of harm to the Internet, it is necessary to recap some 149 important principles of protocol design in large scale networks such 150 as the Internet. Many end users and businesses have come to rely on 151 the Internet as part of their critical infrastructure, thus large 152 scale networks such as the Internet, represent significant economic 153 value. Any outage in a large scale network due to a protocol failure 154 will therefore result in significant commercial and political damage. 155 When two incompatible protocols, or forms of the same protocol, are 156 deployed without coordination, there is a serious risk that this may 157 be catastrophic to the stability or security of the network. 159 Furthermore, the scale and distributed nature of the Internet is such 160 that it may be difficult or impossible to rid the network of the 161 long- term consequences of the protocol incompatibility. Therefore, 162 the following issues are of critical importance. 164 2.2. Importance of Invariants 166 Invariants are core properties that are consistent across the network 167 and do not change over extremely long time-scales. Protocol 168 designers use such invariants as axioms in designing protocols. A 169 protocol often places an absolute reliance on an invariant to resolve 170 a design corner case. One example of an invariance in IP that was 171 inherited in the design of MPLS is the invariant that a time to live 172 (TTL) value is monotonically decreased and that a packet with TTL<=1 173 will not be forwarded. This is a safety mechanism to mitigate the 174 damaging effects of packet forwarding loops. Another example is the 175 way that MPLS applies special semantics to the reserved label set 176 [RFC3032] (0..15), and the notion that a Label Switched Router (LSR) 177 is free to allocate labels with a value of 16 or greater for its own 178 use. 180 2.3. Importance of Correct Identification 182 A special type of invariant is the allocation of a code-point. A 183 code-point may be used to identify a packet type or a component 184 within a packet. Without these identifiers, a packet is an opaque 185 sequence of bits. A packet parser operates by first identifying the 186 code-point and then using the semantics associated with that code- 187 point to interpret other components within the packet. Once a code- 188 point is defined the interpretation of associated data and the 189 consequential actions becomes a protocol invariant. Subsequent 190 protocol development must adhere to those invariants. The semantics 191 for an allocated code point must never change. If a future 192 enhancement requires different semantics, interpretation, or action, 193 then a new code point must be obtained. 195 2.4. The Role of the Design Authority 197 A code-point such as an IEEE Ethertype is allocated to a design 198 authority such as the IETF. It is this design authority that 199 establishes how information identified by the code-point is to be 200 interpreted to associate appropriate invariants. Modification and 201 extension of a protocol requires great care. In particular it is 202 necessary to understand the exact nature of the invariants and the 203 consequences of modification. This may not always be the case when 204 protocols are modified by organizations without the experience of the 205 original designers, or the design authority expert pool. 206 Furthermore, since there can only safely be a single interpretation 207 of the information identified by a code-point, there must be a unique 208 authority responsible for authorizing and documenting the semantics 209 of the information and consequential protocol actions. 211 In the case of IP and MPLS technologies, the design authority is the 212 IETF. The IETF has an internal process for evolving and maintaining 213 the protocols for which it is the design authority. The IETF also 214 has change processes in place [RFC4929] to work with other SDOs that 215 require enhancements to its protocols and architectures. Similarly, 216 the ITU has design authority for Recommendation E.164 [E.164] and 217 allocates the relevant code points, even though the IETF has design 218 authority for the protocols ("ENUM") used to access E.164 numbers 219 through the Internet DNS [RFC3245]. 221 It is a recommendation of this document that the IETF introduces 222 additional change mechanisms to encompass all of the technical areas 223 for which it has design authority. 225 2.5. Ships in the Night 227 It may be tempting for a designer to assert that the protocol 228 extensions it proposes are safe even though it breaks the invariants 229 of the original protocol because these protocol variants will operate 230 as ships in the night. That is, these protocol variants will never 231 simultaneously exist in the same network domain and will never need 232 to inter-work. This is a fundamentally unsound assumption for a 233 number of reasons. First, it is infeasible to ensure that the two 234 instances will never be interconnected under any circumstances. 235 Second, even if the operators that deploy the protocols apply 236 appropriate due diligence to ensure that the two instances do not 237 conflict, it is infeasible to ensure that such conflicting protocols 238 will not be interconnected under fault conditions. 240 This assumption of ships in the night is particularly hazardous when 241 the instances of the protocol share the same identifying code-point. 242 This is because a system is unable to determine which variant of the 243 protocol it has received, and hence how to correctly interpret the 244 associated information or to determine what protocol actions may be 245 safely executed. 247 3. Examples of Miscoordination 249 There are a variety of examples where lack of inter-SDO coordination 250 has led to the publication of flawed protocol designs. This section 251 describes a number of case studies that illustrate co-ordination 252 issues. 254 3.1. T-MPLS As a Case Study 256 A recent example where another SDO created a protocol based on 257 misunderstandings of the IETF protocols is T-MPLS. T-MPLS was 258 created in ITU-T in an attempt to design a packet transport method 259 for transport-oriented networks. This is an example of the success 260 that IETF protocols have enjoyed, and ITU-T's interest and selection 261 of MPLS is a compliment to the IETF work. Quite late in the ITU-T 262 design and specification cycle, there were a number of liaison 263 exchanges between the ITU-T and the IETF, where the IETF became 264 increasingly concerned about incompatibility of IETF MPLS procedures 265 and technologies with ITU-T T-MPLS [RFC5317]. Extensive discussions 266 took place regarding interpretation, definition, and 267 misunderstandings regarding aspects such as MPLS Label 14, MPLS swap 268 operation, TTL semantics, reservation of additional Labels, and EXP 269 bits. If ITU-T had worked with IETF from the start in developing 270 T-MPLS, these problems could have been avoided. A detailed analysis 271 of the T-MPLS case is provided in Appendix A. 273 3.2. PPP over Sonet/SDH 275 An example of where the IETF failed to co-ordinate with the ITU-T is 276 [RFC1619]. In this draft the IETF misdefined PPP over SONET, 277 erroneously stating that "no scrambling is needed during insertion 278 into the SONET/SDH Synchronous Payload Envelope (SPE)." It was later 279 determined by SONET experts operating in the ITU-T and in ANSI, that 280 this error arose due to an incomplete understanding of the SONET 281 scrambler. By not using a scrambler the protocol was attempting to 282 transport non-transparent data over SONET. This resulted in lost or 283 misinterpreted data in the PoS network. This impacted routing, 284 signaling and end-user data traffic. Details of this work are 285 described in [pppext-pppsonet-scrambler]. This problem would have 286 been prevented if the IETF had worked with ITU-T and ANSI in 287 initially developing [RFC1619] . The problem was resolved by working 288 jointly with ITU-T and ANSI experts to publish [RFC2615], which 289 mandated the use of scrambling. 291 Note that [RFC1619] was developed four years before the IETF and 292 ITU-T agreed on formal procedures for cooperation, as documented in 293 [RFC2436]. 295 4. Managing Information Flow 297 This section recommends that intra and inter SDO information flows 298 require careful management in order to prevent the accidental 299 extension of protocols without the complete coordination of the work 300 with the relevant design authority. 302 4.1. Managing Information Flow within an SDO 304 One cannot assume that an SDO is completely familiar with the 305 internal structure, information exchange or internal processes of 306 another SDO. Hence the initial contact point and the subgroup with 307 which a long term working relationship is formed has a the duty to 308 ensure that the work fully is notified and co-ordinated to all 309 relevant parties withing the SDO. 311 4.2. Managing Information Flow between SDOs 313 A recommendation is that as part of their document approval process 314 SDOs should confirm that all protocol parameters code points, TLV 315 identifiers, etc. have been authorized by the appropriate design 316 authority (e.g., IANA, IETF, etc. in this case) and SDO approval from 317 the design authority has been obtained prior to publishing protocol 318 extensions. This confirmation should be an integral part of the 319 approval or consent process as verifying that the normative 320 references are qualified. 322 5. MPLS-TP As Best Practice 324 In order to bridge the gap between the two organizations, the IETF 325 and the ITU-T established a joint working team (JWT) to assess 326 whether it was possible to enhance existing MPLS standards to provide 327 a best in class solution for transport networks. The outcome of this 328 investigation is reported in [RFC5317]. 330 The JWT proposed a design that was acceptable to both SDOs. This has 331 lead to the creation of the MPLS-TP project. This is a joint project 332 in which the ITU-T experts work with the IETF on protocol development 333 tasks; and IETF members work within the ITU-T to understand 334 requirements, and to assist in the creation of the ITU-T 335 recommendations that describe MPLS-TP in which the technical 336 definition is provided through normative references to IETF RFCs. 338 Although the JWT approach allowed the IETF and the ITU-T to agree on 339 a method of resolving the T-MPLS problem, this approach had a 340 significant resource cost. The JWT required considerable protocol 341 design expertise and IETF management time to agree on a suitable 342 technical solution. A light weight process, starting with close 343 coordination during the requirements phase, and continuing during the 344 development phase, would likely reduce the resources needed to an 345 acceptable level in the future. 347 6. IETF Change Process 349 There is an MPLS-change-process [RFC4929] . However the IETF has yet 350 not defined a change process that is applicable to all of its work 351 areas. The problems described in this document indicate that the 352 IETF need to develop a universal change process. The MPLS-change- 353 process would seem to be a suitable starting point. 355 7. IANA considerations 357 There are no requests for IANA allocation of code-points in this 358 document, nor are any other IANA actions required. 360 8. Security considerations 362 The uncoordinated development of protocols is poses a risk of harm to 363 the Internet and must not be permitted. The enhancement or 364 modification of a protocol can increase attack surfaces considerably 365 and may therefore compromise the security or stability of the 366 Internet. The IETF has a review process that combines cross area 367 review with specialist security review by experts familiar with the 368 development and deployment context of the Internet protocol suite. 369 In particular, because of the Internet infrastructure's reliance on 370 the IP and MPLS protocol suites, this security review process must be 371 exercised with considerable diligence. Failure to apply this review 372 process exposes the Internet to increased risk along both security 373 and stability vectors. 375 9. Acknowledgments 377 The authors wish to acknowledge Loa Andersson and the members of the 378 2009/2010 Internet Architecture Board. 380 10. Emerging Issues 382 Although we have used T-MPLS as a case study, there are other ongoing 383 ITU-T projects and core IETF specifications that could be the subject 384 of either improved coordination or new conflicts, depending on 385 whether or not the principles outlined in this document are adhered 386 to by the IETF and ITU., Two current examples are: [Y.2015] , and 387 [Q.Flowsig] . New areas with potential for cooperation or conflict 388 are emerging from the work of ITU-T SG13 Question 7, "IPv6" for 389 example: [Y.ipv6split] and [Y.ipv6migration]. 391 Improved coordination, of course, is not limited to the relationship 392 between IETF and ITU-T. This issue is present between an set of 393 SDOs. The IETF - ITU-T relationship has simply been used because 394 there is a recent example where a potential disaster was, through 395 much hard work, not only prevented, but turned into a net gain for 396 all. 398 11. Conclusion 400 It is important that all SDOs developing standards that effect the 401 operation of the Internet learn the lessons that arise from cases 402 cited in this document. Uncoordinated parallel work between SDOs 403 creates significant problems with potentially damaging operation 404 impact to those that deploy and use the Internet. Both inter and 405 intra SDO information flow needs to be well managed to ensure that 406 all impacted parties are aware of work items. Finally, the IETF 407 needs to develop a universal change process that encompasses all of 408 its work areas. 410 12. Informative references 412 [E.164] ITU-T, "ITU Recommendation E.164: The international public 413 telecommunication numbering plan", February 2005. 415 [I-D.ietf-mpls-tp-requirements] 416 Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 417 and S. Ueno, "MPLS-TP Requirements", 418 draft-ietf-mpls-tp-requirements-10 (work in progress), 419 August 2009. 421 [LS26] ITU-T Study Group 15, "Cooperation Between IETF and ITU-T 422 on the Development of MPLS-TP, Geneva, 1-12 December 2008, 423 https://datatracker.ietf.org/documents/LIAISON/ 424 file596.pdf". 426 [Q.Flowsig] 427 ITU-T Study Group 11, "ITU-T Study Group 11, Question 5, 428 Signalling protocols and procedures relating to flow state 429 aware access QoS control in an NGN; draft 430 Recommendation.". 432 [RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, 433 January 1993. 435 [RFC1619] Simpson, W., "PPP over SONET/SDH", RFC 1619, May 1994. 437 [RFC2436] Brett, R., Bradner, S., and G. Parsons, "Collaboration 438 between ISOC/IETF and ITU-T", RFC 2436, October 1998. 440 [RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, 441 June 1999. 443 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 444 Label Switching Architecture", RFC 3031, January 2001. 446 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 447 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 448 Encoding", RFC 3032, January 2001. 450 [RFC3245] Klensin, J. and IAB, "The History and Context of Telephone 451 Number Mapping (ENUM) Operational Decisions: Informational 452 Documents Contributed to ITU-T Study Group 2 (SG2)", 453 RFC 3245, March 2002. 455 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 456 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 457 Protocol Label Switching (MPLS) Support of Differentiated 458 Services", RFC 3270, May 2002. 460 [RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for 461 Multiprotocol Label Switching Architecture (MPLS) 462 Operation and Maintenance (OAM) Functions", RFC 3429, 463 November 2002. 465 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 466 Label Switched (MPLS) Data Plane Failures", RFC 4379, 467 February 2006. 469 [RFC4775] Bradner, S., Carpenter, B., and T. Narten, "Procedures for 470 Protocol Extensions and Variations", BCP 125, RFC 4775, 471 December 2006. 473 [RFC4929] Andersson, L. and A. Farrel, "Change Process for 474 Multiprotocol Label Switching (MPLS) and Generalized MPLS 475 (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, 476 June 2007. 478 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 479 Marking in MPLS", RFC 5129, January 2008. 481 [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) 482 Report on MPLS Architectural Considerations for a 483 Transport Profile", RFC 5317, February 2009. 485 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 486 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 487 Class" Field", RFC 5462, February 2009. 489 [Y.1711-2002] 490 ITU-T Study Group 13, "ITU-T Recommendation Y.1711 "OAM 491 mechanism for MPLS networks", November 2002". 493 [Y.1711-2004] 494 ITU-T Study Group 13, "ITU-T Recommendation Y.1711 "OAM 495 mechanism for MPLS networks", February 2004". 497 [Y.1711am1] 498 ITU-T Study Group 13, "ITU-T Recommendation Y.1711 499 Amendment 1, New Function Type Codes, October 2005.". 501 [Y.1711cor1] 502 ITU-T Study Group 13, "ITU-T Recommendation Y.1711 (2004) 503 corrigendum 1, February 2005.". 505 [Y.2015] ITU-T Study Group 13, "ITU-T Study Group 13, Question 5, 506 "General Requirements for ID/Locator Separation in NGN"". 508 [Y.ipv6migration] 509 ITU-T, "ITU draft Y.ipv6migration : Roadmap for IPv6 510 migration from NGN operators perspective", 2009. 512 [Y.ipv6split] 513 ITU-T, "ITU draft Y.ipv6split : Framework of ID/LOC 514 separation in IPv6-based NGN", 2009. 516 [pppext-pppsonet-scrambler] 517 http://lptools1.amsl.com/html/ 518 draft-ietf-pppext-pppsonet-scrambler-00>, "PPP over SONET/ 519 SDH". 521 Appendix A. A Review of the T-MPLS Case 523 T-MPLS was created in ITU-T in an attempt to design an MPLS based 524 packet transport method for transport-oriented networks. This 525 appendix describes the technical issues that the IETF identified with 526 the T-MPLS documents and their consequences. 528 A.1. Multiple Definitions of Label 14 530 To appreciate why the use of MPLS Reserved Label 14 by the T-MPLS 531 protocol represented a safety concern to the Internet, it is 532 important to understand the current standards that use MPLS Reserved 533 Label 14. 535 The governing standard on the use of MPLS Reserved Label 14 is 536 [RFC3429], "Assignment of the 'OAM Alert Label' for Multi-protocol 537 Label Switching Architecture (MPLS) Operation and Maintenance (OAM) 538 Functions". 540 Label 14 is assigned to a specific protocol, namely, ITU-T 541 Recommendation [Y.1711-2002]. 543 ITU-T Recommendation [Y.1711-2002] has been superseded by newer 544 versions, specifically: - [Y.1711-2004], [Y.1711cor1] and 545 [Y.1711am1]. 547 All three documents are currently in-force as ITU-T Recommendations. 549 The problem is that the changes made to Y.1711 were never reflected 550 in an update to RFC 3429 which only defines the protocol as specified 551 by the now superseded 2002 Recommendation. So for example, MPLS 552 equipment responding to an MPLS packet containing Label 14 would 553 expect to see the 2002 version of Y.1711 [Y.1711-2002] protocol and 554 would not recognize any of the new function codes specified in Y.1711 555 Amendment 1. This problem arises because Y.1711 does not have a 556 version field, and RFC 3429 offers no other method to disambiguate 557 non-interoperable versions of Y.1711. Having a version number in the 558 protocol permits an implementer to codify non-interoperability. 559 Furthermore, the IETF as the authority over Label 14 semantics has 560 the final say over maintaining the interoperability of the protocol 561 employing that code-point, unless the IETF explicitly delegates such 562 authority. 564 With regard to T-MPLS there was a lack of coordination between the 565 ITU-T and the IETF over the redefinition of the semantics of MPLS 566 label 14, which resulted in protocol definitions that conflicted with 567 the IETF MPLS Architecture. 569 The MPLS architecture [RFC3031], defines a swap operation as an 570 atomic function that replaces the top label in an MPLS label stack 571 with another label which provides context for the next hop LSR. 572 However the ITU-T Recommendations that specified the new OAM 573 functions defined by Label 14 redefined the label swap operation as a 574 POP, followed by a PUSH, thereby causing all LSRs to inspect the 575 label stack for the presence of Label 14 at each hop. This proposed 576 new behaviour conflicts with the IETF definition of a swap operation. 577 The behaviour proposed in these specifications would have had major 578 consequences for deployed hardware designs. The outcome would have 579 been that the equipments built according to the two different 580 specifications would have been incompatible. It is important that 581 the atomic procedure defined in [RFC3031] is kept unchanged. 583 A.2. Redefinition of TTL Semantics 585 The standard method of delivering an OAM message to an entity on a 586 label switched path (LSP) such that the OAM message fate shares with 587 the data traffic is to use TTL expiry. The IETF's Internet Protocol 588 (IP) utilizes this mechanism for traceroute [RFC1393], as does MPLS 589 ping [RFC4379]. 591 At one stage, the T-MPLS designers considered a multi-level OAM 592 design in which the OAM packet was steered to its target by a process 593 in which some nodes increased the TTL as they forwarded the OAM 594 packet to its next hop. TTL is a safety device in the IETF IP and 595 MPLS architecture that prevents a packet from continuously looping 596 under fault conditions. Thus the proposed extension to support an 597 enhanced OAM mechanism violated an MPLS design invariant specifically 598 introduced to ensure safe operation of the Internet by preventing 599 persistent forwarding loops. 601 A.3. Reservation of Additional Labels 603 The IETF MPLS protocol uses a small number of reserved labels 604 [RFC3032] as a mechanism to provide additional context and to trigger 605 some special processing operations in the forwarder. All other 606 labels used for forwarding use semantics defined by the forwarding 607 equivalence class (FEC). In an early implementation of T-MPLS the 608 designers determined that they needed some additional labels to alert 609 the forwarder that the packet needed special processing. Thus a 610 conflict was thereby introduced between the behaviour of an IETF MPLS 611 LSR, and LSRs that operate according to the specification in the 612 ITU-T Recommendation. Thus some LSRs would attribute special 613 semantics to labels 16..31, whist other LSRs would perform normal 614 forwarding on them. 616 A.4. Redefinition of MPLS EXP Bits 618 The early MPLS documents defined the form of the MPLS label stack 619 entry [RFC3032]. This includes a three-bit field called the "EXP 620 field". The exact use of this field was not defined by these 621 documents, except to state that it was to be "reserved for 622 experimental use". 624 Although the intended use of the EXP field was as a "Class of 625 Service" (CoS) field, it was not named a CoS field by these early 626 documents because the use of such a CoS field was not considered to 627 be sufficiently defined. Today a number of standards documents 628 define its usage as a CoS field [RFC3270], [RFC5129], and hardware is 629 deployed that assumes this exclusive usage. 631 The T-MPLS designers, unaware of the historic reason for the 632 "provisional" naming of this field assumed that they were available 633 for any experimental use and re-purposed them to indicate the 634 maintenance entity level (a hierarchical maintenance mechanism). 636 The intended use of the EXP field was subsequently carried in 637 [RFC5462], which reinforces this by formally changing the name to 638 Traffic Class (TC). 640 A.5. The Consequences for the Network Operators 642 Transport network operators need a way to realize the statistical 643 gain inherent in packet networking while retaining the familiar 644 operational structure of their SONET/SDH networks. T-MPLS was an 645 attempt to provide that functionality. However, by creating an 646 incompatible variant of MPLS without tight coordination with IETF 647 created a number of problems for network operators. 649 Firstly, those operators that deployed T-MPLS in production networks 650 will need to address the risk and complexity of transitioning their 651 network to MPLS-TP. Secondly, there has been a consequential delay 652 the necessary enhancements to MPLS to meet their needs 653 [I-D.ietf-mpls-tp-requirements] as the IETF and ITU-T executed a 654 redevelopment of MPLS-based transport network protocols. 656 Fortunately, the two organizations are now working together to design 657 the necessary enhancements 659 The resulting technology, MPLS-TP, brings significant benefits to 660 all. However this has not been without cost. Had things continued, 661 we are not sure what would have happened, at the least, the larger 662 MPLS community would have been denied the benefit of better OAM, and 663 the transport community would have been denied the many benefits of 664 an interoperable solution. 666 A.6. The Consequences for the SDOs 668 The process of resolution required considerable resources and 669 introduced a great deal of conflict between the IETF and the ITU-T, 670 much of which was exposed to public scrutiny, to the detriment of 671 both organizations. In particular this conflict resolution process 672 consumed the very resources required to develop an optimal 673 architecture for MPLS in transport networks. 675 Authors' Addresses 677 Stewart Bryant (editor) 678 On behalf of the IAB 680 Phone: 681 Fax: 682 Email: stbryant@cisco.com 683 URI: 685 Monique Morrow (editor) 686 On behalf of the IAB 688 Phone: 689 Fax: 690 Email: mmorrow@cisco.com 691 URI: