RFC 4929

Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures

📅 published June 2007, from ietf

RFC 4929: Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures 🎀✨

Okay bestie, this is RFC 4929 💅 and it's a Best Current Practice, so it's filed as BCP 129 (the category is Best Current Practice too). It's from the Network Working Group, and it was written by L. Andersson, Ed. (Acreo AB) and A. Farrel, Ed. (Old Dog Consulting). It's dated June 2007 🌸. The header doesn't list any RFCs it obsoletes or updates, so it's not replacing anything and it's not changing anything else. Iconic, honestly 🧚.

Status of This Memo ✨

So this doc is a BCP for the whole Internet Community 🌐, and it's basically asking everyone to talk about it and send ideas for making it better 💬. Also, distribution is totally unlimited, so share away 🦋.

Copyright Notice 💜

Abstract 🔥

Okay so this doc gives you guidelines for applying or extending the MPLS or GMPLS ((G)MPLS) protocol suites, and it clarifies the responsibility the IETF's (G)MPLS working groups have for the (G)MPLS protocols 👑. It's aimed at multi-vendor fora and Standards Development Organizations (SDOs), so they can understand how (G)MPLS work happens in the IETF and when they need to use the IETF review procedures for (G)MPLS applications or protocol extensions in their own work 🫶. It also says, very clearly, that it does not modify IETF processes 💖.

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

1. Introduction ✨

Okay so MPLS and GMPLS are developed on two main tracks in the IETF 🛤️. "MPLS" is the work done for packet switched networks, and "GMPLS" is the effort to apply the MPLS protocols to all types of networks, including both packet and non-packet technologies 🦋.

GMPLS is a superset of MPLS by definition, but this doc uses the term "(G)MPLS" to mean both tracks 💅. If you want the terms and concepts used in this doc explained, check out the terminology section in Section 2.6 🎀.

[RFC4775] is all about the procedural issues around extending or varying IETF protocols in other SDOs 📜. It gives other SDOs the guidelines and procedures to follow when they're thinking about requirements for extensions to IETF protocols 🧠. It also recommends that major extensions to, or variations of, IETF protocols only happen through normal IETF processes or in coordination with the IETF 🫶.

The (G)MPLS protocol families were developed inside the IETF, and they're major protocol suites in the Internet standards 👑. They've gotten really popular for a bunch of new applications and deployment scenarios 🔥. But people have been worried about other technology fora developing, using, and publishing non-standard protocol extensions as a standard, not only for their own community but for wider industry use too 😭. The most concerning part is when extensions get developed without consulting the (G)MPLS working groups, clash with what those working groups are already doing, and then get presented to them as a 'fait accompli' 🙈.

Publishing non-standard extensions outside the IETF, without IETF review and outside the IETF publication process, is a big no 💀. It doesn't matter whether it's justified as being only for vendors in a forum, only for one particular application, or as allowing quick demos. It can hinder interoperability, make the protocol more complicated, sow confusion across the industry, and sidestep the Internet standards process that exists to make sure protocols can actually be implemented 🌸. As [RFC4775] describes, non-standard extensions, including experimental values, are not to be portrayed as industrial standards, whether that comes from one vendor, an industry forum, or a standards body 🚫.

This document makes clear what the IETF's MPLS and Common Control and Measurement Plane (CCAMP) working groups are responsible for regarding the (G)MPLS protocols 📋. It also spells out when to use the [RFC4775] procedure of using the IETF review processes, [RFC2026] and [RFC2418], and how to apply it, for fora that want to apply or extend the (G)MPLS protocols 💜. Using the IETF review processes keeps development open and makes sure these IETF protocols evolve in a non-harmful way, which is good for the wider industry community 🌈. The IETF can't force a forum to follow the (G)MPLS change procedure 🙃. But any forum that doesn't follow it, when it applies for IANA assignment or IETF publication, will get held up until the procedure is done ⏳.

This document doesn't change the formal IETF standards process defined in [RFC2026] and [RFC2418] 💖. It's consistent with the general procedures for protocol extensions in [RFC4775] and shows how they apply to (G)MPLS ✨. Any procedures described here have to be implemented in a way that's consistent with all three of these documents 🎀. Other SDOs and fora MUST use them when they want to propose (G)MPLS changes 🚨. Inside the IETF they SHOULD be used too, unless the responsible Area Director(s) consider the changes non-controversial (for example, if they're covered by the working group charter). In that case, the other parts of the normal IETF standards process cover the procedures that are needed 🦋.

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 👑. Key members of the ITU-T gave it a lot of review and comment, sharing their time and opinions based on their experience, and the authors are super grateful 🥹. The IESG also gave valuable input that helped shape the process written down here 💅. The acknowledgements section lists the people whose contributions were especially helpful 🌸.

