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

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01

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