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

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

Network Working Group                                       L. Andersson
Internet-Draft                                                  Acreo AB
Expires: May 23, 2005                                          A. Farrel
                                                       Olddog consulting
                                                              G. Swallow
                                                           Cisco Systems
                                                             K. Kompella
                                                        Juniper Networks
                                                                A. Zinin
                                                                 Alcatel
                                                       November 22, 2004


                     MPLS and GMPLS Change Process
               draft-andersson-rtg-gmpls-change-00.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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.

   This Internet-Draft will expire on May 23, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract




Andersson, et al.         Expires May 23, 2005                  [Page 1]

Internet-Draft       MPLS and GMPLS Change Process         November 2004


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




































Andersson, et al.         Expires May 23, 2005                  [Page 2]

Internet-Draft       MPLS and GMPLS Change Process         November 2004


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   Routing Area and Routing Area working groups . . . . . . .  8
     2.6   Organizations outside the IETF . . . . . . . . . . . . . .  8
     2.7   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  9
   3.  MPLS and GMPLS Change Process  . . . . . . . . . . . . . . . . 10
     3.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.2   Description  . . . . . . . . . . . . . . . . . . . . . . . 11
       3.2.1   Initiating changes or extensions to (G)MPLS
               protocols  . . . . . . . . . . . . . . . . . . . . . . 11
       3.2.2   Problem statement review . . . . . . . . . . . . . . . 11
       3.2.3   Charter update . . . . . . . . . . . . . . . . . . . . 11
       3.2.4   Problem statement evaluation . . . . . . . . . . . . . 12
       3.2.5   Not accepted requirements  . . . . . . . . . . . . . . 13
   4.  Extensibility and Architecture . . . . . . . . . . . . . . . . 15
   5.  (G)MPLS protocols  . . . . . . . . . . . . . . . . . . . . . . 16
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 19
   8.2   Informative References . . . . . . . . . . . . . . . . . . . 19
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
       Intellectual Property and Copyright Statements . . . . . . . . 20






















Andersson, et al.         Expires May 23, 2005                  [Page 3]

Internet-Draft       MPLS and GMPLS Change Process         November 2004


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.

   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 requesting extensions or
   changes the (G)MPLS protocols by the RFC Editor are requested they
   will looped back through the process described in this document.

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

   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.         Expires May 23, 2005                  [Page 4]

Internet-Draft       MPLS and GMPLS Change Process         November 2004


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.

   Currently there are two working groups in the IETF Routing Area
   working on 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 are currently 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.  The 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.

   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



Andersson, et al.         Expires May 23, 2005                  [Page 5]

Internet-Draft       MPLS and GMPLS Change Process         November 2004


   closed.

   One exeception to this rule is when other IETF working groups has
   been appointed, in accorance with the process descrbide in this
   document, to handled 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;
   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 they are transported over.  While the MPLS
   working group focuses on packet- and frame-switched technologies, the
   CCAMP working group work focuses on common methods accross a broad
   spectrum of switching 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.

   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.

   One exeception to this rule is when other IETF working groups has
   been appointed, in accorance with the process descrbide in this
   document, to handled extensions and/or changes to the protocols
   specified by the CCAMP working group.





Andersson, et al.         Expires May 23, 2005                  [Page 6]

Internet-Draft       MPLS and GMPLS Change Process         November 2004


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 LSP's, 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 (te-wg).  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 (BFD) working
   group also use the (G)MPLS protocols and mechanisms, and when this
   involve 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 VPN's.  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 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
   adaptable to other (G)MPLS technology working groups if such a need



Andersson, et al.         Expires May 23, 2005                  [Page 7]

Internet-Draft       MPLS and GMPLS Change Process         November 2004


   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 Inernet-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  Routing Area and Routing Area working groups

   The change process specified in this document, if this is found
   beneficial, could be extended to any and all Routing Area working
   groups, and thus be applicable to all the protocols specified by
   those Routing Area working groups.

   Should this be the case those working groupss, or the Routing Area
   AD's, need to state this in an Internet-Draft and take it through the
   normal IESG review process.

2.6  Organizations outside the IETF

   A number of standards development organizations (SDOs) and industrial
   forums are using or referencing 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, 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 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



Andersson, et al.         Expires May 23, 2005                  [Page 8]

Internet-Draft       MPLS and GMPLS Change Process         November 2004


   to meet the requirements even if the IETF agrees that the requirement
   is valid.

2.7  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 sections
      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
      are called - 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.         Expires May 23, 2005                  [Page 9]

