idnits 2.17.1 draft-andersson-rtg-gmpls-change-04.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1041. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1018. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1025. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1031. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 2006) is 6401 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3356 (Obsoleted by RFC 6756) -- Obsolete informational reference (is this intentional?): RFC 3932 (Obsoleted by RFC 5742) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Andersson (Editor) 2 Internet-Draft Acreo AB 3 Proposed Status: Best Current Practice A. Farrel (Editor) 4 Old Dog Consulting 6 October 2006 8 Change Process for Multiprotocol Label Switching (MPLS) and 9 Generalized MPLS (GMPLS) Protocols and Procedures 11 draft-andersson-rtg-gmpls-change-04 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 The issues surrounding the extensibility of IETF protocols have been 39 widely debated. These issues include when it is reasonable to 40 extend IETF protocols with little or no review, and when extensions 41 or variations need to be reviewed by the larger IETF community. 42 Experience with IETF protocols has shown that extensibility of 43 protocols without early IETF review can cause problems. 45 The Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 46 suites of protocols have become popular for a number of applications 47 and deployment scenarios. One result of this popularity is a large 48 number of suggestions for modifications and extensions. 50 This document defines a flexible and responsive process for the IETF 51 to handle suggestions for extensions to the MPLS and GMPLS protocols, 52 and clarifies the IETF's responsibility to supervise the growth and 53 evolution of MPLS and GMPLS protocols. 55 The process allows individuals, IETF working groups, and external 56 standards bodies to influence the development of the MPLS and GMPLS 57 standards. When possible, existing liaison relationships are used. 59 Table of Contents 61 1. Introduction ................................................... 3 62 1.1 Document Source ............................................... 4 63 1.2 Conventions Used in this Document ............................. 4 64 2. Applicability of the (G)MPLS Change Process .................... 4 65 2.1 IETF Working Groups Developing (G)MPLS Technology ............. 4 66 2.1.1 Multiprotocol Label Switching Working Group ................. 5 67 2.1.2 Common Control & Measurement Plane Working Group ............ 5 68 2.1.3 MPLS and CCAMP Division of Work ............................. 6 69 2.2 Other (G)MPLS Technology Working Groups ...................... 6 70 2.3 Organizations Outside the IETF ............................... 7 71 2.4 Terminology .................................................. 7 72 3. Summary of Procedures .......................................... 9 73 4. MPLS and GMPLS Change Process ................................ 10 74 4.1 Flow Diagram ................................................ 11 75 4.2 Description of Process Stages ............................... 12 76 4.2.1 Preliminary Investigation .................................. 12 77 4.2.2 Requirements Statement Evaluation .......................... 12 78 4.2.3 Chartering the Rewg ........................................ 13 79 4.2.4 Rewg Evaluation of the Requirements Statement I-D .......... 14 80 4.2.5 AD Evaluation of Completed Requirements Statement I-D ...... 14 81 4.2.6 IESG and IAB review of Requirements Statement I-D and Pswg 82 Charter .................................................... 15 83 4.2.7 Solutions Work ............................................. 15 84 5. Rejecting Requirements Statements I-D ......................... 16 85 5.1 Reasons for Rejection ........................................ 16 86 5.2 Actions Upon Rejection ....................................... 17 87 6. Abandonment of the Solutions I-D .............................. 18 88 7. (G)MPLS Integrity ............................................. 19 89 8. Security Considerations ...................................... 19 90 9. Acknowledgements ............................................. 20 91 10. IANA Considerations .......................................... 20 92 11. References .................................................. 20 93 11.1 Normative References ....................................... 20 94 11.2 Informative References ..................................... 20 96 1. Introduction 98 [PROT-EXT] discusses procedural issues related to the extensibility 99 of IETF protocols, including when it is reasonable to extend IETF 100 protocols with little or no review, and when extensions or variations 101 need to be reviewed by the larger IETF community. Experience with 102 IETF protocols has shown that extensibility of protocols without 103 early IETF review can cause problems. The document also recommends 104 that major extensions to or variations of IETF protocols only take 105 place through normal IETF processes or in coordination with the IETF. 107 This document recognizes that the Multiprotocol Label Switching 108 (MPLS) and Generalized MPLS (GMPLS) protocol families were created 109 within the IETF and constitute significant protocol suites that are 110 strategic to the development of the Internet. They should not be 111 extended or varied without IETF review, and that should preferably 112 only be extended within the IETF process. 114 The process described in this document allows individuals, IETF 115 working groups, and external standards bodies to influence the 116 development of MPLS and GMPLS protocols and related standards. The 117 process means that MPLS and GMPLS extensions and changes can only be 118 done through or in coordination with the IETF. In particular, the 119 MPLS and/or CCAMP working groups or their successors need to be 120 involved in the process. When possible, existing liaison 121 relationships ([RFC4052], [RFC4053]) are leveraged. 123 The IETF will not endorse the publication of any MPLS or GMPLS 124 protocol or technology extensions in RFCs or other documents where 125 the process described here have not been followed. If publication of 126 individual Internet-Drafts describing extensions or changes to the 127 MPLS or GMPLS protocols is requested of the RFC Editor the documents 128 will be returned to the process described in this document using the 129 mechanism described in [RFC3932]. 131 IANA is responsible for managing many codepoints registries including 132 those for MPLS and GMPLS protocols. These registries have specific 133 allocation policies that IANA uses in order to determine whether 134 codepoints can be allocated and which codepoints to allocate. In many 135 cases, the rules require IANA to refer back to the IETF when asked to 136 make an allocation. In the case of changes or extensions to the MPLS 137 or GMPLS protocols, IANA will use the process described in this 138 document to judge whether or not a code point allocation should be 139 made. 141 The MPLS and GMPLS technology is developed in two main tracks in the 142 IETF. "MPLS" refers to the work done for packet switched networks, 143 while "GMPLS" refers to the efforts to apply the MPLS protocols to 144 all types of networks including packet and non-packet technologies. 145 Though GMPLS by definition is a superset of MPLS, the term "(G)MPLS" 146 is used in this document to indicate both of these tracks. A 147 terminology section that covers the use of terms and concepts used in 148 this document is found in Section 2.6. 150 1.1 Document Source 152 This document is the joint work of the IETF Routing Area Directors, 153 the IETF MPLS and CCAMP Working Group Chairs, and the IETF's liaison 154 to the ITU-T. It has had considerable review and comment from key 155 members of the ITU-T who have given their time and opinions based on 156 experience for which the authors are grateful. The acknowledgements 157 section lists those whose contributions have been particularly 158 helpful. 160 1.2 Conventions Used in this Document 162 Although this document is not a protocol definition, the key words 163 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 164 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 165 are to be interpreted as described in RFC 2119 [RFC2119]. This usage 166 is chosen to make the steps and procedures completely clear. 168 2. Applicability of the (G)MPLS Change Process 170 This section outlines the applicability of the (G)MPLS change process 171 specified in this document. It lists the key IETF working groups 172 developing the (G)MPLS technology, examples of IETF working groups 173 using the (G)MPLS technology, and possible parties interested in 174 using, extending, or changing the (G)MPLS technology. 176 It should be remembered that the IETF environment is highly dynamic. 177 Working groups and whole areas come and go. The overview of the 178 relevant working groups within the IETF is only a snapshot in time. 180 A section listing terminology local to this document that will be 181 used in specifying the change process is also included. 183 2.1 IETF Working Groups Developing (G)MPLS Technology 185 Two working groups in the IETF's Routing Area have been responsible 186 for work to develop the (G)MPLS technology. The Multiprotocol Label 187 Switching (MPLS) working group and the Common Control and Measurement 188 Plane (CCAMP) working group. 190 The sections below give brief overviews of the work these two IETF 191 working groups were chartered to do. 193 The IETF may, in the future, define additional working groups to work 194 on specific chartered issues related to (G)MPLS. Further, specific 195 existing working groups such as those listed in section 2.2 may be 196 rechartered by the IESG to work on particular aspects of the (G)MPLS 197 protocols. The procedure for chartering new or existing working 198 groups to undertake (G)MPLS work is covered in section 4.2.3. 200 2.1.1 Multiprotocol Label Switching Working Group 202 The Multiprotocol Label Switching (MPLS) working group is responsible 203 for standardizing the base technology that uses label switching, and 204 for describing the implementation of Label Switched Paths (LSPs) over 205 various packet and frame-based link level technologies. The working 206 group charter includes procedures and protocols for the distribution 207 of labels between routers, as well as encapsulations, operation and 208 management, traffic engineering, and multicast considerations. 210 The procedures in this document assume that the MPLS working group 211 remains the authority on MPLS technologies, but acknowledges that 212 the IETF may appoint another working group (using the procedures in 213 this document) to handle specific extensions or changes to the 214 protocols. Further, in the event that the MPLS working group 215 completes its work and is closed, the IETF may appoint a Designated 216 Expert (sometimes known as a Caretaker) for the MPLS protocols. 218 2.1.2 Common Control & Measurement Plane Working Group 220 The IETF Common Control and Measurement Plane (CCAMP) working group 221 coordinates the work within the IETF defining common control and 222 measurement planes for ISP and SP core tunneling technologies. This 223 includes, but is not limited to, defining signaling protocols and 224 measurement protocols such that they support multiple physical path 225 and tunnel technologies using input from technology-specific working 226 groups such as the MPLS working group. It also includes the 227 development of protocol-independent metrics and parameters for 228 describing links and paths that can be carried in protocols. 230 The technology that the CCAMP working group focuses on is called 231 Generalized MPLS (GMPLS), indicating that CCAMP addresses a 232 generalized technology, where labels are defined in such a way that 233 they will be compatible with the technology over which the data is 234 transported. While the MPLS working group focuses on packet- and 235 frame-switched technologies, the CCAMP working group work focuses on 236 common methods across a broad spectrum of switching technologies 237 including packet and frame technologies. In this respect, GMPLS can 238 be viewed as a superset of MPLS. 240 The procedures in this document assume that the CCAMP working group 241 remains the authority on GMPLS technologies, but acknowledges that 242 the IETF may appoint another working group (using the procedures in 243 this document) to handle specific extensions or changes to the 244 protocols. Further, in the event that the CCAMP working group 245 completes its work and is closed, the IETF may appoint a Designated 246 Expert (sometimes known as a Caretaker) for the GMPLS protocols. 248 2.1.3 MPLS and CCAMP Division of Work 250 From time to time the MPLS and CCAMP working groups decide to divide 251 work between themselves in a way that does not strictly follow the 252 split between the working groups as defined in the working group 253 charters. This is the case, e.g., for P2MP TE LSPs, where the MPLS 254 working group is specifying requirements and base technology for all 255 of the (G)MPLS technology. 257 An entity or individual that wishes to propose extensions or changes 258 to (G)MPLS should first decide to which working group (MPLS or CCAMP) 259 it will bring the proposal. However, the MPLS and CCAMP working group 260 chairs, in conjunction with their Area Directors, may redirect the 261 proposal to another working group. 263 2.2 Other (G)MPLS Technology Working Groups 265 Problem statements and requirements for (G)MPLS technology have been 266 produced by several working groups in addition to the MPLS and CCAMP 267 working groups. For example, the IP over Optical (IPO) working group 268 and the Internet Traffic Engineering working group (TEWG). These 269 working groups have not specified any protocols, but have been a 270 source of problem statements and requirements to be considered by the 271 (G)MPLS working groups. 273 Other working groups, e.g., the Bidirectional Forwarding Detection 274 (BFD) working group, also use the (G)MPLS protocols and mechanisms. 275 When any of these working groups needs to extend or change the 276 (G)MPLS protocols the procedures specified in this document are 277 applicable. 279 The Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) working groups have 280 been chartered to specify a limited number of solutions for Provider 281 Provisioned VPNs. Both working groups are in the Internet Area. The 282 work of the L2VPN and L3VPN working groups does not include 283 specifying new protocols, however, protocol changes and extensions 284 to the (G)MPLS protocols may be needed. If so, the procedures 285 specified in this document are applicable. 287 The Layer 1 VPN (L1VPN) working group is chartered to specify 288 mechanisms necessary for providing layer 1 VPN services 289 (establishment of layer 1 connections between CE devices) over a 290 GMPLS-enabled transport service-provider network. Protocol extensions 291 required for L1VPN will be done in cooperation with MPLS, CCAMP, 292 OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. That is, the 293 L1VPN will not develop GMPLS protocol extensions in isolation, but 294 will develop requirements and propose extensions that will be 295 reviewed and approved by the (G)MPLS working groups. 297 The Pseudo Wire Emulation End to End (PWE3) working group is another 298 working group in the Internet Area that also uses the (G)MPLS 299 protocols in its specifications. Should the PWE3 specifications 300 require extension or changes to the (G)MPLS protocols the procedures 301 specified in this document are applicable. 303 It is assumed that the change process for the MPLS and CCAMP working 304 groups, specified in this document, will be applicable or at least 305 adaptable to other (G)MPLS technology working groups if such a need 306 should arise. 308 2.3 Organizations Outside the IETF 310 A number of standards development organizations (SDOs) and industrial 311 forums use or reference the (G)MPLS protocols in their 312 specifications. Some of these organizations have formal liaison 313 relationships with the IETF [RFC4052]. The IETF exchanges information 314 with these organizations about what is happening on both sides, 315 including plans and schedules, using liaison statements [RFC4053]. 316 More details about the cooperation relationship between the IETF and 317 the ITU-T can be found in [RFC3356]. 319 The procedures in this document are applicable to all organizations 320 outside the IETF whether or not they have formal liaison 321 relationships with the IETF. If any organization outside the IETF 322 has a requirement or believes it may have a requirement for 323 extensions or modifications to the (G)MPLS protocols then the 324 procedures in this document apply. 326 It should be noted that the first stage in the change process is an 327 optional Preliminary Investigation (see Section 4.2.1). This stage is 328 explicitly included to allow external organizations to discuss 329 requirements and proposed uses of the (G)MPLS technologies without 330 the need to first develop Internet-Drafts, and builds on existing 331 liaison processes where they exist. 333 2.4 Terminology 335 This section defines terms for use in the context of this document. 337 o (G)MPLS protocols 338 The (G)MPLS protocols are the protocols and protocol variants 339 developed by the IETF to control, manage, or measure MPLS or GMPLS 340 networks and their component devices. 342 The set of RFCs that constitutes the (G)MPLS protocols are the 343 standards track RFCs from the (G)MPLS working groups (see below). 344 A list of these RFCs is not supplied here since new RFCs are 345 produced from time to time. 347 For the purpose of extending and changing any protocols specified 348 in Experimental RFCs developed by the (G)MPLS working groups, 349 those protocols are considered to be part of the (G)MPLS 350 protocols. 352 o (G)MPLS working groups 353 The (G)MPLS working groups are the MPLS and the CCAMP working 354 groups, and any future working group specifically chartered by the 355 IESG to work on the development or extension of the (G)MPLS 356 protocols. 358 o (G)MPLS technology working group 359 Any working group chartered by the IESG to specify requirements 360 for the (G)MPLS protocols, and any working group that specifies a 361 use for the (G)MPLS protocols. This include the (G)MPLS working 362 groups. 364 o Requirement evaluating working group (rewg) 365 The rewg is the IETF working group charged with the task of 366 evaluating a specific set of requirements and the associated 367 problem statement. 369 o Preliminary Investigation 370 An optional preliminary phase that may be used to exchange views 371 on a proposed requirement and usage of the (G)MPLS technologies 372 without going to the effort of writing an Internet-Draft. This 373 phase may be particularly useful to SDOs that have already 374 invested heavily in documenting a problem statement, or may be 375 used by anyone who wishes to hold discussions on the use of 376 (G)MPLS. 378 o Protocol specifying working group (pswg) 379 The pswg is the working group chartered by the IESG to specify 380 changes or extensions to the (G)MPLS protocols either as part of 381 the normal IETF process or in response to a requirements draft. 383 o Problem statement Internet-Draft 384 The Internet-Draft that initiates the discussion on changing or 385 extending the (G)MPLS protocols. This draft includes a detailed 386 problem description that (G)MPLS is called on to solve. The 387 problem statement draft may also include the requirements (see 388 requirements statement Internet-Draft, below). 390 o Requirements statement Internet-Draft 391 This Internet-Draft provides a detailed list of the requirements 392 that the (G)MPLS extensions or changes need to fulfil. This draft 393 may be merged with the problem statement draft (see above). 395 o Solutions Internet-Draft 396 A specification of extensions or changes to the (G)MPLS protocols 397 to meet the requirements in the requirement statement 398 Internet-Draft. 400 3. Summary of Procedures 402 This non-normative section is intended to provide a high-level view 403 of the procedures in this document to illustrate how they work and to 404 introduce the mechanisms that are defined in detail in Section 4. 406 Whenever there is reason to believe that a particular problem may be 407 solved by use of or extensions to the (G)MPLS protocols, a 408 preliminary investigation phase may be used to discuss the 409 requirements with the IETF. This may lead to an understanding that 410 the problem is already solved, is outside the scope of the IETF, or 411 requires more investigation possibly leading to changes to the 412 (G)MPLS protocols. 414 Whenever any extension or change to the (G)MPLS protocols is desired, 415 a requirements statement must be produced and must be submitted to 416 IETF as an Internet-Draft. As described in [RFC4052], when the 417 requirements come from an external organization informal 418 communications such as e-mail to working group mailing lists often 419 facilitates cooperative work. However, if desired, the Internet-Draft 420 containing the requirement may be submitted to the working group 421 using a liaison statement. That way, the IETF's response to the 422 request will be given as the reply to the liaison, with no risk of 423 confusing an individual participant's opinion for that of the group 424 as can happen on mailing lists. 426 The IETF, through the Routing Area Directors and the chairs of the 427 MPLS and CCAMP working groups, will direct the requirements draft to 428 an appropriate working group for assessment and comment. This process 429 may require communication and discussion for clarification, but the 430 IETF undertakes to perform the assessment in a timely manner. 432 In assessing the requirements statement I-D, the IETF may determine: 433 that the requirements can be satisfied without modifications to the 434 (G)MPLS protocols; that the requirements are not sufficiently general 435 to warrant a change to the (G)MPLS protocols; that the requirements 436 justify a change to the (G)MPLS protocols that will be created by the 437 IETF or within another organization; that the requirements might not 438 be possible to satisfy without vioalting the (G)MPLS architecture in 439 a way that would harm the (G)MPLS technology; or that the 440 requirements should be combined with other requirements to solve a 441 more general problem or solve the same problem in a more flexible 442 way. 444 In the event that the IETF agrees to develop a solution, the IETF 445 will commit to do so in a timely manner. If the IETF rejects the 446 requirements, this will only be done with clear explanation and full 447 discussion with the source of the requirements. 449 The solutions that are developed within the IETF may be sourced from 450 external organizations and presented for review, discussion, 451 modification, and adoption as Internet-Drafts. Such solutions drafts 452 may be presented to the IETF in advance of the completion of the 453 requirements work, but all solutions will compete through the normal 454 IETF process with other proposed solutions, and none will be adopted 455 as an IETF working group draft until the requirements are agreed by 456 the rewg chairs to be stable and, in any case, not before the pswg 457 has a charter item to cover the solutions work. 459 4. MPLS and GMPLS Change Process 461 This section defines the (G)MPLS change process and the rules that 462 must be followed in order to make extensions or changes to the 463 (G)MPLS protocols. The language of [RFC2119] is used in order to 464 clarify the precise required behavior. 466 Anyone who intends to use one of the existing (G)MPLS protocols, but 467 thinks that it will not satisfy their needs MUST use the procedures 468 described in this document. Changes or extensions to the (G)MPLS 469 protocols MUST NOT be made by any other mechanism. The IETF MUST NOT 470 endorse any publications (including RFCs whether on the Standards 471 Track, Informational, or Experimental) that change or extended the 472 (G)MPLS protocols except for those that arise through the correct 473 execution of the procedures in this document. The IETF MUST NOT 474 endorse any IANA action that allocates (G)MPLS protocol codepoints 475 except as a result of actions arising from the correct execution of 476 the procedures in this document. 478 4.1 Flow Diagram 480 Figure 1 is presented to give a visual overview of the process. It 481 does not contain all of the possible interactions of procedures, and 482 the text in the subsequent sections should be used for a definitive 483 description of the process. 485 Start +-------------+ 486 | |optional | 487 +--<--------------------|preliminary |<-------Start 488 | |investigation| 489 V +-------------+ 490 +------------+ +---------+ +---------+ 491 |requirements| discussion |review by| ACK | IESG/ | ACK 492 |statement |----------->|WG chairs|------------->| IAB |------+ 493 |I-D | on mailing |and ADs | request to |decision | | 494 +------------+ list +---------+ IESG/IAB to +---------+ | 495 | appoint rewg | | 496 | NAK and charter |NAK rewg| 497 V req eval | chartered| 498 +-------------+ | to work on| 499 |response | | requirements| 500 |to the | | statement| 501 |requirements |<-----------------+ | 502 +->|statement |<----------------+ | 503 | +-------------+ | | 504 | ^ | | 505 NAK| | NAK | | 506 | +-----------------+ | V 507 | | | NAK +------+ 508 +--------+ +-------+ +--------| rewg | 509 | IESG/ | ACK | AD | | req | 510 +-----------| IAB |<---------------|review |<------------| eval | 511 |WG |decision| request to | | ACK | | 512 |chartered +--------+ IESG/IAB to +-------+ +------+ 513 |to work approve I-D 514 | and charter 515 | 516 | +---------+ 517 | | IETF | +-----+ 518 +--------->| WG |-----/ /---->| RFC | 519 +---->| process | +-----+ 520 | +---------+ 521 solutions 522 I-D 524 Figure 1: Change Process Overview 526 4.2 Description of Process Stages 528 This section describes how the (G)MPLS change process works, what is 529 expected from individuals or organizations that want to extend or 530 change the (G)MPLS protocols, and the responsibilities of the (G)MPLS 531 working groups, the Routing Area and the IETF in general. 533 4.2.1 Preliminary Investigation 535 This step is OPTIONAL, and is intended to provide a lightweight way 536 to "feel out" the IETF's position on a proposal without going to the 537 effort of writing an Internet-Draft. The intention is to determine 538 whether the problem has been examined already, whether the problem is 539 in scope for the IETF, and whether solutions are already known. 541 Useful discussions may be held at this stage in order to ensure that 542 the problem statement and requirements statement Internet-Drafts 543 contain the right material. In fact, although this step is described 544 as lightweight because no Internet-Draft is required and because the 545 nature of the step is discursive, it may be the case that this step 546 involves considerable technical discussions and may, in fact, be an 547 extensive, substantive exchange of opinions. 549 This step SHOULD be carried out informally on the mailing list of the 550 rewg or on the Routing Area discussion mailing list and MAY be 551 initiated by any individual, group of individuals, external 552 organization, or IETF working group. 554 When an external SDO has a liaison relationship with the IETF, it 555 MAY carry out this step using a formal liaison. The liaison SHOULD be 556 sent to the rewg or to the Routing Area, and the initiators of the 557 liaison SHOULD make themselves available for discussion on the 558 selected mailing list. If a formal liaison is used, the IETF MUST 559 respond to pursue the discussion. 561 At this stage, a problem statement I-D MAY be produced to help 562 further the discussions and to clarify the issues being addressed. 564 A possible outcome of this preliminary invsetigation is that the 565 requirements and problem are understood, but agreed to be out of 566 scope for the IETF. Alternatively it may be that the problem can be 567 solved with existing protocols. 569 4.2.2 Requirements Statement Evaluation 571 Before the IETF can formally pronounce on requirements to change or 572 extend the (G)MPLS protocols, a requirements statement I-D MUST be 573 written and submitted to the IETF for publication. 575 The requirements statement I-D MUST be introduced to the IETF through 576 an email to the rewg mailing list or to the Routing Area discussion 577 mailing list, or by a formal liaison from an external SDO which will 578 result in the IETF introducing the requirements statement I-D to the 579 rewg mailing list. If the requirements statement I-D is brought to 580 the IETF through a formal liaison, the initiators of the liaison 581 SHOULD make themselves available for discussion on the appropriate 582 mailing lists. 584 After discussion on the IETF mailing lists, the appropriate IETF 585 working group chairs and the Routing Area Directors MUST decide 586 whether the requirements will be formally evaluated by the IETF or 587 MUST deliver a response to the requirements statement I-D. 589 If the requirements statement I-D is brought to the IETF through a 590 formal liaison, the IETF MUST respond using one of the following 591 answers in a formal liaison reply: 593 a. Requirements not understood. Further discussion required. 595 b. Requirements understood, but judged to be out of scope for the 596 IETF. 598 In this case, the originator of the requirements can work on 599 on requirements and solutions and will not be impeded by the 600 IETF. The IETF may request to be kept informed of progress. 602 c. Requirements understood, but no protocol extensions are needed. 604 It may be desirable for the external SDO to cooperate with the 605 appropriate working group in the production of an Applicability 606 Statement Internet-Draft. 608 d. Requirements understood, and the IETF would like to develop 609 protocol extensions. 611 This results in execution of the rest of the procedure, described 612 below. The requirements raised in the requirements statement I-D 613 may be combined with other requirements to produce more general 614 extensions or changes to the (G)MPLS protocols. 616 4.2.3 Chartering the Rewg 618 In many cases the problem covered by the requirements statement I-D 619 will fall within the scope of the existing charter of a working 620 group. In this case, the Routing Area Directors SHOULD designate the 621 working group as the rewg and pass the requirements statement I-D to 622 the working group for evaluation. 624 If a new charter item is required, the Routing Area Directors with 625 assistance from working group chairs MUST apply to the IESG and IAB 626 for a modification of an existing working group's charter or for the 627 creation of a new working group. If the IESG and IAB approve the 628 charter, the requirements statement I-D is passed to the rewg for 629 evaluation. If the charter change is not approved, the IESG and IAB 630 MUST respond to the requirements statement I-D and, if the 631 requirements were introduced through a formal liaison from another 632 SDO, the IESG and IAB MUST send a liaison response using the options 633 described in Section 5. 635 4.2.4 Rewg Evaluation of the Requirements Statement I-D 637 The objective of the rewg evaluation process is to determine a clear 638 and complete statement of the requirements for changes or extensions 639 to the (G)MPLS protocols. This will necessitate normal IETF working 640 group procedures in the rewg and MAY include the generation of 641 revisions of the requirements statement I-D in cooperation between 642 the members of the rewg and the original authors of the requirements 643 statement I-D. 645 The originators of the requirements statement I-D MUST make 646 themselves available to discuss the work on the rewg mailing list. 647 If this does not happen, the chairs of the rewg MAY determine that 648 there is insufficient support for the work and MAY reject the 649 requirements statement I-D. 651 The output of the rewg MUST be either: 652 - a completed requirements statement I-D that has been accepted by 653 working group consensus within the rewg and has passed through 654 working group last call; 655 or: 656 - a rejection of the requirements following exactly the same format 657 and procedure as described in Section 5. 659 4.2.5 AD Evaluation of Completed Requirements Statement I-D 661 As with all Internet-Drafts produced by a working group, the ADs are 662 MUST review the completed requirements statement I-D produced by the 663 rewg to determine its fitness for publication. The ADs MAY use an 664 Area Directorate to assist them in this review. 666 The result of the AD review MAY request the rewg to do further work 667 on the I-D in which case the previous step and this one will be 668 repeated. 670 The ADs SHOULD NOT reject the requirements statement I-D outright at 671 this stage since the requirements have already been accepted by the 672 ADs at an earlier stage. However, in some situations (such as a 673 significant change in related circumstances) the ADs MAY reject the 674 requirements statement I-D using the format and procedure described 675 in Section 5. 677 When the ADs accept the requirements statement I-D they MUST pass it 678 to the IESG for review, and propose any charter changes necessary to 679 select a pswg. 681 4.2.6 IESG and IAB review of Requirements Statement I-D and Pswg Charter 683 As with all Internet-Drafts, the IESG MUST take a ballot on the 684 progression of the requirements statement I-D. 686 If the IESG rejects the requirements statement I-D, it MUST generate 687 a response to the requirements as described in Section 5. 689 The IESG and IAB MUST take a ballot on any proposed charter changes 690 for the pswg. This MAY include the formation of a new working group 691 specifically to work on the solutions, although it is also possible 692 that the solutions work is covered by an existing working group 693 charter without any changes. 695 If the IESG rejects working group charter changes such that it is not 696 possible for the IETF to work on solutions for the requirements in 697 the requirements statement I-D, this MUST be treated as a rejection 698 of the requirements statement I-D, and the requirements statement I-D 699 MUST NOT be published as an RFC. In this case the IESG MUST reject 700 the requirements statement I-D using the format and procedure 701 described in Section 5. 703 4.2.7 Solutions Work 705 Once the requirements statement I-D has been approved by the IESG it 706 will enter the RFC Editor's queue and be handled according to normal 707 IETF process. 709 Once the pswg has been identified and (re-)chartered as necessary and 710 the requirements statement I-D has been approved by the IESG, the 711 pswg can start work on solutions following the normal IETF process. 713 Solutions I-Ds MAY be prepared externally (such as within an external 714 organization) or within the IETF, submitted to the IETF for 715 publication, and introduced to the pswg for consideration. Such I-Ds 716 MAY be submitted at earlier stages in the process to assist the rewg 717 in its development and discussion of the requirements, but no I-D 718 will be formally considered as a solutions I-Ds until the pswg has a 719 charter item that covers the work and the rewg chairs are confident 720 that the requirements are stable. Even at this stage in the process, 721 the IETF makes no guarantees that an externally produced solutions 722 I-D will form the basis of the pswg solutions I-D, but the pswg MUST 723 consider such an I-D as a possible solution I-D. 725 The final development of the solutions I-D is subject to the normal 726 working group review, consensus, and last call within the pswg. 728 Where the requirements originated from an external organization, the 729 pswg SHOULD regularly communicate its progress using a formal liaison 730 process if one exists. This communication SHOULD also be used to 731 request review input and comment on the development of the solutions 732 I-D. When the solutions I-D is complete (normally upon completing 733 working group last call and/or on entering the RFC Editor's queue) 734 the pswg MUST inform the originating organization of the completed 735 solution. 737 5. Rejecting Requirements Statements I-D 739 Rejection of the requirements statements is a sensitive matter for 740 the authors of the requirements and MUST be handled with full 741 disclosure and explanation by the IETF. 743 The requirements can be rejected at various stages of the process as 744 described in the previous sections. The person or grouping that makes 745 the rejection is responsible for generating an explanation of the 746 rejection and MUST follow the process described in this section. 748 5.1 Reasons for Rejection 750 The requirements statement I-D can only be rejected using one of the 751 following reasons. Each reason MUST be stated with the acceptable 752 next steps as described here. 754 - Requirements not understood. At the early stage of evaluation of 755 the requirements statement I-D before the rewg has been tasked with 756 performing a full evaluation and completing the requirements 757 statement I-D or during the optional preliminary investigation it 758 is not clear what the requirements are for or what the problem 759 being addressed is. 761 This rejection forms part of an on-going communication and it is 762 expected that the process will continue with further iterations. 764 - Out of scope for the IETF. Many stages of this process may 765 determine that the requirements are out of scope for the IETF. In 766 this case, the IETF MUST NOT constrain the authors of the 767 requirements statement I-D permission to work on a solution. 769 - No protocols extensions or changes are needed. At some stage in the 770 evaluation of the requirements it may become clear that they can 771 all be met through appropriate use of existing protocols. In this 772 case no further evaluation of the requirements is required, but the 773 IETF MUST explain how the protocols can be used to meet the 774 requirements and MAY cooperate with the authors of the requirements 775 statement I-D in the production of an Applicability Statement 776 Internet-Draft that explains precisely how the existing protocols 777 can be used to meet the requirements. 779 - Insufficient support within the IETF. Although the work described 780 within the requirements statement I-D is within scope for the IETF, 781 and despite the support of the originators of the requirements 782 statement I-D on the rewg mailing list, the chairs of the rewg have 783 determined that there is insufficient support in the rewg to 784 complete requirements statement I-D. In this case, the IETF MUST 785 grant the authors of the requirements statement I-D permission to 786 work on a solution. The solution SHALL be presented to the IETF 787 for review and possible publication as an Informational or 788 Experimental RFC, and the IETF SHALL NOT block applications to IANA 789 for codepoints. 791 - Insufficient support for the work. If the authors of the 792 requirements statement I-D do not make themselves available on the 793 rewg mailing list for discussion of the requirements or do not 794 contribute the completion of the requirements statement I-D, the 795 chairs of the rewg MAY determine that there is insufficient support 796 for the work and MAY reject the requirements statement I-D. In this 797 case, the IETF MUST NOT grant permission for the work to be carried 798 out in any other organization, and MUST NOT endorse the publication 799 of any changes or extensions to the (G)MPLS protocols and MUST NOT 800 instruct IANA to allocate any codepoints. The requirements may be 801 re-introduced by starting the procedure again from the top. 803 - Satisfying the requirements would break the technology. It is 804 possible that an assessment will be made that, although the 805 requirements are reasonable, it is not possible to satisfy them 806 through extensions or changes to the (G)MPLS protocols without 807 violating the (G)MPLS architecture in such a way as would break the 808 (G)MPLS technology. In this case a recommendation will be made that 809 some other technology be used to satisfy the requirements. See 810 Section 7 for further discussions of the protection of the 811 integrity of the (G)MPLS technology. 813 5.2 Actions Upon Rejection 815 Upon rejection, the IETF MUST make a clear statement of why the 816 requirements statement I-D has been rejected and what next step 817 actions are acceptable. The reasons SHOULD be based on the list in 818 Section 5.1. 820 The form of the rejection depends on the form of the original 821 submission. 823 - If the requirements are brought to the IETF as a preliminary 824 investigation (see Section 4.2.1) through an email exchange then 825 the response SHOULD be made as an email response and SHOULD be 826 archived through an IETF email archive. 828 - If the requirements are brought to the IETF as a preliminary 829 investigation (see Section 4.2.1) through a formal liaison, the 830 rejection MUST be delivered through a formal liaison response. 832 - If a requirements statement I-D has been produced and discussed on 833 an IETF email list, the response SHOULD be made as an email 834 response and copied to the email list. 836 - If a requirements statement I-D has been produced and brought to 837 the IETF through a formal liaison, the rejection MUST be 838 delivered through a formal liaison response. 840 - If an IETF working group has been involved in the review or 841 production of any Internet-Drafts for the requirements or for the 842 solutions, the working group MUST be notified of the rejection and 843 the reasons. 845 The responsibility for the generation response lies with the person, 846 people, or grouping that instigates the rejection. This may be the 847 IAB, the IESG, one or more Area Directors, one or more working group 848 chairs, or a protocol caretaker. In the case of the use of a liaison 849 relationship, the IETF's liaison manager has responsibility for 850 ensuring that the procedures in this document, and particularly the 851 rejection procedures, are followed. 853 6. Abandonment of the Solutions I-D 855 Once the solutions work has been started by the pswg, it MAY be 856 abandoned before completion. This can happen if the pswg chairs 857 determine that there is no longer working group support for doing the 858 work. This could arise, for example, if no-one (including the 859 originators of the requirements statement I-D) is willing to 860 contribute to the development of a solutions I-D. 862 In the event that the solutions work is abandoned by the pswg, the 863 Area Directors responsible for the pswg MUST be consulted. The 864 originators of the requirements statement I-D MUST be informed that 865 the work has been stopped using a mechanism dependent on how the 866 requirements were introduced (as discussed in Section 5.2). 868 If the solution is abandoned in this way, work on solutions for the 869 requirements MUST NOT be started in another forum. The status of 870 extensions and changes to the (G)MPLS protocols with regard to the 871 specific requirements returns to how it was before the process 872 started. Any new examination of the requirements MUST commence at 873 the top of the process. 875 7. (G)MPLS Integrity 877 The (G)MPLS working groups are REQUIRED to protect the architectural 878 integrity of the (G)MPLS protocols and MUST NOT extend the GMPLS 879 architecture with features that do not have general use beyond the 880 specific case. They also MUST NOT modify the architecture just to 881 make some function more efficient at the expense of simplicity or 882 generality. 884 The architectural implications of additions or changes to the (G)MPLS 885 protocols MUST be consider interoperability with existing and future 886 versions of the protocols. The effects of adding features that 887 overlap or that deal with a point solution and are not general are 888 much harder to control with rules. Therefore the (G)MPLS technology 889 calls for this architectural guardianship by its working groups. 891 8. Security Considerations 893 All requirements statement I-Ds MUST give full consideration to the 894 security impact of the proposed additional features or functions. All 895 solutions I-Ds MUST consider the impact on the security of the 896 protocol extensions and to the pre-existing protocol. 898 This documents does not itself introduce any security issues for any 899 (G)MPLS protocols. 901 The IETF process is itself at risk from denial of service attacks. 902 This document utilizes the IETF process and adds details to that 903 process. It is possible, therefore, that this document might put the 904 IETF process at risk. Although this document places additional 905 requirements on key individuals within the IETF, those requirements 906 are not substantial for any individual requirements statement I-D 907 since the responsibility for the majority of the work lies with the 908 rewg and pswg with an underlying assumption that the authors of the 909 requirements statement I-D will participate in the working group 910 process. 912 Therefore, provided that the number of requirements statement I-Ds is 913 not unreasonable, there will be no significant impact on the IETF 914 process. The rate of arrival of requirements statement I-Ds MAY be 915 used by the IESG to detect denial of service attacks, and the IESG 916 SHOULD act on such an event depending on the source of the 917 requirements statement I-D and the perceived relevance of the work. 918 The IESG might, for example, discuss the issue with the management of 919 external organizations. 921 9. Acknowledgements 923 The input given by Bert Wijnen has been useful and detailed. 925 Review feedback and discussions with various members of the ITU-T has 926 been helpful in refining the process described in this document. 927 Thanks in particular to the members of Question 14 of Study Group 15, 928 and to the management of Study Group 15. Important discussions were 929 held with the following participants in the ITU-T: Yoichi Maeda, 930 Greg Jones, Stephen Trowbridge, Malcolm Betts, Kam Lam, 931 George Newsome, Eve Varma, Lyndon Ong, Stephen Shew, Jonathan Sadler, 932 and Ben Mack-Crane. 934 10. IANA Considerations 936 This document makes no specific requests to IANA for action. The 937 procedures described in this document assume that IANA will adhere to 938 the allocation policies defined for the (G)MPLS codepoint registries 939 and that the IETF will not endorse allocation of codepoints from 940 those registries except where work has been carried out in accordance 941 with the procedures described in this document. 943 11. References 945 11.1 Normative References 947 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 948 Requirement Levels", BCP 14, RFC 2119, March 1997. 950 [RFC4052] Daigle, L., "IAB Processes for Management of IETF Liaison 951 Relationships", BCP 102, RFC 4052, April 2005. 953 [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 954 Handling Liaison Statements to and from the IETF", 955 BCP 103, RFC4053, April 2005. 957 [PROT-EXT] Bradner, S., and Carpenter, B., "Procedures for protocol 958 extensions and variations", draft-carpenter-protocol- 959 extensions, work in progress. 961 11.2 Informative References 963 [RFC3356] Fishman, G. and S. Bradner, "Internet Engineering Task 964 Force and International Telecommunication Union - 965 Telecommunications Standardization Sector Collaboration 966 Guidelines", RFC 3356, August 2002. 968 [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: 969 Procedures", BCP 92, RFC 3932, October 2004. 971 Authors' Addresses 973 Loa Andersson 974 Acreo AB 975 Email: loa@pi.se 977 Adrian Farrel 978 Old Dog Consulting 979 Email: adrian@olddog.co.uk 981 George Swallow 982 Cisco Systems 983 Email: swallow@cisco.com 985 Deborah Brungard 986 AT&T 987 Email: dbrungard@att.com 989 Bill Fenner 990 AT&T 991 Email: fenner@research.att.com 993 Ross Callon 994 Juniper Networks 995 Email: rcallon@juniper.net 997 Kireeti Kompella 998 Juniper Networks 999 Email: Kireeti@juniper.net 1001 Alex Zinin 1002 Alcatel 1003 Email: zinin@psg.com 1005 Scott Bradner 1006 Harvard University 1007 Email: sob@harvard.edu 1009 Intellectual Property Statement 1011 The IETF takes no position regarding the validity or scope of any 1012 Intellectual Property Rights or other rights that might be claimed to 1013 pertain to the implementation or use of the technology described in 1014 this document or the extent to which any license under such rights 1015 might or might not be available; nor does it represent that it has 1016 made any independent effort to identify any such rights. Information 1017 on the procedures with respect to rights in RFC documents can be 1018 found in BCP 78 and BCP 79. 1020 Copies of IPR disclosures made to the IETF Secretariat and any 1021 assurances of licenses to be made available, or the result of an 1022 attempt made to obtain a general license or permission for the use of 1023 such proprietary rights by implementers or users of this 1024 specification can be obtained from the IETF on-line IPR repository at 1025 http://www.ietf.org/ipr. 1027 The IETF invites any interested party to bring to its attention any 1028 copyrights, patents or patent applications, or other proprietary 1029 rights that may cover technology that may be required to implement 1030 this standard. Please address the information to the IETF at 1031 ietf-ipr@ietf.org. 1033 Disclaimer of Validity 1035 This document and the information contained herein are provided on an 1036 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1037 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1038 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1039 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1040 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1041 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1043 Copyright Statement 1045 Copyright (C) The Internet Society (2006). This document is subject 1046 to the rights, licenses and restrictions contained in BCP 78, and 1047 except as set forth therein, the authors retain all their rights.