idnits 2.17.1 draft-andersson-rtg-gmpls-change-07.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1106. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1083. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1090. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1096. 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 IETF Trust 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 (November 2006) is 6369 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: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Andersson (Editor) 3 Internet-Draft Acreo AB 4 Proposed Status: Best Current Practice A. Farrel (Editor) 5 Old Dog Consulting 7 November 2006 9 Change Process for Multiprotocol Label Switching (MPLS) and 10 Generalized MPLS (GMPLS) Protocols and Procedures 12 draft-andersson-rtg-gmpls-change-07 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 The issues surrounding the extensibility of IETF protocols have been 40 widely debated. These issues include when it is reasonable to 41 extend IETF protocols with little or no review, and when extensions 42 or variations need to be reviewed by the larger IETF community. 43 Experience with IETF protocols has shown that extensibility of 44 protocols without early IETF review can cause problems. 46 The Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 47 suites of protocols have become popular for a number of applications 48 and deployment scenarios. One result of this popularity is a large 49 number of suggestions for modifications and extensions. 51 This document defines a flexible and responsive process for the IETF 52 to handle suggestions for extensions to the MPLS and GMPLS protocols, 53 and clarifies the IETF's responsibility to supervise the growth and 54 evolution of MPLS and GMPLS protocols. 56 The process describes how individual draft submissions, working 57 group drafts, and inputs from external standards bodies influence the 58 development of the MPLS and GMPLS standards. When possible, existing 59 liaison relationships are used. 61 Table of Contents 63 1. Introduction ................................................... 3 64 1.1 Document Source ............................................... 4 65 1.2 Conventions Used in this Document ............................. 4 66 2. Applicability of the (G)MPLS Change Process .................... 4 67 2.1 IETF Working Groups Developing (G)MPLS Technology ............. 4 68 2.1.1 Multiprotocol Label Switching Working Group ................. 5 69 2.1.2 Common Control & Measurement Plane Working Group ............ 5 70 2.1.3 MPLS and CCAMP Division of Work ............................. 6 71 2.2 Other (G)MPLS Technology Working Groups ...................... 6 72 2.3 Organizations Outside the IETF ............................... 7 73 2.4 Terminology .................................................. 7 74 3. Summary of Procedures .......................................... 9 75 4. MPLS and GMPLS Change Process ................................ 10 76 4.1 Flow Diagram ................................................ 11 77 4.2 Description of Process Stages ............................... 12 78 4.2.1 Preliminary Investigation .................................. 12 79 4.2.2 Requirements Statement Evaluation .......................... 13 80 4.2.3 Chartering or Rechartering the REWG ........................ 14 81 4.2.4 REWG Evaluation of the Requirements Statement I-D .......... 14 82 4.2.5 AD Evaluation of Completed Requirements Statement I-D ...... 15 83 4.2.6 IESG and IAB review of Requirements Statement I-D and PSWG 84 Charter .................................................... 15 85 4.2.7 Solutions Work ............................................. 15 86 5. Rejecting Requirements Statements I-D ......................... 16 87 5.1 Reasons for Rejection ........................................ 16 88 5.2 Actions Required When Rejecting Requirements Statement I-Ds .. 18 89 5.3 Appeals ...................................................... 19 90 6. Abandonment of the Solutions I-D .............................. 19 91 6.1 Appeals ...................................................... 19 92 7. (G)MPLS Integrity ............................................. 19 93 8. Security Considerations ...................................... 20 94 9. Acknowledgements ............................................. 20 95 10. IANA Considerations .......................................... 21 96 11. References ................................................... 21 97 11.1 Normative References ........................................ 21 98 11.2 Informative References ...................................... 21 100 1. Introduction 102 [PROT-EXT] discusses procedural issues related to the extensibility 103 of IETF protocols, including when it is reasonable to extend IETF 104 protocols with little or no review, and when extensions or variations 105 need to be reviewed by the larger IETF community. Experience with 106 IETF protocols has shown that extensibility of protocols without 107 early IETF review can cause problems. [PROT-EXT] also recommends that 108 major extensions to, or variations of, IETF protocols only take place 109 through normal IETF processes or in coordination with the IETF. 111 This document recognizes that the Multiprotocol Label Switching 112 (MPLS) and Generalized MPLS (GMPLS) protocol families were created 113 within the IETF and constitute significant protocol suites that are 114 strategic to the development of the Internet. These protocols should 115 not be extended or varied without IETF review, and they should 116 only be extended within the IETF process. 118 The process described in this document allows individuals, IETF 119 working groups, and external standards bodies to influence the 120 development of MPLS and GMPLS protocols and related standards. The 121 process means that MPLS and GMPLS extensions and changes can only be 122 done through or in coordination with the IETF. In particular, the 123 MPLS and/or CCAMP working groups or their successors need to be 124 involved in the process. When possible, existing liaison 125 relationships ([RFC4052], [RFC4053]) are leveraged. The IETF's formal 126 standards process is defined in [RFC2026] and [RFC2418], and is not 127 changed by this document. 129 The IETF will not endorse the publication of any MPLS or GMPLS 130 protocol or technology extensions in RFCs or other documents where 131 the process described here has not been followed. If publication of 132 individual Internet-Drafts describing extensions or changes to the 133 MPLS or GMPLS protocols is requested of the RFC Editor the documents 134 will be returned to the process described in this document using the 135 mechanism described in [RFC3932]. 137 IANA is responsible for managing many codepoints registries including 138 those for MPLS and GMPLS protocols. These registries have specific 139 allocation policies that IANA uses in order to determine whether 140 codepoints can be allocated and which codepoints to allocate. In many 141 cases, the rules require IANA to refer back to the IETF when asked to 142 make an allocation. In the case of changes or extensions to the MPLS 143 or GMPLS protocols, IANA will use its normal documented procedures to 144 judge whether or not a code point allocation should be made. 146 The MPLS and GMPLS technology is developed in two main tracks in the 147 IETF. "MPLS" refers to the work done for packet switched networks, 148 while "GMPLS" refers to the efforts to apply the MPLS protocols to 149 all types of networks including packet and non-packet technologies. 151 Though GMPLS by definition is a superset of MPLS, the term "(G)MPLS" 152 is used in this document to indicate both of these tracks. A 153 terminology section that covers the use of terms and concepts used in 154 this document is found in Section 2.6. 156 1.1 Document Source 158 This document is the joint work of the IETF Routing Area Directors, 159 the IETF MPLS and CCAMP Working Group Chairs, and the IETF's liaison 160 to the ITU-T. It has had considerable review and comment from key 161 members of the ITU-T who have given their time and opinions based on 162 experience for which the authors are grateful. The acknowledgements 163 section lists those whose contributions have been particularly 164 helpful. 166 1.2 Conventions Used in this Document 168 Although this document is not a protocol definition, the key words 169 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 170 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 171 are to be interpreted as described in RFC 2119 [RFC2119]. This usage 172 is chosen to make the steps and procedures completely clear. 174 2. Applicability of the (G)MPLS Change Process 176 This section outlines the applicability of the (G)MPLS change process 177 specified in this document. It lists the key IETF working groups 178 developing the (G)MPLS technology, examples of IETF working groups 179 using the (G)MPLS technology, and possible parties interested in 180 using, extending, or changing the (G)MPLS technology. 182 It should be remembered that the IETF environment is highly dynamic. 183 Working groups and whole areas come and go. The overview of the 184 relevant working groups within the IETF is only a snapshot in time. 186 A section listing terminology local to this document that will be 187 used in specifying the change process is also included. 189 2.1 IETF Working Groups Developing (G)MPLS Technology 191 Two working groups in the IETF's Routing Area have been responsible 192 for work to develop the (G)MPLS technology. The Multiprotocol Label 193 Switching (MPLS) working group and the Common Control and Measurement 194 Plane (CCAMP) working group. 196 The sections below give brief overviews of the work these two IETF 197 working groups were chartered to do. 199 The IETF may, in the future, define additional working groups to work 200 on specific chartered issues related to (G)MPLS. Further, specific 201 existing working groups such as those listed in section 2.2 may be 202 rechartered by the IESG to work on particular aspects of the (G)MPLS 203 protocols. The procedure for chartering new or existing working 204 groups to undertake (G)MPLS work is covered in section 4.2.3. 206 2.1.1 Multiprotocol Label Switching Working Group 208 The Multiprotocol Label Switching (MPLS) working group is responsible 209 for standardizing the base technology that uses label switching, and 210 for describing the implementation of Label Switched Paths (LSPs) over 211 various packet and frame-based link level technologies. The working 212 group charter includes procedures and protocols for the distribution 213 of labels between routers, as well as encapsulations, operation and 214 management, traffic engineering, and multicast considerations. 216 The procedures in this document assume that the MPLS working group 217 remains the authority on MPLS technologies, but acknowledges that 218 the IETF may appoint another working group (using the procedures in 219 this document) to handle specific extensions or changes to the 220 protocols. Further, in the event that the MPLS working group 221 completes its work and is closed, the IETF may appoint a Designated 222 Expert (sometimes known as a Caretaker) for the MPLS protocols. 224 2.1.2 Common Control & Measurement Plane Working Group 226 The IETF Common Control and Measurement Plane (CCAMP) working group 227 coordinates the work within the IETF defining common control and 228 measurement planes for ISP and SP core tunneling technologies. This 229 includes, but is not limited to, defining signaling protocols and 230 measurement protocols such that they support multiple physical path 231 and tunnel technologies using input from technology-specific working 232 groups such as the MPLS working group. It also includes the 233 development of protocol-independent metrics and parameters for 234 describing links and paths that can be carried in protocols. 236 The technology that the CCAMP working group focuses on is called 237 Generalized MPLS (GMPLS), indicating that CCAMP addresses a 238 generalized technology, where labels are defined in such a way that 239 they will be compatible with the technology over which the data is 240 transported. While the MPLS working group focuses on packet- and 241 frame-switched technologies, the CCAMP working group work focuses on 242 common methods across a broad spectrum of switching technologies 243 including packet and frame technologies. In this respect, GMPLS can 244 be viewed as a superset of MPLS. 246 The procedures in this document assume that the CCAMP working group 247 remains the authority on GMPLS technologies, but acknowledges that 248 the IETF may appoint another working group (using the procedures in 249 this document) to handle specific extensions or changes to the 250 protocols. Further, in the event that the CCAMP working group 251 completes its work and is closed, the IETF may appoint a Designated 252 Expert (sometimes known as a Caretaker) for the GMPLS protocols. 254 2.1.3 MPLS and CCAMP Division of Work 256 From time to time the MPLS and CCAMP working groups decide to divide 257 work between themselves in a way that does not strictly follow the 258 split between the working groups as defined in the working group 259 charters. This is the case, e.g., for P2MP TE LSPs, where the MPLS 260 working group is specifying requirements and base technology for all 261 of the (G)MPLS technology. 263 An entity or individual that wishes to propose extensions or changes 264 to (G)MPLS should first decide to which working group (MPLS or CCAMP) 265 it will bring the proposal. However, the MPLS and CCAMP working group 266 chairs, in conjunction with their Area Directors, may redirect the 267 proposal to another working group. 269 2.2 Other (G)MPLS Technology Working Groups 271 Problem statements and requirements for (G)MPLS technology have been 272 produced by several working groups in addition to the MPLS and CCAMP 273 working groups; for example, the IP over Optical (IPO) working group 274 and the Internet Traffic Engineering working group (TEWG). These 275 working groups have not specified any protocols, but have been a 276 source of problem statements and requirements to be considered by the 277 (G)MPLS working groups. 279 Other working groups, e.g., the Bidirectional Forwarding Detection 280 (BFD) working group, also use the (G)MPLS protocols and mechanisms. 281 When any of these working groups needs to extend or change the 282 (G)MPLS protocols the procedures specified in this document are 283 applicable. Some of those working groups (again, for example, the 284 BFD working group) are already chartered for requirements evaluation 285 and protocol specification, and can fit into the procedures in those 286 roles. 288 The Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) working groups have 289 been chartered to specify a limited number of solutions for Provider 290 Provisioned VPNs. Both working groups are in the Internet Area. The 291 work of the L2VPN and L3VPN working groups does not include 292 specifying new protocols, however, protocol changes and extensions 293 to the (G)MPLS protocols may be needed. If so, the procedures 294 specified in this document are applicable. 296 The Layer 1 VPN (L1VPN) working group is chartered to specify 297 mechanisms necessary for providing layer 1 VPN services 298 (establishment of layer 1 connections between CE devices) over a 299 GMPLS-enabled transport service-provider network. Protocol extensions 300 required for L1VPN will be done in cooperation with MPLS, CCAMP, 301 OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. That is, the 302 L1VPN working group will not develop GMPLS protocol extensions in 303 isolation, but will develop requirements and propose extensions that 304 will be reviewed and approved by the (G)MPLS working groups. 306 The Pseudo Wire Emulation End to End (PWE3) working group is another 307 working group in the Internet Area that also uses the (G)MPLS 308 protocols in its specifications. Should the PWE3 specifications 309 require extension or changes to the (G)MPLS protocols the procedures 310 specified in this document are applicable. 312 It is assumed that the change process for the MPLS and CCAMP working 313 groups, specified in this document, will be applicable or at least 314 adaptable to other (G)MPLS technology working groups if such a need 315 should arise. 317 2.3 Organizations Outside the IETF 319 A number of standards development organizations (SDOs) and industrial 320 forums use or reference the (G)MPLS protocols in their 321 specifications. Some of these organizations have formal or informal 322 liaison relationships with the IETF [RFC4052]. The IETF exchanges 323 information with these organizations about what is happening on both 324 sides, including plans and schedules, using liaison statements 325 [RFC4053]. More details about the cooperation relationship between 326 the IETF and the ITU-T can be found in [RFC3356]. 328 The procedures in this document are applicable to all organizations 329 outside the IETF whether or not they have formal liaison 330 relationships with the IETF. If any organization outside the IETF 331 has a requirement for extensions or modifications to the (G)MPLS 332 protocols then the procedures in this document apply. 334 It should be noted that the first stage in the change process is an 335 optional Preliminary Investigation (see Section 4.2.1). This stage is 336 explicitly included to allow external organizations to discuss 337 requirements and proposed uses of the (G)MPLS technologies without 338 the need to first develop Internet-Drafts, and builds on existing 339 liaison processes where they exist. It is recognized that it is in 340 the interests of all concerned to begin discussions as early as 341 possible. 343 2.4 Terminology 345 This section defines terms for use in the context of this document. 347 o (G)MPLS protocols 348 The (G)MPLS protocols are the protocols and protocol variants 349 developed by the IETF to control, manage, or measure MPLS or GMPLS 350 networks and their component devices. 352 The set of RFCs that constitutes the (G)MPLS protocols are the 353 standards track RFCs from the (G)MPLS working groups (see below). 355 A list of these RFCs is not supplied here since new RFCs are 356 produced from time to time. 358 For the purpose of extending and changing any protocols specified 359 in any specification developed by the (G)MPLS working groups, 360 those protocols are considered to be part of the (G)MPLS 361 protocols. 363 o (G)MPLS working groups 364 The (G)MPLS working groups are the MPLS and the CCAMP working 365 groups, and any future working group specifically chartered by the 366 IESG to work on the development or extension of the (G)MPLS 367 protocols. 369 o (G)MPLS technology working group 370 Any working group chartered by the IESG to specify requirements 371 for the (G)MPLS protocols, and any working group that specifies a 372 use for the (G)MPLS protocols. This also includes the (G)MPLS 373 working groups. 375 o Requirement evaluating working group (REWG) 376 The REWG is the IETF working group charged with the task of 377 evaluating a specific set of requirements and the associated 378 problem statement. 380 o Preliminary Investigation 381 An optional preliminary phase that may be used to exchange views 382 on a proposed requirement and usage of the (G)MPLS technologies 383 without going to the effort of writing an Internet-Draft. This 384 phase may be particularly useful to SDOs that have already 385 invested heavily in documenting a problem statement, or may be 386 used by anyone who wishes to hold discussions on the use of 387 (G)MPLS. 389 o Protocol specifying working group (PSWG) 390 The PSWG is the working group chartered by the IESG to specify 391 changes or extensions to the (G)MPLS protocols either as part of 392 the normal IETF process or in response to a requirements draft. 394 o Problem statement Internet-Draft 395 The Internet-Draft that initiates the discussion on changing or 396 extending the (G)MPLS protocols. This draft includes a detailed 397 problem description that (G)MPLS is called on to solve. The 398 problem statement draft may also include the requirements (see 399 requirements statement Internet-Draft, below). 401 o Requirements statement Internet-Draft 402 This Internet-Draft provides a detailed list of the abstract 403 functional requirements that the (G)MPLS extensions or changes 404 need to fulfill. These requirements should not constrain the 405 solution, but should provide all of the information necessary to 406 develop a satisfactory solution. This draft may be merged with the 407 problem statement draft (see above). 409 o Solutions Internet-Draft 410 A specification of extensions or changes to the (G)MPLS protocols 411 to meet the requirements in the requirement statement 412 Internet-Draft. 414 3. Summary of Procedures 416 This non-normative section is intended to provide a high-level view 417 of the procedures in this document to illustrate how they work and to 418 introduce the mechanisms that are defined in detail in Section 4. 420 Whenever there is reason to believe that a particular problem may be 421 solved by use of or extensions to the (G)MPLS protocols, a 422 preliminary investigation phase may be used to discuss the 423 requirements with the IETF. This may lead to an understanding that 424 the problem is already solved, is outside the scope of the IETF, or 425 requires more investigation possibly leading to changes to the 426 (G)MPLS protocols. 428 Whenever any extension or change to the (G)MPLS protocols is desired, 429 a problem statement and/or requirements statement must be produced 430 and must be submitted to IETF as an Internet-Draft. As described in 431 [RFC4052], when the requirements come from an external organization 432 informal communications such as e-mail to working group mailing lists 433 often facilitates cooperative work. However, if desired, the 434 Internet-Draft containing the requirement may be submitted to the 435 working group using a liaison statement. That way, the IETF's 436 response to the request will be given as the reply to the liaison, 437 with no risk of confusing an individual participant's opinion for 438 that of the group as can happen on mailing lists. 440 The IETF, through the Routing Area Directors and the chairs of the 441 MPLS and CCAMP working groups, will direct the requirements draft to 442 an appropriate working group for assessment and comment. This process 443 may require communication and discussion for clarification, but the 444 IETF undertakes to perform the assessment in a timely manner. 446 In assessing the requirements statement I-D, the IETF may determine: 447 - that the requirements can be satisfied without modifications to the 448 (G)MPLS protocols 449 - that the requirements are not sufficiently general to warrant a 450 change to the (G)MPLS protocols 452 - that the requirements justify a change to the (G)MPLS protocols 453 that will be created by the IETF or within another organization 454 - that the requirements might not be possible to satisfy without 455 violating the (G)MPLS architecture in a way that would harm the 456 (G)MPLS technology 457 - that the requirements should be combined with other requirements 458 to solve a more general problem or solve the same problem in a more 459 flexible way. 461 In the event that the IETF agrees to develop a solution, the IETF 462 will set milestones that would result in timely delivery of the 463 solution in a timely manner. If the IETF rejects the requirements, 464 this will only be done with clear explanation and full 465 discussion with the source of the requirements. 467 The solutions that are developed within the IETF may be sourced from 468 external organizations and presented for review, discussion, 469 modification, and adoption as Internet-Drafts. Such solutions drafts 470 may be presented to the IETF in advance of the completion of the 471 requirements work, but all solutions will compete through the normal 472 IETF process with other proposed solutions, and none will be adopted 473 as an IETF working group draft until the requirements are agreed by 474 the REWG chairs to be stable and, in any case, not before the PSWG 475 has a charter item to cover the solutions work. 477 4. MPLS and GMPLS Change Process 479 This section defines the (G)MPLS change process and the rules that 480 must be followed in order to make extensions or changes to the 481 (G)MPLS protocols. The language of [RFC2119] is used in order to 482 clarify the precise required behavior. 484 Anyone who intends to use one of the existing (G)MPLS protocols, but 485 thinks that it will not satisfy their needs MUST use the procedures 486 described in this document. Changes or extensions to the (G)MPLS 487 protocols MUST NOT be made by any other mechanism. The IETF MUST NOT 488 endorse any publications (including RFCs whether on the Standards 489 Track, Informational, or Experimental) that change or extended the 490 (G)MPLS protocols except for those that arise through the correct 491 execution of the procedures in this document. The IETF MUST NOT 492 endorse any IANA action that allocates (G)MPLS protocol codepoints 493 except as a result of actions arising from the correct execution of 494 the procedures in this document. 496 4.1 Flow Diagram 498 Figure 1 is presented to give a visual overview of the process. It 499 does not contain all of the possible interactions of procedures, and 500 the text in the subsequent sections should be used for a definitive 501 description of the process. 503 Start +-------------+ 504 | |optional | 505 +--<--------------------|preliminary |<-------Start 506 | |investigation| 507 V +-------------+ 508 +------------+ +---------+ +---------+ 509 |requirements| discussion |review by| YES | IESG/ | YES 510 |statement |----------->|WG chairs|------------->| IAB |------+ 511 |I-D | on mailing |and ADs | request to |decision | | 512 +------------+ list +---------+ IESG/IAB to +---------+ | 513 | appoint REWG | | 514 |NO and charter |NO REWG| 515 V req eval | chartered| 516 +-------------+ | to work on| 517 |response | | requirements| 518 |to the | | statement| 519 |requirements |<-----------------+ | 520 +->|statement |<----------------+ | 521 | +-------------+ | | 522 | ^ | | 523 NO| | NO | | 524 | +-----------------+ | V 525 | | | NO +------+ 526 +--------+ +-------+ +--------| REWG | 527 | IESG/ | YES | AD | | req | 528 +-----------| IAB |<---------------|review |<------------| eval | 529 |WG |decision| request to | | YES | | 530 |chartered +--------+ IESG/IAB to +-------+ +------+ 531 |to work approve I-D 532 | and charter 533 | 534 | +---------+ 535 | | IETF | +-----+ 536 +--------->| WG |-----/ /---->| RFC | 537 +---->| process | +-----+ 538 | +---------+ 539 solutions 540 I-D 542 Figure 1: Change Process Overview 544 4.2 Description of Process Stages 546 This section describes how the (G)MPLS change process works, what is 547 expected from individuals or organizations that want to extend or 548 change the (G)MPLS protocols, and the responsibilities of the (G)MPLS 549 working groups, the Routing Area and the IETF in general. 551 4.2.1 Preliminary Investigation 553 This step is OPTIONAL, and is intended to provide a lightweight way 554 to "feel out" the IETF's position on a proposal without going to the 555 effort of writing an Internet-Draft. The intention is to determine 556 whether the problem has been examined already, whether the problem is 557 in scope for the IETF, and whether solutions are already known. 559 Although the preliminary investigation phase is optional it is 560 RECOMMENDED that the originator of any requirements consult and 561 discuss the issues concerned as early as possible to avoid any wasted 562 effort, and the preliminary investigation phase provides a mechanism 563 to do this. 565 Useful discussions may be held at this stage in order to ensure that 566 the problem statement and requirements statement Internet-Drafts 567 contain the right material. This step is described as lightweight 568 because no Internet-Draft is required and because the step largely 569 involves offline discussions. However, it may be the case that this 570 step involves considerable technical discussions and may, in fact, 571 involve an extensive, substantive exchange of ideas and opinions. 573 This step SHOULD be carried out informally on the mailing list of the 574 REWG or on the Routing Area discussion mailing list and MAY be 575 initiated by any individual, group of individuals, external 576 organization, or IETF working group. 578 When an external SDO has a liaison relationship with the IETF, it 579 MAY carry out this step using a formal liaison. The liaison SHOULD be 580 sent to the REWG or to the Routing Area, and the initiators of the 581 liaison SHOULD make themselves available for discussion on the 582 selected mailing list. If a formal liaison is used, the IETF MUST 583 respond to pursue the discussion. 585 At this stage, a problem statement I-D MAY be produced to help 586 further the discussions and to clarify the issues being addressed. 588 A possible outcome of this preliminary investigation is that the 589 requirements and problem are understood, but agreed to be out of 590 scope for the IETF. Alternatively it may be that the problem can be 591 solved with existing protocols. The full list of outcomes from the 592 preliminary investigation phase are identical to those for the 593 requirements statement evaluation phase described in section 4.2.2, 594 but the requirements statement evaluation phase MUST form part of the 595 process if the requirements are understood and the IETF would like to 596 develop protocol solutions - the process cannot move direct from the 597 preliminary investigation phase to the development of solutions. 599 4.2.2 Requirements Statement Evaluation 601 Before the IETF can formally pronounce on requirements to change or 602 extend the (G)MPLS protocols, a requirements statement I-D MUST be 603 written and submitted to the IETF for publication. 605 The requirements statement I-D MUST be introduced to the IETF through 606 an email to the REWG mailing list or to the Routing Area discussion 607 mailing list, or by a formal liaison from an external SDO which will 608 result in the IETF introducing the requirements statement I-D to the 609 REWG mailing list. If the requirements statement I-D is brought to 610 the IETF through a formal liaison, the initiators of the liaison 611 SHOULD make themselves available for discussion on the appropriate 612 mailing lists. 614 After discussion on the IETF mailing lists, the appropriate IETF 615 working group chairs and the Routing Area Directors MUST decide 616 whether the requirements will be formally evaluated by the IETF, and 617 MUST deliver a response to the requirements statement I-D. 619 If the requirements statement I-D is brought to the IETF through a 620 formal liaison, the working group chairs, ADs or their delegates MUST 621 respond using one of the following answers in a formal liaison reply. 622 If a formal liaison was not used the response SHOULD be delivered 623 using one of the following answers in an email copied to the 624 appropriate mailing lists. 626 a. Requirements not understood. Further discussion required. 628 b. Requirements understood, but judged to be out of scope for the 629 IETF. In this case, the originator of the requirements can work 630 on requirements and solutions and will not be impeded by the 631 IETF. The IETF may request to be kept informed of progress. 633 c. Requirements understood, but no protocol extensions are needed. 634 It may be desirable for the external SDO to cooperate with the 635 appropriate working group in the production of an Applicability 636 Statement Internet-Draft. 638 d. Requirements understood, and the IETF would like to develop 639 protocol extensions. This results in execution of the rest of the 640 procedure, described below. The requirements raised in the 641 requirements statement I-D may be combined with other 642 requirements to produce more general extensions or changes to the 643 (G)MPLS protocols. 645 4.2.3 Chartering or Rechartering the REWG 647 In many cases the problem covered by the requirements statement I-D 648 will fall within the scope of the existing charter of a working 649 group. In this case, the Routing Area Directors SHOULD designate the 650 working group as the REWG and pass the requirements statement I-D to 651 the working group for evaluation. 653 If a new charter item is required for an existing working group, the 654 Routing Area Directors with assistance from working group chairs MUST 655 apply to the IESG and IAB for a modification of an existing working 656 group's charter or for the creation of a new working group. If the 657 IESG approves the charter, the requirements statement I-D is passed 658 to the REWG for evaluation. If the charter change is not approved, 659 the IESG MUST respond to the requirements statement I-D and, if the 660 requirements were introduced through a formal liaison from another 661 SDO, the IESG MUST send a liaison response using the options 662 described in Section 5, although the IESG MAY delegate such 663 responses. 665 Under unusual circumstances the Routing Area Directors MAY decide to 666 charter a new working group to act as the REWG. In this case, the ADs 667 are responsible for drafting the charter of the new working group and 668 MUST follow the procedures set out in the previous paragraph. 670 4.2.4 REWG Evaluation of the Requirements Statement I-D 672 The objective of the REWG evaluation process is to determine a clear 673 and complete statement of the requirements for changes or extensions 674 to the (G)MPLS protocols. This will necessitate normal IETF working 675 group procedures in the REWG and MAY include the generation of 676 revisions of the requirements statement I-D in cooperation between 677 the members of the REWG and the original authors of the requirements 678 statement I-D. 680 The originators of the requirements statement I-D MUST make 681 themselves available to discuss the work on the REWG mailing list. 682 If this does not happen, the chairs of the REWG MAY determine that 683 there is insufficient support for the work and MAY reject the 684 requirements statement I-D. 686 The output of the REWG MUST be either: 688 - a completed requirements statement I-D that has been accepted by 689 working group consensus within the REWG and has passed through 690 working group last call; 691 or: 692 - a rejection of the requirements following exactly the same format 693 and procedure as described in Section 5. 695 4.2.5 AD Evaluation of Completed Requirements Statement I-D 697 As with all Internet-Drafts produced by a working group, the ADs MUST 698 review the completed requirements statement I-D produced by the REWG 699 to determine its fitness for publication. At their discretion, the 700 ADs MAY use an Area Directorate and/or other subject matter experts 701 to assist them in this review. 703 The result of the AD review MAY request the REWG to do further work 704 on the I-D in which case the previous step and this one will be 705 repeated. 707 The ADs SHOULD NOT reject the requirements statement I-D outright at 708 this stage since the requirements have already been accepted by the 709 ADs at an earlier stage. However, in some situations (such as a 710 significant change in related circumstances) the ADs MAY reject the 711 requirements statement I-D using the format and procedure described 712 in Section 5. 714 When the ADs accept the requirements statement I-D they MUST pass it 715 to the IESG for review, and propose any charter changes necessary to 716 select a PSWG. 718 4.2.6 IESG review of Requirements Statement I-D and PSWG Charter 720 As with all Internet-Drafts, the IESG MUST take a ballot on the 721 progression of the requirements statement I-D. 723 If the IESG rejects the requirements statement I-D, it MUST generate 724 a response to the requirements as described in Section 5. 726 The IESG MUST take a ballot on any proposed charter changes for the 727 PSWG. This MAY include the formation of a new working group 728 specifically to work on the solutions, although it is also possible 729 that the solutions work is covered by an existing working group 730 charter without any changes. 732 If the IESG rejects working group charter changes such that it is not 733 possible for the IETF to work on solutions for the requirements in 734 the requirements statement I-D, this MUST be treated as a rejection 735 of the requirements statement I-D, and the requirements statement I-D 736 MUST NOT be published as an RFC. In this case the IESG MUST reject 737 the requirements statement I-D using the format and procedure 738 described in Section 5. 740 4.2.7 Solutions Work 742 Once the requirements statement I-D has been approved by the IESG it 743 will enter the RFC Editor's queue and be handled according to normal 744 IETF process. 746 Once the PSWG has been identified and (re-)chartered as necessary and 747 the requirements statement I-D has been approved by the IESG, the 748 PSWG can start work on solutions following the normal IETF process. 750 Solutions I-Ds MAY be prepared externally (such as within an external 751 organization) or within the IETF, submitted to the IETF for 752 publication, and introduced to the PSWG for consideration. Such I-Ds 753 MAY be submitted at earlier stages in the process to assist the REWG 754 in its development and discussion of the requirements, but no I-D 755 will be formally considered as a solutions I-Ds until the PSWG has a 756 charter item that covers the work and the REWG chairs are confident 757 that the requirements are stable. Even at this stage in the process, 758 the IETF makes no guarantees that an externally produced solutions 759 I-D will form the basis of the PSWG solutions I-D, but the PSWG MUST 760 consider such an I-D for review and revision as a possible solution 761 I-D. 763 The final development of the solutions I-D is subject to the normal 764 working group review, consensus, and last call within the PSWG. 766 Where the requirements originated from an external organization, the 767 PSWG SHOULD regularly communicate its progress using a formal liaison 768 process if one exists. This communication SHOULD also be used to 769 request review input and comment on the development of the solutions 770 I-D. The solutions I-D MUST be communicated to the originating 771 organization during working group last call for final review against 772 the requirements. When the solutions I-D is complete (normally upon 773 completing working group last call and/or on entering the RFC 774 Editor's queue) the PSWG MUST inform the originating organization of 775 the completed solution. 777 5. Rejecting Requirements Statements I-D 779 Rejection of the requirements statements is a sensitive matter for 780 the authors of the requirements and MUST be handled with full 781 disclosure and explanation by the IETF. 783 The requirements can be rejected at various stages of the process as 784 described in the previous sections. The person or group that makes 785 the rejection is responsible for generating an explanation of the 786 rejection and MUST follow the process described in this section. 788 5.1 Reasons for Rejection 790 The requirements statement I-D can only be rejected using one of the 791 following reasons. Each reason MUST be stated with the acceptable 792 next steps as described here. 794 - Requirements not understood. Either during preliminary 795 investigation or during evaluation of the requirements statement 796 I-D, it wasn't clear what the requirements are, or what the problem 797 being addressed is. 799 This rejection forms part of an on-going communication and it is 800 expected that the process will continue with further iterations. 802 - Out of scope for the IETF. Many stages of this process may 803 determine that the requirements are out of scope for the IETF. In 804 this case, the IETF MUST NOT constrain the authors of the 805 requirements statement I-D from working on a solution. 807 - No protocols extensions or changes are needed. At some stage in the 808 evaluation of the requirements it may become clear that they can 809 all be met through appropriate use of existing protocols. In this 810 case no further evaluation of the requirements is required, but the 811 REWG MUST explain how the protocols can be used to meet the 812 requirements and MAY cooperate with the authors of the requirements 813 statement I-D in the production of an Applicability Statement 814 Internet-Draft or a Profiles Internet-Draft that explains precisely 815 how the existing protocols can be used to meet the requirements. 817 - Insufficient support within the IETF. Although the work described 818 within the requirements statement I-D is within scope for the IETF, 819 and despite the support of the originators of the requirements 820 statement I-D on the REWG mailing list, the chairs of the REWG have 821 determined that there is insufficient support in the REWG to 822 complete requirements statement I-D. In this case, the IETF MUST 823 NOT restrict the authors of the requirements statement I-D from 824 working on a solution. The solution SHALL be presented to the IETF 825 for review and possible publication as an Informational or 826 Experimental RFC, and the IETF SHALL NOT block applications to IANA 827 for codepoints. 829 - Insufficient support for the work from the original requesters. If 830 the authors of the requirements statement I-D do not make 831 themselves available on the REWG mailing list for discussion of the 832 requirements or do not contribute the completion of the 833 requirements statement I-D, the chairs of the REWG MAY determine 834 that there is insufficient support for the work and MAY reject the 835 requirements statement I-D. In this case, the IETF MUST NOT grant 836 permission for the work to be carried out in any other 837 organization, and MUST NOT endorse the publication of any changes 838 or extensions to the (G)MPLS protocols and MUST NOT instruct IANA 839 to allocate any codepoints. The requirements may be re-introduced 840 by starting the procedure again from the top. 842 - Satisfying the requirements would break the technology. It is 843 possible that an assessment will be made that, although the 844 requirements are reasonable, it is not possible to satisfy them 845 through extensions or changes to the (G)MPLS protocols without 846 violating the (G)MPLS architecture in such a way as would break the 847 (G)MPLS technology. In this case a recommendation will be made that 848 some other technology be used to satisfy the requirements. See 849 Section 7 for further discussions of the protection of the 850 integrity of the (G)MPLS technology. 852 5.2 Actions Required When Rejecting Requirements Statement I-Ds 854 Upon rejection, the IETF MUST make a clear statement of why the 855 requirements statement I-D has been rejected and what next step 856 actions are acceptable. The reasons MUST be based on the list in 857 Section 5.1. 859 The form of the rejection depends on the form of the original 860 submission as follows. 862 - If the requirements are brought to the IETF as a preliminary 863 investigation (see Section 4.2.1) through an email exchange then 864 the response MUST be made as an email response copied to an IETF 865 mailing list so that it is automatically archived. 867 - If the requirements are brought to the IETF as a preliminary 868 investigation (see Section 4.2.1) through a formal liaison, the 869 rejection MUST be delivered through a formal liaison response. 871 - If a requirements statement I-D has been produced and discussed on 872 an IETF email list, the response MUST be made as an email response 873 and copied to the email list. 875 - If a requirements statement I-D has been produced and brought to 876 the IETF through a formal liaison, the rejection MUST be 877 delivered through a formal liaison response. 879 - If an IETF working group has been involved in the review or 880 production of any Internet-Drafts for the requirements or for the 881 solutions, the working group MUST be notified of the rejection and 882 the reasons. 884 The responsibility for the generation of the response lies with the 885 person, people, or group that instigates the rejection. This may 886 be the IESG, one or more Area Directors, one or more working group 887 chairs, or a protocol caretaker. In the case of the use of a liaison 888 relationship, the IETF's liaison manager has responsibility for 889 ensuring that the procedures in this document, and particularly the 890 rejection procedures, are followed. 892 5.3 Appeals 894 The rejection of a requirements statement I-D as described in 895 Sections 5.1 and 5.2 may be appealed in the event it is considered to 896 be deeply incorrect and cannot be reversed by direct discussion 897 between the parties. The conflict resolution and appeal mechanism is 898 documented in [RFC2026]. 900 6. Abandonment of the Solutions I-D 902 Once the solutions work has been started by the PSWG, it may be 903 abandoned before completion. This can happen if the PSWG chairs 904 determine that there is no longer working group support for doing the 905 work. This could arise, for example, if no-one (including the 906 originators of the requirements statement I-D) is willing to 907 contribute to the development of a solutions I-D. 909 In the event that the solutions work is abandoned by the PSWG, the 910 Area Directors responsible for the PSWG MUST be consulted. The 911 originators of the requirements statement I-D MUST be informed that 912 the work has been abandoned using a mechanism dependent on how the 913 requirements were introduced (as discussed in Section 5.2). 915 If the solution is abandoned in this way, work on solutions for the 916 requirements MUST NOT be started in another forum. The status of 917 extensions and changes to the (G)MPLS protocols with regard to the 918 specific requirements returns to how it was before the process 919 started. Any new examination of the requirements MUST commence at 920 the top of the process. 922 6.1 Appeals 924 The abandonment of a solutions I-D may be appealed in the event it is 925 considered to be deeply incorrect and cannot be reversed by direct 926 discussion between the parties. The conflict resolution and appeal 927 mechanism is documented in [RFC2026]. 929 7. (G)MPLS Integrity 931 The (G)MPLS working groups are REQUIRED to protect the architectural 932 integrity of the (G)MPLS protocols and MUST NOT extend the GMPLS 933 architecture with features that do not have general use beyond the 934 specific case. They also MUST NOT modify the architecture just to 935 make some function more efficient at the expense of simplicity or 936 generality. 938 The architectural implications of additions or changes to the (G)MPLS 939 protocols MUST be consider interoperability with existing and future 940 versions of the protocols. The effects of adding features that 941 overlap or that deal with a point solution and are not general are 942 much harder to control with rules. Therefore the (G)MPLS technology 943 calls for this architectural guardianship by its working groups. 945 8. Security Considerations 947 All requirements statement I-Ds MUST give full consideration to the 948 security impact of the proposed additional features or functions. All 949 solutions I-Ds MUST consider the impact on the security of the 950 protocol extensions and to the pre-existing protocol. 952 This documents does not itself introduce any security issues for any 953 (G)MPLS protocols. 955 The IETF process is itself at risk from denial of service attacks. 956 This document utilizes the IETF process and adds details to that 957 process. It is possible, therefore, that this document might put the 958 IETF process at risk. Although this document places additional 959 requirements on key individuals within the IETF, those requirements 960 are not substantial for any individual requirements statement I-D 961 since the responsibility for the majority of the work lies with the 962 REWG and PSWG with an underlying assumption that the authors of the 963 requirements statement I-D will participate in the working group 964 process. 966 Therefore, provided that the number of requirements statement I-Ds is 967 not unreasonable, there will be no significant impact on the IETF 968 process. The rate of arrival of requirements statement I-Ds MAY be 969 used by the IESG to detect denial of service attacks, and the IESG 970 SHOULD act on such an event depending on the source of the 971 requirements statement I-D and the perceived relevance of the work. 972 The IESG might, for example, discuss the issue with the management of 973 external organizations. 975 9. Acknowledgements 977 The input given by Bert Wijnen has been useful and detailed. 979 Review feedback and discussions with various members of the ITU-T has 980 been helpful in refining the process described in this document. 981 Thanks in particular to the members of Question 14 of Study Group 15, 982 and to the management of Study Group 15. Important discussions were 983 held with the following participants in the ITU-T: Yoichi Maeda, 984 Greg Jones, Stephen Trowbridge, Malcolm Betts, Kam Lam, 985 George Newsome, Eve Varma, Lyndon Ong, Stephen Shew, Jonathan Sadler, 986 and Ben Mack-Crane. 988 Thanks for further review comments to Brian Carpenter, Stewart Bryant 989 and Dave Ward. Thanks to Spencer Dawkins for the GenArt review. 991 10. IANA Considerations 993 This document makes no specific requests to IANA for action. The 994 procedures described in this document assume that IANA will adhere to 995 the allocation policies defined for the (G)MPLS codepoint registries 996 and that the IETF will not endorse allocation of codepoints from 997 those registries except where work has been carried out in accordance 998 with the procedures described in this document. 1000 11. References 1002 11.1 Normative References 1004 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1005 3", BCP 9, RFC 2026, October 1996. 1007 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1008 Requirement Levels", BCP 14, RFC 2119, March 1997. 1010 [RFC2418] Bradner, S., "IETF Working Group - Guidelines and 1011 Procedures", BCP 25, RFC 2418, September 1998. 1013 [RFC4052] Daigle, L., "IAB Processes for Management of IETF Liaison 1014 Relationships", BCP 102, RFC 4052, April 2005. 1016 [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 1017 Handling Liaison Statements to and from the IETF", 1018 BCP 103, RFC4053, April 2005. 1020 [PROT-EXT] Bradner, S., and Carpenter, B., "Procedures for protocol 1021 extensions and variations", draft-carpenter-protocol- 1022 extensions, work in progress. 1024 11.2 Informative References 1026 [RFC3356] Fishman, G. and S. Bradner, "Internet Engineering Task 1027 Force and International Telecommunication Union - 1028 Telecommunications Standardization Sector Collaboration 1029 Guidelines", RFC 3356, August 2002. 1031 [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: 1032 Procedures", BCP 92, RFC 3932, October 2004. 1034 Editor' Addresses 1036 Loa Andersson 1037 Acreo AB 1038 Email: loa@pi.se 1040 Adrian Farrel 1041 Old Dog Consulting 1042 Email: adrian@olddog.co.uk 1044 Authors' Addresses 1046 George Swallow 1047 Cisco Systems 1048 Email: swallow@cisco.com 1050 Deborah Brungard 1051 AT&T 1052 Email: dbrungard@att.com 1054 Bill Fenner 1055 AT&T 1056 Email: fenner@research.att.com 1058 Ross Callon 1059 Juniper Networks 1060 Email: rcallon@juniper.net 1062 Kireeti Kompella 1063 Juniper Networks 1064 Email: Kireeti@juniper.net 1066 Alex Zinin 1067 Alcatel 1068 Email: zinin@psg.com 1070 Scott Bradner 1071 Harvard University 1072 Email: sob@harvard.edu 1074 Intellectual Property Statement 1076 The IETF takes no position regarding the validity or scope of any 1077 Intellectual Property Rights or other rights that might be claimed to 1078 pertain to the implementation or use of the technology described in 1079 this document or the extent to which any license under such rights 1080 might or might not be available; nor does it represent that it has 1081 made any independent effort to identify any such rights. Information 1082 on the procedures with respect to rights in RFC documents can be 1083 found in BCP 78 and BCP 79. 1085 Copies of IPR disclosures made to the IETF Secretariat and any 1086 assurances of licenses to be made available, or the result of an 1087 attempt made to obtain a general license or permission for the use of 1088 such proprietary rights by implementers or users of this 1089 specification can be obtained from the IETF on-line IPR repository at 1090 http://www.ietf.org/ipr. 1092 The IETF invites any interested party to bring to its attention any 1093 copyrights, patents or patent applications, or other proprietary 1094 rights that may cover technology that may be required to implement 1095 this standard. Please address the information to the IETF at 1096 ietf-ipr@ietf.org. 1098 Disclaimer of Validity 1100 This document and the information contained herein are provided on an 1101 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1102 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1103 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1104 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1105 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1106 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1108 Copyright Statement 1110 Copyright (C) The IETF Trust (2006). 1112 This document is subject to the rights, licenses and restrictions 1113 contained in BCP 78, and except as set forth therein, the authors 1114 retain all their rights.