Network Working Group Loa Andersson
Internet-Draft (ed)
Expires September 2003 February 2003
MPLS and GMPLS Change Process
<draft-andersson-mpls-g-chng-proc-00.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC 2026.
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 (C) The Internet Society (2003). All Rights Reserved.
Abstract
This memo describes the process through which individuals, working
groups and external standards bodies can influence the development of
MPLS and GMPLS standards. With respect to standardization, this
process means that (G)MPLS extensions and changes can be done through
the IETF only, the body that created the (G)MPLS technology. The
IETF will not publish a (G)MPLS technology extension RFC outside of
the processes described here.
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 September 2003 [Page 1]
Internet-Draft MPLS and GMPLS Change Process February 2003
Table of Contents
1 Managing the (G)MPLS technology in the IETF ........... 2
1.1 Multiprotocol Label Switching Working Group ........... 3
1.2 Common Control & Measurement Plane Working Group ...... 3
1.3 Other (G)MPLS technology working groups ............... 4
1.4 Terminology ........................................... 4
2 MPLS and GMPLS Change Process ......................... 5
2.1 Overview .............................................. 5
2.2 Description ........................................... 6
2.2.1 Initiating changes or extensions to (G)MPLS protocols . 6
2.2.2 Problem statement review .............................. 6
2.2.3 Charter update ........................................ 6
2.2.4 Problem statement evaluation .......................... 7
3 Extensibility and Architecture ........................ 8
4 (G)MPLS protocols ..................................... 8
5 Security Considerations ............................... 9
6 References ............................................ 9
6.1 Normative ............................................. 9
7 Authors' Addresses .................................... 10
8 Full Copyright Statement .............................. 11
1. Managing the (G)MPLS technology in the IETF
This memo describes the process through which individuals, working
groups and external standards bodies can influence the development of
MPLS and GMPLS standards. With respect to standardization, this pro-
cess means that (G)MPLS extensions and changes can be done through
the IETF only, the body that created the (G)MPLS technology. The
IETF will not publish a (G)MPLS technology extension RFC outside of
the processes described here.
Currently, the MPLS Working Group specifies MPLS while the CCAMP
Working Group specifies GMPLS. The SUB-IP Area contains both working
groups.
If the IETF were to re-organize the working groups developing the
(G)MPLS technology into more than one area, the process described in
this memo would still apply. It would, however, require the co-opera-
tion of all IETF Area Directors who manage groups that participate in
the specification of (G)MPLS protocols.
Andersson et al Expires September 2003 [Page 2]
Internet-Draft MPLS and GMPLS Change Process February 2003
1.1. Multiprotocol Label Switching Working Group
The Multiprotocol Label Switching (MPLS) working group is responsi-
ble for standardizing a base technology for using label switching and
for the implementation of label-switched paths over various link-
level technologies. The WG charter includes procedures and protocols
for the distribution of labels between routers, encapsulations and
multicast considerations.
When the (G)MPLS technology was broken out to be developed by multi-
ple working groups, one of the assumptions was that the MPLS Working
group should accept requirements 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 must be handled by the MPLS working group include new
MPLS methods and new MPLS encapsulation.
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 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 MPLS; 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 call 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. In this respect GMPLS can be viewed as a superset
of MPLS.
When the (G)MPLS 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 (G)MPLS requirement spec-
ifying working groups. The CCAMP Working group is also open for
requirements from other sources, e.g. individuals or external stan-
dards bodies. Such requirements shall be sent to the working group in
the form of Internet drafts.
Documents that must be handled by the working group include new GMPLS
methods and new GMPLS encapsulation.
Andersson et al Expires September 2003 [Page 3]
Internet-Draft MPLS and GMPLS Change Process February 2003
1.3. Other (G)MPLS technology working groups
The IP over Optical and the Internet Traffic Engineering Working
groups are mainly requirement generating working groups for the
(G)MPLS technology area. The Provider Provisioned Virtual Private
Networks Working (ppvpn) group has been chartered to specify a lim-
ited number of solutions for Provider Provisioned VPN's, but it is
not assumed that this will include specifying new protocols. The
General Switch Management Protocol Working (gsmp) group is a protocol
specifying working group.
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.
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
1.4. Terminology
(G)MPLS working groups -
in this document the (G)MPLS working groups is used to indicate
the MPLS and the CCAMP working groups.
(G)MPLS technology working groups -
the (G)MPLS working groups plus the working groups focused on
requirements on the (G)MPLS technology, see sections 1.1 to 1.3
for a list of the (G)MPLS technology working groups as this memo
is written.
(G)MPLS protocols -
in this document the (G)MPLS protocols is used to indicate the
union of the protocols specified by the (G)MPLS working groups.
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
protocol specifying working group -
in the process described below the working group chartered to
specify certain changes and/or extensions to the (G)MPLS protocols
are called - the protocol specifying working group.
problem statement internet draft -
Andersson et al Expires September 2003 [Page 4]
Internet-Draft MPLS and GMPLS Change Process February 2003
the draft that initiates the discussion on changing or extending
the (G)MPLS protocols, this ID needs to include a detailed problem
description and a set of requirements that the (G)MPLS protocols
needs to meet to solve the problem
solutions internet draft -
a specification on how to change or extend the (G)MPLS protocols
to meet the requirements in the problem statement ID
2. MPLS and GMPLS Change Process
2.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|
| dust | <----------------+ |
+->| bin | <--------------------+ |
| +-------+ | |
| ^ | |
|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 September 2003 [Page 5]
Internet-Draft MPLS and GMPLS Change Process February 2003
2.2. Description
2.2.1. Initiating changes or extensions to (G)MPLS protocols
Anyone who intend 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 require-
ments that (G)MPLS would need to meet to solve the particular prob-
lem. The ID must also describe in detail any security issues that
arise from meeting the requirements. This ID shall be sent to IETF as
an individual ID and after it is published the authors should send a
note to the appropriate mailing list to start discussion on the prob-
lems discussed in the ID. The mailing list to use should be the Area
mailing list for the area that the working group that has specified
the protocol being changed and that will likely be the requirement
evaluation working group.
2.2.2. Problem statement review
The MPLS and CCAMP working group chairs in conjunction with the Area
Directors will determine if the particular problems raised in the
Internet-Draft should be evaluated by a working group. This decision
will based on the mailing list discussion. If the decision is that a
requirement evaluation is warranted a decision is taken on which
working group should act as requirement evaluation working group
(rewg).
2.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 IAB approve 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 (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 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.
Andersson et al Expires September 2003 [Page 6]
Internet-Draft MPLS and GMPLS Change Process February 2003
2.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:
1 that no extensions to the (G)MPLS protocols are needed since the
problem can be solved by the protocols as they exists.
2 that no changes or extensions to the (G)MPLS protocols are justi-
fied the problem is not a general enough one
In cases 1 & 2 the IETF will not publish an RFC that attempts to get
around the decision.
3 that the problem is real and extensions to the (G)MPLS protocols
are justified and recommend to the ADs that a work item 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.
The rewg will evaluate and refine the requirements, merging them with
others if warranted. The result of these deliberations will be a
requirements RFC. When the IESG approves publication of the require-
ments RFC it will add it as new task to the protocol specifying Work-
ing Group charter.
The protocol specifying working group will then develop the modifica-
tions 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 been published as an ID, the protocol
specifying Working Group may evaluate the proposed solution - but
there is no requirement that the proposal be adopted.
The (G)MPLS Working Groups are required to protect the architectural
integrity of (G)MPLS protocols and must not add features that do not
have general use beyond the specific case - they also must not add
features just to make some function more efficient at the expense of
simplicity or generality.
4 that the problem is real and that they would be solved with exten-
sions to the (G)MPLS protocols, but that this for some reason is
Andersson et al Expires September 2003 [Page 7]
Internet-Draft MPLS and GMPLS Change Process February 2003
not best done within the IETF, but some other organization. The
IETF might in such a case come to an agreement with this organiza-
tion to 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.
3. 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.
4. (G)MPLS protocols
The current set of (G)MPLS protocols are:
RFC 3032 - MPLS Label Stack Encoding
RFC 3034 - Use of Label Switching on Frame Relay Networks Specification
RFC 3035 - MPLS using LDP and ATM VC Switching
RFC 3036 - LDP Specification
RFC 3038 - VCID Notification over ATM link for LDP
RFC 3033 - The Assignment of the Information Field and Protocol
Identifier in the Q.2941 Generic Identifier and Q.2957
User-to-user Signaling for the Internet Protocol
RFC 3063 - MPLS Loop Prevention Mechanism
RFC 3107 - Carrying Label Information in BGP-4
RFC 3209 - RSVP-TE: Extensions to RSVP for LSP Tunnels
RFC 3212 - Constraint-Based LSP Setup using LDP
RFC 3214 - LSP Modification Using CR-LDP
RFC 3279 - MPLS Support of Differentiated Services
RFC 3429 - Assignment of the 'OAM Alert Label' for Multiprotocol Label
Switching Architecture (MPLS) Operation and Maintenance (OAM)
Functions
Andersson et al Expires September 2003 [Page 8]
Internet-Draft MPLS and GMPLS Change Process February 2003
RFC 3443 - Time to Live (TTL) Processing in MPLS Networks
(Updates RFC 3032)
Note that in the future more (G)MPLS related protocols may become
members of this set. (G)MPLS protocol specifying working group docu-
ments and documents produced by those groups under the review of IESG
or in the RFC-Editor queue will be treated as if they were members of
this set.
5. Security Considerations
Complexity and indeterminate or hard to define protocol behavior,
depending on which of many extensions operate, is a fine breeding
ground for security flaws.
All Internet-Drafts that present new requirements for the (G)MPLS
protocols must include a discussion of the security requirements and
implications inherent in the proposal. All RFCs that modify or
extend the (G)MPLS protocols must explore the security considerations
of the modifications and extensions.
6. References
6.1. Normative
[RFC2026]
Bradner, S. "The Internet Standards Process -- Revision 3", RFC 2026,
October 1996.
[RFC2119]
Bradner, S. "Key words for use in RFCs to Indicate Requirement Lev-
els", RFC 2119, March 1997.
Andersson et al Expires September 2003 [Page 9]
Internet-Draft MPLS and GMPLS Change Process February 2003
7. Authors' Addresses
Loa Andersson
email: loa@pi.se
Ron Bonica
WorldCom
22001 Loudoun County Parkway
Ashburn, VA 20191
ronald.p.bonica@wcom.com
Scott Bradner
Harvard University
29 Oxford St.
Cambridge MA 02138
Email: sob@harvard.edu
Phone: +1-617-495-3864
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave
Sunnyvale, CA 94089
Email: kireeti@juniper.net
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Phone: +1 978 497 8143
Email: swallow@cisco.com
Bert Wijnen
Lucent Technologies
Schagen 33
3461 GL Linschoten
Netherlands
Phone: +31 348 680 485
EMail: bwijnen@lucent.com
Andersson et al Expires September 2003 [Page 10]
Internet-Draft MPLS and GMPLS Change Process February 2003
8. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this doc-
ument itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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 MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Andersson et al Expires September 2003 [Page 11]