1.2. Conventions Used in This Document 🎀

Even though this doc isn't a protocol definition, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119] 📖. This wording was picked so the steps and procedures are completely clear 💯.

2. Overview of (G)MPLS within the IETF 🧚

This section is the tea on the key IETF working groups developing (G)MPLS technology, plus info on the IETF working groups that use it 🫖.

It should be remembered that the IETF environment is highly dynamic 🌪️. Working groups and whole areas come and go 🍃. So the overview of the relevant working groups in 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 developing the (G)MPLS technologies: the Multiprotocol Label Switching (MPLS) working group and the Common Control and Measurement Plane (CCAMP) working group 👯‍♀️.

The next sections give quick 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 🏷️. It also describes how Label Switched Paths (LSPs) get implemented over various packet and frame-based link level technologies 🛣️. The working group charter covers procedures and protocols for distributing labels between routers, plus encapsulations, operation and management, traffic engineering, and multicast considerations 🌈.

This document assumes that the MPLS working group stays the chartered authority on MPLS technologies 👑. It also notes that the IETF may appoint another working group (refer to [RFC2418]) to handle specific extensions or changes to the protocols 🔀. And if the MPLS working group finishes its work and gets closed, the IETF will use the non-working group standards track document process (described in [RFC2026]) with designated experts from the community [RFC2434] for the MPLS protocols 🫶.

2.1.2. Common Control & Measurement Plane Working Group 🦋

okay bestie, so the CCAMP working group (Common Control and Measurement Plane) is the crew that coordinates the IETF work on 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 so they support multiple physical path and tunnel technologies, using input from technology-specific working groups like the MPLS working group 💅. It also covers developing protocol-independent metrics and parameters for describing links and paths that can be carried in protocols ✨.

The technology CCAMP focuses on is called Generalized MPLS (GMPLS) 💖, which tells you CCAMP is all about a generalized technology, where labels are defined so they stay compatible with the technology the data is transported over. Like, the MPLS working group is focused on packet- and frame-switched technologies, but CCAMP is going for common methods across a broad spectrum of switching technologies, including packet and frame technologies 🫶. So honestly? GMPLS can be viewed as a superset of MPLS 👑.

The procedures in this document assume that the CCAMP working group stays the authority on GMPLS technologies 🎀, but the IETF may appoint another working group (refer to [RFC2418]) to handle specific extensions or changes to the protocols 🧚. And if the CCAMP working group ever finishes its work and gets 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 🌸

ngl, the MPLS and CCAMP working groups sometimes split up the work between themselves in a way that doesn't strictly follow the split in their 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 💜.

So if an entity or individual wants to propose extensions or changes to (G)MPLS, they should first decide which working group (MPLS or CCAMP) they're bringing the proposal to 🍓. However, the MPLS and CCAMP working group chairs, together with their Area Directors, may redirect the proposal to another working group 🔥.

Problem statements and requirements for (G)MPLS technology have been produced by several working groups besides MPLS and CCAMP 💅. IETF working groups are defined for managing specific tasks by their charter 📜. The charter defines their role, their relationship with other working groups, and the applicable procedures to follow when extensions to (G)MPLS may be needed ✨. This section gives you an overview of the (G)MPLS-related groups and their responsibilities, and extra info about 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 that focus on problem statements and requirements for (G)MPLS, to be considered by the (G)MPLS working groups 🌸. These working groups haven't specified any protocols, though 🙈.

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 that working group needs to extend or change the (G)MPLS protocols, the procedures specified by its charter and the IETF's standard processes apply 🫶.

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 🌐. A lot of the L2VPN and L3VPN work doesn't include specifying new protocols or extensions to existing protocols 😭. Where extensions are needed, the procedures in their charters and the IETF's standard processes apply 💅.

The Layer 1 VPN (L1VPN) working group is chartered to specify mechanisms needed 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 means the L1VPN working group won't develop GMPLS protocol extensions in isolation 🙅. Instead, it 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 extensions or changes to the (G)MPLS protocols, the procedures in its charter and the IETF's standard processes apply 🌸.

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's 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 apply 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 👑.

3. Overview of (G)MPLS Change Process 🧚

This is a non-normative section 🙈, since it's meant to give a high-level view of [RFC4775] procedures for protocol extensions. Application of these procedures for (G)MPLS is defined in detail in Section 4 ✨.