Internet-Draft       MPLS and GMPLS Change Process         November 2004


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



   +-------+           +---------+              +---------+
   |  prob |discussion |review by|     ACK      |   IESG  | ACK
   | statem|---------->|wg chairs|------------->|   IAB   |-------+
   |   id  |on mailing |and ad's | request to   |decision |       |
   +-------+   list    +---------+ IESG/IAB to  +---------+       |
                            |      appoint rewg    |              |
                            | NAK  and charter     |NAK    rewg   |
                            |      req eval        |     chartered|
                            |                      |       to work|
                            V                      |       on prob|
                                                   |     statement|
                        |response |                |              |
                        |to the   |                |              |
                        |prob     | <---------------+             |
                     +->|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





Andersson, et al.         Expires May 23, 2005                 [Page 10]

Internet-Draft       MPLS and GMPLS Change Process         November 2004


                                Figure 1

   The figure above gives an overview of the (G)MPLS change process.  A
   more 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 wants
   to extend and/or change the (G)MPLS and the responsibilities of the
   (G)MPLS working groups, the Routing Area and the IETF in general.

3.2.1  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
   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 Interenet-Draft SHALL
   be sent to the IETF as an individual Ineternet-Draft 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 maililng list, as this is the Area containing working
   group that has specified the protocol being changed and that 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.

3.2.2  Problem statement review

   The MPLS and CCAMP working group chairs in conjunction with the
   Routing Area 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 essentail part in forming a
   decission.  If the decision is that a requirement evaluation is
   warranted a decision is taken, by the ADs, on which working group
   should act as the rewg.

3.2.3  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 and IAB.  If the IESG and the IAB approve of the charter



Andersson, et al.         Expires May 23, 2005                 [Page 11]

Internet-Draft       MPLS and GMPLS Change Process         November 2004


   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, but 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
   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 requirment
   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.4  Problem statement evaluation

   The rewg will evaluate the problem statement ID and based on the
   evaluation make a recommendation to the IESG/IAB.  The recommendation
   may be:

   o  that it is not a problem that falls within the remit of the IETF
      or 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 reject 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



Andersson, et al.         Expires May 23, 2005                 [Page 12]

Internet-Draft       MPLS and GMPLS Change Process         November 2004


      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 rewuirments 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
   the requirements RFC, as soon as the problem space is sufficently
   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.5  Not accepted requirements

   Whenever a problem statement Inter-Draft is not accepted this should
   be clearly communicated to the authors of the draft.  This
   communication could take any of several forms; it might be obvious
   after author(s) has presented the problem statement at a working
   group meeting that the requirements will be accepted it is considered
   enough capturing this in the meeting minutes; if working groups



Andersson, et al.         Expires May 23, 2005                 [Page 13]

Internet-Draft       MPLS and GMPLS Change Process         November 2004


   chairs and/or ADs takes the concensus decision meaning that the
   requirments will not be accpted this decision should be sent to the
   working group mailing list, with a copy to the authors; if the
   problem statement were accompanied by a liaison or communication a
   response should be sent to the organization originating the liaison
   or communication.













































Andersson, et al.         Expires May 23, 2005                 [Page 14]

Internet-Draft       MPLS and GMPLS Change Process         November 2004


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.

   We encourage other protocol working groups with highly extensible
   protocols to review whether they need more coordination of extensions
   as in the (G)MPLS case.

































Andersson, et al.         Expires May 23, 2005                 [Page 15]

Internet-Draft       MPLS and GMPLS Change Process         November 2004


5.  (G)MPLS protocols

   The set of RFC³s that constitutes the (G)MPLS protocols are the
   standards track RFCs from the (G)MPLS working groups.  We don't
   supply a list of these RFCs since these numbers are increasing rather
   quickly since there are new IDs going through working group last call
   and awaiting publication in the in the RFC-Editors queue.

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








































Andersson, et al.         Expires May 23, 2005                 [Page 16]

Internet-Draft       MPLS and GMPLS Change Process         November 2004


6.  Security Considerations

   Note: Needs to be filled in
















































Andersson, et al.         Expires May 23, 2005                 [Page 17]

Internet-Draft       MPLS and GMPLS Change Process         November 2004


7.  Acknowledgements

   The input given by Bill Fenner, Scott Bradner and Bert Wijnjen has
   been useful and detailed.















































Andersson, et al.         Expires May 23, 2005                 [Page 18]

Internet-Draft       MPLS and GMPLS Change Process         November 2004


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.

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.


Authors' Addresses

   Loa Andersson
   Acreo AB

   EMail: loa@pi.se


   Adrian Farrel
   Olddog consulting

   EMail: adrian@olddog.co.uk


   George Swallow
   Cisco Systems

   EMail: swallow@cisco.com


   Kireeti Kompella
   Juniper Networks

   EMail: Kireeti@juniper.net


   Alex Zinin
   Alcatel

   EMail: zinin@psg.com







Andersson, et al.         Expires May 23, 2005                 [Page 19]

Internet-Draft       MPLS and GMPLS Change Process         November 2004


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 (2004).  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.         Expires May 23, 2005                 [Page 20]


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