[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
Internet-Draft                                                  Acreo AB
                                                               A. Farrel
                                                      Old Dog Consulting
                                                              G. Swallow
                                                           Cisco Systems
                                                             K. Kompella
                                                        Juniper Networks
                                                                A. Zinin
                                                                 Alcatel
                                                               B. Fenner
                                                    AT&T Labs - Research
                                                           December 2005


                     MPLS and GMPLS Change Process
                  draft-andersson-rtg-gmpls-change-02

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.

Copyright Notice

   Copyright (C) The Internet Society (2005).







Andersson, et al.                                               [Page 1]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


Abstract

   The MPLS and GMPLS protocol suites have become quite popular for a
   growing number of applications and deployment scenarios.  One result
   of this popularity is a large number of suggestions for modifications
   and extensions.

   The IETF needs to be flexible and responsive in how it handles these
   suggestions, and has a responsibility to supervise the growth and
   evolution of MPLS and GMPLS protocols.

   This memo describes the process through which individuals, working
   groups and external standards bodies can influence the development of
   the MPLS and GMPLS standards.  This process means that extensions and
   changes to protocols specified by these working groups can only be
   made through the IETF, the body that created the (G)MPLS
   ((Generalized) Multiprotocol Label Switching) technologies.  When
   possible, existing liaison relationships are used.

Status of this Proceess

   Note that this process is still in flux; although the general shape
   of the process is expected to remain the same, the details,
   especially in the realm of liaisons and interactions with other SDOs,
   may change.

   Comments are solicited and should be addressed to the Routing Area
   mailing list at routing-discussion@ietf.org and/or the authors.






















Andersson, et al.                                               [Page 2]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Managing the (G)MPLS technology in the IETF  . . . . . . . . .  5
     2.1   Multiprotocol Label Switching Working Group  . . . . . . .  5
     2.2   Common Control & Measurement Plane Working Group . . . . .  6
     2.3   MPLS and CCAMP cooperation . . . . . . . . . . . . . . . .  7
     2.4   Other (G)MPLS technology working groups  . . . . . . . . .  7
     2.5   Organizations outside the IETF . . . . . . . . . . . . . .  8
     2.6   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  9
   3.  MPLS and GMPLS Change Process  . . . . . . . . . . . . . . . . 10
     3.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.2   Description  . . . . . . . . . . . . . . . . . . . . . . . 11
       3.2.1   Preliminary investigation  . . . . . . . . . . . . . . 11
       3.2.2   Initiating changes or extensions to (G)MPLS
               protocols  . . . . . . . . . . . . . . . . . . . . . . 11
       3.2.3   Problem statement review . . . . . . . . . . . . . . . 12
       3.2.4   Charter update . . . . . . . . . . . . . . . . . . . . 12
       3.2.5   Problem statement evaluation . . . . . . . . . . . . . 13
       3.2.6   Not accepted requirements  . . . . . . . . . . . . . . 14
   4.  Extensibility and Architecture . . . . . . . . . . . . . . . . 16
   5.  (G)MPLS protocols  . . . . . . . . . . . . . . . . . . . . . . 17
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     8.1   Normative References . . . . . . . . . . . . . . . . . . . 20
     8.2   Informative References . . . . . . . . . . . . . . . . . . 20
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
       Intellectual Property and Copyright Statements . . . . . . . . 22





















Andersson, et al.                                               [Page 3]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


1.  Introduction

   This memo describes the process through which individuals, working
   groups and external standards bodies can influence the development of
   MPLS and GMPLS related standards.  This process means that (G)MPLS
   extensions and changes can only be done through the IETF, the body
   that created the (G)MPLS technology.  In particular, the MPLS and/or
   CCAMP working groups need to be involved in the process.  When
   possible, existing liaison relationships ([RFC4052], [RFC4053]) are
   leveraged.

   The IETF will not endorse publishing (G)MPLS technology extension
   RFCs that did not follow the processes described here.  If
   publication of individual Internet-Drafts describing extensions or
   changes to he (G)MPLS protocols is requested via the RFC Editor they
   will looped back through the process described in this document,
   using the mechanism described in [RFC3932].

   IANA has allocation policies for all of the code point registries it
   manages.  In many cases, IANA will refer back to the IETF when asked
   to make an allocation.  In the case of changes or extensions to the
   (G)MPLS protocols, the process described in this document will be
   used to judge whether or not a code point allocation that should be
   made.

   The (G)MPLS technology is developed in two main tracks in the IETF.
   "MPLS" refers to the work done for packet switched networks, while
   the "GMPLS" refers to the efforts to apply the MPLS protocols to all
   types of networks.  Though GMPLS by definition is a superset of MPLS,
   the term "(G)MPLS" is used 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.

   Conventions used in this document

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












Andersson, et al.                                               [Page 4]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


2.  Managing the (G)MPLS technology in the IETF

   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.  A terminology
   local to this document that will be used in specifying the change
   process is also included.

   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.

   This section (Section 2) gives an overview of the work these IETF
   working groups were chartered to do, and some of the working groups
   that use the (G)MPLS technology.  It should be remembered that the
   IETF environment is highly dynamic; working groups and whole areas
   come and go.  This overview of the IETF structure is only a snapshot
   in time.

2.1  Multiprotocol Label Switching Working Group

   The Multiprotocol Label Switching (MPLS) working group is responsible
   for standardizing the base technology for using label switching and
   for describing the implementation of label-switched paths 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.

   When the (G)MPLS technology was broken out to be developed by
   multiple working groups, one of the assumptions was that for changes
   and extensions to the existing MPLS protocols the MPLS working group
   should accept requirements, relevant to protocols specified by the
   MPLS working group or for work items on the working group charter,
   from other working groups.  The MPLS working group also accepts
   requirements from other sources, e.g., individuals or external
   standards bodies.  Such requirements SHALL be sent to the working
   group in the form of Internet-Drafts (and/or liaison statements, if
   appropriate).

   Documents that propose extensions or changes to the MPLS protocols,
   e.g., those that specify new MPLS methods or new MPLS encapsulations,
   MUST be handled according to the processes described in this document
   by the MPLS working group or by the MPLS Designated Expert (a.k.a.
   caretaker) appointed by the IESG if the MPLS working group has been
   closed.

Andersson, et al.                                               [Page 5]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


   Further, another IETF working group MAY be appointed, in accordance
   with the process described in this document, to handle extensions
   and/or changes to the protocols specified by the MPLS working group.

2.2  Common Control & Measurement Plane Working Group

   The IETF Common Control and Measurement Plane (CCAMP) working group
   coordinates the work within the IETF defining a common control plane
   and a separate common measurement plane 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;
   and developing 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 sometimes
   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.

   When the (G)MPLS protocols were broken out to be developed by
   multiple working groups, one of the assumptions was that the CCAMP
   working group should take input in the form of requirements from
   other working groups.  The CCAMP working group is also open for
   requirements from other sources, e.g., individuals or external
   standards bodies.  Such requirements SHALL be sent to the working
   group in the form of Internet-Drafts (and/or liaison statements, if
   appropriate).

   Documents that propose extensions or changes to protocols that have
   been specified by the CCAMP working group, e.g., documents that
   specify new GMPLS methods and new GMPLS encapsulations, MUST be
   handled according to the processes described in this document by the
   CCAMP working group or by the GMPLS Designated Expert (a.k.a.
   caretaker) if the CCAMP working group has been closed.

   Further, another IETF working group MAY be appointed, in accordance
   with the process described in this document, to handle extensions
   and/or changes to the protocols specified by the CCAMP working group.






Andersson, et al.                                               [Page 6]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


2.3  MPLS and CCAMP cooperation

   From time to time the MPLS and CCAMP working groups decide to divide
   work between themselves in a way that does not always strictly follow
   the split between the working groups as defined in the working groups
   charter.  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 area.

   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 WG chairs,
   in conjunction with their Area Directors, MAY redirect the proposal.

2.4  Other (G)MPLS technology working groups

   There have been several working groups working on (G)MPLS
   requirements, e.g., 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
   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, and
   when this involves extending and/or changing the protocols specified
   by the (G)MPLS working groups, this has to be submitted to the
   working group that originally specified the protocol in the form of
   an Internet-Draft.

   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.  It
   is assumed that the work of L2VPN and L3VPN does not include
   specifying new protocols, however, should protocol changes and/or
   extensions be made to protocols specified by the (G)MPLS working
   groups, these changes and/or extensions SHALL be submitted to the
   (G)MPLS working group that originally specified the protocol in the
   form of an Internet-Draft.

   The Pseudo Wire Emulation End to End (PWE3) working group is a
   working group in the Internet Area that also uses the (G)MPLS
   protocols in its specifications.  Should the PWE3 specifications
   require extension and/or changes to the (G)MPLS protocols these
   changes and/or extensions SHALL be submitted to the (G)MPLS working
   group that originally specified the protocol in the form of an
   Internet-Draft.

   It is assumed that the change process for the MPLS and CCAMP working
   groups, specified in this document, will be applicable or at least


Andersson, et al.                                               [Page 7]

Internet-Draft        MPLS and GMPLS Change Process        December 2005

   adaptable to other (G)MPLS technology working groups if such a need
   should arise.

   If the requirements for a proposal to change or extend (G)MPLS
   protocols falls under the purview of a (G)MPLS technology working
   group, the review process MUST involve both the technology working
   group(s) that understand the requirements as well as the working
   group(s) that shepherd protocol changes.

   Should this be the case, that other working group needs to explicitly
   state this in a Internet-Draft and take it through the normal IESG
   review process.

   The set of (G)MPLS technology working groups, as indeed IETF working
   groups in general, changes over time.  A list of the current set of
   working groups and areas will be found at
   http://www.ietf.org/html.charters/wg-dir.html.

2.5  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, and sometimes these liaison
   relationships go back several years.  The IETF exchanges information
   with these organizations about what is happening on both sides,
   including plans and schedules.

   However, if any organization outside the IETF thinks they need to
   extend and/or change an existing (G)MPLS protocol or create a new
   protocol in the (G)MPLS area, after an optional preliminary
   investigation, a description of the requirement that brought the
   organization to this conclusion MUST to be submitted to the (G)MPLS
   working groups in the form of Internet-Drafts.  Such Internet-Drafts
   SHALL be handled by the IETF in a timely manner according to the
   process described in this document.  Note that the Internet-Draft
   must detail the requirements.  This Internet-Draft MAY be accompanied
   by a separate Internet-Draft that proposes a way to meet the
   requirements.  The IETF is not required to accept the way suggested
   to meet the requirements even if the IETF agrees that the requirement
   is valid.

   As described in [RFC4052], informal communications such as e-mail to
   working group mailing lists often facilitates working together.
   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.

Andersson, et al.                                               [Page 8]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


2.6  Terminology

   o  (G)MPLS working groups -
      in this document the term (G)MPLS working groups is used to
      indicate 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 groups -
      the (G)MPLS working groups plus any working groups chartered to
      specify requirements on the (G)MPLS protocols and working groups
      using the (G)MPLS protocols in their specifications.  See
      Section 2.1, Section 2.2, and Section 2.4 for examples of (G)MPLS
      technology working groups.

   o  (G)MPLS protocols -
      in this document the term (G)MPLS protocols is used to indicate
      the union of the protocols specified by the (G)MPLS working
      groups.

   o  requirement evaluating working group (rewg) -
      in the process described below, the working group charged with the
      task of evaluating a certain problem statement and a certain set
      of requirements is termed the rewg

   o  protocol specifying working group (pswg)-
      in the process described below, the working group chartered to
      specify certain changes and/or extensions to the (G)MPLS protocols
      is called the pswg.

   o  problem statement Internet-Draft -
      the draft that initiates the discussion on changing or extending
      the (G)MPLS protocols.  This Internet-Draft needs to include a
      detailed problem description and a set of requirements that the
      (G)MPLS protocols need to meet to solve the problem.

   o  solutions Internet-Draft -
      a specification on how to change or extend the (G)MPLS protocols
      to meet the requirements in the problem statement Internet-Draft.
      This is not required, but may be useful.










Andersson, et al.                                               [Page 9]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


3.  MPLS and GMPLS Change Process

   This section includes Figure 1 in Section 3.1 that summarizes the
   (G)MPLS change process, and Section 3.2 that discusses the process in
   more detail.

3.1  Overview

     Start                     +-------------+
       |                       |optional     |
       +-----------------------|preliminary  |<-------Start
       |                       |investigation|
       V                       +-------------+
   +---------+           +---------+              +---------+
   |problem  |discussion |review by|     ACK      |  IESG/  | ACK
   |statement|---------->|wg chairs|------------->|   IAB   |-------+
   |   id    |on mailing |and ads  | request to   |decision |       |
   +---------+   list    +---------+ IESG/IAB to  +---------+       |
                              |      appoint rewg    |              |
                              | NAK  and charter     |NAK    rewg   |
                              V      req eval        |     chartered|
                       +---------+                   |       to work|
                       |response |                   |    on problem|
                       |to the   |                   |     statement|
                       |problem  |<------------------+              |
                    +->|statement|<--------------------+            |
                    |  +---------+                     |            |
                    |      ^                           |            |
                    |NAK   |     NAK                   |            |
                    |      +-----------------+         |            V
                    |                        |         | NAK  +-------+
                +--------+                +-------+    +------|  rewg |
                | IESG/  |        ACK     |   AD  |    ACK    |   req |
    +-----------|  IAB   |<---------------|review |<----------|  eval |
    | wg        |decision|    request to  |       |           |       |
    |chartered  +--------+   IESG/IAB to  +-------+           +-------+
    |to work                  approve wg
    |solution  +---------+  charter changes
    |          | IETF    |
    +--------->|  WG     |-----/ /----> RFC
         +---->| process |
         |     +---------+
     solutions
        ID(s)

                     Figure 1: Change Process Overview

   Figure 1 gives an overview of the (G)MPLS change process.  A more


Andersson, et al.                                              [Page 10]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


   detailed discussion on the key elements in the process is found
   below.

3.2  Description

   This section discusses in more detail how the (G)MPLS change process
   works, what is expected from individuals or organizations that want
   to extend and/or change the (G)MPLS protocols, and the
   responsibilities of the (G)MPLS working groups, the Routing Area and
   the IETF in general.

3.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.  When an external SDO has an
   application or set of requirements that it believes may require
   extensions to the (G)MPLS protocols it should send details to the
   IETF as a liaison.  The liaison can be sent directly to the rewg if
   known, or to the Routing Area if a rewg must still be determined.  To
   respond to the liaison, the IETF will examine the supplied
   requirements and provide one of four answers as a liaison reply:

   a.  Requirements not understood.  Further discussion required.

   b.  Requirements understood, but judged to be out of scope for the
       IETF.

   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.


3.2.2  Initiating changes or extensions to (G)MPLS protocols

   Anyone who intends to use one of the existing (G)MPLS protocols, but
   thinks that it will not satisfy their needs MUST write an Internet-
   Draft (ID) explaining the problem they are trying to solve and why
   the existing (G)MPLS protocols will not work.  This Internet-Draft -
   the problem statement ID - MUST include a detailed set of


Andersson, et al.                                              [Page 11]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


   requirements that (G)MPLS would need to meet to solve the particular
   problem.  The ID MUST also describe in detail any security issues
   that arise from meeting the requirements.  This Internet-Draft SHALL
   be sent to the IETF as an individual submission and after it is
   published the authors should send a note to the appropriate mailing
   list to start discussion on the problems discussed in the Internet-
   Draft.  The mailing list to use will in most cases be the Routing
   Area mailing list, as this is the Area containing the working group
   that has specified the protocol being changed, which will likely be
   the rewg.  The IESG or the Routing Area ADs may decide to use a
   specific working group mailing list for this discussion.

   If desired, a liaison statement may be sent to the Routing Area
   requesting IETF review of these requirements.  The WG chairs or ADs
   will respond to this liaison as described in section 3.2.2.2 of
   [RFC4053], providing the result of the evaluation described in
   Section 3.2.3 and Section 3.2.5 of this document.

3.2.3  Problem statement review

   The MPLS and CCAMP working group chairs, in conjunction with the
   Routing ADs, will determine if the particular problems raised in the
   Internet-Draft should be evaluated by a working group.  This mailing
   list discussion will be an essential part in forming a decision.  If
   the decision is that a requirement evaluation is warranted, the ADs
   decide which working group should act as the rewg.  During this
   process, and the evaluation in Section 3.2.5, the document authors
   (or some delegate) SHOULD make themselves available on the mailing
   list in order to more rapidly facilitate this review.

3.2.4  Charter update

   If the chairs and the ADs both feel that the particular problems
   should be added to the MPLS or the CCAMP working group charter the
   ADs will propose specific charter modifications for the working group
   to the IESG.  If the IESG, in consultation with the IAB, approves of
   the charter changes, the working group can then update its charter
   and start the work to evaluate the requirements and the problems
   described in the Internet-Draft.

   In a separate Internet-Draft the authors of the problem statement (or
   anyone else) MAY describe a set of changes to the (G)MPLS protocols
   that would meet the requirements.  This Internet-Draft would not be
   considered by the rewg as part of the requirement evaluation.  No
   discussions on progressing the draft will be held until a working
   group has been chartered to work on a solution, i.e., one of the
   possible outcomes of the process described in this document.  The
   IETF is not required to accept the solutions proposed in such an


Andersson, et al.                                              [Page 12]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


   Internet-Draft.

   There may, in fact, exist more than one Internet-Draft trying to meet
   the requirements specified in the problem statement draft.  If this
   is the case, neither draft will be considered in the requirement
   evaluation process.  They will all be held until a working group has
   been chartered to work on a solution and then all solutions drafts
   will be brought to the chartered working group.

3.2.5  Problem statement evaluation

   The rewg will evaluate the problem statement ID and based on the
   evaluation make a recommendation to the IESG/IAB.  If the
   requirements document was included in a liaison statement as
   described in Section 3.2.2, this recommendation will be the response
   to the liaison.  The recommendation may be:

   o  that it is not a problem that falls within the remit of the IETF
      or that it is a not problem that could be solved by extending or
      changing the (G)MPLS protocols


   o  that no changes or extensions to the (G)MPLS protocols are
      justified because the problem is not a general enough one.


   In these two cases the IETF will not publish an RFC that attempts to
   get around the decision.

   The IETF works based on a rough consensus within the working group,
   i.e., even if a proposal is not rejected based on the criteria above,
   it is still possible for the working group to decide that it is not
   something that should be done in the working group.

   o  that the problem is real and extensions to the (G)MPLS protocols
      are justified, and that a work item should be added to the charter
      of the appropriate working group - if the ADs agree then they will
      bring the proposal before the IESG and IAB.  If the IESG (with IAB
      advice) agrees that the task should be added to that particular
      charter then the rewg can work on it with the aim of developing a
      final set of requirements to be forwarded to the working group
      that will handle the specification of the protocol changes.


   In this case the rewg will evaluate and refine the requirements,
   merging them with other requirements if warranted.  The result of
   these deliberations will be captured in a requirements RFC.  The IESG
   may add a new task to the pswg charter prior to the publication of


Andersson, et al.                                              [Page 13]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


   the requirements RFC, as soon as the problem space is sufficiently
   understood.

   The protocol specifying working group will then develop the
   modifications or extensions to the (G)MPLS protocol needed to fulfill
   the requirements.

   If such a requirements document is added to a working group charter
   and if a proposed solution has previously been published as an
   Internet-Draft, the pswg may evaluate the proposed solution - but
   there is no requirement that any particular proposal be adopted.

   The (G)MPLS working groups are REQUIRED to protect the architectural
   integrity of the (G)MPLS protocols and MUST NOT extend the GMPLS
   architecture with features that do not have general use beyond the
   specific case - they also MUST NOT modify the architecture just to
   make some function more efficient at the expense of simplicity or
   generality.

   o  that the problem is real and that they would be solved with
      extensions to the (G)MPLS protocols, but that this for some reason
      is not best done within the IETF, but within some other SDO.  The
      IETF might in such a case come to an agreement with this SDO that
      it may specify the protocol extensions and that these will be
      described in a ID sent to the IETF for review and eventually be
      published as an RFC.


   In this case the IETF enters into some limited commitments towards
   the SDO undertaking the protocol specification, e.g., support in
   reviewing and publishing the work.

3.2.6  Not accepted requirements

   Whenever a problem statement Internet-Draft is not accepted, this
   should be clearly communicated to the authors of the draft.  This
   communication could take any of several forms:

   o  It might be obvious after the author(s) have presented the problem
      statement at a working group meeting that the requirements will be
      accepted.  In this case it is considered enough to capture this in
      the meeting minutes.

   o  If working group chairs and/or ADs take a consensus decision
      meaning that the requirements will not be accepted, this decision
      MUST be sent to the working group mailing list, with a copy to the
      authors.



Andersson, et al.                                              [Page 14]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


   o  If the problem statement were accompanied by a liaison or a
      communication, then a response MUST be sent to the organization
      originating the liaison or communication.















































Andersson, et al.                                              [Page 15]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


4.  Extensibility and Architecture

   In an idealized technical design, the extensibility design would be
   self-contained, and it would be inherent that new extensions and new
   headers would naturally have an architectural coherence with the
   original protocol.

   However, this idealized vision has not been attained in the world of
   standards tracks protocols.  Implications for interoperability can be
   addressed by capabilities negotiation rules.  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.




































Andersson, et al.                                              [Page 16]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


5.  (G)MPLS protocols

   The set of RFCs that constitutes the (G)MPLS protocols are the
   standards track RFCs from the (G)MPLS working groups.  A list of
   these RFCs is not supplied here since their number is increasing
   rather quickly since there are new IDs going through working group
   last call and awaiting publication in the RFC-Editor's queue.

   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.







































Andersson, et al.                                              [Page 17]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


6.  Security Considerations

   Documents that describe cooperation procedures, like this one does,
   have no direct Internet security implications.














































Andersson, et al.                                              [Page 18]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


7.  Acknowledgements

   The input given by Scott Bradner and 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.









































Andersson, et al.                                              [Page 19]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


8.  References

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

8.2  Informative References

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

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


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



Andersson, et al.                                              [Page 20]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


   Kireeti Kompella
   Juniper Networks

   Email: Kireeti@juniper.net


   Alex Zinin
   Alcatel

   Email: zinin@psg.com


   Bill Fenner
   AT&T Labs - Research
   75 Willow Rd
   Menlo Park, CA  94025
   USA

   Phone: +1 650 330-7893
   Fax:   +1 650 463-7037
   Email: fenner@research.att.com





























Andersson, et al.                                              [Page 21]

Internet-Draft        MPLS and GMPLS Change Process        December 2005


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.

   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 (2005).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



Andersson, et al.                                              [Page 22]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/