summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3563.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3563.txt')
-rw-r--r--doc/rfc/rfc3563.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc3563.txt b/doc/rfc/rfc3563.txt
new file mode 100644
index 0000000..aa396bc
--- /dev/null
+++ b/doc/rfc/rfc3563.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group A. Zinin
+Request for Comments: 3563 Alcatel
+Category: Informational July 2003
+
+
+ Cooperative Agreement Between the ISOC/IETF and ISO/IEC
+ Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on
+ IS-IS Routing Protocol Development
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ 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.
+
+Document Header
+
+ Annexe 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: 2003-01-28
+
+ This annexe 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.
+
+
+
+
+Zinin Informational [Page 1]
+
+RFC 3563 IETF - JTC1 Agreement on IS-IS July 2003
+
+
+ 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 organizations.
+
+2. Definitions
+
+2.1 Core IS-IS Mechanisms
+
+ Core IS-IS 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 TLVs defined in [10589]
+
+ 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) Topology abstraction defined in [10589]
+
+2.2 Internet-specific IS-IS Extensions:
+
+ Internet-specific IS-IS Extensions are extensions to the IS-IS
+ protocol that are within the work scope of the IETF including any
+ routing or packet forwarding technology that the IETF decides to work
+ on in the future (such as IPv4 or IPv6 unicast and multicast routing,
+ MPLS, MPLS Traffic Engineering, or Generalized MPLS), 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
+
+
+
+
+Zinin Informational [Page 2]
+
+RFC 3563 IETF - JTC1 Agreement on IS-IS July 2003
+
+
+ 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 the introduction of new TLVs or sub-TLVs that do not modify
+ the algorithms of the Core Mechanisms in a way that would affect
+ interoperability with non-IP or dual implementations of IS-IS is not
+ considered to be a modification to the Core IS-IS Mechanisms.
+
+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
+ standardization, 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.
+
+
+
+
+
+
+
+
+Zinin Informational [Page 3]
+
+RFC 3563 IETF - JTC1 Agreement on IS-IS July 2003
+
+
+ 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
+ documents will not be published as standards-track IETF RFCs).
+
+ In the situations where it is not clear from the provisions of this
+ document whether a specific protocol extension should be standardized
+ within the IETF or within JTC1, the decisions will be made on a case-
+ by-case basis and will be based on the agreement between the two
+ organizations reached via a discussion between the IETF Routing Area
+ Directors or the IETF liaison to JTC1/SC6 (who will reflect the IETF
+ consensus on the matter), and the JTC1/SC6 secretariat.
+
+3.2 Requirements for IS-IS-specific IETF documents
+
+ All IS-IS-related IETF 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.3 IS-IS Registries (IANA Considerations)
+
+3.3.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 has created and currently maintains a registry for IS-IS TLV
+ codepoints. The range of values is 0-255. Initial state of the
+ registry should be synchronized with [RFC3359]. 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
+ arising within JTC1 constituencies to the IANA registry process.
+
+3.3.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.
+
+
+
+
+
+
+Zinin Informational [Page 4]
+
+RFC 3563 IETF - JTC1 Agreement on IS-IS July 2003
+
+
+3.4 Collaboration Guidelines
+
+3.4.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.4.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 email message to the secretariat of ISO JTC 1 specifying the
+ number of the Informational RFC containing the specification (the
+ document 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.4.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
+ Editor to publish the document as an Informational RFC. See sections
+ 4.2.2 and 7 of [RFC2026] for more information. Guidelines for
+ Internet Draft preparation are given in [ID-GUIDE].
+
+3.4.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
+
+
+
+Zinin Informational [Page 5]
+
+RFC 3563 IETF - JTC1 Agreement on IS-IS July 2003
+
+
+ email to the working group mailing list), the ISIS WG chairs (see
+ [ISISWG] for more information), 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
+ message to the IETF ISIS WG mailing list requesting the comments.
+
+ The IETF MAY request JTC1 to circulate provided comments among the
+ National Bodies and Liaison Organizations involved in the discussion
+ of the work under review.
+
+4. References
+
+ [10589] ISO, "Intermediate system to Intermediate system routing
+ information exchange protocol for use in conjunction with
+ the Protocol for providing the Connectionless-mode
+ Network Service (ISO 8473)", ISO/IEC 10589:1992.
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+ [RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV)
+ Codepoints in Intermediate System to Intermediate
+ System", RFC 3359, August 2002.
+
+ [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/
+ TechnicalCommitteeDetailPage.
+ 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
+
+
+
+
+
+
+
+Zinin Informational [Page 6]
+
+RFC 3563 IETF - JTC1 Agreement on IS-IS July 2003
+
+
+5. Signatures
+
+ Approved, Approved,
+
+ for ISO/IEC JTC1/SC6 for the Internet Society
+
+ Original signed by Original signed by
+
+ Jack Houldsworth Harald Alvestrand
+
+ Date: March 3, 2003 Date: March 19, 2003
+
+6. Security Considerations
+
+ This type of non-protocol document does not directly affect the
+ security of the Internet.
+
+7. Author's Address
+
+ Alex Zinin
+ Alcatel
+
+ EMail: zinin@psg.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zinin Informational [Page 7]
+
+RFC 3563 IETF - JTC1 Agreement on IS-IS July 2003
+
+
+8. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zinin Informational [Page 8]
+