Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development
RFC 3563
Document | Type |
RFC - Informational
(July 2003; No errata)
Updated by RFC 6233
Was draft-zinin-ietf-jtc1-aggr (individual in rtg area)
|
|
---|---|---|---|
Author | Alex Zinin | ||
Last updated | 2018-08-07 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3563 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Alex Zinin | ||
Send notices to | (None) |
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 toShow full document text