Network Working Group Loa Andersson Internet-Draft (ed) Expires September 2003 February 2003 MPLS and GMPLS Change Process 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]