idnits 2.17.1 draft-farrel-mpls-tp-recommendation-review-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (April 1, 2010) is 5110 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4677 (Obsoleted by RFC 6722) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Bryant 2 Internet-Draft Cisco Systems 3 Intended status: Informational 4 Expires: October 1, 2010 A. Farrel 5 Huawei Technologies 6 April 1, 2010 8 IETF Expectations of Participation in Development and Review of 9 ITU-T Recommendations on MPLS-TP 11 draft-farrel-mpls-tp-recommendation-review-01.txt 13 Abstract 15 The decision to develop a Multiprotocol Label Switching (MPLS) 16 Transport Profile (MPLS-TP) in cooperation between the IETF and the 17 ITU-T is documented in RFC 5317 as the report of the Joint Working 18 Team on MPLS-TP. As part of this development process, the 19 International Telecommunication Union - Telecommunication 20 Standardisation Sector (ITU-T) will develop a number of 21 Recommendations. Those Recomendations will allow MPLS-TP to be 22 integrated with current transport equipment and networks, including, 23 in agreement with the IETF, the definition of any ITU-T-specific 24 functionality within the MPLS-TP architecture via the Change Process 25 for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 26 Protocols and Procedures. 28 This document sets out the IETF's expectations of how the IETF, 29 through individual participation and through consensus decisions, 30 will contribute to in the development, review, and approval of those 31 Recommendations. 33 This document does not modify any existing ITU-T or IETF procedures, 34 but shows how those procedures can be used to facilitate cooperation 35 for the MPLS-TP project. 37 Status of this Memo 39 This Internet-Draft is submitted to IETF in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt. 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html. 57 Copyright Notice 59 Copyright (c) 2010 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 1. Introduction 74 The decision to develop a Multiprotocol Label Switching (MPLS) 75 Transport Profile (MPLS-TP) in cooperation between the IETF and the 76 ITU-T is documented in [RFC5317] as the report of the Joint Working 77 Team on MPLS-TP. As part of this development process, the 78 International Telecommunication Union - Telecommunication 79 Standardisation Sector (ITU-T) will develop a number of 80 Recommendations. Those Recomendations will allow MPLS-TP to be 81 integrated with current transport equipment and networks, including, 82 in agreement with the IETF, the definition of any ITU-T-specific 83 functionality within the MPLS-TP architecture via the Change Process 84 for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 85 Protocols and Procedures [RFC4929]. 87 This document sets out the IETF's expectations of how the IETF, 88 through individual participation and through consensus decisions, 89 will contribute to in the development, review, and approval of those 90 Recommendations. 92 This document does not modify any existing ITU-T or IETF procedures, 93 but shows how those procedures can be used to facilitate cooperation 94 for the MPLS-TP project. 96 1.1. Terminology 98 This documents uses a number of terms that are common to the MPLS-TP 99 cooperation project. Please refer to [MPLS-TP-PROCESS] for a list of 100 applicable IETF and ITU-T terms. 102 1.2. Purpose, Intent, and Procedures for Cooperation on MPLS-TP 104 This section is a deliberate restatement of the equivalent section 105 in [MPLS-TP-PROCESS]. It is reproduced here because the purpose and 106 intent of the cooperation project on MPLS-TP is fundamental to the 107 establishment of procedures for that cooperation, and is the basis 108 for the IETF's expectations of participation in the ITU-T's 109 development of MPLS-TP Recommendations. 111 The purpose and objectives of the development activity on MPLS-TP is 112 described in [RFC5317]. The JWT report, accepted by the ITU-T and the 113 IETF, includes the recognition that the design authority for MPLS 114 (including MPLS-TP) is the IETF. 116 At the same time, the JWT report recognises the role of the ITU-T in 117 providing input (especially input to the requirements statements) to 118 the development process for MPLS-TP. There is also a clear statement 119 of expectation that the ITU-T's opinions will be heard within the 120 IETF and must be properly considered during the development of 121 MPLS-TP documents. 123 It should be noted that the IETF will continue to work on MPLS and 124 pseudowire technologies for core MPLS (i.e., not MPLS-TP) 125 deployments. Additionally, the IETF will work on technologies that 126 are close to, but not directly part of MPLS-TP (for example, the OSPF 127 routing protocol, and bidirectional forwarding detection - BFD). All 128 work by the IETF on the development of Internet technologies will 129 proceed as before, and the IETF welcomes participation from all 130 individuals. Where such developments overlap with MPLS-TP such that 131 they are important to the work on MPLS-TP, they will form part of the 132 cooperation project. 134 The development of standards for MPLS-TP is, therefore, carried out 135 within the IETF according to IETF process and with strong input from 136 the ITU-T. This input takes three forms (see also Section 2.2): 138 o Active participation. 140 All interested parties are encouraged to participate in the 141 development of MPLS-TP standards within the IETF through the 142 normal IETF process. In short, this involves the generation and 143 documentation of new ideas as Internet-Drafts, and the discussion 144 of work in progress through the IETF mailing lists, at IETF 145 meetings, and through informal conversations and conference calls. 146 The IETF is not a membership organisation; the mailing lists and 147 meetings are open to everyone. 149 o Informal communication. 151 It is recognised that discussions about MPLS-TP will take place 152 within the Questions and Study Groups of the ITU-T. In order to 153 speed up the development process and ensure smooth communications, 154 the ITU-T is requested to make informal (i.e., email, conference 155 call, face-to-face conversation) communications to the IETF 156 whenever any issues or questions arise. Informal communication can 157 be made by any individual or Rapporteur of a Question, and the 158 MPLS-TP mailing list is the default forum for such communication. 159 The chairs of the Ad Hoc Team on MPLS-TP may also summarise 160 discussions within the ITU-T (especially those on the Ad Hoc Team 161 on MPLS-TP mailing list) and communicate them to the IETF via 162 email. 164 o Formal communication. 166 The formal liaison process with the IETF is described in [RFC4052] 167 and [RFC4053]. This process will be used for ensuring that 168 specific progress steps are check-pointed and recorded, and for 169 making sure that appropriate responses are generated in a timely 170 manner. Formal liaison communications may be marked as "For 171 Action", "For Comment", or "For Information" depending on the 172 level of feedback that is required. Where formal liaison 173 communication is indicated in this document, the type of liaison 174 that is advised in each instance is also indicated. 176 The objective of cooperation between the IETF and ITU-T is to ensure 177 full participation of interested parties in order to make sure that 178 all opinions are heard with the intention of producing sound and 179 stable MPLS-TP documentation. It is understood that the neither the 180 IETF nor the ITU-T is in a position to block the work of the other 181 body within its areas of authority. In the context of this document, 182 this means that the ITU-T cannot block IETF work on MPLS-TP against 183 the IETF consensus view. 185 Part of this process must be the understanding that all IETF 186 documentation (including RFCs) can be revised or extended according 187 to normal IETF procedures. Therefore, it is not a requirement that 188 the first version of any RFC be perfect for all time (we do not need 189 to "boil the ocean"); the initial aim of the work is to provide 190 documentation of MPLS-TP as it is initially developed and deployed. 192 Fundamental to understanding the process described in the rest of 193 this document and to participating in the MPLS-TP development process 194 is a working knowledge of the procedures of the IETF. Readers needing 195 clarification of the IETF procedures are invited to read [RFC2026], 196 [RFC4677], and [RFC4929]. Further clarification and guidance can be 197 obtained from the MPLS-TP responsible working group chair, the MPLS- 198 TP responsible AD, and the IETF liaison to the ITU-T on MPLS. 200 The ITU-T may also develop Recommendations to document MPLS-TP. The 201 JWT decision recognises that these Recommendations must not contain 202 normative definitions of MPLS-TP (these are captured solely in IETF 203 RFCs). Recommendations on MPLS-TP will be provided for review by the 204 IETF to ensure conformance with the previous point and to verify that 205 the material is consistent across MPLS-TP. The process for producing 206 and reviewing Recommendations is the subject of this document. 208 1.3. Communications with the ITU-T 210 A most important part of this process is the information exchange 211 between the IETF and ITU-T. This information exchange consists of 212 two equally important pieces. 214 o Informal information exchange 216 This is done primarily by e-mail to the relevant mailing lists. 217 Information sent to the ITU-T must be sent to the Ad Hoc Team on 218 MPLS-TP mailing list. Information sent to the IETF must be sent to 219 the MPLS-TP mailing list. 221 o Formal information exchange 223 In addition to the informal information exchange, a formal 224 information exchange is accomplished by liaison correspondence 225 between the two organisations. Exchange of liaisons makes it 226 possible to follow the request/response exchange between the 227 organisations in more detail, and to obtain an official view of 228 each organisation's position on any topic. 230 Formal liaisons should include tracking numbers in their subject 231 lines to facilitate easy coordination of responses with the 232 requests to which they are associated. 234 1.3.1. Document Formats 236 The purpose of communications in the context of this document is the 237 review of draft text of Recommendations. Such text is usually worked 238 on by the ITU-T using Microsoft Word, and it is expected that it will 239 be supplied to the IETF as either a Word document or in PDF. Such 240 files may be quite large as a result of embedded figures. 242 Recommendation text sent to the IETF as part of formal liaisons 243 will be archived alongside the liaisons in the IETF repository. In 244 this case, file size will not be an issue. 246 Recommendation text sent as part of an informal communication is 247 quite likely to exceed the message size limits on IETF mailing lists. 248 Senders of such communications are advised to place the text files on 249 publically accessible FTP sites. 251 1.4. Non-Response to Liaisons 253 The liaison relationship between the IETF and the ITU-T is founded on 254 the understanding that each party will respond in a timely and 255 appropriate manner to the other party's liaisons so long as 256 reasonable notice is given. 258 Failure to respond by a deadline properly expressed in a liaison must 259 not be used to cause deadlock or to block advancement of work. Such 260 failures shall be assumed to represent accidental errors or 261 oversights and shall be brought to the attention of the management of 262 the body that has failed to respond. 264 In extreme cases, the JWT is empowered to convene itself to resolve 265 issues of failed communications. 267 2. High-Level Description of the ITU-T Development and Approval Process 269 This section provides a high-level description of the processes used 270 within the ITU-T for the development and approval of Recommendations. 272 This section is for information only and is not a normative 273 description of these processes. 275 2.1. Development of Recommendation Text 277 This document makes no change to the normal procedures for the 278 development of Recommendation text. 280 IETF participants whose companies or organizations are members of the 281 ITU-T may contribute to the text of Recommendations using the normal 282 procedures of submitting Contributions or participating in ITU-T 283 meetings. 285 ISOC delegates (usually people holding IETF management or liaison 286 positions) may also attend ITU-T meetings and contribute to the 287 development of Recommendation text. 289 Invited Experts may also attend ITU-T meetings at the discretion of 290 the ITU-T management. These experts may be invited according to their 291 particular areas of expertise and can contribute to the efforts to 292 develop Recommendation text. 294 Section 3 of this document describes how the IETF may participate in 295 the development and review of ITU-T Recommendation text. Formal 296 liaisons form an important part of this process and allow the IETF to 297 provide review comments and make suggestions in the process of the 298 development of ITU-T Recommendations. 300 2.2. Final Edit, Consent, and Approval of Recommendations 302 It is anticipated that all of the MPLS-TP Recommendations will be 303 approved by the ITU-T via the Alternative Approval Process (AAP) 304 defined in Recommendation A.8 [A.8] 306 The process used for MPLS-TP Recommendations will be that the draft 307 text of Recommendations intend for consent will be made available at 308 least 7 working days before the SG15 meeting at which consent is 309 planned. 311 At that meeting, the text may be edited based only on the 312 contributions or liaison statements available at the meeting. Note 313 that the draft Recommendation can only be modified based on these 314 specific inputs. 316 On the final day of the meeting, if the members present agree to 317 consent the draft Recommendation (as modified during the meeting) 318 then the last call process is initiated. As defined in Recommendation 319 A.8 [A.8], last call is a 4 week period during which members of the 320 ITU-T can submit comments. If substantive comments are submitted 321 during the last call period they are addressed by modifying the draft 322 Recommendation. When all parties are satisfied, an additional review 323 is initiated. After the additional review the Recommendation is 324 either approved or, exceptionally, if objections are received, the 325 Recommendation is returned to the next meeting of the study group for 326 further work. 328 3. IETF Input to ITU-T Development Process 330 In accordance with the agreements reached in the JWT [RFC5317], it is 331 important that the IETF has adequate opportunity to review the draft 332 Recommendations at a stage where changes can be readily accommodated, 333 i.e., before consent and the initiation of the Last Call period. 334 The participation of experts from the IETF in the early stages of the 335 development of the MPLS-TP Recommendations is critical to the 336 successful completion of the final stages of this process. This early 337 interaction will be facilitated by taking the following steps: 339 - At any time in the process of developing the text for an MPLS-TP 340 Recommendation, the ITU-T may solicit input or clarification by 341 sending email to the IETF's MPLS-TP mailing list (mpls-tp@ietf.org) 342 or by sending a liaison For Action. 344 - IETF participants whose companies are members of the ITU-T are 345 strongly encouraged to participate in the development of the 346 Recommendation text through the normal ITU-T process by submitting 347 contributions, and by participating in meetings and virtual 348 meetings to discuss the content. 350 - Once the draft Recommendation has reached a reasonable state of 351 stability the text will be sent to the IETF in a liaison For 352 Comment to solicit early review and comments. 354 4. IETF Input to the ITU-T Final Modification and Consent Process 356 It is important to allow the IETF time to review the draft 357 Recommendation that is intended for consent at an SG15 meeting, and 358 to allow the IETF to provide comments as a liaison statement to the 359 meeting so that the comments can be used as a source for final 360 modification of the Recommendation text 362 To facilitate this, the IETF expects that the ITU-T will make a 363 version of the draft text available 3 weeks before the start of the 364 SG 15 meeting. This draft can be reviewed by the IETF and will be 365 the version of the text presented to the SG 15 meeting. 367 A response liaison from the IETF to convey any review comments or a 368 statement that there are no comment is required and should reach the 369 ITU-T before the start of the meeting. 371 During the SG15 meeting, the draft Recommendation will be updated 372 based on the contributions and liaison statements available at the 373 meeting (including the comments from the IETF review). This may 374 result in any of: 376 - no changes to the draft text if there is no input 378 - modifications consistent with the comments received from the IETF 380 - additional modifications based on contributions from other parties. 382 The IETF participation in this final modification is limited to 383 participation at the meeting by representatives of organizations that 384 are ITU-T Sector Members. This does not constitute formal IETF 385 participation, but some of the same people may be involved. 387 At the end of the meeting, the modified text will be considered for 388 consent by the members of the SG who are present. This will decide 389 whether the Recommendation will proceed to last call and approval. 391 In order that the MPLS-TP work developed by the IETF and ITU-T can 392 proceed as a cooperative development, it is important that the text 393 of the Recommendation that is consented and taken forward does not 394 contain modification of substance that have not been reviewed and 395 agreed by the IETF. This means that editorial changes made within the 396 SG15 meeting are acceptable, but that technical changes may require 397 further review and agreement by the IETF. 399 A judgement call must be made to determine which changes are 400 substantial and require further IETF review and agreement. The IETF 401 shall designate one individual present at the SG15 meeting to make 402 this decision with the assistance of the ITU-T management responsible 403 for the Recommendation concerned. This person will usually be the 404 ISOC delegate, but may be some other designated person (for example, 405 the IETF's liaison on MPLS, an Area Director, or a working group 406 chair). 408 If the judgment call is that further IETF review and agreement is 409 required, a choice must be made: 411 - If the changes are small, the Recommendation may continue to be 412 consented with the understanding that any changes identified during 413 IETF review will be submitted to the ITU-T as last call comments 414 (see Section 5). 416 - If the change is more significant, the designated IETF 417 representative will advise the Study Group through the Study Group 418 chair. In this case, the IETF expects that the text will be sent 419 back to the IETF for further review and agreement prior to consent. 420 Depending on the result of the IETF review, the ITU-T Question 421 responsible for the Recommendation will undertake further work to 422 revise the text and initiate additional IETF review before 423 proposing the revised text for consent. 425 The process used for IETF review and agreement is that a copy of the 426 final text of the Recommendation as proposed for consent will be sent 427 to the IETF in a liaison for Action and the IETF will immediately 428 hold a further last call on an email list that it designates (usually 429 the MPLS-TP email list). Normal IETF rough consensus mechanisms will 430 be used to judge support for approval and to request further changes, 431 except that silence will be determined to represent support for 432 approval. 434 5. IETF Input to the ITU-T Last Call and Approval Process 436 This document does not modify the ITU-T's last call and approval 437 process as defined in Recommendation A.8 [A.8]. 439 The IETF's expectation is that, by the time last call is held, the 440 IETF will have already reviewed and agreed the text of the 441 Recommendation. Thus, it is not expected that the IETF will need to 442 make any comments during last call. If, however, an issue is 443 discovered during the last call period, it will be sent to the ITU-T 444 in a formal liaison. 446 If substantive comments are submitted to the ITU-T from other sources 447 during the last call period they will be addressed by modifying the 448 draft Recommendation. When all parties are satisfied, an additional 449 review will be initiated within the ITU-T and it is the IETF's 450 expectation that the IETF would be notified of any changes and given 451 the opportunity to comment and agree the changes. If, after the 452 additional review there are still objections, the Recommendation will 453 be returned to the next meeting of the study group for further work. 455 6. Guidelines For MPLS-TP work in the ITU-T 457 These guidelines apply to progressing work on MPLS-TP in the ITU-T. 459 - Any member of the ITU-T may send an MPLS-TP contribution to a ITU-T 460 Study Group or Question. 462 - Before the ITU-T initiates any new work (i.e., items not previously 463 identified by the JWT) based on such contributions the ITU-T shall 464 send a liaison to the IETF. The message will go to the IETF 465 liaison to the ITU-T on MPLS, the MPLS-TP responsible working 466 group chair, and the MPLS-TP responsible AD. They are responsible 467 for sending a consolidated response from the IETF, but may 468 delegate the work of writing the response. 470 - The IETF must respond to such liaisons according to the deadline 471 in the liaison. Acceptable responses include: 473 o Acknowledgement of receipt and agreement that the ITU-T is 474 clear to proceed with the work described. 476 o Request that the work described be transferred from the ITU-T to 477 the IETF in the form of an Internet-Draft to form part of the 478 MPLS-TP work in the IETF. 480 o Request that the work be put on hold until specific issues have 481 been resolved. In the event that this response is seen as 482 blocking of ITU-T work, the JWT may be convened to seek a 483 resolution. 485 Note that the process described in this section is conformant to the 486 Change Process for Multiprotocol Label Switching (MPLS) and 487 Generalized MPLS (GMPLS) Protocols and Procedures [RFC4929] and is in 488 accord with the IETF's Best Current Practice Procedures for Protocol 489 Extensions and Variations [RFC4775]. 491 7. IANA Considerations 493 There are no requests for IANA action in this document. 495 8. Security Considerations 497 This document describes the IETF's expectations for participating in 498 the development of ITU-T Recommendations on MPLS-TP and thus does not 499 introduce any new security considerations. 501 The successful development of MPLS-TP standards that are consistent 502 across the industry is an essential component to ensuring the 503 security and stability of MPLS networks. 505 9. Acknowledgments 507 Thanks to the participants in the ITU-T Study Groups 15 (Questions 3, 508 9, 10, 12, and 14) interim meeting in May 2009 for writing a liaison 509 on which a significant part of this text is based [LS-54] and for 510 providing review of this text. Thanks to Malcolm Betts and to Ross 511 Callon for review comments and input. Thanks to the joint ITU-T and 512 IETF Management Steering Group on MPLS-TP for their review of the 513 content of this document. Yuanlong Jiang, Ben Niven-Jenkins, Tom 514 Petch, and Scott Mansfield provided helpful comments. 516 10. References 518 10.1. Normative References 520 10.2. Informative References 522 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 523 3", BCP 9, RFC 2026, October 1996. 525 [RFC4052] Daigle, L., Ed., and Internet Architecture Board, "IAB 526 Processes for Management of IETF Liaison Relationships", 527 BCP 102, RFC 4052, April 2005. 529 [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 530 Handling Liaison Statements to and from the IETF", BCP 531 103, RFC 4053, April 2005. 533 [RFC4677] Hoffman, P. and Harris, S., "The Tao of IETF: A Novice's 534 Guide to the Internet Engineering Task Force", RFC 4677, 535 September 2006. 537 [RFC4775] Bradner, S., Carpenter, B, and Narten, T., "Procedures for 538 Protocol Extensions and Variations", BCP 125, RFC 4775, 539 December 2006. 541 [RFC4929] Andersson, L. and Farrel, A., "Change Process for 542 Multiprotocol Label Switching (MPLS) and Generalized MPLS 543 (GMPLS) Protocols and Procedures", BCP 129, RFC4929, June 544 2007. 546 [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) 547 Report on MPLS Architectural Considerations for a 548 Transport Profile", RFC 5317, February 2009. 550 [A.8] ITU-T, "Alternative approval process for new and revised 551 ITU-T Recommendations", Recommendation A.8, October 2008. 553 [LS-54] ITU-T Study Group 15, "IETF Review of ITU-T MPLS-TP 554 Recommendations", Liaison Statement, COM15-LS54-E, May 555 2009. 557 [MPLS-TP-PROCESS] Farrel, A., Betts, M., Andersson, L. and Ward, D., 558 "IETF Multi-Protocol Label Switching (MPLS) Transport 559 Profile (MPLS-TP) Document Process", draft-ietf-mpls-tp- 560 process, work in progress. 562 Authors' Addresses 564 Adrian Farrel 565 Huawei Technologies 567 Email: adrian.farrel@huawei.com 569 Stewart Bryant 570 Cisco Systems 572 Email: stbryant@cisco.com