idnits 2.17.1 draft-bryant-mpls-tp-jwt-report-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 432. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2008) is 5771 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'T-MPLS1' on line 366 looks like a reference -- Missing reference section? 'Ethertypes' on line 340 looks like a reference -- Missing reference section? 'Stuttgart' on line 359 looks like a reference -- Missing reference section? 'MPLS-TP-22' on line 355 looks like a reference -- Missing reference section? 'MPLS-TP' on line 351 looks like a reference -- Missing reference section? 'JWTcreation' on line 345 looks like a reference -- Missing reference section? 'REF' on line 204 looks like a reference Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 14 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 Cisco Systems 4 Intended status: Informational L. Andersson, Ed. 5 Expires: January 8, 2009 Acreo AB 6 July 7, 2008 8 JWT Report on MPLS Architectural Considerations for a Transport Profile 9 draft-bryant-mpls-tp-jwt-report-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 8, 2009. 36 Abstract 38 This RFC archives the report of the IETF - ITU-T Joint Working Team 39 (JWT) on the application of MPLS to Transport Networks. The JWT 40 recommended of Option 1: The IETF and the ITU-T jointly agree to work 41 together and bring transport requirements into the IETF and extend 42 IETF MPLS forwarding, OAM, survivability, network management and 43 control plane protocols to meet those requirements through the IETF 44 Standards Process. There are two versions of this RFC. An ASCII 45 version that contains a summary of the slides and a PDF version that 46 contains the summary and a copy of the slides. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Executive Summary . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Introduction and Background Material . . . . . . . . . . . . . 5 53 4. High-Level Architecture . . . . . . . . . . . . . . . . . . . 6 54 5. OAM and Forwarding . . . . . . . . . . . . . . . . . . . . . . 6 55 6. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 7 56 7. Survivability . . . . . . . . . . . . . . . . . . . . . . . . 7 57 8. Network Management . . . . . . . . . . . . . . . . . . . . . . 7 58 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 60 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 12. The JWT Report . . . . . . . . . . . . . . . . . . . . . . . . 8 62 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 13.1. Informative References . . . . . . . . . . . . . . . . . 9 64 13.2. URL References . . . . . . . . . . . . . . . . . . . . . 9 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 66 Intellectual Property and Copyright Statements . . . . . . . . . . 11 68 1. Introduction 70 For a number of years the ITU-T has been designing a connection- 71 oriented packet switched technology to be used in Transport Networks. 72 A Transport Network can be considered to be the network that provides 73 wide area connectivity upon which other services such IP, or the 74 phone network run. The ITU-T chose to adapt the IETF's MPLS to this 75 task, and introduced a protocol suite known as T-MPLS. 77 Quite late in the ITU-T design and specification cycle, there were a 78 number of liaison exchanges between the ITU-T and the IETF concerning 79 this technology [T-MPLS1], and the chairs of the MPLS, PWE3, BFD and 80 CCAMP working groups as well as the Routing and Internet Area 81 Directors attended a number of ITU-T meetings. During this process 82 the IETF became increasingly concerned that the incompatibility of 83 IETF MPLS and ITU-T T-MPLS would "represent a mutual danger to both 84 the Internet and the Transport network". These concerns led the 85 chairs of the IESG and IAB to take the step of sending a liaison to 86 the ITU-T, stating that either T-MPLS should become and fully 87 compliant MPLS protocol, standardised under the IETF process (the so 88 called "Option 1"), or it should become a completely disjoint 89 protocol with a new name and completely new set of code points (the 90 so called "Option 2")[Ethertypes]. 92 Option 1 and Option 2 were discussed at an ITU-T meeting of Question 93 12 Study Group 15 in Stuttgart [Stuttgart], where it was proposed 94 that a Joint (ITU-T - IETF) Team should be formed to evaluate the 95 issues, and make a recommendation to ITU-T management on the best way 96 forward. 98 Following discussion between the management of the IETF and the ITU-T 99 a Joint Working Team (JWT) was established, this was supported by an 100 IETF Design Team and an Ad Hoc Group on T-MPLS in the ITU-T 101 [ahtmpls]. The first meeting of the Ad Hoc group occurred during the 102 ITU-T Geneva Plenary in February this year. As a result of the work 103 of the JWT and the resulting agreement on a way forward, the fears 104 that a set of next-generation network transport specifications 105 developed by ITU-T could cause interoperability problems were 106 allayed. 108 The JWT submitted their report to ITU-T and IETF management in the 109 form of a set of power point slides [MPLS-TP-22] [ALSO INCLUDE SELF 110 REF TO PDF WHEN AVAILABLE]. The ITU-T have accepted the JWT 111 recommendations, as documented in [MPLS-TP]. This RFC archives the 112 JWT report in a format that is accessible to the IETF. 114 There are two versions of this RFC. An ASCII version that contains a 115 summary of the slides and a PDF version that contains the summary and 116 a copy of the slides. In the case of a conflict between the summary 117 and the slides, the slides take precedence. Since those slides were 118 the basis of an important agreement between the IETF and the ITU-T, 119 it should further be noted that in the event that the PDF version of 120 the slides differs from those emailed to ITU-T and IETF management on 121 18th April 2008 by the co-chairs of the JWT, the emailed slides take 122 precedence. 124 2. Executive Summary 126 Slides 4 to 10 provide an executive summary of the JWT Report. The 127 following is a summary of those slides: 129 The JWT achieved consensus on the recommendation of Option 1: to 130 jointly agree to work together and bring transport requirements into 131 the IETF and extend IETF MPLS forwarding, OAM, survivability, network 132 management and control plane protocols to meet those requirements 133 through the IETF Standards Process. The Joint Working Team believed 134 that this would fulfil the mutual goals of improving the 135 functionality of the transport networks and the Internet and 136 guaranteeing complete interoperability and architectural soundness. 137 This technology would be referred to as the Transport Profile for 138 MPLS (MPLS-TP) 140 The JWT recommended that future work should focus on: 142 In the IETF: 144 Definition of the MPLS "Transport Profile" (MPLS-TP). 146 In the ITU-T: 148 Integration of MPLS-TP into the transport network, 150 Alignment of the current T-MPLS ITU-T Recommendations with MPLS-TP 151 and, 153 Termination of the work on current T-MPLS. 155 The technical feasibility analysis concluded there were no "show 156 stopper" issues in the recommendation of Option 1 and that the IETF 157 MPLS and Pseudowire architecture could be extended to support 158 transport functional requirements. Therefore the team believed that 159 there was no need for the analysis of any other option. 161 The JWT proposed that the MPLS Interoperability Design Team (MEAD 162 Team), JWT and ad hoc T-MPLS groups continue as described in SG15 163 TD515/PLEN [JWTcreation] with the following roles: 165 Facilitate the rapid exchange of information between the IETF and 166 ITU-T, 168 Ensure that the work is progressing with a consistent set of 169 priorities, 171 Identify gaps/inconsistencies in the solutions under development, 173 Propose solutions for consideration by the appropriate WG/ 174 Question, 176 Provide guidance when work on a topic is stalled or a technical 177 decision must be mediated. 179 None of these groups would have the authority to create or modify 180 IETF RFCs or ITU-T Recommendations. Any such work would be 181 progressed via the normal process of the respective standards body. 182 Direct participation in the work by experts from the IETF and ITU-T 183 would be required. 185 The JWT recommended that the normative definition of the MPLS-TP that 186 supports the ITU-T transport network requirements will be captured in 187 IETF RFCs. It proposed that the ITU-T should: 189 Develop ITU-T Recommendations to allow MPLS-TP to be integrated 190 with current transport equipment and networks Including in 191 agreement with the IETF, the definition of any ITU-T specific 192 functionality within the MPLS-TP architecture via the MPLS change 193 process (RFC 4929), 195 Revise existing ITU-T Recommendations to align with MPLS-TP, 197 ITU-T Recommendations will make normative references to the 198 appropriate RFCs. 200 The executive summary contains a number of detailed JWT 201 recommendations to both IETF and ITU-T management together with 202 proposed document structure and timetable. 204 These JWT recommendations were accepted by ITU-T management [REF] 206 3. Introduction and Background Material 208 Slides 11 to 22 provide introductory and background material. 210 The starting point of the analysis was to attempt to satisfy Option 1 211 by showing the high level architecture, any show stoppers and the 212 design points that would need to be addressed after the decision has 213 been made to work together. Option 1 was stated as preferred by the 214 IETF and because Option 1 was shown to be feasible, Option 2 was not 215 explored. 217 The work was segmented into five groups looking at: Forwarding, OAM, 218 Protection, Control Plane and Network Management. The outcome of 219 each review was reported in following sections and is summarised 220 below. 222 There follows a detailed description of the overall requirements and 223 architectural assumptions that would be used in the remainder of the 224 work. 226 4. High-Level Architecture 228 Slides 23 to 28 provide a high-level architectural view of the 229 proposed design. 231 The spectrum of services that MPLS-TP needs to address and the wider 232 MPLS context is described, together with the provisioning issues. 233 Some basic terminology needed to understand the MPLS-TP is defined 234 and some context examples provided. 236 5. OAM and Forwarding 238 Slides 29 to 32 describe the OAM requirements and talk about segment 239 recovery and node identification. 241 Slides 33 to 38 introduce OAM hierarchy and describe LSP monitoring, 242 the MEP and MIP relationship and the LSP and PW monitoring 243 relationship. 245 Sides 39 to 46 introduce the Associated Channel Header and its 246 generalisation to carry the OAM over LSPs through the use of the 247 "Label for You" (LFU). 249 Slides 47 to 48 provide a description of how the forwarding and the 250 ACH OAM mechanism work in detail. A significant number of scenarios 251 are described to work through the operation on a case by case basis. 252 These slides introduce a new textual notation to simplify the 253 description of complex MPLS stacks. 255 Note that the MPLS forwarding, as specified by IETF RFCs, requires no 256 changes to support MPLS-TP. 258 6. Control Plane 260 Sides 79 to 83 discuss various aspects of the control plane design. 262 Control plane sub-team stated that existing IETF protocols can be 263 used to provide required functions for transport network operation 264 and for data-communications-network/switched-circuit-network 265 operation. IETF GMPLS protocols have already applied to ASON 266 architecture, and the JWT considered that any protocol extensions 267 needed will be easy to make. The slides provide a number of 268 scenarios to demonstrate this conclusion. 270 7. Survivability 272 The survivability considerations are provided in slides 95 to 104 274 Survivability sub-team did not find any issues that prevented the 275 creation of an MPLS-TP, and therefore recommended that Option 1 be 276 selected. Three potential solutions were identified. Each solutions 277 has different attributes and advantages, and thought that further 278 work in the design phase should eliminate one or more of these 279 options and/or provide an applicability statement. 281 After some clarifications and discussion there follow in the slide 282 set a number of linear and ring protection scenarios with examples of 283 how they might be addressed. 285 8. Network Management 287 Slide 106 states the conclusion of the Network Management sub-team : 288 that it found no issues that prevent the creation of an MPLS-TP and 289 hence Option 1 can be selected. 291 9. Summary 293 Slide 113 provides a summary of the JWT report. 295 The JWT found no show stoppers and unanimously agreed that they had 296 identified a viable solution. They therefore recommend Option 1. 297 They stated that in their view it is technically feasible that the 298 existing MPLS architecture can be extended to meet the requirements 299 of a Transport profile, and that the architecture allows for a single 300 OAM technology for LSPs, PWs and a deeply-nested network. From 301 probing various ITU-T Study Groups and IETF Working Groups it appears 302 that MPLS reserved label 14 has had wide enough implementation and 303 deployment that the solution may have to use a different reserved 304 label (e.g. Label 13). The JWT recommended that extensions to Label 305 14 should cease. 307 The JWT further recommended that this architecture appeared to 308 subsume Y.1711, since the requirements can be met by the mechanism 309 proposed in their report. 311 10. IANA considerations 313 There are no IANA considerations that arise from this draft. 315 Any IANA allocations needed to implement the JWT recommendation will 316 be requested in the standards-track RFCs that define the MPLS-TP 317 protocol. 319 11. Security Considerations 321 The only security consideration that arises as a result of this 322 document is the need to ensure that this is a faithful representation 323 of the JWT report. 325 The protocol work that arises from this agreement will have technical 326 security requirements which will be identified in the RFCs that 327 define MPLS-TP. 329 12. The JWT Report 331 In the PDF version of this RFC [REF to PDF VERSION] there follows the 332 JWT report as a set of slides. 334 13. References 336 13.1. Informative References 338 13.2. URL References 340 [Ethertypes] 341 ITU-T, SG 15 Question 12, "T-MPLS use of the MPLS 342 Ethertypes, https://datatracker.ietf.org/documents/ 343 LIAISON/file470.txt", 2006. 345 [JWTcreation] 346 Chairman, ITU-T SG 15, "Proposal to establish an Ad Hoc 347 group on T-MPLS, 348 http://www.itu.int/md/T05-SG15-080211-TD-PLEN-0515/en", 349 2008. 351 [MPLS-TP] "IETF and ITU-T cooperation on extensions to MPLS for 352 transport network functionality, 353 https://datatracker.ietf.org/liaison/446/", 2008. 355 [MPLS-TP-22] 356 IETF - ITU-T Joint Working Team, 357 "http://www.ietf.org/MPLS-TP_overview-22.pdf", 2008. 359 [Stuttgart] 360 IETF - IESG and IAB Chairs, "Report of interim meeting of 361 Q.12 on T-MPLS - Stuttgart, Germany, 12-14 September , 362 2007, Annex 4,http://ties.itu.int/u//tsg15/sg15/xchange/ 363 wp3/200709_joint_q12_q14_stuttgart/T-MPLS/ 364 wdt03_rapporteur_report-final.doc", 2006. 366 [T-MPLS1] IETF and ITU-T, "Various ITU-T and IETF Liaison Statements 367 Concerning T-MPLS, https://datatracker.ietf.org/liaison/". 369 [ahtmpls] "Ad Hoc group on T-MPLS, 370 http://www.itu.int/ITU-T/studygroups/com15/ahtmpls.html", 371 2008. 373 Authors' Addresses 375 Stewart Bryant (editor) 376 Cisco Systems 377 250, Longwater, Green Park, 378 Reading RG2 6GB, UK 379 UK 381 Email: stbryant@cisco.com 383 Loa Andersson (editor) 384 Acreo AB 385 Isafjordsgatan 22 386 Kista, 387 Sweden 389 Phone: 390 Fax: 391 Email: loa@pi.nu 392 URI: 394 Full Copyright Statement 396 Copyright (C) The IETF Trust (2008). 398 This document is subject to the rights, licenses and restrictions 399 contained in BCP 78, and except as set forth therein, the authors 400 retain all their rights. 402 This document and the information contained herein are provided on an 403 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 404 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 405 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 406 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 407 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 408 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 410 Intellectual Property 412 The IETF takes no position regarding the validity or scope of any 413 Intellectual Property Rights or other rights that might be claimed to 414 pertain to the implementation or use of the technology described in 415 this document or the extent to which any license under such rights 416 might or might not be available; nor does it represent that it has 417 made any independent effort to identify any such rights. Information 418 on the procedures with respect to rights in RFC documents can be 419 found in BCP 78 and BCP 79. 421 Copies of IPR disclosures made to the IETF Secretariat and any 422 assurances of licenses to be made available, or the result of an 423 attempt made to obtain a general license or permission for the use of 424 such proprietary rights by implementers or users of this 425 specification can be obtained from the IETF on-line IPR repository at 426 http://www.ietf.org/ipr. 428 The IETF invites any interested party to bring to its attention any 429 copyrights, patents or patent applications, or other proprietary 430 rights that may cover technology that may be required to implement 431 this standard. Please address the information to the IETF at 432 ietf-ipr@ietf.org.