Network Working Group L. Andersson
Internet-Draft Redback Networks
Intended status: Standards Track D. Ward
Expires: August 30, 2009 Cisco Systems
M. Betts
Nortel
February 26, 2009
Joint IETF and ITU-T Multi-Protocol Label Switching (MPLS) Transport
Profile process
draft-andersson-mpls-tp-process-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Andersson, et al. Expires August 30, 2009 [Page 1]
Internet-Draft MPLS-TP document process February 2009
Abstract
The decision to develop a Multiprotocol Label Switching (MPLS)
Transport Profile in cooperation between IETF and ITU-T does not
fully defines and document process for development the required RFCs.
This document complements the process as documented in the JWT
decision with a couple of separate elements
o An adaptation of the IETF working group process.
o Identifies the expected participation in the process by the ITU-T.
o A clarification of the decision rules regarding MPLS-TP documents.
This document does not intend specify any ITU-T process, to the
extent that is necessary it will be done according to ITU-T
processes.
Andersson, et al. Expires August 30, 2009 [Page 2]
Internet-Draft MPLS-TP document process February 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. IETF terms and abbreviations . . . . . . . . . . . . . 4
1.1.2. ITU-T terms and abbreviations . . . . . . . . . . . . 5
2. Adaptation of the IETF working group process . . . . . . . . . 6
2.1. Adaptation of the IETF working group process . . . . . . . 6
2.2. The IETF MPLS-TP process . . . . . . . . . . . . . . . . . 7
2.2.1. Developing a MPLS-TP document . . . . . . . . . . . . 7
3. Expectations on ITU-T participation in the process . . . . . . 11
3.1. Becoming a MEAD team document . . . . . . . . . . . . . . 11
3.2. Comments on MEAD team documents by participants in the
ITU-T . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Poll for working group documents . . . . . . . . . . . . . 11
3.4. Responding to an IETF Working Group Last Call . . . . . . 12
4. Specific guidelines that apply to work on MPLS-TP in the
ITU-T . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Security considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative references . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Andersson, et al. Expires August 30, 2009 [Page 3]
Internet-Draft MPLS-TP document process February 2009
1. Introduction
When IETF and ITU-T entered into the agreement to develop MPLS-TP was
agreed on - the JWT agreement - it was decided that the MPLS-TP
documents should be developed "according to IETF processes". It was
also assumed that a close cooperation in reviewing these IETF
documents. The JWT decision is documented in RFC 5317 [RFC5317].
However, the process for this close cooperative review was mostly
left to be decided as the documents evolved. The ITU-T committed to
responding promptly to IETF working group last calls, this may
require the development of the response via correspondence.
This document complements the process as documented in the JWT
decision with a couple of separate elements:
o An adaptation of the IETF working group process, with respect to
the role of the teams (MPLS Interoperability Design Team (MEAD
Team), the Joint Working Team (JWT) and the ITU-T MPLS-TP ad hoc
team) that has been set up to facilitate the development of
MPLS-TP; see Section 2.
o Identifies the expected participation by the ITU-T in the document
development process; see Section 3.
o Clarification of the decision rules regarding MPLS-TP documents;
see Section 4.
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].
1.1. Terminology
This section includes a number of terms and abbreviations that is
used on this document. The section is split into two subsection;
IETF terms and ITU-T terms.
1.1.1. IETF terms and abbreviations
o JWT - Joint Working Team, a team with participants with experience
from standards development in the IETF and the ITU-T.
Note: The JWT is not part of either the IETF or ITU-T, but a group
that has been set up to facilitate cooperation on MPLS-TP between
the two organizations.
Andersson, et al. Expires August 30, 2009 [Page 4]
Internet-Draft MPLS-TP document process February 2009
o JWT documents - the set of documents that were envisioned in the
documentation of the JWT decision
o MEAD team - MPLS Interoperability Design Team, a temporary team
with participants with experience from standards development for
MPLS and transport networks. The MEAD team is chartered to
coordinated the development of MPLS-TP within the IETF and to
coordinate the on MPLS-TP cooperation with the ITU-T.
o MPLS-TP documents - the following sets of documents are counted as
MPLS-TP documents:
* Internet Drafts that are coordinated by the MEAD team.
* Individual Internet Drafts that addresses the MPLS-TP problem
space.
* Working group Internet Drafts that addresses the MPLS-TP
problem space.
* Internet Drafts that are considered for publication by the IESG
and that addresses the MPLS-TP problem space.
* Internet Drafts that are approved for publication by the IESG
and that addresses the MPLS-TP problem space.
* Published RFCs that addresses the MPLS-TP problem space.
* ITU-T Recommendations and draft Recommendations in various
stages of development that addresses the MPLS-TP problem space.
Documents that originates from the IRTF RFC stream is NOT considered
as MPLS-TP documents.
1.1.2. ITU-T terms and abbreviations
o Ad Hoc on MPLS-TP - A team established by SG 15 of ITU-T to
coordinate the work on MPLS-TP within the ITU-T and to act as a
focal point for communication with the IETF.
o Contribution - a contribution is a document that is submitted to
the ITU-T to advance work on the development of a Recommendation
or to propose the development of a new Recommendation.
o Recommendation - a Recommendation is the ITU-T standards document.
Andersson, et al. Expires August 30, 2009 [Page 5]
Internet-Draft MPLS-TP document process February 2009
2. Adaptation of the IETF working group process
The IETF working group processes as defined in RFC 2026 [RFC2026] are
for the purpose of the MPLS-TP updated as follows.
IETF works according the the 'rough consensus' model where the
working group chairs determines the consensus after discussions on
the mailing lists. This is applicable to the MPLS-TP work also. The
mpls-tp@ietf.org is the mailing list used to find out consensus and
the consensus is decided by the MEAD team chair. After a document
has become a working group document the consensus is decided by the
WG chairs and the MEAD team chair jointly.
A most important part of this process is the information exchange
between the IETF and ITU-T. This information exchange consists of
two equally important pieces:
o informal information exchange
this is done primarily by mails to the relevant mailing lists.
o formal information exchange
In addition to a mail to the relevant mailing lists, the formal
information exchange is accompanied by a liaison between the two
organisations. Exchange of liaisons makes it possible to follow
the request/response exchange between the organisations i n more
detail.
2.1. Adaptation of the IETF working group process
The flow chart below describes the adaption of the working group
process
Andersson, et al. Expires August 30, 2009 [Page 6]
Internet-Draft MPLS-TP document process February 2009
............. .............
: Ind Docs :----------+ : JWT docs :
............. | .............
| | |
| ind-00 (1) | ind-00 (2) | ind-00 (3)
| | |
v | v
+-----------+ | +----------------+ (4) +-------+
| WG proc | +------------->| MEAD team proc |<------>| ITU-T |
| |--------+ +------| | +-------+
+-----------+ | | +----------------+ (5) |
+-> ind-00, ind-01, etc | | ind-00, ind-01, etc <-+<-----+
| | (6) +----+----+ (6) | |
+----------+ |(7) +--------------+
review | review
poll for wg doc -----------------+
| | (7a)
v v
+-------------+ (8) +-------+
| wg doc |<------------>| ITU-T |
+-------------+ +-------+
| +-> wg-00, wg-01, etc |
| | | (9) | (10)
| +----------+<----------------+
(11) | review
v
+-----------------+ (12) +---------+
| wg last call |<----------->| ITU-T |
+-----------------+ +---------+
|
| (13)
|
v
+-----------------+
| req for publ |
+-----------------+
2.2. The IETF MPLS-TP process
This section gives guidelines for how the flow chart above could be
traversed.
2.2.1. Developing a MPLS-TP document
Individual MPLS-TP documents may take different paths through the
this process, the numbers in the list below is mapped to the numbers
in the flow chart above.
Andersson, et al. Expires August 30, 2009 [Page 7]
Internet-Draft MPLS-TP document process February 2009
Although the different paths through the flow chart is given as
'options' it is always possible for the MEAD team to step in aand
take over the shepherding af a particular document. This is done in
cooperation between the MEAD team chair, the relevant working group
chairs and the document editors/authors.
1. They may be intended for and managed by a working group.
This means that the author(s) of such a document has chosen to
send the document to a working group instead of running through
the MEAD team. Normal IETF process will kick in in such cases
and working group chairs will agree to which working group(s)
such a document will be taken.
2. They may be coordinated by the MEAD team.
This means that the author(s) of such a document has chosen to
send the document to the MEAD team to be coordinated with the
rest of the MPLS-TP documents that is in the purview of the MEAD
team.
3. They may be originated by the MEAD team based on the jwt
decision.
The documentation of the work of the JWT, there is a proposed
document structure. The MEAD team used this structure to decide
on a set of documents that will, when completed, constitute the
MPLS-TP standard. This set of documents are slightly changing,
e.g. because it becomes more appropriate to split a single
document into two or more, or if new aspects of MPLS-TP needs to
be specified.
4. Everytime a document is accepted by the MEAD team into the set
of documents coordinated by the MEAD team a liaison is sent to
the ITU-T with a pointer to the document. At the same time note
is sent to the MPLS-TP ad hoc team mailing list informing that
the document has become a MEAD team document.
The ITU-T may chose to respond to the liaison but is not
required to do so, see Section 3 and Section 4.
5. At any time it is possible for the ITU-T SGs and Questions to
send review comments on MEAD team documents. It is also
possible for the MEAD team to ask for such reviews and comments.
Any time such an input or requests are sent between the two
organizations it SHALL be accompanied by a note from the MPLS-TP
ad hoc team chair(s) to the MEAD team mailing list, or from the
Andersson, et al. Expires August 30, 2009 [Page 8]
Internet-Draft MPLS-TP document process February 2009
MEAD team chair to the MPLS-TP ad hoc team mailing list. This
is done to enhance the efficiency of the information exchange.
6. A working group or the MEAD team may issue requests for general
comments on MPLS-TP documents at any time, if it is deemed
appropriate to extend these requests to the MPLS-TP ad hoc team
this is done via a note according to entry (5) in this list.
7. If a MPLS-TP document is mature enough to become a working group
document a poll is done on the mpls-tp mailing list and the
appropriate wg mailing list, this request will also be sent to
the ITU-T as a liaison. A note will also be sent to the MPLS-TP
ad hoc team.
Which working group a document goes into is decided jointly
between the MEAD team, working group chairs of the potential
working groups and the document editors/authors.
If the document is accepted as a working group document the
working group takes over the revision control of the document.
The ITU-T is expected to respond to the liaison within in the
time indicated in the liaison, see Section 3 and Section 4.
8. Every time a MPLS-TP document is accepted as a working group
document by any IETF working group a liaison is sent to the
ITU-T with a pointer to the document. At the same time note is
sent to the MPLS-TP ad hoc team mailing list informing that the
document has become a working group document.
9. Working group documents may be reviewed in several steps, every
time such a review is initiated the MPLS-TP ad hoc team is
notified (10).
Note that most reviews that leads to updates of working group
documents are spontaneous individual comments from participants
in the MPLS-TP effort.
10. Every time a review is initiated by a working group the
appropriate ITU-T SGs and Questions will be notified by a mail
to the MPLS-TP ad hoc team.
Optionally the request for review may be accompanied by a
liaison to formalize the request.
The MPLS-TP ad hoc is responsible for ensuring that any e-mail
requests are copied/forwarded the relevant SGs and Questions.
Andersson, et al. Expires August 30, 2009 [Page 9]
Internet-Draft MPLS-TP document process February 2009
11. When a document is deemed to mature enough a working group last
call is initiated. At this time the action describe under item
12 in this list MUST be executed.
12. Procedures to be followed when a working group last call is
inititated.
* A liaison containing a request for participation in the
working group last call will be sent to the appropriate ITU-T
SG and Questions
* A mail with a notification that the working group lst call is
taking place will be sent to the MPLS-TP ad hoc team.
* ITU-T is REQUIRED to respond to the liaison within the time
indicated. The MPLS-TP ad hoc team is expected to verify
that all the SGs and Questions with the ITU-T that needs to
respond to the working group last call are aware that it has
been issued.
Note that a request to participate in an IETF are in some
ways different from any other of the information exchanges
according to the process adaptations described in this
document between the IETF and the ITU-T.
+ This is the last point in this process where IETF
processes are adapted for the purpose of facilitating the
development of the MPLS-TP standard.
+ A response is REQUIRED, at all other points in the process
lack of comments will be interpreted as "no issues".
13. When all last call are addressed and responded to a request for
publication will be sent to the IESG. The document after this
point in time handled as any other IETF document.
Note: WG last call may be re-iterated, for the entire document
or limited to only verify the updates made because of an earlier
working group last call.
Andersson, et al. Expires August 30, 2009 [Page 10]
Internet-Draft MPLS-TP document process February 2009
3. Expectations on ITU-T participation in the process
The IETF and ITU-T processes for the development of the MPLS-TP
standards interconnect at the following point in the flow chart above
(4), (5), (7a), (8), (10) and (12). This section describes in short
what is expected to happen on the ITU-T side at the interaction
points.
3.1. Becoming a MEAD team document
(4) is a point where the MEAD team communicates to the ITU-T that a
document is considered to be accepted to be coordinated by the MEAD
team.
The ITU-T is expected to respond to the communication with a simple
ACK or NAK, however a non-response is counted as an ACK.
An ACK means that ITU-T accepts that the documents has become a MEAD
team document, a NAK means that ITU-T has issues that needs to be
resolved before the document is allowed to progress.
3.2. Comments on MEAD team documents by participants in the ITU-T
(5) and (10) offers possibilities for ITU-T or people active in the
ITU-T to send un-triggered comments on MEAD team or working group
documents. Such comments shall be sent to the mpls-tp list and for
working group documents also to the appropriate working group mailing
list. Comments received in this way will be treated as the same way
any as other individual comments received on the IETF documents.
3.3. Poll for working group documents
(7a) is the point where an IETF working group informs the ITU-T that
a poll to progress a document to an IETF working group document has
been started.
It is not necessary or required for the ITU-T to respond to this
message. If the ITU-T has serious concerns these should be provided
via a liaison statement. If the ITU-T has no serious concerns it is
allowed and encouraged that individual participants provide comments.
Such responses shall be sent to the appropriate working group and
mpls-tp mailing lists and represent the view of the person sending
the mail.
An Internet Draft is ready to become a working group draft if it
meets at least the three criteria below.
Andersson, et al. Expires August 30, 2009 [Page 11]
Internet-Draft MPLS-TP document process February 2009
o it is within the charter of the working group
o it addresses a problem that needs to be solved
o it is a good enough start to solve this problem
Responses to polls for checking if a document is ready to become a
working group document should be limited to answer if the document
meets those three criteria.
3.4. Responding to an IETF Working Group Last Call
(12) is the point in the process where ITU-T is made aware of that an
IETF working group last call has been started. The working group
last call is issued when a working group document is getting close to
be ready for publication. The intention is to make sure that there
are no important pieces missing and that technical details are
correct.
According to the JWT decision ITU-T is required to respond to a
working group last call within the time set for the working group
last.
The chair of an IETF working group that starts a working group last
call will send a liaison to the ITU-T announcing the working group
last call. A message will also be sent to the MPLS-TP ad hoc team.
The IETF will make a best effort to target the SGs and Questions that
should be involved in responding to the working group last call.
However, the ITU-T has to make sure that the appropriate entities
within the ITU-T participate in responding to the working group last
call. The ITU-T MPLS-TP ad hoc team coordinates the development of
the ITU-T response to the working group last call.
Andersson, et al. Expires August 30, 2009 [Page 12]
Internet-Draft MPLS-TP document process February 2009
4. Specific guidelines that apply to work on MPLS-TP in the ITU-T
These guidelines apply to progressing work on MPLS-TP in the ITU-T.
Any member of the ITU-T may send a MPLS-TP contribution to a ITU-T
Study Group or Question.
Before the ITU-T initiates any new work (i.e. items not previously
identified by the JWT) based on such contributions the ITU-T shall
send a liaison to the IETF. The message will go to the MEAD team,
the team is responsible for creating a consolidated IETF response.
The IETF is expected to respond to the information that a new
MPLS-TP work item has been proposed with an ACK or NAK.
If the response is a NAK that work item is held until the issues
is resolved.
Andersson, et al. Expires August 30, 2009 [Page 13]
Internet-Draft MPLS-TP document process February 2009
5. IANA considerations
There are no requests for IANA allocation of code points in this
document.
Andersson, et al. Expires August 30, 2009 [Page 14]
Internet-Draft MPLS-TP document process February 2009
6. Security considerations
This document defines a process adaptation for the cooperation
between IETF and ITU-T and thus does not introduce any new security
considerations.
Andersson, et al. Expires August 30, 2009 [Page 15]
Internet-Draft MPLS-TP document process February 2009
7. Acknowledgments
Andersson, et al. Expires August 30, 2009 [Page 16]
Internet-Draft MPLS-TP document process February 2009
8. References
8.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT)
Report on MPLS Architectural Considerations for a
Transport Profile", RFC 5317, February 2009.
8.2. Informative references
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
Andersson, et al. Expires August 30, 2009 [Page 17]
Internet-Draft MPLS-TP document process February 2009
Authors' Addresses
Loa Andersson
Redback Networks
Email: loa@pi.nu
David Ward
Cisco Systems
Email: dward@cisco.com
Malcolm Betts
Nortel
Email: betts01@nortel.com
Andersson, et al. Expires August 30, 2009 [Page 18]