diff options
Diffstat (limited to 'doc/rfc/rfc4929.txt')
| -rw-r--r-- | doc/rfc/rfc4929.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc4929.txt b/doc/rfc/rfc4929.txt new file mode 100644 index 0000000..e27267f --- /dev/null +++ b/doc/rfc/rfc4929.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group L. Andersson, Ed. +Request for Comments: 4929 Acreo AB +BCP: 129 A. Farrel, Ed. +Category: Best Current Practice Old Dog Consulting + June 2007 + + + Change Process for Multiprotocol Label Switching (MPLS) and + Generalized MPLS (GMPLS) Protocols and Procedures + +Status of This Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + This document provides guidelines for applying or extending the MPLS + or GMPLS ((G)MPLS) protocol suites and clarifies the IETF's (G)MPLS + working groups' responsibility for the (G)MPLS protocols. This + document is directed to multi-vendor fora and Standards Development + Organizations (SDOs) to provide an understanding of (G)MPLS work in + the IETF and documents the requisite use of IETF review procedures + when considering (G)MPLS applications or protocol extensions in their + work. This document does not modify IETF processes. + + + + + + + + + + + + + + + + + + + + + +Andersson & Farrel Best Current Practice [Page 1] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Document Source ............................................4 + 1.2. Conventions Used in This Document ..........................4 + 2. Overview of (G)MPLS within the IETF .............................4 + 2.1. IETF Working Groups Developing (G)MPLS Technology ..........5 + 2.1.1. Multiprotocol Label Switching Working Group .........5 + 2.1.2. Common Control & Measurement Plane Working Group ....5 + 2.1.3. MPLS and CCAMP Division of Work .....................6 + 2.2. Other (G)MPLS Technology-Related Working Groups ............6 + 2.3. Organizations Outside the IETF .............................7 + 3. Overview of (G)MPLS Change Process ..............................8 + 4. MPLS and GMPLS Change Process ...................................9 + 4.1. Flow Diagram ..............................................10 + 4.2. Description of Process Stages .............................11 + 4.2.1. Preliminary Investigation ..........................12 + 4.2.2. Requirements Statement Evaluation ..................13 + 4.2.3. Working Group Procedures ...........................14 + 4.2.4. REWG Evaluation of the Requirements Statement I-D ..14 + 4.2.5. AD Evaluation of Completed Requirements + Statement I-D ......................................14 + 4.2.6. IESG review of Requirements Statement I-D + and PSWG Charter ...................................15 + 4.2.7. Solutions Work .....................................15 + 5. Rejecting the Requirements Statements I-D ......................16 + 5.1. Reasons for Rejection .....................................16 + 5.2. Actions Required When Rejecting Requirements + Statement I-Ds ............................................18 + 5.3. Appeals ...................................................18 + 6. Abandonment of the Solutions I-D ...............................19 + 6.1. Appeals ...................................................19 + 7. (G)MPLS Integrity and Ownership ................................19 + 8. Security Considerations ........................................20 + 9. Acknowledgements ...............................................20 + 10. IANA Considerations ...........................................21 + 11. References ....................................................21 + 11.1. Normative References .....................................21 + 11.2. Informative References ...................................21 + + + + + + + + + + + + +Andersson & Farrel Best Current Practice [Page 2] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + +1. Introduction + + The MPLS and GMPLS technology is developed in two main tracks in the + IETF. "MPLS" refers to the work done for packet switched networks, + while "GMPLS" refers to the efforts to apply the MPLS protocols to + all types of networks including packet and non-packet technologies. + + Though GMPLS by definition is a superset of MPLS, the term "(G)MPLS" + is used in this document to indicate both of these tracks. A + terminology section that covers the use of terms and concepts used in + this document is found in Section 2.6. + + [RFC4775] discusses procedural issues related to the extension or + variation of IETF protocols by other SDOs. It provides the + guidelines and procedures to be used by other SDOs when considering + the requirements for extensions to IETF protocols. [RFC4775] + recommends that major extensions to, or variations of, IETF protocols + only take place through normal IETF processes or in coordination with + the IETF. + + The (G)MPLS protocol families were developed within the IETF and + constitute significant protocol suites within the Internet standards. + The (G)MPLS suites of protocols have become popular for a number of + new applications and deployment scenarios. There have been concerns + with regards to other technology fora developing, using, and + publishing non-standard protocol extensions as a standard not only + for use within their community, also for wider use by the industry. + Especially concerning is the development of extensions, without + consulting the (G)MPLS working groups, which are in conflict with + efforts on-going in the (G)MPLS working groups, and then presented to + the (G)MPLS working group as 'fait accompli'. + + The definition and publishing of non-standard extensions by other + fora, without IETF review, and outside of the IETF publication + process, regardless if rationalized as limited to use among fora + vendors, or limited to a particular application, or rationalized as + allowing timely demos, has the unfortunate potential to hinder + interoperability and increase complexity of the protocol, sows + confusion in the industry, and circumvents the Internet standards + process that exists to ensure protocol implementability. As + described in [RFC4775], non-standard extensions, including + experimental values, are not to be portrayed as industrial standards + whether by an individual vendor, an industry forum, or a standards + body. + + This document clarifies the IETF's MPLS and Common Control and + Measurement Plane (CCAMP) working groups' roles and responsibilities + for the (G)MPLS protocols and documents the requisite use of, and how + + + +Andersson & Farrel Best Current Practice [Page 3] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + + to apply, the [RFC4775] procedure of using the IETF review processes, + [RFC2026] and [RFC2418], for fora wishing to apply or extend the + (G)MPLS protocols. Use of the IETF review processes will ensure an + open process for protocol development and ensure a non-harmful + evolution for these IETF protocols, which will benefit the larger + industry users' community. IETF itself cannot enforce a forum to use + the (G)MPLS change procedure, though any forum not following it, when + applying for IANA assignment or IETF publication, will be delayed + until this procedure has been completed. + + This document does not change the formal IETF standards process as + defined in [RFC2026] and [RFC2418]. It is consistent with the + general procedures for protocol extensions defined in [RFC4775] and + shows how they are applied in the case of (G)MPLS. Any procedures + described in this document are to be implemented in a way consistent + with these three documents. They MUST be used when other SDOs and + fora wish to propose (G)MPLS changes. They SHOULD be used internally + within the IETF unless the changes concerned are considered non- + controversial by the responsible Area Director(s) (e.g., covered by + the working group charter), in which case other aspects of the normal + IETF standards process cover the necessary procedures. + +1.1. Document Source + + This document is the joint work of the IETF Routing Area Directors, + the IETF MPLS and CCAMP Working Group Chairs, and the IETF's liaisons + to the ITU-T. It had considerable review and comment from key + members of the ITU-T who have given their time and opinions based on + experience for which the authors are grateful. The IESG has also + provided valuable input to arrive at the process documented here. + The acknowledgements section lists those whose contributions have + been particularly helpful. + +1.2. Conventions Used in This Document + + Although this document is not a protocol definition, the key words + "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", + "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document + are to be interpreted as described in RFC 2119 [RFC2119]. This usage + is chosen to make the steps and procedures completely clear. + +2. Overview of (G)MPLS within the IETF + + This section describes the key IETF working groups developing the + (G)MPLS technology and provides information on IETF working groups + using the (G)MPLS technology. + + + + + +Andersson & Farrel Best Current Practice [Page 4] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + + It should be remembered that the IETF environment is highly dynamic. + Working groups and whole areas come and go. The overview of the + relevant working groups within the IETF is only a snapshot in time. + +2.1. IETF Working Groups Developing (G)MPLS Technology + + Two working groups in the IETF's Routing Area are responsible for + work related to developing the (G)MPLS technologies: Multiprotocol + Label Switching (MPLS) working group and the Common Control and + Measurement Plane (CCAMP) working group. + + The following sections provide brief overviews of the chartered work + of these two IETF working groups. + +2.1.1. Multiprotocol Label Switching Working Group + + The Multiprotocol Label Switching (MPLS) working group is responsible + for standardizing the base technology that uses label switching, and + for describing the implementation of Label Switched Paths (LSPs) over + various packet and frame-based link level technologies. The working + group charter includes procedures and protocols for the distribution + of labels between routers, as well as encapsulations, operation and + management, traffic engineering, and multicast considerations. + + This document assumes that the MPLS working group remains the + chartered authority on MPLS technologies, but notes that the IETF may + appoint another working group (refer to [RFC2418]) to handle specific + extensions or changes to the protocols. Further, in the event that + the MPLS working group completes its work and is closed, the IETF + will use the non-working group standards track document process + (described in [RFC2026]) using designated experts from the community + [RFC2434] for the MPLS protocols. + +2.1.2. Common Control & Measurement Plane Working Group + + The IETF Common Control and Measurement Plane (CCAMP) working group + coordinates the work within the IETF defining common control and + measurement planes for ISP and SP core tunneling technologies. This + includes, but is not limited to, defining signaling protocols and + measurement protocols such that they support multiple physical path + and tunnel technologies using input from technology-specific working + groups such as the MPLS working group. It also includes the + development of protocol-independent metrics and parameters for + describing links and paths that can be carried in protocols. + + The technology that the CCAMP working group focuses on is called + Generalized MPLS (GMPLS), indicating that CCAMP addresses a + generalized technology, where labels are defined in such a way that + + + +Andersson & Farrel Best Current Practice [Page 5] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + + they will be compatible with the technology over which the data is + transported. While the MPLS working group focuses on packet- and + frame-switched technologies, the CCAMP working group work focuses on + common methods across a broad spectrum of switching technologies + including packet and frame technologies. In this respect, GMPLS can + be viewed as a superset of MPLS. + + The procedures in this document assume that the CCAMP working group + remains the authority on GMPLS technologies, but acknowledges that + the IETF may appoint another working group (refer to [RFC2418]) to + handle specific extensions or changes to the protocols. Further, in + the event that the CCAMP working group completes its work and is + closed, the IETF will use the non-working group standards track + document process (described in [RFC2026]) using designated experts + from the community [RFC2434] for the GMPLS protocols. + +2.1.3. MPLS and CCAMP Division of Work + + From time to time, the MPLS and CCAMP working groups decide to divide + work between themselves in a way that does not strictly follow the + split between the working groups as defined in the working group + charters. This is the case, e.g., for P2MP TE LSPs, where the MPLS + working group is specifying requirements and base technology for all + of the (G)MPLS technologies. + + An entity or individual that wishes to propose extensions or changes + to (G)MPLS should first decide to which working group (MPLS or CCAMP) + it will bring the proposal. However, the MPLS and CCAMP working + group chairs, in conjunction with their Area Directors, may redirect + the proposal to another working group. + +2.2. Other (G)MPLS Technology-Related Working Groups + + Problem statements and requirements for (G)MPLS technology have been + produced by several working groups in addition to the MPLS and CCAMP + working groups. IETF working groups are defined for the management + of specific tasks by their charter. Their charter defines their + role, relationship with other working groups, and the applicable + procedures to follow when extensions to (G)MPLS may be needed. This + section provides an overview of the (G)MPLS-related groups and their + responsibilities. Additional information describing the working + groups and their charters is available on the IETF web pages. + + The IP over Optical (IPO) working group and the Internet Traffic + Engineering working group (TEWG) are examples of working groups which + focus on problem statements and requirements for (G)MPLS to be + considered by the (G)MPLS working groups. These working groups have + not specified any protocols. + + + +Andersson & Farrel Best Current Practice [Page 6] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + + The Bidirectional Forwarding Detection (BFD) working group, also may + use the (G)MPLS protocols and mechanisms. The BFD working group is + chartered for requirements evaluation and protocol specification + related to BFD. If the working group needs to extend or change the + (G)MPLS protocols, the procedures specified by its charter and the + IETF's standard processes are applicable. + + The Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) working groups have + been chartered to specify a limited number of solutions for Provider + Provisioned VPNs. Both working groups are in the Internet Area. + Much of the work of the L2VPN and L3VPN working groups does not + include specifying new protocols or extensions to existing protocols. + Where extensions are needed, the procedures as specified by their + charters and the IETF's standard processes are applicable. + + The Layer 1 VPN (L1VPN) working group is chartered to specify + mechanisms necessary for providing Layer 1 VPN services + (establishment of layer 1 connections between CE devices) over a + GMPLS-enabled transport service-provider network. Protocol + extensions required for L1VPN will be done in cooperation with MPLS, + CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. That + is, the L1VPN working group will not develop GMPLS protocol + extensions in isolation, but will develop requirements and propose + extensions that will be reviewed and approved by the (G)MPLS working + groups. + + The Pseudo Wire Emulation End to End (PWE3) working group is a + working group that may use the (G)MPLS protocols in its + specifications. Should the PWE3 specifications require extension or + changes to the (G)MPLS protocols, the procedures as specified by its + charter and the IETF's standard processes are applicable. + +2.3. Organizations Outside the IETF + + A number of standards development organizations (SDOs) and industrial + forums use or reference the (G)MPLS protocols in their + specifications. Some of these organizations have formal or informal + liaison relationships with the IETF [RFC4052]. The IETF exchanges + information with these organizations about what is happening on both + sides, including plans and schedules, using liaison statements + [RFC4053]. More details about the cooperation relationship between + the IETF and the ITU-T can be found in [RFC3356]. + + The procedures in this document are applicable to all organizations + outside the IETF whether or not they have formal liaison + relationships with the IETF. If any organization outside the IETF + has a requirement for extensions or modifications to the (G)MPLS + protocols then the procedures in this document apply. + + + +Andersson & Farrel Best Current Practice [Page 7] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + +3. Overview of (G)MPLS Change Process + + This is a non-normative section, as it is intended to provide a high- + level view of [RFC4775] procedures for protocol extensions. + Application of these procedures for (G)MPLS are defined in detail in + Section 4. + + Whenever there is reason to believe that a particular problem may be + solved by use of or extensions to the (G)MPLS protocols, a + communication using the formal liaison process, or, for a forum + without a formal relationship, an informal communication, may be used + to discuss the problem with the IETF ([RFC4052] and [RFC4053]). + Collaboration with the IETF in the early discussion phase will + facilitate a timely understanding of whether the problem has already + been solved, may be outside the scope of the (G)MPLS protocols, or + may require more investigation. + + Whenever any extension or change to the (G)MPLS protocols is desired, + a problem statement and/or requirements statement must be produced + and must be submitted to IETF as an Internet-Draft. When the + requirements come from an external organization, informal + communications, such as e-mail to working group mailing lists, is + strongly encouraged as it facilitates timely and cooperative work. + However, if desired, the Internet-Draft, containing the + requirement(s), may be submitted to the working group using a formal + liaison statement. IETF's response to the request will be given as a + reply to the liaison. This use of formal communication reduces the + risk of confusing an individual participant's opinion for that of the + group as can happen on mailing lists, though it does introduce a more + lengthy communication cycle. If there is no formal liaison + relationship, a communication may be sent directly to the (G)MPLS + working group, a relevant Area Director, or the IESG. + + The IETF, through the appropriate Area Director, and the chairs of + the MPLS and CCAMP working groups for (G)MPLS related work, will + direct the requirements draft to an appropriate working group for + assessment and comment. This process may require communication and + discussion for clarification, but the IETF undertakes to perform the + assessment in a timely manner. + + In assessing the requirements statement I-D, the IETF may determine: + + + - that the requirements can be satisfied without modifications to the + (G)MPLS protocols + + + + + + +Andersson & Farrel Best Current Practice [Page 8] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + + - that the requirements are not sufficiently general or there is not + sufficient interest to do a standards-track solution to warrant a + Standards-track change to the (G)MPLS protocols + + - that the requirements justify a standards-track change to the + (G)MPLS protocols + + - that the requirements might not be possible to satisfy without + violating the (G)MPLS architecture in a way that would harm the + (G)MPLS technology + + - that the requirements should be combined with other requirements to + solve a more general problem or solve the same problem in a more + flexible way. + + In the event that the IETF agrees to develop a solution, the IETF + will set milestones that would result in timely delivery of the + solution in a timely manner. If the IETF rejects the requirements, + this will only be done with clear explanation and full discussion + with the source of the requirements. + + The solutions that are developed within the IETF may be sourced from + external organizations and presented for review, discussion, + modification, and adoption as Internet-Drafts. Such solutions drafts + may be presented to the IETF in advance of the completion of the + requirements work, but all solutions will be processed through the + normal IETF process with other proposed solutions. Solution drafts + are adopted as an IETF working group draft when the requirements are + stable, and not before the protocol-responsible working group has a + charter item to cover the solutions work. It is strongly recommended + for interested parties to start informal discussion in the IETF, as + early as possible, and to co-author in the IETF's work. It is not + recommended for the source forum to continue to work on solutions in + parallel with on-going work in the IETF. If the protocol-responsible + working group is unable to accept the work (e.g., due to current work + load), the IETF processes ([RFC2418]) provide alternate options for + ensuring the work is completed. + +4. MPLS and GMPLS Change Process + + This section defines the (G)MPLS change process and the rules that + must be followed in order to make extensions or changes to the + (G)MPLS protocols. The language of [RFC2119] is used in order to + clarify the required behavior of the IETF and the originator of the + change request. It is consistent with the general procedures for + protocol extensions defined in [RFC4775]. Any interpretation of + procedures described in this document and their implementation are to + be in a way consistent with [RFC4775]. + + + +Andersson & Farrel Best Current Practice [Page 9] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + + Anyone who intends to use one of the existing (G)MPLS protocols, but + thinks that it will not satisfy their needs MUST use the procedures + described in this document. They SHOULD be used internally within + the IETF unless the changes concerned are considered non- + controversial by the responsible Area Director(s) (e.g., covered by + the working group charter), in which case other aspects of the normal + IETF standards process apply. Changes or extensions to the (G)MPLS + protocols MUST NOT be made by any other mechanism. The IETF MUST NOT + endorse any publications (including RFCs, whether on the Standards + Track, Informational, or Experimental) that change or extend the + (G)MPLS protocols except for those that arise through the correct + execution of the procedures in this document. The IETF MUST NOT + endorse any IANA action that allocates (G)MPLS protocol codepoints, + except as a result of actions arising from the correct execution of + the procedures in this document. + +4.1. Flow Diagram + + Figure 1 gives a visual overview to illustrate the roles of a (G)MPLS + requirements evaluation working group (REWG) and (G)MPLS protocol + solutions working group (PSWG). The figure presents two alternatives + for a requestor: (1) contact the IETF early in the problem definition + phase (preliminary investigation), or, (2) later, with a requirements + statement. The figure is for illustration only; it does not contain + all of the possible interactions and IETF procedure alternatives. + The text in the subsequent sections describes the process. + + + + + + + + + + + + + + + + + + + + + + + + + +Andersson & Farrel Best Current Practice [Page 10] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + + Start +-------------+ + | |optional | + +--<--------------------|preliminary |<-------Start + | |investigation| + V +-------------+ + +------------+ +---------+ +---------+ + |requirements| discussion |review by| YES | IESG | YES + |statement |----------->|WG chairs|------------->|decision |------+ + |I-D | on mailing |and ADs | request to | | | + +------------+ list +---------+ IESG to +---------+ | + | appoint REWG | | + |NO and charter |NO REWG| + V req eval | chartered| + +-------------+ | to work on| + |response | | requirements| + |to the | | statement| + |requirements |<-----------------+ | + +->|statement |<----------------+ | + | +-------------+ | | + | ^ | | + NO| | NO | | + | +-----------------+ | V + | | | NO +------+ + +--------+ +-------+ +--------| REWG | + | IESG/ | YES | AD | | req | + +-----------|decision|<---------------|review |<------------| eval | + |PSWG | | request to | | YES | | + |chartered +--------+ IESG to +-------+ +------+ + |to work approve I-D + | and charter + | PSWG (if needed) + | +---------+ + | | IETF | +-----+ + +--------->| PSWG |-----/ /---->| RFC | + +---->| process | +-----+ + | +---------+ + solutions + I-D + Figure 1: Change Process Overview + +4.2. Description of Process Stages + + This section describes how the (G)MPLS change process works, what is + expected from individuals or organizations that want to extend or + change the (G)MPLS protocols, and the responsibilities of the IETF. + + + + + + +Andersson & Farrel Best Current Practice [Page 11] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + +4.2.1. Preliminary Investigation + + This step is OPTIONAL, and is intended to provide a lightweight way + to "feel out" the IETF's position on a proposal without going to the + effort of writing an Internet-Draft. The intention is to determine + whether the problem has been examined already, whether the problem is + in scope for the IETF, and whether solutions are already known. + + Although the preliminary investigation phase is optional it is + RECOMMENDED that the originator of any requirements consult and + discuss the issues concerned as early as possible to avoid any wasted + effort, and the preliminary investigation phase provides a mechanism + to do this. + + Useful discussions may be held at this stage in order to ensure that + the problem statement and requirements statement Internet-Drafts + contain the right material. This step is described as lightweight + because no Internet-Draft is required and because the step largely + involves offline discussions. However, it may be the case that this + step involves considerable technical discussions and may, in fact, + involve an extensive, substantive exchange of ideas and opinions. + + This step SHOULD be carried out informally on the mailing list of the + REWG or on the Routing Area discussion mailing list, and MAY be + initiated by any individual, group of individuals, external + organization, or IETF working group. + + When an external SDO has a liaison relationship with the IETF, it MAY + carry out this step using a formal liaison. The liaison SHOULD be + sent to the designated liaison manager who is responsible for + forwarding them to the IESG who will assign a Responsible AD. The + initiators of the liaison SHOULD make themselves available for + discussion on the selected mailing list. If a formal liaison is + used, the IETF will respond using the procedures of [RFC4053]. + + At this stage, a problem statement I-D MAY be produced to help + further the discussions and to clarify the issues being addressed. + + A possible outcome of this preliminary investigation is that the + requirements and problem are understood, but agreed to be out of + scope for the IETF. Alternatively, it may be that the problem can be + solved with existing protocols. The full list of outcomes from the + preliminary investigation phase are similar to those for the + requirements statement evaluation phase described in Section 4.2.2, + but the requirements statement evaluation phase that allows wider + IETF community participation in developing a complete requirement set + MUST form part of the process if the IETF is to consider to develop + protocol solutions. The process cannot move direct from the + + + +Andersson & Farrel Best Current Practice [Page 12] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + + preliminary investigation phase to the development of solutions + unless the working group agrees (e.g., the problem is minor). + +4.2.2. Requirements Statement Evaluation + + Before the IETF can formally pronounce on requests to change or + extend the (G)MPLS protocols, a requirements statement I-D MUST be + written per [RFC2026]. + + The requirements statement I-D MUST be introduced by the authors to + the IETF through an email to the REWG mailing list, to the Routing + Area discussion mailing list, or by a formal liaison from an external + SDO which will result in the IETF introducing the requirements + statement I-D to the REWG mailing list. If the requirements + statement I-D is brought to the IETF through a formal liaison, the + initiators of the liaison SHOULD make themselves available for + discussion on the designated IETF mailing lists. + + After discussion on the IETF mailing lists, the responsible Area + Director MUST decide whether the requirements will be formally + evaluated by the IETF, and MUST deliver a response to the per + [RFC4053] and [RFC4775]. If a formal liaison was not used, the + response SHOULD be delivered to the appropriate contact as listed on + the communication. + + The IETF response MUST be sufficiently explanatory to inform the + requesting organization of what, if anything, the IETF has decided to + do in response to the request. The following list is provided to + illustrate possible responses: + + a. Requirements not understood. Further discussion is required. + + b. Requirements understood, but judged to be out of scope for the + IETF. In this case, the originator of the requirements can work + on requirements and solutions and will not be impeded by the + IETF. The IETF may request to be kept informed of progress. + + c. Requirements understood, but no protocol extensions are needed. + It may be desirable for the external SDO to cooperate with the an + IETF working group in the production of an Applicability + Statement Internet-Draft. + + d. Requirements understood, and the IETF would like to develop + protocol extensions. This results in execution of the rest of + the procedure, described below. The requirements raised in the + requirements statement I-D may be combined with other + requirements to produce more general extensions or changes to the + (G)MPLS protocols. + + + +Andersson & Farrel Best Current Practice [Page 13] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + +4.2.3. Working Group Procedures + + In many cases, the problem covered by the requirements statement I-D + will fall within the scope of the existing charter of a working + group. In this case, the responsible Area Directors will designate + the working group as the REWG and pass the requirements statement I-D + to the working group for evaluation. If the problem is not covered + by an existing charter, other alternatives (refer to [RFC2418]) may + be used, e.g., rechartering, BOF, chartering a new working group. + + If the IETF modifies its prior decision to accept the work, the IETF + MUST communicate this to the requestor in a timely manner. + +4.2.4. REWG Evaluation of the Requirements Statement I-D + + The objective of the REWG evaluation process is to determine a clear + and complete statement of the requirements for changes or extensions + to the (G)MPLS protocols. This will necessitate normal IETF working + group procedures in the REWG and MAY include the generation of + revisions of the requirements statement I-D in cooperation between + the members of the REWG and the original authors of the requirements + statement I-D. + + The originators of the requirements statement I-D MUST make + themselves available to discuss the work on the REWG mailing list. + If this does not happen, the chairs of the REWG MAY determine that + there is insufficient support for the work and MAY reject the + requirements statement I-D. + + The output of the REWG will be either: + + - a completed requirements statement I-D that has been accepted by + working group consensus within the REWG and has passed through + working group last call; + + or + + - a rejection of the requirements using the response procedure as + described in Section 5. + +4.2.5. AD Evaluation of Completed Requirements Statement I-D + + As with all Internet-Drafts produced by a working group, the ADs will + review the completed requirements statement I-D produced by the REWG. + The ADs will then pass the document to the IESG for review. If + charter changes are needed or a new PSWG needed, the appropriate + process will be followed. + + + + +Andersson & Farrel Best Current Practice [Page 14] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + +4.2.6. IESG review of Requirements Statement I-D and PSWG Charter + + As with all Internet-Drafts, the IESG will review and make a decision + on the progression of the requirements statement I-D. + + If the IESG rejects the requirements statement I-D, it will generate + an appropriate response to the working group (and, if needed, to the + originator of the request). + + The IESG will review any proposed charter changes for the PSWG or, if + needed, consider alternatives. This might include the formation of a + new working group specifically to work on the solutions. + +4.2.7. Solutions Work + + The appropriate PSWG will start work on solutions following the + normal IETF process. + + Solutions I-Ds MAY be prepared externally (such as within an external + organization) or within the IETF, submitted to the IETF for draft + publication using the procedures of [RFC2418], and introduced to the + PSWG for consideration. Such I-Ds MAY be submitted at earlier stages + in the process to assist the REWG in its development and discussion + of the requirements, but no I-D will be formally considered as a + solutions I-D until the PSWG has a charter item that covers the work + and the REWG chairs are confident that the requirements are stable. + + The IETF makes no guarantees that an externally produced solutions + I-D will form the basis of the PSWG solutions I-D, but the PSWG MUST + consider such an I-D for review and revision as a possible solution + I-D, using the same open procedures ([RFC2418]) as for any individual + submission. The IETF's procedures are based on open and fair + participation, and thorough consideration of technical alternatives. + + Interested parties (both implementers and users) of the SDO + originating the request are strongly encouraged to participate in the + PSWG to ensure appropriate interest is shown in the solutions work + and to provide timely solutions development. The IETF's work, as + that of any SDO, is driven by its participants. The IETF is an open + community and any SDO requesting IETF solutions work SHOULD ensure + appropriate industry interest in the work, or the IETF MAY + discontinue its support of the work. Appropriate communication of + the discontinued work will be made to the originator of the request + (if the originator is reachable). + + The final development of the solutions I-D is subject to the normal + working group review, consensus, and last call within the PSWG. + + + + +Andersson & Farrel Best Current Practice [Page 15] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + + Where the requirements originated from an external organization, the + PSWG SHOULD regularly communicate its progress using a formal liaison + process if one exists. This communication SHOULD also be used to + request review input and comment on the development of the solutions + I-D. The solutions I-D MUST be communicated to the originating + organization during working group last call for final review against + the requirements. When the solutions I-D is complete (normally upon + completing working group last call and/or on entering the RFC + Editor's queue) the PSWG MUST inform the originating organization of + the completed solution. + +5. Rejecting the Requirements Statements I-D + + Rejection of the requirements statements is a sensitive matter for + the authors of the requirements and MUST be handled with full + disclosure and explanation by the IETF. All working group actions + are taken in a public forum ([RFC2418]). + + The requirements can be rejected at various stages of the process as + described in the previous sections. The person or group that makes + the rejection is responsible for generating an explanation of the + rejection and MUST follow the [RFC4775] process. Possible reasons + for rejection are described in this section. + +5.1. Reasons for Rejection + + The requirements statement I-D can only be rejected with full + disclosure by the IETF. Possible reasons for rejection and possible + next steps as described here. + + - Requirements not understood. Either during preliminary + investigation or during evaluation of the requirements statement + I-D, it was not clear what the requirements are, or what the + problem being addressed is. + + This rejection forms part of an on-going communication and it is + expected that the process will continue with further iterations. + + - Out of scope for the IETF. Many stages of this process may + determine that the requirements are out of scope for the IETF. In + this case, the IETF MUST NOT constrain the authors of the + requirements statement I-D from working on a solution. If any + (G)MPLS changes are later identified, the requestor MUST reinitiate + the (G)MPLS change procedure. + + - No protocols extensions or changes are needed. At some stage in + the evaluation of the requirements it may become clear that they + can all be met through appropriate use of existing protocols. In + + + +Andersson & Farrel Best Current Practice [Page 16] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + + this case, no further evaluation of the requirements is required, + but the REWG MUST explain how the protocols can be used to meet the + requirements and MAY cooperate with the authors of the requirements + statement I-D in the production of an Applicability Statement + Internet-Draft or a Profiles Internet-Draft that explains precisely + how the existing protocols can be used to meet the requirements. + + - Insufficient support within the IETF. Although the work described + within the requirements statement I-D is within scope for the IETF, + and despite the support of the originators of the requirements + statement I-D on the REWG mailing list, the chairs of the REWG have + determined that there is insufficient support in the REWG to + complete requirements statement I-D and initiate solutions work in + the PSWG. In this case, the IETF MUST NOT restrict the authors of + the requirements statement I-D from working on a solution. The + solution (and/or IANA codepoints requested) SHALL be presented to + the IETF's (G)MPLS PSWG for review and possible publication as an + Informational or Experimental RFC, and, pending IETF review + results, the IETF SHALL NOT block applications to IANA for + codepoints. If IANA codepoint assignments are required, the IANA + Requirements prescribed for those assignments in the relevant RFCs + MUST be satisfied. It is highly recommended for the SDO to + encourage its participants to participate in the IETF work to + ensure appropriate industry representation in the work. + + - Insufficient support for the work from the original requesters. If + the authors of the requirements statement I-D do not make + themselves available on the REWG mailing list for discussion of the + requirements or do not contribute the completion of the + requirements statement I-D, the chairs of the REWG MAY determine + that there is insufficient support for the work and MAY reject the + requirements statement I-D. In this case, the IETF MUST NOT grant + permission for the work to be carried out in any other + organization, and MUST NOT endorse the publication of any changes + or extensions to the (G)MPLS protocols and MUST NOT instruct IANA + to allocate any codepoints. The requirements may be reintroduced + by starting the procedure again from the top. + + - Satisfying the requirements would break the technology. It is + possible that an assessment will be made that, although the + requirements are reasonable, it is not possible to satisfy them + through extensions or changes to the (G)MPLS protocols without + violating the (G)MPLS architecture in such a way as would break the + (G)MPLS technology. In this case, a recommendation will be made + that some other technology be used to satisfy the requirements. + See Section 7 for further discussions of the protection of the + integrity of the (G)MPLS technology. In this case, the IETF MUST + NOT grant permission for the work to be carried out in any other + + + +Andersson & Farrel Best Current Practice [Page 17] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + + organization, and MUST NOT endorse the publication of any changes + or extensions to the (G)MPLS protocols and MUST NOT instruct IANA + to allocate any codepoints. + +5.2. Actions Required When Rejecting Requirements Statement I-Ds + + Upon rejection, the IETF MUST make a clear statement of why the + requirements statement I-D has been rejected and what next step + actions are acceptable (refer to Section 5.1). + + The communication of the rejection depends on the form of the + original submission as follows. + + - If the requirements are brought to the IETF as a preliminary + investigation (see Section 4.2.1) through an email exchange then + the response MUST be made as an email response copied to an IETF + mailing list so that it is automatically archived. + + - If the requirements are brought to the IETF as a preliminary + investigation (see Section 4.2.1) through a formal liaison, the + rejection MUST be delivered through a formal liaison response. + + - If a requirements statement I-D has been produced and discussed on + an IETF email list, the response MUST be made as an email response + and copied to the email list. + + - If a requirements statement I-D has been produced and brought to + the IETF through a formal liaison, the rejection MUST be delivered + through a formal liaison response. + + - If an IETF working group has been involved in the review or + production of any Internet-Drafts for the requirements or for the + solutions, the working group MUST be notified of the rejection and + the reasons. + + The responsibility for the generation of the response lies with the + person, people, or group that instigates the rejection. This may be + the IESG, one or more Area Directors, one or more working group + chairs, or a designated expert [RFC2434]. In the case of the use of + a liaison relationship, the IETF's liaison manager has responsibility + for ensuring that the procedures in this document, and particularly + the rejection procedures, are followed. + +5.3. Appeals + + [RFC2026] contains additional information related to procedure + disagreements and appeals. The rejection of a requirements statement + I-D as described in Sections 5.1 and 5.2 may be appealed in the event + + + +Andersson & Farrel Best Current Practice [Page 18] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + + it is disputed and cannot be reversed by direct discussion between + the parties. The conflict resolution and appeal mechanism is + documented in [RFC2026]. + +6. Abandonment of the Solutions I-D + + Once the solutions work has been started by the PSWG, it may be + abandoned before completion. This can happen if the PSWG chairs + determine that there is no longer working group support for doing the + work. This could arise, for example, if no one (including the + originators of the requirements statement I-D) is willing to + contribute to the development of a solutions I-D. + + In the event that the solutions work is abandoned by the PSWG, the + Area Directors responsible for the PSWG MUST be consulted. The + originators of the requirements statement I-D MUST be informed that + the work has been abandoned using a mechanism dependent on how the + requirements were introduced (as discussed in Section 5.2). + + If the solution is abandoned in this way, work on solutions for the + requirements MUST NOT be started in another forum. The status of + extensions and changes to the (G)MPLS protocols with regard to the + specific requirements returns to how it was before the process + started. Any new examination of the requirements MUST commence at + the top of the process. + +6.1. Appeals + + The abandonment of a solutions I-D may be appealed in the event it is + disputed and cannot be reversed by direct discussion between the + parties. The conflict resolution and appeal mechanism is documented + in [RFC2026]. + +7. (G)MPLS Integrity and Ownership + + The (G)MPLS working groups are REQUIRED to protect the architectural + integrity of the (G)MPLS protocols and MUST NOT extend the GMPLS + architecture with features that do not have general use beyond the + specific case. They also MUST NOT modify the architecture just to + make some function more efficient at the expense of simplicity or + generality. + + The architectural implications of additions or changes to the (G)MPLS + protocols MUST consider interoperability with existing and future + versions of the protocols. The effects of adding features that + overlap, or that deal with a point solution and are not general, are + much harder to control with rules and risk impacting the protocol as + a whole. Therefore, to minimize operational and technical risks to + + + +Andersson & Farrel Best Current Practice [Page 19] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + + the (G)MPLS technology, IETF processes SHALL be followed for any + requests on extensions to (G)MPLS protocols. With respect to (G)MPLS + protocols, the (G)MPLS PSWG is the chartered "owner" of the (G)MPLS + protocol, as long as the working group exists. All changes or + extensions to (G)MPLS MUST first be reviewed by the (G)MPLS PSWG. + +8. Security Considerations + + All requirements statement I-Ds MUST give full consideration to the + security impact of the proposed additional features or functions. + All solutions I-Ds MUST consider the impact on the security of the + protocol extensions and to the pre-existing protocol. + + This documents does not itself introduce any security issues for any + (G)MPLS protocols. + + The IETF process is itself at risk from denial of service attacks. + This document utilizes the IETF process and adds clarity to that + process. It is possible, therefore, that this document might put the + IETF process at risk. + + Therefore, provided that the number of requirements statement I-Ds is + not unreasonable, there will be no significant impact on the IETF + process. The rate of arrival of requirements statement I-Ds MAY be + used by the IESG to detect denial of service attacks, and the IESG + SHOULD act on such an event depending on the source of the + requirements statement I-D and the perceived relevance of the work. + The IESG might, for example, discuss the issue with the management of + external organizations. + +9. Acknowledgements + + The input given by Bert Wijnen has been useful and detailed. + + Review feedback and discussions with various members of the ITU-T has + been helpful in refining the process described in this document. + Thanks in particular to the members of Question 14 of Study Group 15, + and to the management of Study Group 15. Important discussions were + held with the following participants in the ITU-T: Yoichi Maeda, Greg + Jones, Stephen Trowbridge, Malcolm Betts, Kam Lam, George Newsome, + Eve Varma, Lyndon Ong, Stephen Shew, Jonathan Sadler, and Ben Mack- + Crane. + + Thanks for further review comments to Brian Carpenter, Stewart + Bryant, Sam Hartman, Mark Townsley, and Dave Ward. Thanks to Spencer + Dawkins for the GenArt review. + + + + + +Andersson & Farrel Best Current Practice [Page 20] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + +10. IANA Considerations + + This document makes no specific requests to IANA for action. The + procedures described in this document assume that IANA will adhere to + the allocation policies defined for the (G)MPLS codepoint registries + and that the IETF will not endorse allocation of codepoints from + those registries except where work has been carried out in accordance + with the procedures described in this document. + +11. References + +11.1. Normative References + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2418] Bradner, S., "IETF Working Group Guidelines and + Procedures", BCP 25, RFC 2418, September 1998. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC4052] Daigle, L., Ed., and Internet Architecture Board, "IAB + Processes for Management of IETF Liaison Relationships", + BCP 102, RFC 4052, April 2005. + + [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for + Handling Liaison Statements to and from the IETF", BCP + 103, RFC 4053, April 2005. + + [RFC4775] Bradner, S., Carpenter, B., Ed., and T. Narten, + "Procedures for Protocol Extensions and Variations", BCP + 125, RFC 4775, December 2006. 2006. + +11.2. Informative References + + [RFC3356] Fishman, G. and S. Bradner, "Internet Engineering Task + Force and International Telecommunication Union - + Telecommunications Standardization Sector Collaboration + Guidelines", RFC 3356, August 2002. + + + + + + + +Andersson & Farrel Best Current Practice [Page 21] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + +Authors' Addresses + + George Swallow + Cisco Systems + EMail: swallow@cisco.com + + Deborah Brungard + AT&T + EMail: dbrungard@att.com + + Bill Fenner + AT&T + EMail: fenner@research.att.com + + Ross Callon + Juniper Networks + EMail: rcallon@juniper.net + + Kireeti Kompella + Juniper Networks + EMail: Kireeti@juniper.net + + Alex Zinin + Alcatel + EMail: zinin@psg.com + + Scott Bradner + Harvard University + EMail: sob@harvard.edu + +Editors' Addresses + + Loa Andersson + Acreo AB + EMail: loa@pi.se + + Adrian Farrel + Old Dog Consulting + EMail: adrian@olddog.co.uk + + + + + + + + + + + + +Andersson & Farrel Best Current Practice [Page 22] + +RFC 4929 MPLS and GMPLS Change Process June 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Andersson & Farrel Best Current Practice [Page 23] + |