idnits 2.17.1 draft-andersson-rtg-gmpls-change-06.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 1059. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1036. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1043. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1049. ** 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 6402 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-06 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 .......................... 13 78 4.2.3 Chartering the Rewg ........................................ 14 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. Normative References ......................................... 20 93 12. Informative References ....................................... 20 95 1. Introduction 97 [PROT-EXT] discusses procedural issues related to the extensibility 98 of IETF protocols, including when it is reasonable to extend IETF 99 protocols with little or no review, and when extensions or variations 100 need to be reviewed by the larger IETF community. Experience with 101 IETF protocols has shown that extensibility of protocols without 102 early IETF review can cause problems. [PROT-EXT] also recommends that 103 major extensions to, or variations of, IETF protocols only take place 104 through normal IETF processes or in coordination with the IETF. 106 This document recognizes that the Multiprotocol Label Switching 107 (MPLS) and Generalized MPLS (GMPLS) protocol families were created 108 within the IETF and constitute significant protocol suites that are 109 strategic to the development of the Internet. They should not be 110 extended or varied without IETF review, and that should preferably 111 only be extended within the IETF process. 113 The process described in this document allows individuals, IETF 114 working groups, and external standards bodies to influence the 115 development of MPLS and GMPLS protocols and related standards. The 116 process means that MPLS and GMPLS extensions and changes can only be 117 done through or in coordination with the IETF. In particular, the 118 MPLS and/or CCAMP working groups or their successors need to be 119 involved in the process. When possible, existing liaison 120 relationships ([RFC4052], [RFC4053]) are leveraged. 122 The IETF will not endorse the publication of any MPLS or GMPLS 123 protocol or technology extensions in RFCs or other documents where 124 the process described here have not been followed. If publication of 125 individual Internet-Drafts describing extensions or changes to the 126 MPLS or GMPLS protocols is requested of the RFC Editor the documents 127 will be returned to the process described in this document using the 128 mechanism described in [RFC3932]. 130 IANA is responsible for managing many codepoints registries including 131 those for MPLS and GMPLS protocols. These registries have specific 132 allocation policies that IANA uses in order to determine whether 133 codepoints can be allocated and which codepoints to allocate. In many 134 cases, the rules require IANA to refer back to the IETF when asked to 135 make an allocation. In the case of changes or extensions to the MPLS 136 or GMPLS protocols, IANA will use its normal documented procedures to 137 judge whether or not a code point allocation should be made. 139 The MPLS and GMPLS technology is developed in two main tracks in the 140 IETF. "MPLS" refers to the work done for packet switched networks, 141 while "GMPLS" refers to the efforts to apply the MPLS protocols to 142 all types of networks including packet and non-packet technologies. 143 Though GMPLS by definition is a superset of MPLS, the term "(G)MPLS" 144 is used in this document to indicate both of these tracks. A 145 terminology section that covers the use of terms and concepts used in 146 this document is found in Section 2.6. 148 1.1 Document Source 150 This document is the joint work of the IETF Routing Area Directors, 151 the IETF MPLS and CCAMP Working Group Chairs, and the IETF's liaison 152 to the ITU-T. It has had considerable review and comment from key 153 members of the ITU-T who have given their time and opinions based on 154 experience for which the authors are grateful. The acknowledgements 155 section lists those whose contributions have been particularly 156 helpful. 158 1.2 Conventions Used in this Document 160 Although this document is not a protocol definition, the key words 161 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 162 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 163 are to be interpreted as described in RFC 2119 [RFC2119]. This usage 164 is chosen to make the steps and procedures completely clear. 166 2. Applicability of the (G)MPLS Change Process 168 This section outlines the applicability of the (G)MPLS change process 169 specified in this document. It lists the key IETF working groups 170 developing the (G)MPLS technology, examples of IETF working groups 171 using the (G)MPLS technology, and possible parties interested in 172 using, extending, or changing the (G)MPLS technology. 174 It should be remembered that the IETF environment is highly dynamic. 175 Working groups and whole areas come and go. The overview of the 176 relevant working groups within the IETF is only a snapshot in time. 178 A section listing terminology local to this document that will be 179 used in specifying the change process is also included. 181 2.1 IETF Working Groups Developing (G)MPLS Technology 183 Two working groups in the IETF's Routing Area have been responsible 184 for work to develop the (G)MPLS technology. The Multiprotocol Label 185 Switching (MPLS) working group and the Common Control and Measurement 186 Plane (CCAMP) working group. 188 The sections below give brief overviews of the work these two IETF 189 working groups were chartered to do. 191 The IETF may, in the future, define additional working groups to work 192 on specific chartered issues related to (G)MPLS. Further, specific 193 existing working groups such as those listed in section 2.2 may be 194 rechartered by the IESG to work on particular aspects of the (G)MPLS 195 protocols. The procedure for chartering new or existing working 196 groups to undertake (G)MPLS work is covered in section 4.2.3. 198 2.1.1 Multiprotocol Label Switching Working Group 200 The Multiprotocol Label Switching (MPLS) working group is responsible 201 for standardizing the base technology that uses label switching, and 202 for describing the implementation of Label Switched Paths (LSPs) over 203 various packet and frame-based link level technologies. The working 204 group charter includes procedures and protocols for the distribution 205 of labels between routers, as well as encapsulations, operation and 206 management, traffic engineering, and multicast considerations. 208 The procedures in this document assume that the MPLS working group 209 remains the authority on MPLS technologies, but acknowledges that 210 the IETF may appoint another working group (using the procedures in 211 this document) to handle specific extensions or changes to the 212 protocols. Further, in the event that the MPLS working group 213 completes its work and is closed, the IETF may appoint a Designated 214 Expert (sometimes known as a Caretaker) for the MPLS protocols. 216 2.1.2 Common Control & Measurement Plane Working Group 218 The IETF Common Control and Measurement Plane (CCAMP) working group 219 coordinates the work within the IETF defining common control and 220 measurement planes for ISP and SP core tunneling technologies. This 221 includes, but is not limited to, defining signaling protocols and 222 measurement protocols such that they support multiple physical path 223 and tunnel technologies using input from technology-specific working 224 groups such as the MPLS working group. It also includes the 225 development of protocol-independent metrics and parameters for 226 describing links and paths that can be carried in protocols. 228 The technology that the CCAMP working group focuses on is called 229 Generalized MPLS (GMPLS), indicating that CCAMP addresses a 230 generalized technology, where labels are defined in such a way that 231 they will be compatible with the technology over which the data is 232 transported. While the MPLS working group focuses on packet- and 233 frame-switched technologies, the CCAMP working group work focuses on 234 common methods across a broad spectrum of switching technologies 235 including packet and frame technologies. In this respect, GMPLS can 236 be viewed as a superset of MPLS. 238 The procedures in this document assume that the CCAMP working group 239 remains the authority on GMPLS technologies, but acknowledges that 240 the IETF may appoint another working group (using the procedures in 241 this document) to handle specific extensions or changes to the 242 protocols. Further, in the event that the CCAMP working group 243 completes its work and is closed, the IETF may appoint a Designated 244 Expert (sometimes known as a Caretaker) for the GMPLS protocols. 246 2.1.3 MPLS and CCAMP Division of Work 248 From time to time the MPLS and CCAMP working groups decide to divide 249 work between themselves in a way that does not strictly follow the 250 split between the working groups as defined in the working group 251 charters. This is the case, e.g., for P2MP TE LSPs, where the MPLS 252 working group is specifying requirements and base technology for all 253 of the (G)MPLS technology. 255 An entity or individual that wishes to propose extensions or changes 256 to (G)MPLS should first decide to which working group (MPLS or CCAMP) 257 it will bring the proposal. However, the MPLS and CCAMP working group 258 chairs, in conjunction with their Area Directors, may redirect the 259 proposal to another working group. 261 2.2 Other (G)MPLS Technology Working Groups 263 Problem statements and requirements for (G)MPLS technology have been 264 produced by several working groups in addition to the MPLS and CCAMP 265 working groups. For example, the IP over Optical (IPO) working group 266 and the Internet Traffic Engineering working group (TEWG). These 267 working groups have not specified any protocols, but have been a 268 source of problem statements and requirements to be considered by the 269 (G)MPLS working groups. 271 Other working groups, e.g., the Bidirectional Forwarding Detection 272 (BFD) working group, also use the (G)MPLS protocols and mechanisms. 273 When any of these working groups needs to extend or change the 274 (G)MPLS protocols the procedures specified in this document are 275 applicable. 277 The Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) working groups have 278 been chartered to specify a limited number of solutions for Provider 279 Provisioned VPNs. Both working groups are in the Internet Area. The 280 work of the L2VPN and L3VPN working groups does not include 281 specifying new protocols, however, protocol changes and extensions 282 to the (G)MPLS protocols may be needed. If so, the procedures 283 specified in this document are applicable. 285 The Layer 1 VPN (L1VPN) working group is chartered to specify 286 mechanisms necessary for providing layer 1 VPN services 287 (establishment of layer 1 connections between CE devices) over a 288 GMPLS-enabled transport service-provider network. Protocol extensions 289 required for L1VPN will be done in cooperation with MPLS, CCAMP, 290 OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. That is, the 291 L1VPN will not develop GMPLS protocol extensions in isolation, but 292 will develop requirements and propose extensions that will be 293 reviewed and approved by the (G)MPLS working groups. 295 The Pseudo Wire Emulation End to End (PWE3) working group is another 296 working group in the Internet Area that also uses the (G)MPLS 297 protocols in its specifications. Should the PWE3 specifications 298 require extension or changes to the (G)MPLS protocols the procedures 299 specified in this document are applicable. 301 It is assumed that the change process for the MPLS and CCAMP working 302 groups, specified in this document, will be applicable or at least 303 adaptable to other (G)MPLS technology working groups if such a need 304 should arise. 306 2.3 Organizations Outside the IETF 308 A number of standards development organizations (SDOs) and industrial 309 forums use or reference the (G)MPLS protocols in their 310 specifications. Some of these organizations have formal or less 311 formal liaison relationships with the IETF [RFC4052]. The IETF 312 exchanges information with these organizations about what is 313 happening on both sides, including plans and schedules, using liaison 314 statements [RFC4053]. More details about the cooperation relationship 315 between the IETF and the ITU-T can be found in [RFC3356]. 317 The procedures in this document are applicable to all organizations 318 outside the IETF whether or not they have formal liaison 319 relationships with the IETF. If any organization outside the IETF 320 has a requirement, or believes it may have a requirement, for 321 extensions or modifications to the (G)MPLS protocols then the 322 procedures in this document apply. 324 It should be noted that the first stage in the change process is an 325 optional Preliminary Investigation (see Section 4.2.1). This stage is 326 explicitly included to allow external organizations to discuss 327 requirements and proposed uses of the (G)MPLS technologies without 328 the need to first develop Internet-Drafts, and builds on existing 329 liaison processes where they exist. It is recognized that it is in 330 the interests of all concerned to begin discussions as early as 331 possible. 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, Informational, or BCP RFCs developed by the 349 (G)MPLS working groups, those protocols are considered to be part 350 of the (G)MPLS 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 also includes the (G)MPLS 362 working 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 abstract 392 functional requirements that the (G)MPLS extensions or changes 393 need to fulfill. These requirements should not constrain the 394 solution, but should provide all of the information necessary to 395 develop a satisfactory solution. This draft may be merged with the 396 problem statement draft (see above). 398 o Solutions Internet-Draft 399 A specification of extensions or changes to the (G)MPLS protocols 400 to meet the requirements in the requirement statement 401 Internet-Draft. 403 3. Summary of Procedures 405 This non-normative section is intended to provide a high-level view 406 of the procedures in this document to illustrate how they work and to 407 introduce the mechanisms that are defined in detail in Section 4. 409 Whenever there is reason to believe that a particular problem may be 410 solved by use of or extensions to the (G)MPLS protocols, a 411 preliminary investigation phase may be used to discuss the 412 requirements with the IETF. This may lead to an understanding that 413 the problem is already solved, is outside the scope of the IETF, or 414 requires more investigation possibly leading to changes to the 415 (G)MPLS protocols. 417 Whenever any extension or change to the (G)MPLS protocols is desired, 418 a requirements statement must be produced and must be submitted to 419 IETF as an Internet-Draft. As described in [RFC4052], when the 420 requirements come from an external organization informal 421 communications such as e-mail to working group mailing lists often 422 facilitates cooperative work. However, if desired, the Internet-Draft 423 containing the requirement may be submitted to the working group 424 using a liaison statement. That way, the IETF's response to the 425 request will be given as the reply to the liaison, with no risk of 426 confusing an individual participant's opinion for that of the group 427 as can happen on mailing lists. 429 The IETF, through the Routing Area Directors and the chairs of the 430 MPLS and CCAMP working groups, will direct the requirements draft to 431 an appropriate working group for assessment and comment. This process 432 may require communication and discussion for clarification, but the 433 IETF undertakes to perform the assessment in a timely manner. 435 In assessing the requirements statement I-D, the IETF may determine: 436 that the requirements can be satisfied without modifications to the 437 (G)MPLS protocols; that the requirements are not sufficiently general 438 to warrant a change to the (G)MPLS protocols; that the requirements 439 justify a change to the (G)MPLS protocols that will be created by the 440 IETF or within another organization; that the requirements might not 441 be possible to satisfy without violating the (G)MPLS architecture in 442 a way that would harm the (G)MPLS technology; or that the 443 requirements should be combined with other requirements to solve a 444 more general problem or solve the same problem in a more flexible 445 way. 447 In the event that the IETF agrees to develop a solution, the IETF 448 will set milestones that would result in timely delivery of the 449 solution in a timely manner. If the IETF rejects the requirements, 450 this will only be done with clear explanation and full 451 discussion with the source of the requirements. 453 The solutions that are developed within the IETF may be sourced from 454 external organizations and presented for review, discussion, 455 modification, and adoption as Internet-Drafts. Such solutions drafts 456 may be presented to the IETF in advance of the completion of the 457 requirements work, but all solutions will compete through the normal 458 IETF process with other proposed solutions, and none will be adopted 459 as an IETF working group draft until the requirements are agreed by 460 the rewg chairs to be stable and, in any case, not before the pswg 461 has a charter item to cover the solutions work. 463 4. MPLS and GMPLS Change Process 465 This section defines the (G)MPLS change process and the rules that 466 must be followed in order to make extensions or changes to the 467 (G)MPLS protocols. The language of [RFC2119] is used in order to 468 clarify the precise required behavior. 470 Anyone who intends to use one of the existing (G)MPLS protocols, but 471 thinks that it will not satisfy their needs MUST use the procedures 472 described in this document. Changes or extensions to the (G)MPLS 473 protocols MUST NOT be made by any other mechanism. The IETF MUST NOT 474 endorse any publications (including RFCs whether on the Standards 475 Track, Informational, or Experimental) that change or extended the 476 (G)MPLS protocols except for those that arise through the correct 477 execution of the procedures in this document. The IETF MUST NOT 478 endorse any IANA action that allocates (G)MPLS protocol codepoints 479 except as a result of actions arising from the correct execution of 480 the procedures in this document. 482 4.1 Flow Diagram 484 Figure 1 is presented to give a visual overview of the process. It 485 does not contain all of the possible interactions of procedures, and 486 the text in the subsequent sections should be used for a definitive 487 description of the process. 489 Start +-------------+ 490 | |optional | 491 +--<--------------------|preliminary |<-------Start 492 | |investigation| 493 V +-------------+ 494 +------------+ +---------+ +---------+ 495 |requirements| discussion |review by| ACK | IESG/ | ACK 496 |statement |----------->|WG chairs|------------->| IAB |------+ 497 |I-D | on mailing |and ADs | request to |decision | | 498 +------------+ list +---------+ IESG/IAB to +---------+ | 499 | appoint rewg | | 500 | NAK and charter |NAK rewg| 501 V req eval | chartered| 502 +-------------+ | to work on| 503 |response | | requirements| 504 |to the | | statement| 505 |requirements |<-----------------+ | 506 +->|statement |<----------------+ | 507 | +-------------+ | | 508 | ^ | | 509 NAK| | NAK | | 510 | +-----------------+ | V 511 | | | NAK +------+ 512 +--------+ +-------+ +--------| rewg | 513 | IESG/ | ACK | AD | | req | 514 +-----------| IAB |<---------------|review |<------------| eval | 515 |WG |decision| request to | | ACK | | 516 |chartered +--------+ IESG/IAB to +-------+ +------+ 517 |to work approve I-D 518 | and charter 519 | 520 | +---------+ 521 | | IETF | +-----+ 522 +--------->| WG |-----/ /---->| RFC | 523 +---->| process | +-----+ 524 | +---------+ 525 solutions 526 I-D 528 Figure 1: Change Process Overview 530 4.2 Description of Process Stages 532 This section describes how the (G)MPLS change process works, what is 533 expected from individuals or organizations that want to extend or 534 change the (G)MPLS protocols, and the responsibilities of the (G)MPLS 535 working groups, the Routing Area and the IETF in general. 537 4.2.1 Preliminary Investigation 539 This step is OPTIONAL, and is intended to provide a lightweight way 540 to "feel out" the IETF's position on a proposal without going to the 541 effort of writing an Internet-Draft. The intention is to determine 542 whether the problem has been examined already, whether the problem is 543 in scope for the IETF, and whether solutions are already known. 545 Although the preliminary investigation phase is optional it is 546 RECOMMENDED that the originator of any requirements consult and 547 discuss the issues concerned as early as possible to avoid any wasted 548 effort, and the preliminary investigation phase provides a mechanism 549 to do this. 551 Useful discussions may be held at this stage in order to ensure that 552 the problem statement and requirements statement Internet-Drafts 553 contain the right material. This step is described as lightweight 554 because no Internet-Draft is required and because the step largely 555 involves offline discussions. However, it may be the case that this 556 step involves considerable technical discussions and may, in fact, 557 involve an extensive, substantive exchange of ideas and opinions. 559 This step SHOULD be carried out informally on the mailing list of the 560 rewg or on the Routing Area discussion mailing list and MAY be 561 initiated by any individual, group of individuals, external 562 organization, or IETF working group. 564 When an external SDO has a liaison relationship with the IETF, it 565 MAY carry out this step using a formal liaison. The liaison SHOULD be 566 sent to the rewg or to the Routing Area, and the initiators of the 567 liaison SHOULD make themselves available for discussion on the 568 selected mailing list. If a formal liaison is used, the IETF MUST 569 respond to pursue the discussion. 571 At this stage, a problem statement I-D MAY be produced to help 572 further the discussions and to clarify the issues being addressed. 574 A possible outcome of this preliminary investigation is that the 575 requirements and problem are understood, but agreed to be out of 576 scope for the IETF. Alternatively it may be that the problem can be 577 solved with existing protocols. The full list of outcomes from the 578 preliminary investigation phase are identical to those for the 579 requirements statement evaluation phase described in section 4.2.2, 580 but the requirements statement evaluation phase MUST form part of the 581 process if the requirements are understood and the IETF would like to 582 develop protocol solutions - the process cannot move direct form the 583 preliminary investigation pahse to the development of solutions. 585 4.2.2 Requirements Statement Evaluation 587 Before the IETF can formally pronounce on requirements to change or 588 extend the (G)MPLS protocols, a requirements statement I-D MUST be 589 written and submitted to the IETF for publication. 591 The requirements statement I-D MUST be introduced to the IETF through 592 an email to the rewg mailing list or to the Routing Area discussion 593 mailing list, or by a formal liaison from an external SDO which will 594 result in the IETF introducing the requirements statement I-D to the 595 rewg mailing list. If the requirements statement I-D is brought to 596 the IETF through a formal liaison, the initiators of the liaison 597 SHOULD make themselves available for discussion on the appropriate 598 mailing lists. 600 After discussion on the IETF mailing lists, the appropriate IETF 601 working group chairs and the Routing Area Directors MUST decide 602 whether the requirements will be formally evaluated by the IETF, and 603 MUST deliver a response to the requirements statement I-D. 605 If the requirements statement I-D is brought to the IETF through a 606 formal liaison, the IETF MUST respond using one of the following 607 answers in a formal liaison reply: 609 a. Requirements not understood. Further discussion required. 611 b. Requirements understood, but judged to be out of scope for the 612 IETF. In this case, the originator of the requirements can work 613 on on requirements and solutions and will not be impeded by the 614 IETF. The IETF may request to be kept informed of progress. 616 c. Requirements understood, but no protocol extensions are needed. 617 It may be desirable for the external SDO to cooperate with the 618 appropriate working group in the production of an Applicability 619 Statement Internet-Draft. 621 d. Requirements understood, and the IETF would like to develop 622 protocol extensions. This results in execution of the rest of the 623 procedure, described below. The requirements raised in the 624 requirements statement I-D may be combined with other 625 requirements to produce more general extensions or changes to the 626 (G)MPLS protocols. 628 4.2.3 Chartering the Rewg 630 In many cases the problem covered by the requirements statement I-D 631 will fall within the scope of the existing charter of a working 632 group. In this case, the Routing Area Directors SHOULD designate the 633 working group as the rewg and pass the requirements statement I-D to 634 the working group for evaluation. 636 If a new charter item is required, the Routing Area Directors with 637 assistance from working group chairs MUST apply to the IESG and IAB 638 for a modification of an existing working group's charter or for the 639 creation of a new working group. If the IESG approves the charter, 640 the requirements statement I-D is passed to the rewg for evaluation. 641 If the charter change is not approved, the IESG MUST respond to the 642 requirements statement I-D and, if the requirements were introduced 643 through a formal liaison from another SDO, the IESG MUST send a 644 liaison response using the options described in Section 5, although 645 the IESG MAY delegate such responses. 647 4.2.4 Rewg Evaluation of the Requirements Statement I-D 649 The objective of the rewg evaluation process is to determine a clear 650 and complete statement of the requirements for changes or extensions 651 to the (G)MPLS protocols. This will necessitate normal IETF working 652 group procedures in the rewg and MAY include the generation of 653 revisions of the requirements statement I-D in cooperation between 654 the members of the rewg and the original authors of the requirements 655 statement I-D. 657 The originators of the requirements statement I-D MUST make 658 themselves available to discuss the work on the rewg mailing list. 659 If this does not happen, the chairs of the rewg MAY determine that 660 there is insufficient support for the work and MAY reject the 661 requirements statement I-D. 663 The output of the rewg MUST be either: 665 - a completed requirements statement I-D that has been accepted by 666 working group consensus within the rewg and has passed through 667 working group last call; 669 or: 671 - a rejection of the requirements following exactly the same format 672 and procedure as described in Section 5. 674 4.2.5 AD Evaluation of Completed Requirements Statement I-D 676 As with all Internet-Drafts produced by a working group, the ADs MUST 677 review the completed requirements statement I-D produced by the rewg 678 to determine its fitness for publication. At their discretion, the 679 ADs MAY use an Area Directorate and/or other subject matter experts 680 to assist them in this review 682 The result of the AD review MAY request the rewg to do further work 683 on the I-D in which case the previous step and this one will be 684 repeated. 686 The ADs SHOULD NOT reject the requirements statement I-D outright at 687 this stage since the requirements have already been accepted by the 688 ADs at an earlier stage. However, in some situations (such as a 689 significant change in related circumstances) the ADs MAY reject the 690 requirements statement I-D using the format and procedure described 691 in Section 5. 693 When the ADs accept the requirements statement I-D they MUST pass it 694 to the IESG for review, and propose any charter changes necessary to 695 select a pswg. 697 4.2.6 IESG review of Requirements Statement I-D and Pswg Charter 699 As with all Internet-Drafts, the IESG MUST take a ballot on the 700 progression of the requirements statement I-D. 702 If the IESG rejects the requirements statement I-D, it MUST generate 703 a response to the requirements as described in Section 5. 705 The IESG MUST take a ballot on any proposed charter changes for the 706 pswg. This MAY include the formation of a new working group 707 specifically to work on the solutions, although it is also possible 708 that the solutions work is covered by an existing working group 709 charter without any changes. 711 If the IESG rejects working group charter changes such that it is not 712 possible for the IETF to work on solutions for the requirements in 713 the requirements statement I-D, this MUST be treated as a rejection 714 of the requirements statement I-D, and the requirements statement I-D 715 MUST NOT be published as an RFC. In this case the IESG MUST reject 716 the requirements statement I-D using the format and procedure 717 described in Section 5. 719 4.2.7 Solutions Work 721 Once the requirements statement I-D has been approved by the IESG it 722 will enter the RFC Editor's queue and be handled according to normal 723 IETF process. 725 Once the pswg has been identified and (re-)chartered as necessary and 726 the requirements statement I-D has been approved by the IESG, the 727 pswg can start work on solutions following the normal IETF process. 729 Solutions I-Ds MAY be prepared externally (such as within an external 730 organization) or within the IETF, submitted to the IETF for 731 publication, and introduced to the pswg for consideration. Such I-Ds 732 MAY be submitted at earlier stages in the process to assist the rewg 733 in its development and discussion of the requirements, but no I-D 734 will be formally considered as a solutions I-Ds until the pswg has a 735 charter item that covers the work and the rewg chairs are confident 736 that the requirements are stable. Even at this stage in the process, 737 the IETF makes no guarantees that an externally produced solutions 738 I-D will form the basis of the pswg solutions I-D, but the pswg MUST 739 consider such an I-D as a possible solution I-D. 741 The final development of the solutions I-D is subject to the normal 742 working group review, consensus, and last call within the pswg. 744 Where the requirements originated from an external organization, the 745 pswg SHOULD regularly communicate its progress using a formal liaison 746 process if one exists. This communication SHOULD also be used to 747 request review input and comment on the development of the solutions 748 I-D. The solutions I-D MUST be communicated to the originating 749 organization during working group last call for final review against 750 the requirements. When the solutions I-D is complete (normally upon 751 completing working group last call and/or on entering the RFC 752 Editor's queue) the pswg MUST inform the originating organization of 753 the completed solution. 755 5. Rejecting Requirements Statements I-D 757 Rejection of the requirements statements is a sensitive matter for 758 the authors of the requirements and MUST be handled with full 759 disclosure and explanation by the IETF. 761 The requirements can be rejected at various stages of the process as 762 described in the previous sections. The person or grouping that makes 763 the rejection is responsible for generating an explanation of the 764 rejection and MUST follow the process described in this section. 766 5.1 Reasons for Rejection 768 The requirements statement I-D can only be rejected using one of the 769 following reasons. Each reason MUST be stated with the acceptable 770 next steps as described here. 772 - Requirements not understood. At the early stage of evaluation of 773 the requirements statement I-D before the rewg has been tasked with 774 performing a full evaluation and completing the requirements 775 statement I-D or during the optional preliminary investigation it 776 is not clear what the requirements are for or what the problem 777 being addressed is. 779 This rejection forms part of an on-going communication and it is 780 expected that the process will continue with further iterations. 782 - Out of scope for the IETF. Many stages of this process may 783 determine that the requirements are out of scope for the IETF. In 784 this case, the IETF MUST NOT constrain the authors of the 785 requirements statement I-D permission to work on a solution. 787 - No protocols extensions or changes are needed. At some stage in the 788 evaluation of the requirements it may become clear that they can 789 all be met through appropriate use of existing protocols. In this 790 case no further evaluation of the requirements is required, but the 791 IETF MUST explain how the protocols can be used to meet the 792 requirements and MAY cooperate with the authors of the requirements 793 statement I-D in the production of an Applicability Statement 794 Internet-Draft or a Profiles Internet-Draft that explains precisely 795 how the existing protocols can be used to meet the requirements. 797 - Insufficient support within the IETF. Although the work described 798 within the requirements statement I-D is within scope for the IETF, 799 and despite the support of the originators of the requirements 800 statement I-D on the rewg mailing list, the chairs of the rewg have 801 determined that there is insufficient support in the rewg to 802 complete requirements statement I-D. In this case, the IETF MUST 803 grant the authors of the requirements statement I-D permission to 804 work on a solution. The solution SHALL be presented to the IETF 805 for review and possible publication as an Informational or 806 Experimental RFC, and the IETF SHALL NOT block applications to IANA 807 for codepoints. 809 - Insufficient support for the work. If the authors of the 810 requirements statement I-D do not make themselves available on the 811 rewg mailing list for discussion of the requirements or do not 812 contribute the completion of the requirements statement I-D, the 813 chairs of the rewg MAY determine that there is insufficient support 814 for the work and MAY reject the requirements statement I-D. In this 815 case, the IETF MUST NOT grant permission for the work to be carried 816 out in any other organization, and MUST NOT endorse the publication 817 of any changes or extensions to the (G)MPLS protocols and MUST NOT 818 instruct IANA to allocate any codepoints. The requirements may be 819 re-introduced by starting the procedure again from the top. 821 - Satisfying the requirements would break the technology. It is 822 possible that an assessment will be made that, although the 823 requirements are reasonable, it is not possible to satisfy them 824 through extensions or changes to the (G)MPLS protocols without 825 violating the (G)MPLS architecture in such a way as would break the 826 (G)MPLS technology. In this case a recommendation will be made that 827 some other technology be used to satisfy the requirements. See 828 Section 7 for further discussions of the protection of the 829 integrity of the (G)MPLS technology. 831 5.2 Actions Upon Rejection 833 Upon rejection, the IETF MUST make a clear statement of why the 834 requirements statement I-D has been rejected and what next step 835 actions are acceptable. The reasons SHOULD be based on the list in 836 Section 5.1. 838 The form of the rejection depends on the form of the original 839 submission as follows. 841 - If the requirements are brought to the IETF as a preliminary 842 investigation (see Section 4.2.1) through an email exchange then 843 the response SHOULD be made as an email response and SHOULD be 844 archived through an IETF email archive. 846 - If the requirements are brought to the IETF as a preliminary 847 investigation (see Section 4.2.1) through a formal liaison, the 848 rejection MUST be delivered through a formal liaison response. 850 - If a requirements statement I-D has been produced and discussed on 851 an IETF email list, the response SHOULD be made as an email 852 response and copied to the email list. 854 - If a requirements statement I-D has been produced and brought to 855 the IETF through a formal liaison, the rejection MUST be 856 delivered through a formal liaison response. 858 - If an IETF working group has been involved in the review or 859 production of any Internet-Drafts for the requirements or for the 860 solutions, the working group MUST be notified of the rejection and 861 the reasons. 863 The responsibility for the generation of the response lies with the 864 person, people, or grouping that instigates the rejection. This may 865 be the IESG, one or more Area Directors, one or more working group 866 chairs, or a protocol caretaker. In the case of the use of a liaison 867 relationship, the IETF's liaison manager has responsibility for 868 ensuring that the procedures in this document, and particularly the 869 rejection procedures, are followed. 871 6. Abandonment of the Solutions I-D 873 Once the solutions work has been started by the pswg, it MAY be 874 abandoned before completion. This can happen if the pswg chairs 875 determine that there is no longer working group support for doing the 876 work. This could arise, for example, if no-one (including the 877 originators of the requirements statement I-D) is willing to 878 contribute to the development of a solutions I-D. 880 In the event that the solutions work is abandoned by the pswg, the 881 Area Directors responsible for the pswg MUST be consulted. The 882 originators of the requirements statement I-D MUST be informed that 883 the work has been stopped using a mechanism dependent on how the 884 requirements were introduced (as discussed in Section 5.2). 886 If the solution is abandoned in this way, work on solutions for the 887 requirements MUST NOT be started in another forum. The status of 888 extensions and changes to the (G)MPLS protocols with regard to the 889 specific requirements returns to how it was before the process 890 started. Any new examination of the requirements MUST commence at 891 the top of the process. 893 7. (G)MPLS Integrity 895 The (G)MPLS working groups are REQUIRED to protect the architectural 896 integrity of the (G)MPLS protocols and SHOULD NOT extend the GMPLS 897 architecture with features that do not have general use beyond the 898 specific case. They also MUST NOT modify the architecture just to 899 make some function more efficient at the expense of simplicity or 900 generality. 902 The architectural implications of additions or changes to the (G)MPLS 903 protocols MUST be consider interoperability with existing and future 904 versions of the protocols. The effects of adding features that 905 overlap or that deal with a point solution and are not general are 906 much harder to control with rules. Therefore the (G)MPLS technology 907 calls for this architectural guardianship by its working groups. 909 8. Security Considerations 911 All requirements statement I-Ds MUST give full consideration to the 912 security impact of the proposed additional features or functions. All 913 solutions I-Ds MUST consider the impact on the security of the 914 protocol extensions and to the pre-existing protocol. 916 This documents does not itself introduce any security issues for any 917 (G)MPLS protocols. 919 The IETF process is itself at risk from denial of service attacks. 920 This document utilizes the IETF process and adds details to that 921 process. It is possible, therefore, that this document might put the 922 IETF process at risk. Although this document places additional 923 requirements on key individuals within the IETF, those requirements 924 are not substantial for any individual requirements statement I-D 925 since the responsibility for the majority of the work lies with the 926 rewg and pswg with an underlying assumption that the authors of the 927 requirements statement I-D will participate in the working group 928 process. 930 Therefore, provided that the number of requirements statement I-Ds is 931 not unreasonable, there will be no significant impact on the IETF 932 process. The rate of arrival of requirements statement I-Ds MAY be 933 used by the IESG to detect denial of service attacks, and the IESG 934 SHOULD act on such an event depending on the source of the 935 requirements statement I-D and the perceived relevance of the work. 936 The IESG might, for example, discuss the issue with the management of 937 external organizations. 939 9. Acknowledgements 941 The input given by Bert Wijnen has been useful and detailed. 943 Review feedback and discussions with various members of the ITU-T has 944 been helpful in refining the process described in this document. 945 Thanks in particular to the members of Question 14 of Study Group 15, 946 and to the management of Study Group 15. Important discussions were 947 held with the following participants in the ITU-T: Yoichi Maeda, 948 Greg Jones, Stephen Trowbridge, Malcolm Betts, Kam Lam, 949 George Newsome, Eve Varma, Lyndon Ong, Stephen Shew, Jonathan Sadler, 950 and Ben Mack-Crane. 952 Thanks for further review comments to Brian Carpenter. 954 10. IANA Considerations 956 This document makes no specific requests to IANA for action. The 957 procedures described in this document assume that IANA will adhere to 958 the allocation policies defined for the (G)MPLS codepoint registries 959 and that the IETF will not endorse allocation of codepoints from 960 those registries except where work has been carried out in accordance 961 with the procedures described in this document. 963 11. Normative References 965 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 966 Requirement Levels", BCP 14, RFC 2119, March 1997. 968 [RFC4052] Daigle, L., "IAB Processes for Management of IETF Liaison 969 Relationships", BCP 102, RFC 4052, April 2005. 971 [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 972 Handling Liaison Statements to and from the IETF", 973 BCP 103, RFC4053, April 2005. 975 [PROT-EXT] Bradner, S., and Carpenter, B., "Procedures for protocol 976 extensions and variations", draft-carpenter-protocol- 977 extensions, work in progress. 979 12. Informative References 981 [RFC3356] Fishman, G. and S. Bradner, "Internet Engineering Task 982 Force and International Telecommunication Union - 983 Telecommunications Standardization Sector Collaboration 984 Guidelines", RFC 3356, August 2002. 986 [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: 987 Procedures", BCP 92, RFC 3932, October 2004. 989 Authors' Addresses 991 Loa Andersson 992 Acreo AB 993 Email: loa@pi.se 995 Adrian Farrel 996 Old Dog Consulting 997 Email: adrian@olddog.co.uk 999 George Swallow 1000 Cisco Systems 1001 Email: swallow@cisco.com 1003 Deborah Brungard 1004 AT&T 1005 Email: dbrungard@att.com 1007 Bill Fenner 1008 AT&T 1009 Email: fenner@research.att.com 1011 Ross Callon 1012 Juniper Networks 1013 Email: rcallon@juniper.net 1015 Kireeti Kompella 1016 Juniper Networks 1017 Email: Kireeti@juniper.net 1019 Alex Zinin 1020 Alcatel 1021 Email: zinin@psg.com 1023 Scott Bradner 1024 Harvard University 1025 Email: sob@harvard.edu 1027 Intellectual Property Statement 1029 The IETF takes no position regarding the validity or scope of any 1030 Intellectual Property Rights or other rights that might be claimed to 1031 pertain to the implementation or use of the technology described in 1032 this document or the extent to which any license under such rights 1033 might or might not be available; nor does it represent that it has 1034 made any independent effort to identify any such rights. Information 1035 on the procedures with respect to rights in RFC documents can be 1036 found in BCP 78 and BCP 79. 1038 Copies of IPR disclosures made to the IETF Secretariat and any 1039 assurances of licenses to be made available, or the result of an 1040 attempt made to obtain a general license or permission for the use of 1041 such proprietary rights by implementers or users of this 1042 specification can be obtained from the IETF on-line IPR repository at 1043 http://www.ietf.org/ipr. 1045 The IETF invites any interested party to bring to its attention any 1046 copyrights, patents or patent applications, or other proprietary 1047 rights that may cover technology that may be required to implement 1048 this standard. Please address the information to the IETF at 1049 ietf-ipr@ietf.org. 1051 Disclaimer of Validity 1053 This document and the information contained herein are provided on an 1054 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1055 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1056 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1057 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1058 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1059 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1061 Copyright Statement 1063 Copyright (C) The Internet Society (2006). This document is subject 1064 to the rights, licenses and restrictions contained in BCP 78, and 1065 except as set forth therein, the authors retain all their rights.