Whenever there's reason to believe a particular problem may be solved by using or extending the (G)MPLS protocols 🔥, a communication can be used to discuss the problem with the IETF 💌. For that, use the formal liaison process or, for a forum without a formal relationship, an informal communication ([RFC4052] and [RFC4053]) 🌈. Collaborating with the IETF in the early discussion phase helps everyone understand quickly whether the problem has already been solved, whether it might be outside the scope of the (G)MPLS protocols, or whether it needs 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 the IETF as an Internet-Draft 📝. When the requirements come from an external organization, informal communications, like e-mail to working group mailing lists, are strongly encouraged because they make the work move faster and more cooperatively 💜. But if you want, the Internet-Draft containing the requirement(s) can be submitted to the working group using a formal liaison statement 🎀. The IETF's response will be given as a reply to the liaison 💅. Using formal communication cuts the risk of confusing one participant's opinion with the group's opinion (which can happen on mailing lists) 👑, though it does mean a longer communication cycle 😭. If there's 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 may take some communication and discussion for clarification, but the IETF commits to doing the assessment in a timely manner ⭐.

When assessing the requirements statement I-D, the IETF may determine any of the following 🔍:

that the requirements can be satisfied without modifications to the (G)MPLS protocols
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

If the IETF agrees to develop a solution, it will set milestones that result in timely delivery of the solution 🗓️. If the IETF rejects the requirements, that will only be done with a clear explanation and full discussion with the source of the requirements 🫶.

Solutions developed within the IETF may be sourced from external organizations and presented for review, discussion, modification, and adoption as Internet-Drafts 🌸. Solution drafts may be presented to the IETF before the requirements work is complete, but all solutions will go 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 covering the solutions work 🔥. It's strongly recommended that interested parties start informal discussion in the IETF as early as possible and co-author in the IETF's work ✨. It's not recommended for the source forum to keep working on solutions in parallel with ongoing 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 making sure the work gets completed 💖.

4. MPLS and GMPLS Change Process ✨

okay so this section is the rulebook for how anyone changes or extends the (G)MPLS protocols 💅 it's using the [RFC2119] language so everyone knows exactly what's required of the IETF and of whoever's asking for the change 🎀 and it lines up with the general protocol extension process in [RFC4775], so any reading or implementing of these steps has to match [RFC4775] too 🫶

if you want to use one of the existing (G)MPLS protocols but you're like "ngl this doesn't cover what I need," you MUST follow the procedures in this document 🔥 they SHOULD happen inside the IETF, unless the Area Director(s) think the changes are non-controversial (like they're already covered by the working group charter). then the rest of the normal IETF standards process applies instead 🦋 changes or extensions to the (G)MPLS protocols MUST NOT go through any other mechanism, no exceptions bestie 🙅‍♀️ the IETF MUST NOT endorse any publications (RFCs on the Standards Track, Informational, or Experimental, all of them 💀) that change or extend the (G)MPLS protocols, unless they came out of doing these procedures correctly 🌸 and the IETF MUST NOT endorse any IANA action that allocates (G)MPLS protocol codepoints either, unless it came from correctly following this process 👑

4.1. Flow Diagram

okay so Figure 1 is a visual tour of how the (G)MPLS requirements evaluation working group (REWG) and the (G)MPLS protocol solutions working group (PSWG) fit together 🧚 a requestor has two options: (1) reach out to the IETF super early during the problem definition phase (the preliminary investigation), or (2) come in later with a requirements statement 💜 the figure is just for illustration, so it's NOT showing every single interaction or IETF procedure option 🙈 the subsections after this one walk through the actual process 🍓

  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
              +--------+                +-------+    +--------| 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 part is the walkthrough of how the (G)MPLS change process actually works 🔥 it covers what's expected from individuals or organizations who want to extend or change the (G)MPLS protocols, plus what the IETF is responsible for ✨

4.2.1. Preliminary Investigation

