| < draft-zinin-ietf-jtc1-aggr-00.txt | draft-zinin-ietf-jtc1-aggr-01.txt > | |||
|---|---|---|---|---|
| A new Request for Comments is now available in online RFC libraries. | ||||
| Network Working Group Alex Zinin | RFC 3563 | |||
| Internet Draft Alcatel | ||||
| Expiration Date: April 2003 October 2002 | ||||
| File name: draft-zinin-ietf-jtc1-aggr-00.txt | ||||
| Draft of agreement between ISOC/IETF and ISO/IEC JTC1/SC6 | ||||
| on IS-IS protocol development | ||||
| draft-zinin-ietf-jtc1-aggr-00.txt | ||||
| Status of this Memo | ||||
| This document is an Internet-Draft and is in full conformance with | ||||
| all provisions of Section 10 of RFC2026. | ||||
| 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. Internet Drafts may be updated, replaced, or obsoleted by | ||||
| other documents at any time. It is not appropriate to use Internet | ||||
| Drafts as reference material or to cite them other than as a "working | ||||
| draft" or "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. | ||||
| Abstract | ||||
| This document contains a proposed text of the agreement between | ||||
| ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of | ||||
| the IS-IS routing protocol. The agreement includes definitions of the | ||||
| related work scopes for the two organizations, request for creation | ||||
| and maintenance of an IS-IS registry by IANA, as well as | ||||
| collaboration guidelines. | ||||
| Please send any comments on this document to the IESG (iesg@ietf.org) | ||||
| Document Header | ||||
| Title: Draft Addendum 1 (to Cooperative Agreement Between the | ||||
| Internet Society and the International Organization for | ||||
| Standardization / International Electrotechnical Commission / Joint | ||||
| Technical Committee 1 / Sub Committee 6 (ISO/IEC JTC1/SC6): IS-IS | ||||
| Routing Protocols | ||||
| Date: XXXX | ||||
| This addendum records the agreed collaborative process for the | ||||
| further development and standardisation of the Intermediate System to | ||||
| Intermediate System (IS-IS) intra-domain routing protocol (ISO/IEC | ||||
| 10589). | ||||
| 1. Introduction | ||||
| The IS-IS intra-domain routing protocols, originally developed in | ||||
| ISO/IEC/JTC1/SC6, have been successfully deployed in the Internet for | ||||
| several years. | ||||
| ISO/IEC/JTC1/SC6 is the JTC1 sub-committee which has responsibility | ||||
| for maintenance of the IS-IS standard (ISO/IEC 10589). | ||||
| The IS-IS Working Group of the IETF is chartered to develop | ||||
| extensions to the IS-IS protocol to be used within the scope of the | ||||
| Internet. | ||||
| This addendum documents the agreed process for the future development | ||||
| of IS-IS by both organisations. | ||||
| 2. Definitions | ||||
| 2.1 Core IS-IS Mechanisms | ||||
| Core IS-S Mechanisms are subsystems with associated algorithms, data | ||||
| structures, and PDU formats as specified in (ISO/IEC 10589), | ||||
| constituting the core of the IS-IS protocol and including the | ||||
| following elements: | ||||
| a) Framework of PDU formats, including standard TLVs | ||||
| b) Encapsulation of PDUs | ||||
| c) Adjacency state machine and formation logic | ||||
| d) DIS election algorithm | ||||
| e) Initial LSP synchronization via CSNP exchange | ||||
| f) Asynchronous LSP flooding (including DIS flooding behavior) | ||||
| g) LSP database maintenance including LSP origination, aging, and | ||||
| purging | ||||
| h) Standard topology abstraction | ||||
| 2.2 Internet-specific IS-IS Extensions: | ||||
| Internet-specific IS-IS Extensions are extensions to the IS-IS proto- | ||||
| col that are within the work scope of the IETF (including, but not | ||||
| limited to IPv4 or IPv6 unicast and multicast routing, MPLS, MPLS TE, | ||||
| GMPLS, or any other routing technology that the IETF decides to work | ||||
| on in future), and: | ||||
| a) do not modify the Core IS-IS Mechanisms and do not change | ||||
| operation of non-IP or affect compatibility with non-IP and | ||||
| dual implementations of IS-IS, or | ||||
| b) add supplementary mechanisms to the Core IS-IS Mechanisms, are | ||||
| not generally applicable to non-IP implementations of IS-IS, | ||||
| and do not change operation of non-IP or affect compatibility | ||||
| with non-IP and dual implementations of IS-IS, or | ||||
| c) are de facto implementation agreements that are not generally | ||||
| applicable to non-IP implementations of IS-IS. | ||||
| Note that in the text above introduction of new TLVs or sub-TLVs | ||||
| without modifying the algorithms of the Core Mechanisms in a way | ||||
| affecting interoperability with non-IP or dual implementations of IS- | ||||
| IS is not considered to be a modification to the Core IS-IS Mecha- | ||||
| nisms. | ||||
| 3. Agreement | ||||
| The following conventions are used in the rest of this document. | ||||
| SHALL This term is used to indicate commitment to follow | ||||
| a specific element of this agreement. | ||||
| MUST Equivalent to "SHALL" | ||||
| SHALL NOT This phrase is used to indicate commitment to NOT | ||||
| perform a specific action | ||||
| MAY This term is used to indicate the right to perform a | ||||
| specific action | ||||
| SHOULD This term is used to indicate that following a specific | ||||
| element of this agreement is encouraged, however there | ||||
| may exist circumstances in which a decision may be made | ||||
| not to do so. | ||||
| 3.1 Separation of IS-IS Work Scope | ||||
| JTC1 SHALL NOT and IETF MAY (subject to the IETF standards process) | ||||
| standardize any Internet-specific IS-IS Extensions. | ||||
| Any IS-IS Extensions produced within the IETF that require standard- | ||||
| ization, but cannot be identified as Internet-specific per section | ||||
| 2.2 of this document SHOULD be submitted for standardization to JTC1 | ||||
| (see section 3.3.2). IETF SHALL NOT publish documents describing such | ||||
| IS-IS extensions other than as Informational RFCs. | ||||
| IS-IS extensions submitted from the IETF to JTC1 will be processed | ||||
| under the JTC1 fast track procedure. To ensure the quality of such | ||||
| submissions, IETF SHALL apply to them the procedures for Proposed | ||||
| Standard submission according to [RFC2026] (even though these docu- | ||||
| ments will not be published as standards-track IETF RFCs). | ||||
| 3.1 Requirements for IS-IS-specific IETF documents | ||||
| All IS-IS-related IETF draft documents intended to be published as | ||||
| IETF standards track RFCs MUST include a section explaining why they | ||||
| qualify to be considered as Internet-specific IS-IS Extensions | ||||
| described in section 2.2 of this document. | ||||
| 3.2 IS-IS Registries (IANA Considerations) | ||||
| 3.2.1 IS-IS TLV Codepoint Registry | ||||
| Until JTC1 provides the registry service for IS-IS, IANA is requested | ||||
| to temporarily maintain such a registry as described below. Upon | ||||
| notification from JTC1, the registry management authority (i.e., | ||||
| value allocation) will be transferred to JTC1. IANA MAY still retain | ||||
| the registry for informational purposes and keep updating it based on | ||||
| information provided by JTC1. | ||||
| IANA is requested to create and maintain a registry for IS-IS TLV | ||||
| codepoints. The range of values is 0-255. Initial state of the reg- | ||||
| istry should be synchronized with [ISIS-TLVS]. Allocation of values | ||||
| in the registry has to be approved by the designated expert assigned | ||||
| by the IESG. IETF SHALL keep JTC1/SC6 informed of TLV codepoint | ||||
| values allocated, and JTC1/SC6 SHALL refer allocation requests aris- | ||||
| ing within JTC1 constituencies to the IANA registry process. | ||||
| 3.2.2 IETF-specific Registries | ||||
| IETF MAY request IANA to maintain IS-IS-related registries if those | ||||
| are required to maintain name spaces internal to Internet-specific | ||||
| IS-IS extensions. | ||||
| 3.3 Collaboration Guidelines | ||||
| 3.3.1 Learning About New Work | ||||
| IETF SHALL inform the chairman and secretariat of ISO JTC 1/SC 6 | ||||
| about new IS-IS-related work items. | ||||
| JTC1/SC6 SHALL inform the IETF Routing Area directors and ISIS WG | ||||
| chairs about new IS-IS-related work items. | ||||
| Communication MAY be enacted directly using electronic mail, or may | ||||
| be conducted via appointed SC6 / IETF liaison representatives. | ||||
| 3.3.2 Submitting IETF Documents to JTC1 | ||||
| As a class A liaison organisation to JTC1, the Internet Society may | ||||
| submit existing standards for adoption as International Standards of | ||||
| the ISO, using the Fast-Track procedure. | ||||
| IS-IS extensions developed by IETF and intended for standardization | ||||
| in JTC1 according to section 3.1 SHOULD therefore be submitted by one | ||||
| of the IETF ISIS WG chairs, or an IETF Routing Area director, sending | ||||
| an e-mail message to the secretariat of ISO JTC 1 specifying the num- | ||||
| ber of the Informational RFC containing the specification (the docu- | ||||
| ment MUST have been published as an RFC at the time of submission) | ||||
| and requesting fast-track processing by JTC1. The full text of the | ||||
| specification is then available using the following URL: | ||||
| http://www.ietf.org/rfc/rfcNNNN.txt | ||||
| where "NNNN" is the number of the RFC being submitted. The IETF | ||||
| SHOULD also recommend that JTC1 assign the document to JTC1/SC6, and | ||||
| SHOULD also submit to JTC1 the name of an individual who is prepared | ||||
| to serve as project editor for the fast-track document. | ||||
| 3.3.3 Submitting JTC1 Documents to IETF | ||||
| It is possible to make JTC1 standards specifications available for | ||||
| informational purposes of the IETF community by submitting the text | ||||
| of the specification as an Internet Draft and requesting the RFC Edi- | ||||
| tor to publish the document as an Informational RFC. See sections | ||||
| 4.2.2 and 7 of [RFC2026] for more information. Guidelines for Inter- | ||||
| net Draft preparation are given in [ID-GUIDE]. | ||||
| 3.3.4 Mutual Document Review | ||||
| Members of ISO JTC 1/SC 6 are welcome to review any IS-IS-related | ||||
| IETF document (all IETF documents are publicly available at the IETF | ||||
| web site) and submit their comments to the ISIS WG (by sending an e- | ||||
| mail to the working group mailing list), the ISIS WG chairs, the IETF | ||||
| Routing Area directors, or the IESG (iesg@ietf.org). | ||||
| JTC1 is encouraged to request an IETF review of IS-IS-related work | ||||
| performed by JTC 1/SC 6 by submitting the text of the document as an | ||||
| informational Internet Draft (see section 3.3.2) and sending a mes- | ||||
| sage to the IETF ISIS WG mailing list requesting the comments. | ||||
| 4. References | ||||
| [10589] | ||||
| ISO, "Intermediate system to Intermediate system routeing informa- | ||||
| tion exchange protocol for use in conjunction with the Protocol for | ||||
| providing the Connectionless-mode Network Service (ISO 8473)", | ||||
| ISO/IEC 10589:1992. | ||||
| [RFC2026] | ||||
| S. Bradner, "The Internet Standards Process -- Revision 3", RFC | ||||
| 2026, BCP 9, October 1996. | ||||
| [ISIS-TLVS] | ||||
| draft-ietf-isis-wg-tlv-codepoints-01.txt | ||||
| [ISISWG] | ||||
| "IS-IS for IP Internets (isis), IETF WG charter", | ||||
| http://www.ietf.org/html.charters/isis-charter.html | ||||
| [ISO] | ||||
| "ISO Technical Committee details web-page", | ||||
| http://www.iso.org/iso/en/stdsdevelopment/tc/tclist/ TechnicalCom- | ||||
| mitteeDetailPage.TechnicalCommitteeDetail?COMMID=1 | ||||
| [JTC1] | ||||
| "ISO/IEC JTC1 web-page" http://www.jtc1.org | ||||
| [SC6] | ||||
| "ISO/IEC JTC1/SC6 web-page" http://www.jtc1sc06.org | ||||
| [IETF-ML] | ||||
| "IETF Mailing Lists web-page", http://www.ietf.org/maillist.html | ||||
| [ID-GUIDE] | ||||
| "Guidelines to Authors of Internet-Drafts", | ||||
| http://www.ietf.org/ietf/1id-guidelines.txt | ||||
| 5. Signatures | ||||
| Approved, Approved, | Title: Cooperative Agreement Between the ISOC/IETF and | |||
| ISO/IEC Joint Technical Committee 1/Sub | ||||
| Committee 6 (JTC1/SC6) on IS-IS Routing Protocols | ||||
| Author(s): A. Zinin | ||||
| Status: Informational | ||||
| Date: July 2003 | ||||
| Mailbox: zinin@psg.com | ||||
| Pages: 8 | ||||
| Characters: 14974 | ||||
| Updates/Obsoletes/SeeAlso: None | ||||
| for ISO/IEC JTC1/SC6 for the Internet Society | I-D Tag: draft-zinin-ietf-jtc1-aggr-01.txt | |||
| Original signed by Original signed by | URL: ftp://ftp.rfc-editor.org/in-notes/rfc3563.txt | |||
| _____________________ _______________________ | This document contains the text of the agreement signed between | |||
| ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of | ||||
| the IS-IS routing protocol. The agreement includes definitions of the | ||||
| related work scopes for the two organizations, request for creation | ||||
| and maintenance of an IS-IS registry by IANA, as well as | ||||
| collaboration guidelines. | ||||
| XXXX XXXX | This memo provides information for the Internet community. It does | |||
| not specify an Internet standard of any kind. Distribution of this | ||||
| memo is unlimited. | ||||
| Date: _________ Date: ___________ | This announcement is sent to the IETF list and the RFC-DIST list. | |||
| Requests to be added to or deleted from the IETF distribution list | ||||
| should be sent to IETF-REQUEST@IETF.ORG. Requests to be | ||||
| added to or deleted from the RFC-DIST distribution list should | ||||
| be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. | ||||
| 6. Security Considerations | Details on obtaining RFCs via FTP or EMAIL may be obtained by sending | |||
| an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body | ||||
| help: ways_to_get_rfcs. For example: | ||||
| This type of non-protocol document does not directly affect the secu- | To: rfc-info@RFC-EDITOR.ORG | |||
| rity of the Internet. | Subject: getting rfcs | |||
| 7. Author's address | help: ways_to_get_rfcs | |||
| Alex Zinin | Requests for special distribution should be addressed to either the | |||
| Alcatel | author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless | |||
| E-mail: zinin@psg.com | specifically noted otherwise on the RFC itself, all RFCs are for | |||
| unlimited distribution.echo | ||||
| Submissions for Requests for Comments should be sent to | ||||
| RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC | ||||
| Authors, for further information. | ||||
| End of changes. 12 change blocks. | ||||
| 298 lines changed or deleted | 34 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||