[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 4929

Network Working Group                              L. Andersson (Editor)
Internet-Draft                                                  Acreo AB
Proposed Status: Best Current Practice                A. Farrel (Editor)
                                                      Old Dog Consulting

                                                            October 2006


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

                  draft-andersson-rtg-gmpls-change-05


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   The issues surrounding the extensibility of IETF protocols have been
   widely debated. These issues include when it is reasonable to
   extend IETF protocols with little or no review, and when extensions
   or variations need to be reviewed by the larger IETF community.
   Experience with IETF protocols has shown that extensibility of
   protocols without early IETF review can cause problems.

   The Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
   suites of protocols have become popular for a number of applications
   and deployment scenarios. One result of this popularity is a large
   number of suggestions for modifications and extensions.



Andersson and Farrel                                            [Page 1]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

   This document defines a flexible and responsive process for the IETF
   to handle suggestions for extensions to the MPLS and GMPLS protocols,
   and clarifies the IETF's responsibility to supervise the growth and
   evolution of MPLS and GMPLS protocols.

   The process allows individuals, IETF working groups, and external
   standards bodies to influence the development of the MPLS and GMPLS
   standards. When possible, existing liaison relationships are used.


Table of Contents

   1. Introduction ................................................... 3
   1.1 Document Source ............................................... 4
   1.2 Conventions Used in this Document ............................. 4
   2. Applicability of the (G)MPLS Change Process .................... 4
   2.1 IETF Working Groups Developing (G)MPLS Technology ............. 4
   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 Working Groups ...................... 6
   2.3  Organizations Outside the IETF ............................... 7
   2.4  Terminology .................................................. 7
   3. Summary of Procedures .......................................... 9
   4.  MPLS and GMPLS Change Process ................................ 10
   4.1  Flow Diagram ................................................ 11
   4.2  Description of Process Stages ............................... 12
   4.2.1 Preliminary Investigation .................................. 12
   4.2.2 Requirements Statement Evaluation .......................... 12
   4.2.3 Chartering the Rewg ........................................ 13
   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 and IAB review of Requirements Statement I-D and Pswg
         Charter .................................................... 15
   4.2.7 Solutions Work ............................................. 15
   5. Rejecting Requirements Statements I-D ......................... 16
   5.1 Reasons for Rejection ........................................ 16
   5.2 Actions Upon Rejection ....................................... 17
   6. Abandonment of the Solutions I-D .............................. 18
   7. (G)MPLS Integrity ............................................. 19
   8.  Security Considerations ...................................... 19
   9.  Acknowledgements ............................................. 20
   10. IANA Considerations .......................................... 20
   11.  References .................................................. 20
   11.1  Normative References ....................................... 20
   11.2  Informative References ..................................... 20





Andersson and Farrel                                            [Page 2]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

1. Introduction

   [PROT-EXT] discusses procedural issues related to the extensibility
   of IETF protocols, including when it is reasonable to extend IETF
   protocols with little or no review, and when extensions or variations
   need to be reviewed by the larger IETF community. Experience with
   IETF protocols has shown that extensibility of protocols without
   early IETF review can cause problems. [PROT-EXT] also recommends that
   major extensions to, or variations of, IETF protocols only take place
   through normal IETF processes or in coordination with the IETF.

   This document recognizes that the Multiprotocol Label Switching
   (MPLS) and Generalized MPLS (GMPLS) protocol families were created
   within the IETF and constitute significant protocol suites that are
   strategic to the development of the Internet. They should not be
   extended or varied without IETF review, and that should preferably
   only be extended within the IETF process.

   The process described in this document allows individuals, IETF
   working groups, and external standards bodies to influence the
   development of MPLS and GMPLS protocols and related standards. The
   process means that MPLS and GMPLS extensions and changes can only be
   done through or in coordination with the IETF. In particular, the
   MPLS and/or CCAMP working groups or their successors need to be
   involved in the process. When possible, existing liaison
   relationships ([RFC4052], [RFC4053]) are leveraged.

   The IETF will not endorse the publication of any MPLS or GMPLS
   protocol or technology extensions in RFCs or other documents where
   the process described here have not been followed. If publication of
   individual Internet-Drafts describing extensions or changes to the
   MPLS or GMPLS protocols is requested of the RFC Editor the documents
   will be returned to the process described in this document using the
   mechanism described in [RFC3932].

   IANA is responsible for managing many codepoints registries including
   those for MPLS and GMPLS protocols. These registries have specific
   allocation policies that IANA uses in order to determine whether
   codepoints can be allocated and which codepoints to allocate. In many
   cases, the rules require IANA to refer back to the IETF when asked to
   make an allocation. In the case of changes or extensions to the MPLS
   or GMPLS protocols, IANA will use the process described in this
   document to judge whether or not a code point allocation should be
   made.

   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"

Andersson and Farrel                                            [Page 3]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

   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.

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 liaison
   to the ITU-T. It has 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 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. Applicability of the (G)MPLS Change Process

   This section outlines the applicability of the (G)MPLS change process
   specified in this document. It lists the key IETF working groups
   developing the (G)MPLS technology, examples of IETF working groups
   using the (G)MPLS technology, and possible parties interested in
   using, extending, or changing the (G)MPLS technology.

   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.

   A section listing terminology local to this document that will be
   used in specifying the change process is also included.

2.1 IETF Working Groups Developing (G)MPLS Technology

   Two working groups in the IETF's Routing Area have been responsible
   for work to develop the (G)MPLS technology. The Multiprotocol Label
   Switching (MPLS) working group and the Common Control and Measurement
   Plane (CCAMP) working group.

   The sections below give brief overviews of the work these two IETF
   working groups were chartered to do.

   The IETF may, in the future, define additional working groups to work
   on specific chartered issues related to (G)MPLS. Further, specific
   existing working groups such as those listed in section 2.2 may be

Andersson and Farrel                                            [Page 4]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

   rechartered by the IESG to work on particular aspects of the (G)MPLS
   protocols. The procedure for chartering new or existing working
   groups to undertake (G)MPLS work is covered in section 4.2.3.

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.

   The procedures in this document assume that the MPLS working group
   remains the authority on MPLS technologies, but acknowledges that
   the IETF may appoint another working group (using the procedures in
   this document) 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 may appoint a Designated
   Expert (sometimes known as a Caretaker) 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
   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 (using the procedures in
   this document) 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 may appoint a Designated

Andersson and Farrel                                            [Page 5]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

   Expert (sometimes known as a Caretaker) 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 technology.

   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 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. For example, the IP over Optical (IPO) working group
   and the Internet Traffic Engineering working group (TEWG). These
   working groups have not specified any protocols, but have been a
   source of problem statements and requirements to be considered by the
   (G)MPLS working groups.

   Other working groups, e.g., the Bidirectional Forwarding Detection
   (BFD) working group, also use the (G)MPLS protocols and mechanisms.
   When any of these working groups needs to extend or change the
   (G)MPLS protocols the procedures specified in this document 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. The
   work of the L2VPN and L3VPN working groups does not include
   specifying new protocols, however, protocol changes and extensions
   to the (G)MPLS protocols may be needed. If so, the procedures
   specified in this document 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 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.

Andersson and Farrel                                            [Page 6]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

   The Pseudo Wire Emulation End to End (PWE3) working group is another
   working group in the Internet Area that also uses the (G)MPLS
   protocols in its specifications. Should the PWE3 specifications
   require extension or changes to the (G)MPLS protocols the procedures
   specified in this document are applicable.

   It is assumed that the change process for the MPLS and CCAMP working
   groups, specified in this document, will be applicable or at least
   adaptable to other (G)MPLS technology working groups if such a need
   should arise.

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 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 or believes it may have a requirement for
   extensions or modifications to the (G)MPLS protocols then the
   procedures in this document apply.

   It should be noted that the first stage in the change process is an
   optional Preliminary Investigation (see Section 4.2.1). This stage is
   explicitly included to allow external organizations to discuss
   requirements and proposed uses of the (G)MPLS technologies without
   the need to first develop Internet-Drafts, and builds on existing
   liaison processes where they exist.

2.4  Terminology

   This section defines terms for use in the context of this document.

   o  (G)MPLS protocols
      The (G)MPLS protocols are the protocols and protocol variants
      developed by the IETF to control, manage, or measure MPLS or GMPLS
      networks and their component devices.

      The set of RFCs that constitutes the (G)MPLS protocols are the
      standards track RFCs from the (G)MPLS working groups (see below).
      A list of these RFCs is not supplied here since new RFCs are
      produced from time to time.


Andersson and Farrel                                            [Page 7]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

      For the purpose of extending and changing any protocols specified
      in Experimental RFCs developed by the (G)MPLS working groups,
      those protocols are considered to be part of the (G)MPLS
      protocols.

   o  (G)MPLS working groups
      The (G)MPLS working groups are the MPLS and the CCAMP working
      groups, and any future working group specifically chartered by the
      IESG to work on the development or extension of the (G)MPLS
      protocols.

   o  (G)MPLS technology working group
      Any working group chartered by the IESG to specify requirements
      for the (G)MPLS protocols, and any working group that specifies a
      use for the (G)MPLS protocols. This include the (G)MPLS working
      groups.

   o  Requirement evaluating working group (rewg)
      The rewg is the IETF working group charged with the task of
      evaluating a specific set of requirements and the associated
      problem statement.

   o  Preliminary Investigation
      An optional preliminary phase that may be used to exchange views
      on a proposed requirement and usage of the (G)MPLS technologies
      without going to the effort of writing an Internet-Draft. This
      phase may be particularly useful to SDOs that have already
      invested heavily in documenting a problem statement, or may be
      used by anyone who wishes to hold discussions on the use of
      (G)MPLS.

   o  Protocol specifying working group (pswg)
      The pswg is the working group chartered by the IESG to specify
      changes or extensions to the (G)MPLS protocols either as part of
      the normal IETF process or in response to a requirements draft.

   o  Problem statement Internet-Draft
      The Internet-Draft that initiates the discussion on changing or
      extending the (G)MPLS protocols. This draft includes a detailed
      problem description that (G)MPLS is called on to solve. The
      problem statement draft may also include the requirements (see
      requirements statement Internet-Draft, below).

   o  Requirements statement Internet-Draft
      This Internet-Draft provides a detailed list of the requirements
      that the (G)MPLS extensions or changes need to fulfill. This draft
      may be merged with the problem statement draft (see above).

   o  Solutions Internet-Draft
      A specification of extensions or changes to the (G)MPLS protocols

Andersson and Farrel                                            [Page 8]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

      to meet the requirements in the requirement statement
      Internet-Draft.

3. Summary of Procedures

   This non-normative section is intended to provide a high-level view
   of the procedures in this document to illustrate how they work and to
   introduce the mechanisms that 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
   preliminary investigation phase may be used to discuss the
   requirements with the IETF. This may lead to an understanding that
   the problem is already solved, is outside the scope of the IETF, or
   requires more investigation possibly leading to changes to the
   (G)MPLS protocols.

   Whenever any extension or change to the (G)MPLS protocols is desired,
   a requirements statement must be produced and must be submitted to
   IETF as an Internet-Draft. As described in [RFC4052], when the
   requirements come from an external organization informal
   communications such as e-mail to working group mailing lists often
   facilitates cooperative work. However, if desired, the Internet-Draft
   containing the requirement may be submitted to the working group
   using a liaison statement. That way, the IETF's response to the
   request will be given as the reply to the liaison, with no risk of
   confusing an individual participant's opinion for that of the group
   as can happen on mailing lists.

   The IETF, through the Routing Area Directors and the chairs of the
   MPLS and CCAMP working groups, 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; that the requirements are not sufficiently general
   to warrant a change to the (G)MPLS protocols; that the requirements
   justify a change to the (G)MPLS protocols that will be created by the
   IETF or within another organization; 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; or 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 commit to do so in a timely manner. If the IETF rejects the
   requirements, this will only be done with clear explanation and full

Andersson and Farrel                                            [Page 9]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

   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 compete through the normal
   IETF process with other proposed solutions, and none will be adopted
   as an IETF working group draft until the requirements are agreed by
   the rewg chairs to be stable and, in any case, not before the pswg
   has a charter item to cover the solutions work.

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 precise required behavior.

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





















Andersson and Farrel                                           [Page 10]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

4.1  Flow Diagram

   Figure 1 is presented to give a visual overview of the process. It
   does not contain all of the possible interactions of procedures, and
   the text in the subsequent sections should be used for a definitive
   description of the process.

     Start                     +-------------+
       |                       |optional     |
       +--<--------------------|preliminary  |<-------Start
       |                       |investigation|
       V                       +-------------+
   +------------+            +---------+              +---------+
   |requirements| discussion |review by|     ACK      |  IESG/  | ACK
   |statement   |----------->|WG chairs|------------->|   IAB   |------+
   |I-D         | on mailing |and ADs  | request to   |decision |      |
   +------------+   list     +---------+ IESG/IAB to  +---------+      |
                              |          appoint rewg   |              |
                              | NAK      and charter    |NAK       rewg|
                              V          req eval       |     chartered|
                       +-------------+                  |    to work on|
                       |response     |                  |  requirements|
                       |to the       |                  |     statement|
                       |requirements |<-----------------+              |
                    +->|statement    |<----------------+               |
                    |  +-------------+                 |               |
                    |      ^                           |               |
                 NAK|      |     NAK                   |               |
                    |      +-----------------+         |               V
                    |                        |         |  NAK   +------+
                +--------+                +-------+    +--------| rewg |
                | IESG/  |        ACK     |   AD  |             |  req |
    +-----------|  IAB   |<---------------|review |<------------| eval |
    |WG         |decision|    request to  |       |     ACK     |      |
    |chartered  +--------+   IESG/IAB to  +-------+             +------+
    |to work                 approve I-D
    |                        and charter
    |
    |          +---------+
    |          | IETF    |             +-----+
    +--------->|  WG     |-----/ /---->| RFC |
         +---->| process |             +-----+
         |     +---------+
     solutions
        I-D

                     Figure 1: Change Process Overview




Andersson and Farrel                                           [Page 11]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

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 (G)MPLS
   working groups, the Routing Area and the IETF in general.

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.

   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 rewg or to the Routing Area, and the initiators of the
   liaison SHOULD make themselves available for discussion on the
   selected mailing list. If a formal liaison is used, the IETF MUST
   respond to pursue the discussion.

   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.

4.2.2 Requirements Statement Evaluation

   Before the IETF can formally pronounce on requirements to change or
   extend the (G)MPLS protocols, a requirements statement I-D MUST be
   written and submitted to the IETF for publication.

   The requirements statement I-D MUST be introduced to the IETF through

Andersson and Farrel                                           [Page 12]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

   an email to the rewg mailing list or 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 appropriate
   mailing lists.

   After discussion on the IETF mailing lists, the appropriate IETF
   working group chairs and the Routing Area Directors MUST decide
   whether the requirements will be formally evaluated by the IETF, and
   MUST deliver a response to the requirements statement I-D.

   If the requirements statement I-D is brought to the IETF through a
   formal liaison, the IETF MUST respond using one of the following
   answers in a formal liaison reply:

   a.  Requirements not understood.  Further discussion 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
       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
       appropriate 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 Chartering the Rewg

   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 Routing Area Directors SHOULD designate the
   working group as the rewg and pass the requirements statement I-D to
   the working group for evaluation.

   If a new charter item is required, the Routing Area Directors with
   assistance from working group chairs MUST apply to the IESG and IAB

Andersson and Farrel                                           [Page 13]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

   for a modification of an existing working group's charter or for the
   creation of a new working group. If the IESG and IAB approve the
   charter, the requirements statement I-D is passed to the rewg for
   evaluation. If the charter change is not approved, the IESG and IAB
   MUST respond to the requirements statement I-D and, if the
   requirements were introduced through a formal liaison from another
   SDO, the IESG and IAB MUST send a liaison response using the options
   described in Section 5.

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 MUST 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 following exactly the same format
     and 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 MUST
   review the completed requirements statement I-D produced by the rewg
   to determine its fitness for publication. At their discretion, the
   ADs MAY use an Area Directorate and/or other subject matter experts
   to assist them in this review

   The result of the AD review MAY request the rewg to do further work
   on the I-D in which case the previous step and this one will be
   repeated.

   The ADs SHOULD NOT reject the requirements statement I-D outright at
   this stage since the requirements have already been accepted by the

Andersson and Farrel                                           [Page 14]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

   ADs at an earlier stage. However, in some situations (such as a
   significant change in related circumstances) the ADs MAY reject the
   requirements statement I-D using the format and procedure described
   in Section 5.

   When the ADs accept the requirements statement I-D they MUST pass it
   to the IESG for review, and propose any charter changes necessary to
   select a pswg.

4.2.6 IESG and IAB review of Requirements Statement I-D and Pswg Charter

   As with all Internet-Drafts, the IESG MUST take a ballot on the
   progression of the requirements statement I-D.

   If the IESG rejects the requirements statement I-D, it MUST generate
   a response to the requirements as described in Section 5.

   The IESG and IAB MUST take a ballot on any proposed charter changes
   for the pswg. This MAY include the formation of a new working group
   specifically to work on the solutions, although it is also possible
   that the solutions work is covered by an existing working group
   charter without any changes.

   If the IESG rejects working group charter changes such that it is not
   possible for the IETF to work on solutions for the requirements in
   the requirements statement I-D, this MUST be treated as a rejection
   of the requirements statement I-D, and the requirements statement I-D
   MUST NOT be published as an RFC. In this case the IESG MUST reject
   the requirements statement I-D using the format and procedure
   described in Section 5.

4.2.7 Solutions Work

   Once the requirements statement I-D has been approved by the IESG it
   will enter the RFC Editor's queue and be handled according to normal
   IETF process.

   Once the pswg has been identified and (re-)chartered as necessary and
   the requirements statement I-D has been approved by the IESG, the
   pswg can 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
   publication, 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-Ds until the pswg has a
   charter item that covers the work and the rewg chairs are confident
   that the requirements are stable. Even at this stage in the process,
   the IETF makes no guarantees that an externally produced solutions

Andersson and Farrel                                           [Page 15]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

   I-D will form the basis of the pswg solutions I-D, but the pswg MUST
   consider such an I-D as a possible solution I-D.

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

   The requirements can be rejected at various stages of the process as
   described in the previous sections. The person or grouping that makes
   the rejection is responsible for generating an explanation of the
   rejection and MUST follow the process described in this section.

5.1 Reasons for Rejection

   The requirements statement I-D can only be rejected using one of the
   following reasons. Each reason MUST be stated with the acceptable
   next steps as described here.

   - Requirements not understood. At the early stage of evaluation of
     the requirements statement I-D before the rewg has been tasked with
     performing a full evaluation and completing the requirements
     statement I-D or during the optional preliminary investigation it
     is not clear what the requirements are for 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 permission to work on a solution.

   - 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

Andersson and Farrel                                           [Page 16]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

     case no further evaluation of the requirements is required, but the
     IETF 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. In this case, the IETF MUST
     grant the authors of the requirements statement I-D permission to
     work on a solution. The solution SHALL be presented to the IETF
     for review and possible publication as an Informational or
     Experimental RFC, and the IETF SHALL NOT block applications to IANA
     for codepoints.

   - Insufficient support for the work. 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
     re-introduced 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.

5.2 Actions Upon Rejection

   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. The reasons SHOULD be based on the list in
   Section 5.1.

   The form of the rejection depends on the form of the original
   submission as follows.

Andersson and Farrel                                           [Page 17]

Internet-Draft        MPLS and GMPLS Change Process         October 2006


   - If the requirements are brought to the IETF as a preliminary
     investigation (see Section 4.2.1) through an email exchange then
     the response SHOULD be made as an email response and SHOULD be
     archived through an IETF email archive.

   - 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 SHOULD 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 response lies with the person,
   people, or grouping that instigates the rejection. This may be the
   IAB, the IESG, one or more Area Directors, one or more working group
   chairs, or a protocol caretaker. 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.

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 stopped 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

Andersson and Farrel                                           [Page 18]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

   started. Any new examination of the requirements MUST commence at
   the top of the process.

7. (G)MPLS Integrity

   The (G)MPLS working groups are REQUIRED to protect the architectural
   integrity of the (G)MPLS protocols and SHOULD 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 be 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. Therefore the (G)MPLS technology
   calls for this architectural guardianship by its working groups.

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 details to that
   process. It is possible, therefore, that this document might put the
   IETF process at risk. Although this document places additional
   requirements on key individuals within the IETF, those requirements
   are not substantial for any individual requirements statement I-D
   since the responsibility for the majority of the work lies with the
   rewg and pswg with an underlying assumption that the authors of the
   requirements statement I-D will participate in the working group
   process.

   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.



Andersson and Farrel                                           [Page 19]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

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.

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4052]  Daigle, L., "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, RFC4053, April 2005.

   [PROT-EXT] Bradner, S., and Carpenter, B., "Procedures for protocol
              extensions and variations", draft-carpenter-protocol-
              extensions, work in progress.

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.

   [RFC3932]  Alvestrand, H., "The IESG and RFC Editor Documents:
              Procedures", BCP 92, RFC 3932, October 2004.


Andersson and Farrel                                           [Page 20]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

Authors' Addresses

   Loa Andersson
   Acreo AB
   Email: loa@pi.se


   Adrian Farrel
   Old Dog Consulting
   Email: adrian@olddog.co.uk


   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

Intellectual Property Statement

   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.

Andersson and Farrel                                           [Page 21]

Internet-Draft        MPLS and GMPLS Change Process         October 2006

   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.

Disclaimer of Validity

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

Copyright Statement

   Copyright (C) The Internet Society (2006).  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.























Andersson and Farrel                                           [Page 22]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/