Network Working Group S. Bryant
Internet-Draft Cisco Systems
Intended status: Informational
Expires: October 1, 2010 A. Farrel
Huawei Technologies
April 1, 2010
IETF Expectations of Participation in Development and Review of
ITU-T Recommendations on MPLS-TP
draft-farrel-mpls-tp-recommendation-review-01.txt
Abstract
The decision to develop a Multiprotocol Label Switching (MPLS)
Transport Profile (MPLS-TP) in cooperation between the IETF and the
ITU-T is documented in RFC 5317 as the report of the Joint Working
Team on MPLS-TP. As part of this development process, the
International Telecommunication Union - Telecommunication
Standardisation Sector (ITU-T) will develop a number of
Recommendations. Those Recomendations will allow MPLS-TP to be
integrated with current transport equipment and networks, including,
in agreement with the IETF, the definition of any ITU-T-specific
functionality within the MPLS-TP architecture via the Change Process
for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Protocols and Procedures.
This document sets out the IETF's expectations of how the IETF,
through individual participation and through consensus decisions,
will contribute to in the development, review, and approval of those
Recommendations.
This document does not modify any existing ITU-T or IETF procedures,
but shows how those procedures can be used to facilitate cooperation
for the MPLS-TP project.
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."
Farrel and Bryant [Page 1]
Internet-Draft Review of MPLS-TP Recommendations April 2010
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 Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Farrel and Bryant [Page 2]
Internet-Draft Review of MPLS-TP Recommendations April 2010
1. Introduction
The decision to develop a Multiprotocol Label Switching (MPLS)
Transport Profile (MPLS-TP) in cooperation between the IETF and the
ITU-T is documented in [RFC5317] as the report of the Joint Working
Team on MPLS-TP. As part of this development process, the
International Telecommunication Union - Telecommunication
Standardisation Sector (ITU-T) will develop a number of
Recommendations. Those Recomendations will allow MPLS-TP to be
integrated with current transport equipment and networks, including,
in agreement with the IETF, the definition of any ITU-T-specific
functionality within the MPLS-TP architecture via the Change Process
for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Protocols and Procedures [RFC4929].
This document sets out the IETF's expectations of how the IETF,
through individual participation and through consensus decisions,
will contribute to in the development, review, and approval of those
Recommendations.
This document does not modify any existing ITU-T or IETF procedures,
but shows how those procedures can be used to facilitate cooperation
for the MPLS-TP project.
1.1. Terminology
This documents uses a number of terms that are common to the MPLS-TP
cooperation project. Please refer to [MPLS-TP-PROCESS] for a list of
applicable IETF and ITU-T terms.
1.2. Purpose, Intent, and Procedures for Cooperation on MPLS-TP
This section is a deliberate restatement of the equivalent section
in [MPLS-TP-PROCESS]. It is reproduced here because the purpose and
intent of the cooperation project on MPLS-TP is fundamental to the
establishment of procedures for that cooperation, and is the basis
for the IETF's expectations of participation in the ITU-T's
development of MPLS-TP Recommendations.
The purpose and objectives of the development activity on MPLS-TP is
described in [RFC5317]. The JWT report, accepted by the ITU-T and the
IETF, includes the recognition that the design authority for MPLS
(including MPLS-TP) is the IETF.
At the same time, the JWT report recognises the role of the ITU-T in
providing input (especially input to the requirements statements) to
the development process for MPLS-TP. There is also a clear statement
of expectation that the ITU-T's opinions will be heard within the
Farrel and Bryant [Page 3]
Internet-Draft Review of MPLS-TP Recommendations April 2010
IETF and must be properly considered during the development of
MPLS-TP documents.
It should be noted that the IETF will continue to work on MPLS and
pseudowire technologies for core MPLS (i.e., not MPLS-TP)
deployments. Additionally, the IETF will work on technologies that
are close to, but not directly part of MPLS-TP (for example, the OSPF
routing protocol, and bidirectional forwarding detection - BFD). All
work by the IETF on the development of Internet technologies will
proceed as before, and the IETF welcomes participation from all
individuals. Where such developments overlap with MPLS-TP such that
they are important to the work on MPLS-TP, they will form part of the
cooperation project.
The development of standards for MPLS-TP is, therefore, carried out
within the IETF according to IETF process and with strong input from
the ITU-T. This input takes three forms (see also Section 2.2):
o Active participation.
All interested parties are encouraged to participate in the
development of MPLS-TP standards within the IETF through the
normal IETF process. In short, this involves the generation and
documentation of new ideas as Internet-Drafts, and the discussion
of work in progress through the IETF mailing lists, at IETF
meetings, and through informal conversations and conference calls.
The IETF is not a membership organisation; the mailing lists and
meetings are open to everyone.
o Informal communication.
It is recognised that discussions about MPLS-TP will take place
within the Questions and Study Groups of the ITU-T. In order to
speed up the development process and ensure smooth communications,
the ITU-T is requested to make informal (i.e., email, conference
call, face-to-face conversation) communications to the IETF
whenever any issues or questions arise. Informal communication can
be made by any individual or Rapporteur of a Question, and the
MPLS-TP mailing list is the default forum for such communication.
The chairs of the Ad Hoc Team on MPLS-TP may also summarise
discussions within the ITU-T (especially those on the Ad Hoc Team
on MPLS-TP mailing list) and communicate them to the IETF via
email.
o Formal communication.
The formal liaison process with the IETF is described in [RFC4052]
and [RFC4053]. This process will be used for ensuring that
Farrel and Bryant [Page 4]
Internet-Draft Review of MPLS-TP Recommendations April 2010
specific progress steps are check-pointed and recorded, and for
making sure that appropriate responses are generated in a timely
manner. Formal liaison communications may be marked as "For
Action", "For Comment", or "For Information" depending on the
level of feedback that is required. Where formal liaison
communication is indicated in this document, the type of liaison
that is advised in each instance is also indicated.
The objective of cooperation between the IETF and ITU-T is to ensure
full participation of interested parties in order to make sure that
all opinions are heard with the intention of producing sound and
stable MPLS-TP documentation. It is understood that the neither the
IETF nor the ITU-T is in a position to block the work of the other
body within its areas of authority. In the context of this document,
this means that the ITU-T cannot block IETF work on MPLS-TP against
the IETF consensus view.
Part of this process must be the understanding that all IETF
documentation (including RFCs) can be revised or extended according
to normal IETF procedures. Therefore, it is not a requirement that
the first version of any RFC be perfect for all time (we do not need
to "boil the ocean"); the initial aim of the work is to provide
documentation of MPLS-TP as it is initially developed and deployed.
Fundamental to understanding the process described in the rest of
this document and to participating in the MPLS-TP development process
is a working knowledge of the procedures of the IETF. Readers needing
clarification of the IETF procedures are invited to read [RFC2026],
[RFC4677], and [RFC4929]. Further clarification and guidance can be
obtained from the MPLS-TP responsible working group chair, the MPLS-
TP responsible AD, and the IETF liaison to the ITU-T on MPLS.
The ITU-T may also develop Recommendations to document MPLS-TP. The
JWT decision recognises that these Recommendations must not contain
normative definitions of MPLS-TP (these are captured solely in IETF
RFCs). Recommendations on MPLS-TP will be provided for review by the
IETF to ensure conformance with the previous point and to verify that
the material is consistent across MPLS-TP. The process for producing
and reviewing Recommendations is the subject of this document.
1.3. Communications with the ITU-T
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.
Farrel and Bryant [Page 5]
Internet-Draft Review of MPLS-TP Recommendations April 2010
o Informal information exchange
This is done primarily by e-mail to the relevant mailing lists.
Information sent to the ITU-T must be sent to the Ad Hoc Team on
MPLS-TP mailing list. Information sent to the IETF must be sent to
the MPLS-TP mailing list.
o Formal information exchange
In addition to the informal information exchange, a formal
information exchange is accomplished by liaison correspondence
between the two organisations. Exchange of liaisons makes it
possible to follow the request/response exchange between the
organisations in more detail, and to obtain an official view of
each organisation's position on any topic.
Formal liaisons should include tracking numbers in their subject
lines to facilitate easy coordination of responses with the
requests to which they are associated.
1.3.1. Document Formats
The purpose of communications in the context of this document is the
review of draft text of Recommendations. Such text is usually worked
on by the ITU-T using Microsoft Word, and it is expected that it will
be supplied to the IETF as either a Word document or in PDF. Such
files may be quite large as a result of embedded figures.
Recommendation text sent to the IETF as part of formal liaisons
will be archived alongside the liaisons in the IETF repository. In
this case, file size will not be an issue.
Recommendation text sent as part of an informal communication is
quite likely to exceed the message size limits on IETF mailing lists.
Senders of such communications are advised to place the text files on
publically accessible FTP sites.
1.4. Non-Response to Liaisons
The liaison relationship between the IETF and the ITU-T is founded on
the understanding that each party will respond in a timely and
appropriate manner to the other party's liaisons so long as
reasonable notice is given.
Failure to respond by a deadline properly expressed in a liaison must
not be used to cause deadlock or to block advancement of work. Such
failures shall be assumed to represent accidental errors or
oversights and shall be brought to the attention of the management of
Farrel and Bryant [Page 6]
Internet-Draft Review of MPLS-TP Recommendations April 2010
the body that has failed to respond.
In extreme cases, the JWT is empowered to convene itself to resolve
issues of failed communications.
2. High-Level Description of the ITU-T Development and Approval Process
This section provides a high-level description of the processes used
within the ITU-T for the development and approval of Recommendations.
This section is for information only and is not a normative
description of these processes.
2.1. Development of Recommendation Text
This document makes no change to the normal procedures for the
development of Recommendation text.
IETF participants whose companies or organizations are members of the
ITU-T may contribute to the text of Recommendations using the normal
procedures of submitting Contributions or participating in ITU-T
meetings.
ISOC delegates (usually people holding IETF management or liaison
positions) may also attend ITU-T meetings and contribute to the
development of Recommendation text.
Invited Experts may also attend ITU-T meetings at the discretion of
the ITU-T management. These experts may be invited according to their
particular areas of expertise and can contribute to the efforts to
develop Recommendation text.
Section 3 of this document describes how the IETF may participate in
the development and review of ITU-T Recommendation text. Formal
liaisons form an important part of this process and allow the IETF to
provide review comments and make suggestions in the process of the
development of ITU-T Recommendations.
2.2. Final Edit, Consent, and Approval of Recommendations
It is anticipated that all of the MPLS-TP Recommendations will be
approved by the ITU-T via the Alternative Approval Process (AAP)
defined in Recommendation A.8 [A.8]
The process used for MPLS-TP Recommendations will be that the draft
text of Recommendations intend for consent will be made available at
least 7 working days before the SG15 meeting at which consent is
planned.
Farrel and Bryant [Page 7]
Internet-Draft Review of MPLS-TP Recommendations April 2010
At that meeting, the text may be edited based only on the
contributions or liaison statements available at the meeting. Note
that the draft Recommendation can only be modified based on these
specific inputs.
On the final day of the meeting, if the members present agree to
consent the draft Recommendation (as modified during the meeting)
then the last call process is initiated. As defined in Recommendation
A.8 [A.8], last call is a 4 week period during which members of the
ITU-T can submit comments. If substantive comments are submitted
during the last call period they are addressed by modifying the draft
Recommendation. When all parties are satisfied, an additional review
is initiated. After the additional review the Recommendation is
either approved or, exceptionally, if objections are received, the
Recommendation is returned to the next meeting of the study group for
further work.
3. IETF Input to ITU-T Development Process
In accordance with the agreements reached in the JWT [RFC5317], it is
important that the IETF has adequate opportunity to review the draft
Recommendations at a stage where changes can be readily accommodated,
i.e., before consent and the initiation of the Last Call period.
The participation of experts from the IETF in the early stages of the
development of the MPLS-TP Recommendations is critical to the
successful completion of the final stages of this process. This early
interaction will be facilitated by taking the following steps:
- At any time in the process of developing the text for an MPLS-TP
Recommendation, the ITU-T may solicit input or clarification by
sending email to the IETF's MPLS-TP mailing list (mpls-tp@ietf.org)
or by sending a liaison For Action.
- IETF participants whose companies are members of the ITU-T are
strongly encouraged to participate in the development of the
Recommendation text through the normal ITU-T process by submitting
contributions, and by participating in meetings and virtual
meetings to discuss the content.
- Once the draft Recommendation has reached a reasonable state of
stability the text will be sent to the IETF in a liaison For
Comment to solicit early review and comments.
4. IETF Input to the ITU-T Final Modification and Consent Process
It is important to allow the IETF time to review the draft
Recommendation that is intended for consent at an SG15 meeting, and
to allow the IETF to provide comments as a liaison statement to the
Farrel and Bryant [Page 8]
Internet-Draft Review of MPLS-TP Recommendations April 2010
meeting so that the comments can be used as a source for final
modification of the Recommendation text
To facilitate this, the IETF expects that the ITU-T will make a
version of the draft text available 3 weeks before the start of the
SG 15 meeting. This draft can be reviewed by the IETF and will be
the version of the text presented to the SG 15 meeting.
A response liaison from the IETF to convey any review comments or a
statement that there are no comment is required and should reach the
ITU-T before the start of the meeting.
During the SG15 meeting, the draft Recommendation will be updated
based on the contributions and liaison statements available at the
meeting (including the comments from the IETF review). This may
result in any of:
- no changes to the draft text if there is no input
- modifications consistent with the comments received from the IETF
- additional modifications based on contributions from other parties.
The IETF participation in this final modification is limited to
participation at the meeting by representatives of organizations that
are ITU-T Sector Members. This does not constitute formal IETF
participation, but some of the same people may be involved.
At the end of the meeting, the modified text will be considered for
consent by the members of the SG who are present. This will decide
whether the Recommendation will proceed to last call and approval.
In order that the MPLS-TP work developed by the IETF and ITU-T can
proceed as a cooperative development, it is important that the text
of the Recommendation that is consented and taken forward does not
contain modification of substance that have not been reviewed and
agreed by the IETF. This means that editorial changes made within the
SG15 meeting are acceptable, but that technical changes may require
further review and agreement by the IETF.
A judgement call must be made to determine which changes are
substantial and require further IETF review and agreement. The IETF
shall designate one individual present at the SG15 meeting to make
this decision with the assistance of the ITU-T management responsible
for the Recommendation concerned. This person will usually be the
ISOC delegate, but may be some other designated person (for example,
the IETF's liaison on MPLS, an Area Director, or a working group
chair).
Farrel and Bryant [Page 9]
Internet-Draft Review of MPLS-TP Recommendations April 2010
If the judgment call is that further IETF review and agreement is
required, a choice must be made:
- If the changes are small, the Recommendation may continue to be
consented with the understanding that any changes identified during
IETF review will be submitted to the ITU-T as last call comments
(see Section 5).
- If the change is more significant, the designated IETF
representative will advise the Study Group through the Study Group
chair. In this case, the IETF expects that the text will be sent
back to the IETF for further review and agreement prior to consent.
Depending on the result of the IETF review, the ITU-T Question
responsible for the Recommendation will undertake further work to
revise the text and initiate additional IETF review before
proposing the revised text for consent.
The process used for IETF review and agreement is that a copy of the
final text of the Recommendation as proposed for consent will be sent
to the IETF in a liaison for Action and the IETF will immediately
hold a further last call on an email list that it designates (usually
the MPLS-TP email list). Normal IETF rough consensus mechanisms will
be used to judge support for approval and to request further changes,
except that silence will be determined to represent support for
approval.
5. IETF Input to the ITU-T Last Call and Approval Process
This document does not modify the ITU-T's last call and approval
process as defined in Recommendation A.8 [A.8].
The IETF's expectation is that, by the time last call is held, the
IETF will have already reviewed and agreed the text of the
Recommendation. Thus, it is not expected that the IETF will need to
make any comments during last call. If, however, an issue is
discovered during the last call period, it will be sent to the ITU-T
in a formal liaison.
If substantive comments are submitted to the ITU-T from other sources
during the last call period they will be addressed by modifying the
draft Recommendation. When all parties are satisfied, an additional
review will be initiated within the ITU-T and it is the IETF's
expectation that the IETF would be notified of any changes and given
the opportunity to comment and agree the changes. If, after the
additional review there are still objections, the Recommendation will
be returned to the next meeting of the study group for further work.
Farrel and Bryant [Page 10]
Internet-Draft Review of MPLS-TP Recommendations April 2010
6. Guidelines For MPLS-TP work 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 an 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 IETF
liaison to the ITU-T on MPLS, the MPLS-TP responsible working
group chair, and the MPLS-TP responsible AD. They are responsible
for sending a consolidated response from the IETF, but may
delegate the work of writing the response.
- The IETF must respond to such liaisons according to the deadline
in the liaison. Acceptable responses include:
o Acknowledgement of receipt and agreement that the ITU-T is
clear to proceed with the work described.
o Request that the work described be transferred from the ITU-T to
the IETF in the form of an Internet-Draft to form part of the
MPLS-TP work in the IETF.
o Request that the work be put on hold until specific issues have
been resolved. In the event that this response is seen as
blocking of ITU-T work, the JWT may be convened to seek a
resolution.
Note that the process described in this section is conformant to the
Change Process for Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Protocols and Procedures [RFC4929] and is in
accord with the IETF's Best Current Practice Procedures for Protocol
Extensions and Variations [RFC4775].
7. IANA Considerations
There are no requests for IANA action in this document.
8. Security Considerations
This document describes the IETF's expectations for participating in
the development of ITU-T Recommendations on MPLS-TP and thus does not
introduce any new security considerations.
The successful development of MPLS-TP standards that are consistent
across the industry is an essential component to ensuring the
Farrel and Bryant [Page 11]
Internet-Draft Review of MPLS-TP Recommendations April 2010
security and stability of MPLS networks.
9. Acknowledgments
Thanks to the participants in the ITU-T Study Groups 15 (Questions 3,
9, 10, 12, and 14) interim meeting in May 2009 for writing a liaison
on which a significant part of this text is based [LS-54] and for
providing review of this text. Thanks to Malcolm Betts and to Ross
Callon for review comments and input. Thanks to the joint ITU-T and
IETF Management Steering Group on MPLS-TP for their review of the
content of this document. Yuanlong Jiang, Ben Niven-Jenkins, Tom
Petch, and Scott Mansfield provided helpful comments.
10. References
10.1. Normative References
10.2. Informative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC4052] Daigle, L., Ed., and Internet Architecture Board, "IAB
Processes for Management of IETF Liaison Relationships",
BCP 102, RFC 4052, April 2005.
[RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for
Handling Liaison Statements to and from the IETF", BCP
103, RFC 4053, April 2005.
[RFC4677] Hoffman, P. and Harris, S., "The Tao of IETF: A Novice's
Guide to the Internet Engineering Task Force", RFC 4677,
September 2006.
[RFC4775] Bradner, S., Carpenter, B, and Narten, T., "Procedures for
Protocol Extensions and Variations", BCP 125, RFC 4775,
December 2006.
[RFC4929] Andersson, L. and Farrel, A., "Change Process for
Multiprotocol Label Switching (MPLS) and Generalized MPLS
(GMPLS) Protocols and Procedures", BCP 129, RFC4929, June
2007.
[RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT)
Report on MPLS Architectural Considerations for a
Transport Profile", RFC 5317, February 2009.
Farrel and Bryant [Page 12]
Internet-Draft Review of MPLS-TP Recommendations April 2010
[A.8] ITU-T, "Alternative approval process for new and revised
ITU-T Recommendations", Recommendation A.8, October 2008.
[LS-54] ITU-T Study Group 15, "IETF Review of ITU-T MPLS-TP
Recommendations", Liaison Statement, COM15-LS54-E, May
2009.
[MPLS-TP-PROCESS] Farrel, A., Betts, M., Andersson, L. and Ward, D.,
"IETF Multi-Protocol Label Switching (MPLS) Transport
Profile (MPLS-TP) Document Process", draft-ietf-mpls-tp-
process, work in progress.
Authors' Addresses
Adrian Farrel
Huawei Technologies
Email: adrian.farrel@huawei.com
Stewart Bryant
Cisco Systems
Email: stbryant@cisco.com
Farrel and Bryant [Page 13]