this step is OPTIONAL 🫶 (ok, I'm yelling it on purpose, it's a key word, and it's giving "you can totally skip this if you want") it's a chill way to "feel out" where the IETF stands on a proposal without writing a whole Internet-Draft 🦋 the goal is to figure out whether the problem has already been looked at, whether it's even in scope for the IETF, and whether solutions already exist 💅

even though this phase is optional, it is RECOMMENDED that whoever originates a requirement talks through the issues with people as early as possible so nobody wastes time 🍓 the preliminary investigation phase is literally the tool for that 🧚

this is where you can have useful discussions to make sure the problem statement and the requirements statement Internet-Drafts have the right stuff in them 🌸 it's called lightweight because no Internet-Draft is needed and most of the talking happens offline 💜 but honestly, it could get super technical and turn into a big, deep exchange of ideas and opinions 😭

this step SHOULD happen informally on the REWG mailing list or on the Routing Area discussion mailing list 🎀 and it MAY be kicked off by any individual, group of individuals, external organization, or IETF working group 👑

if an external SDO has a liaison relationship with the IETF, it MAY do this step through a formal liaison ✨ the liaison SHOULD go to the designated liaison manager, who forwards it to the IESG, and the IESG assigns a Responsible AD 🫶 the people who started the liaison SHOULD be available to chat on the selected mailing list 🦋 if a formal liaison is used, the IETF responds using the procedures of [RFC4053] 💅

at this stage, a problem statement I-D MAY be written to keep the discussion going and make the issues clearer 🌈

one possible outcome of this preliminary investigation is that everyone gets the requirements and the problem, but agrees it's out of scope for the IETF 🙃 another possible outcome is that the problem can already be solved with existing protocols 🍓 the full list of outcomes from this phase is pretty similar to the ones from the requirements statement evaluation phase in Section 4.2.2, but if the IETF wants to develop protocol solutions, the requirements statement evaluation phase MUST be part of the process, because that's where the wider IETF community gets to help build a complete set of requirements 🔥 the process can't jump straight from preliminary investigation to developing solutions unless the working group agrees (e.g., the problem is minor) 💀

4.2.2. Requirements Statement Evaluation

before the IETF can formally weigh in on requests to change or extend the (G)MPLS protocols, a requirements statement I-D MUST be written per [RFC2026] 👑 this is the main paper trail, bestie 📝

the requirements statement I-D MUST be introduced to the IETF by its authors, either through an email to the REWG mailing list, to the Routing Area discussion mailing list, or through a formal liaison from an external SDO that results in the IETF bringing the requirements statement I-D to the REWG mailing list 🎀 if it comes in through a formal liaison, the people who started the liaison SHOULD be available to talk on the designated IETF mailing lists 🫶

after the IETF mailing lists have discussed it, the responsible Area Director MUST decide whether the IETF will formally evaluate the requirements 🔥 and they MUST deliver a response per [RFC4053] and [RFC4775] 💅 if a formal liaison wasn't used, the response SHOULD go to the appropriate contact listed on the communication 🌸

the IETF response MUST be explanatory enough to tell the requesting organization what the IETF has decided to do about the request, if anything 💜 here are some examples of possible responses to illustrate the idea 🧚

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. 🦋

4.2.3. Working Group Procedures

in a lot of cases, the problem in the requirements statement I-D fits inside the existing charter of a working group 🌈 when that happens, the responsible Area Directors will name that working group as the REWG and hand the requirements statement I-D over for evaluation 💅 if the problem isn't covered by an existing charter, other options (see [RFC2418]) can be used, like rechartering, a BOF, or chartering a brand new working group ✨

if the IETF changes its earlier decision to accept the work, the IETF MUST tell the requestor about it in a timely manner 😭 no ghosting allowed, periodt 💅

4.2.4. REWG Evaluation of the Requirements Statement I-D

the whole point of the REWG evaluation is to pin down a clear and complete statement of the requirements for changes or extensions to the (G)MPLS protocols 💜 this takes normal IETF working group procedures inside the REWG and MAY include making revisions to the requirements statement I-D, worked out together by REWG members and the original authors 🫶

the originators of the requirements statement I-D MUST be available to discuss the work on the REWG mailing list 🙈 if that doesn't happen, the REWG chairs MAY decide there isn't enough support for the work and MAY reject the requirements statement I-D 💀

the REWG will end up with one of two outcomes 🔥

a completed requirements statement I-D that the working group has accepted by consensus within the REWG and that has gone through working group last call;

a rejection of the requirements, using the response procedure described in Section 5. 👑

4.2.5. AD Evaluation of Completed Requirements Statement I-D 💅

Okay so, just like every Internet-Draft a working group produces, the ADs take a close look at the finished requirements statement I-D that the REWG put together 👀. Then they pass it along to the IESG for review. If charter changes are needed, or a brand-new PSWG is needed, the right process gets followed too ✨.

4.2.6. IESG review of Requirements Statement I-D and PSWG Charter 🧚

Same energy as any Internet-Draft: the IESG reviews the requirements statement I-D and decides what happens to it next 🔍.

If the IESG rejects it, they write an appropriate response to the working group (and, if needed, to the originator of the request) 📝.

The IESG also reviews any proposed charter changes for the PSWG or, if needed, considers alternatives 🤔. That might mean forming a brand-new working group just to tackle the solutions 🎀.

4.2.7. Solutions Work 🦋

The appropriate PSWG kicks off the solutions work, following the normal IETF process 💜.

Solutions I-Ds MAY be prepared externally (like inside some external organization) or within the IETF. They get submitted to the IETF for draft publication using the procedures of [RFC2418], then introduced to the PSWG for consideration 📬. They MAY also be submitted at earlier stages to help the REWG with its development and discussion of the requirements 🌸. Just know that no I-D counts as a formal solutions I-D until the PSWG has a charter item covering the work and the REWG chairs feel confident the requirements are stable 🫶.

The IETF makes no guarantees that an externally produced solutions I-D will become 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 whole vibe is open and fair participation, plus really thorough consideration of technical alternatives ✨.

Interested parties (both implementers and users) of the SDO that originated the request are strongly encouraged to join the PSWG 🙌. That way the right amount of interest shows up for the solutions work, and the solutions get developed on time 🔥. The IETF's work, like 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 😬. If that happens, the originator of the request gets appropriate communication about the discontinued work (as long as they can be reached) 📭.

The final development of the solutions I-D is subject to the normal working group review, consensus, and last call within the PSWG ✅.

Where the requirements came from an external organization, the PSWG SHOULD regularly communicate its progress using a formal liaison process, if one exists 📣. That communication SHOULD also be used to ask for 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 🚫

Rejecting requirements statements is a sensitive matter for their authors, so it 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 making the rejection is responsible for generating an explanation of it, and they 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 are 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 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. It MAY cooperate with the authors of the requirements statement I-D in producing 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 the 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. 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 take part 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 to completing 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, 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 a way that 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 discussion of protecting 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 organization, 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 generating 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 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 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 ✨

okay so, once the PSWG has started the solutions work, it can still get abandoned before it's finished 💀. This can happen if the PSWG chairs decide there's no working group support left for doing the work. Like, if nobody (including the people who wrote the requirements statement I-D) is willing to help build a solutions I-D 😭.

If the solutions work gets 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 is over, and how they hear about it depends on how the requirements got introduced in the first place (see Section 5.2 🎀).

If the solution gets abandoned like this, work on solutions for the requirements MUST NOT be started in another forum 🚫. The status of extensions and changes to the (G)MPLS protocols for those specific requirements goes right back to how it was before the process started 🔙. Any new look at the requirements MUST commence at the top of the process 🔝.

Basically, abandonment is a full reset, bestie. No sneaking the work into another room 💅.

6.1. Appeals

The abandonment of a solutions I-D may be appealed if it's disputed and can't be sorted out by talking it through directly 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 🛡️. They MUST NOT extend the GMPLS architecture with features that don't have general use beyond the specific case 🙅‍♀️. They also MUST NOT modify the architecture just to make some function more efficient if that costs 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 🧚. Adding features that overlap, or that handle a point solution and aren't general, is way harder to control with rules and can put the whole protocol at risk 😬. So, to keep operational and technical risks low for (G)MPLS technology, IETF processes SHALL be followed for any requests for extensions to (G)MPLS protocols 🌸. The (G)MPLS PSWG is the chartered "owner" of the (G)MPLS protocol for 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 🔥

This part is SERIOUS, bestie, so pay attention 🙈.

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 on 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 uses the IETF process and adds clarity to that process, so it's possible that this document might put the IETF process at risk 😭.

So, provided the number of requirements statement I-Ds is not unreasonable, there will be no significant impact on the IETF process 🌈. The rate at which requirements statement I-Ds arrive MAY be used by the IESG to detect denial of service attacks 👀. The IESG SHOULD act on such an event depending on where the requirements statement I-D came from and how relevant the work seems 🫣. For example, the IESG might discuss the issue with the management of external organizations 🤝.

9. Acknowledgements 🎀

The input given by Bert Wijnen has been super useful and detailed 🫶.

Review feedback and discussions with various members of the ITU-T have been so helpful in refining the process described in this document 🌸. Huge thanks 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 ITU-T participants: 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 ✨.

10. IANA Considerations 🧾

This document makes no specific requests to IANA for action 🙅‍♀️. The procedures described here assume that IANA will stick to the allocation policies defined for the (G)MPLS codepoint registries 📚. They also assume that the IETF will not endorse allocating codepoints from those registries, except where the work has been done according to the procedures 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.

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

Full Copyright Statement ⚖️

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, 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 💖.

📦 where this page comes from

ietf: rfc4929 2007-06
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms