Network Working Group L. Andersson
Internet-Draft Acreo AB
Expires: August 24, 2005 A. Farrel
Olddog consulting
G. Swallow
Cisco Systems
K. Kompella
Juniper Networks
A. Zinin
Alcatel
B. Fenner
AT&T Labs - Research
February 20, 2005
MPLS and GMPLS Change Process
draft-andersson-rtg-gmpls-change-01
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 August 24, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Andersson, et al. Expires August 24, 2005 [Page 1]
Internet-Draft MPLS and GMPLS Change Process February 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. Expires August 24, 2005 [Page 2]
Internet-Draft MPLS and GMPLS Change Process February 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 . . . . . . . . . . . . . . . . 11
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Description . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1 Preliminary investigation . . . . . . . . . . . . . . 12
3.2.2 Initiating changes or extensions to (G)MPLS
protocols . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3 Problem statement review . . . . . . . . . . . . . . . 13
3.2.4 Charter update . . . . . . . . . . . . . . . . . . . . 13
3.2.5 Problem statement evaluation . . . . . . . . . . . . . 14
3.2.6 Not accepted requirements . . . . . . . . . . . . . . 15
4. Extensibility and Architecture . . . . . . . . . . . . . . . . 17
5. (G)MPLS protocols . . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1 Normative References . . . . . . . . . . . . . . . . . . . 21
8.2 Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . 23
Andersson, et al. Expires August 24, 2005 [Page 3]
Internet-Draft MPLS and GMPLS Change Process February 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 ([I-D.iab-liaison-mgt], [I-
D.baker-liaison-statements]) 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. Expires August 24, 2005 [Page 4]
Internet-Draft MPLS and GMPLS Change Process February 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
Andersson, et al. Expires August 24, 2005 [Page 5]
Internet-Draft MPLS and GMPLS Change Process February 2005
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 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. Expires August 24, 2005 [Page 6]
Internet-Draft MPLS and GMPLS Change Process February 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. Expires August 24, 2005 [Page 7]
Internet-Draft MPLS and GMPLS Change Process February 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 [I-D.iab-liaison-mgt], 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
Andersson, et al. Expires August 24, 2005 [Page 8]
Internet-Draft MPLS and GMPLS Change Process February 2005
individual participant's opinion for that of the group as can happen
on mailing lists.
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.
Andersson, et al. Expires August 24, 2005 [Page 9]
Internet-Draft MPLS and GMPLS Change Process February 2005
This is not required, but may be useful.
Andersson, et al. Expires August 24, 2005 [Page 10]
Internet-Draft MPLS and GMPLS Change Process February 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. Expires August 24, 2005 [Page 11]
Internet-Draft MPLS and GMPLS Change Process February 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. Expires August 24, 2005 [Page 12]
Internet-Draft MPLS and GMPLS Change Process February 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 [I-
D.baker-liaison-statements], 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. Expires August 24, 2005 [Page 13]
Internet-Draft MPLS and GMPLS Change Process February 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. Expires August 24, 2005 [Page 14]
Internet-Draft MPLS and GMPLS Change Process February 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. Expires August 24, 2005 [Page 15]
Internet-Draft MPLS and GMPLS Change Process February 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. Expires August 24, 2005 [Page 16]
Internet-Draft MPLS and GMPLS Change Process February 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. Expires August 24, 2005 [Page 17]
Internet-Draft MPLS and GMPLS Change Process February 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. Expires August 24, 2005 [Page 18]
Internet-Draft MPLS and GMPLS Change Process February 2005
6. Security Considerations
Documents that describe cooperation procedures, like this one does,
have no direct Internet security implications.
Andersson, et al. Expires August 24, 2005 [Page 19]
Internet-Draft MPLS and GMPLS Change Process February 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. Expires August 24, 2005 [Page 20]
Internet-Draft MPLS and GMPLS Change Process February 2005
8. References
8.1 Normative References
[I-D.baker-liaison-statements]
Baker, F., "Procedures for handling liaison statements to
and from the IETF", draft-baker-liaison-statements-04
(work in progress), January 2005.
[I-D.iab-liaison-mgt]
Daigle, L., "IAB Processes for management of liaison
relationships", draft-iab-liaison-mgt-03 (work in
progress), December 2004.
[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.
[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
Olddog consulting
Email: adrian@olddog.co.uk
Andersson, et al. Expires August 24, 2005 [Page 21]
Internet-Draft MPLS and GMPLS Change Process February 2005
George Swallow
Cisco Systems
Email: swallow@cisco.com
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. Expires August 24, 2005 [Page 22]
Internet-Draft MPLS and GMPLS Change Process February 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. Expires August 24, 2005 [Page 23]
