idnits 2.17.1 draft-bryant-jwt-mplstp-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 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 428. 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 (June 20, 2008) is 5789 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'T-MPLS1' on line 362 looks like a reference -- Missing reference section? 'Ethertypes' on line 336 looks like a reference -- Missing reference section? 'Stuttgart' on line 355 looks like a reference -- Missing reference section? 'MPLS-TP-22' on line 351 looks like a reference -- Missing reference section? 'MPLS-TP' on line 347 looks like a reference -- Missing reference section? 'JWTcreation' on line 341 looks like a reference -- Missing reference section? 'REF' on line 201 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: December 22, 2008 Acreo AB 6 June 20, 2008 8 JWT Report on MPLS Architectural Considerations for a Transport Profile 9 draft-bryant-jwt-mplstp-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 December 22, 2008. 36 Abstract 38 This RFC archives the report of the IETF - ITU-T Jooint 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 label switched 71 protocol to be used in Transport Networks. A Transport Network can 72 be considered to be the network that provides wide area connectivity 73 upon which other services such IP, or the phone network run. The 74 ITU-T chose to adapt the IETF's MPLS to this task, and introduced a 75 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 lead to a "train wreck on the 84 Internet". These concerns led the chairs of the IESG and IAB to take 85 the step of sending a liaison to the ITU-T, stating that either 86 T-MPLS should become and fully compliant MPLS protocol, standardized 87 under the IETF process (the so called "Option 1"), or it should 88 become a completely disjoint protocol with a new name and completely 89 new set of code points (the so called "Option 2")[Ethertypes]. 91 Option 1 and Option 2 were discussed at an ITU-T meeting of Question 92 12 Study Group 15 in Stuttgart [Stuttgart], where it was proposed 93 that a Joint (ITU-T - IETF) Team should be formed to evaluate the 94 issues, and make a recommendation to ITU-T management on the best way 95 forward. 97 Following discussion between the management of the IETF and the ITU-T 98 a Joint Working Team (JWT) was established, this was supported by an 99 IETF Design Team and an Ad Hoc Group on T-MPLS in the ITU-T 100 [ahtmpls]. The first meeting of the Ad Hoc group occurred during the 101 ITU-T Geneva Plenary in February this year. As a result of the work 102 of the JWT and the resulting agreement on a way forward, the fears 103 that a set of next-generation network transport specifications 104 developed by ITU-T could cause interoperability problems were 105 allayed. 107 The JWT submitted their report to ITU-T and IETF management in the 108 form of a set of powerpoint slides [MPLS-TP-22] [ALSO INCLUDE SELF 109 REF TO PDF WHEN AVALIABLE]. The ITU-T have accepted this 110 recommendation, as documented in [MPLS-TP]. This RFC archives the 111 JWT report in a format that is accessable to the IETF. 113 There are two versions of this RFC. An ASCII version that contains a 114 summary of the slides and a pdf version that contains the summary and 115 a copy of the slides. In the case of a conflict between the summary 116 and the slides, the slides have normacy. Since those slides were the 117 basis of an important agreement between the the IETF and the ITU-T, 118 it should further be noted that In the event that the pdf verson of 119 the slides differ from those emailed to ITU-T and IETF management on 120 18th April 2008 by the co-chairs of the JWT, the emailed slides have 121 normacy. 123 2. Executive Summary 125 Slides 4 to 10 provide an executive summary of the JWT Report. The 126 following is a summary of those slides: 128 The JWT acheived consensus on the recommendation of Option 1: to 129 jointly agree to work together and bring transport requirements into 130 the IETF and extend IETF MPLS forwarding, OAM, survivability, network 131 management and control plane protocols to meet those requirements 132 through the IETF Standards Process. The Joint Working Team believed 133 that this would fulfill the mutual goal of improving the 134 functionality of the transport networks and the internet and 135 guaranteeing complete interoperability and architectural soundness. 136 This technolgy would be refered to as the Transport Profile for MPLS 137 (MPLS-TP) 139 The JWT recommend that future work should focus on: 141 In the IETF: 143 Definition of the MPLS "Transport Profile" (MPLS-TP) 145 In the ITU-T: 147 Integration of MPLS-TP into the transport network 149 Alignment of the current T-MPLS Recommendations with MPLS-TP and, 151 Terminate the work on current T-MPLS 153 The technical feasibility analysis demonstrated there were no "show 154 stopper" issues in the recommendation of Option 1 and that the IETF 155 MPLS and Pseudowire architecture could be extended to support 156 transport functional requirements. Therefore the team believed that 157 there was no need for the analysis of any other option. 159 The JWT proposed that the MPLS Interoperability Design Team (MEAD 160 Team), JWT and ad hoc T-MPLS groups continue as described in SG15 161 TD515/PLEN [JWTcreation] with the following roles: 163 Facilitate the rapid exchange of information between the IETF and 164 ITU-T 166 Ensure that the work is progressing with a consistent set of 167 priorities 169 Identify gaps/inconsistencies in the solutions under development 171 Propose solutions for consideration by the appropriate WG/Question 173 Provide guidance when work on a topic is stalled or technical 174 decision must be mediated 176 None of these groups would have the authority to create or modify 177 IETF RFCs or ITU-T Recommendations. Any such work would be 178 progressed via the normal process of the respective standards body. 179 Direct participation in the work by experts from the IETF and ITU-T 180 would be required. 182 The JWT recommended that the normative definition of the MPLS-TP that 183 supports the ITU-T transport network requirements will be captured in 184 IETF RFCs. It proposed that the ITU-T should: 186 Develop Recommendations to allow MPLS-TP to be integrated with 187 current transport equipment and networks Including in agreement 188 with the IETF, the definition of any ITU-T specific functionality 189 within the MPLS-TP architecture via the MPLS change process (RFC 190 4929) 192 Revise existing Recommendations to align with MPLS-TP 194 ITU-T Recommendations will make normative references to the 195 appropriate RFCs 197 The executive summary contains a number of detailed recommendations 198 to both IETF and ITU-T management together with proposed document 199 structure and timetable. 201 These recommendations were accepted by ITU-T management [REF] 203 3. Introduction and Background Material 205 Slides 11 to 22 provide introductory and background material. 207 The starting point of the analysis was to attempt to satisfy option 1 208 by showing the high level architecture, any show stoppers and the 209 design points that would need to be addressed after the decision has 210 been made to work together. Option 1 was stated as preferred by the 211 IETF and because Option 1 was shown to be feasible, Option 2 was not 212 explored. 214 The work was segmented into five groups looking at: Forwarding, OAM, 215 Protection, Control Plane and Network Management. The outcome of 216 each review was reported in following sections and is summarised 217 below. 219 There followed a detailed description of the overall requirements and 220 architectural assumptions that would be used in the remainder of the 221 work. 223 4. High Level Architecture 225 Slides 23 to 28 provide a high level architectural view of the 226 proposed design. 228 The spectrum of services that MPLS-TP needs to address and the wider 229 MPLS context is described, together with the provisioning issues. 230 Some basic terminology needed to understand the MPLS-TP is defined 231 and some context examples provided. 233 5. OAM and Forwarding 235 Slides 29 to 32 describe the OAM requirements and talk about segment 236 recovery and node identification. 238 Slides 33 to 38 introduce OAM hierarchy and describe LSP monitoring, 239 the MEP and MIP relationship and the LSP and PW monitoring 240 relationship. 242 Sides 39 to 46 introduce the Associated Channel Header and its 243 generalisation to carry the OAM over LSPs through the use of the 244 "Label for You" (LFU). 246 Slides 47 to 48 provide a didactic description of how the forwarding 247 and the ACH OAM mechanism work in detail. A significant number of 248 scenarios are described to work through the operation on a case by 249 case basis. These slides introduce a new textual notation to 250 simplify the description of complex MPLS stacks. 252 Note that the MPLS forwarding, as specified by the IETF RFCs, 253 requires no changes to support MPLS-TP 255 6. Control Plane 257 Sides 79 to 83 discuss various aspects of the control plane design. 259 Control plane sub-team stated that existing IETF protocols can be 260 used to provide required functions for transport network operation 261 and DCN/SCN operation. IETF GMPLS protocols have already applied to 262 ASON architecture, and the JWT considered that any protocol 263 extensions needed will be easy to make. The slides provide a number 264 of scenarios to demonstrate this conclusion. 266 7. Survivability 268 The survivability considerations are provided in slides 95 to 104 270 Survivability sub-team did nit find any issues that prevented the 271 creation of an MPLS-TP, and therefore recommended that Option 1 be 272 selected. Three potential solutions were identified. Each solutions 273 has different attributes and advantages, and thought that further 274 work in the design phase should eliminate one or more of these 275 options and/or provide an applicability statement. 277 After some clarifications and discussion there follow in the slide 278 set a number of linear and ring protection scenarios with examples of 279 how they might be addressed. 281 8. Network Management 283 Slide 106 States the conclusion of the Network Management sub team : 284 that they found no issues that prevent the creation of an MPLS-TP and 285 hence Option 1 can be selected. 287 9. Summary 289 Slide 113 Provides a summary of the JWT report. 291 The JWT found no show stoppers and everyone was in agreement that 292 they had identified a viable solution. They therefore recommend 293 Option 1. They stated that in their view it is technically feasible 294 that the existing MPLS architecture can be extended to meet the 295 requirements of a Transport profile, and that the architecture allows 296 for a single OAM technology for LSPs, PWs and a deeply nested 297 network. From probing various ITU-T Study Groups and IETF Working 298 Groups it appears that MPLS reserved label 14 has had wide enough 299 implementation and deployment that the solution may have to use a 300 different reserved label (e.g. Label 13). The JWT recommended that 301 extensions to Label 14 should cease. 303 The JWT further recommended that this architecture appeared to 304 subsume Y.1711 since the requirements can be met by the mechanism 305 proposed in their report. 307 10. IANA considerations 309 There are no IANA considerations that arise from this draft. 311 Any IANA allocations needed to implement the JWT recommendation will 312 be requested in the standards track RFCs that define the MPLS-TP 313 protocol. 315 11. Security Considerations 317 The only security consideration that arises as a result of this RFC 318 is the need to ensure that this is a faithful representation of the 319 JWT report. 321 The protocol work that arises from this agreement will have technical 322 security requirements which will be identified in the RFCs that 323 define MPLS-TP. 325 12. The JWT Report 327 In the PDF version of this RFC [REF to PDF VERSION] there follows the 328 JWT report as a set of slides. 330 13. References 332 13.1. Informative References 334 13.2. URL References 336 [Ethertypes] 337 ITU-T, SG 15 Question 12, "T-MPLS use of the MPLS 338 Ethertypes, https://datatracker.ietf.org/documents/ 339 LIAISON/file366.txt", 2006. 341 [JWTcreation] 342 Chairman, ITU-T SG 15, "Proposal to establish an Ad Hoc 343 group on T-MPLS, 344 http://www.itu.int/md/T05-SG15-080211-TD-PLEN-0515/en", 345 2008. 347 [MPLS-TP] "IETF and ITU-T cooperation on extensions to MPLS for 348 transport network functionality, 349 https://datatracker.ietf.org/liaison/446/", 2008. 351 [MPLS-TP-22] 352 IETF - ITU-T Joint Working Team, 353 "http://www.ietf.org/MPLS-TP_overview-22.pdf", 2008. 355 [Stuttgart] 356 IETF - IESG and IAB Chairs, "Report of interim meeting of 357 Q.12 on T-MPLS - Stuttgart, Germany, 12-14 September , 358 2007, Annex 4,http://ties.itu.int/u//tsg15/sg15/xchange/ 359 wp3/200709_joint_q12_q14_stuttgart/T-MPLS/ 360 wdt03_rapporteur_report-final.doc", 2006. 362 [T-MPLS1] IETF and ITU-T, "Various ITU-T and IETF Liaison Statements 363 Concerning T-MPLS, https://datatracker.ietf.org/liaison/". 365 [ahtmpls] "Ad Hoc group on T-MPLS, 366 http://www.itu.int/ITU-T/studygroups/com15/ahtmpls.html", 367 2008. 369 Authors' Addresses 371 Stewart Bryant (editor) 372 Cisco Systems 373 250, Longwater, Green Park, 374 Reading RG2 6GB, UK 375 UK 377 Email: stbryant@cisco.com 379 Loa Andersson (editor) 380 Acreo AB 381 Isafjordsgatan 22 382 Kista, 383 Sweden 385 Phone: 386 Fax: 387 Email: loa@pi.nu 388 URI: 390 Full Copyright Statement 392 Copyright (C) The IETF Trust (2008). 394 This document is subject to the rights, licenses and restrictions 395 contained in BCP 78, and except as set forth therein, the authors 396 retain all their rights. 398 This document and the information contained herein are provided on an 399 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 400 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 401 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 402 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 403 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 404 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 406 Intellectual Property 408 The IETF takes no position regarding the validity or scope of any 409 Intellectual Property Rights or other rights that might be claimed to 410 pertain to the implementation or use of the technology described in 411 this document or the extent to which any license under such rights 412 might or might not be available; nor does it represent that it has 413 made any independent effort to identify any such rights. Information 414 on the procedures with respect to rights in RFC documents can be 415 found in BCP 78 and BCP 79. 417 Copies of IPR disclosures made to the IETF Secretariat and any 418 assurances of licenses to be made available, or the result of an 419 attempt made to obtain a general license or permission for the use of 420 such proprietary rights by implementers or users of this 421 specification can be obtained from the IETF on-line IPR repository at 422 http://www.ietf.org/ipr. 424 The IETF invites any interested party to bring to its attention any 425 copyrights, patents or patent applications, or other proprietary 426 rights that may cover technology that may be required to implement 427 this standard. Please address the information to the IETF at 428 ietf-ipr@ietf.org.