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]