M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)
RFC 5120

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

• Versions
• 12

Network Working Group                                      T. Przygienda
Request for Comments: 5120                                       Z2 Sagl
Category: Standards Track                                        N. Shen
                                                           Cisco Systems
                                                                N. Sheth
                                                        Juniper Networks
                                                           February 2008

                M-ISIS: Multi Topology (MT) Routing in
          Intermediate System to Intermediate Systems (IS-ISs)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document describes an optional mechanism within Intermediate
   System to Intermediate Systems (IS-ISs) used today by many ISPs for
   IGP routing within their clouds.  This document describes how to run,
   within a single IS-IS domain, a set of independent IP topologies that
   we call Multi-Topologies (MTs).  This MT extension can be used for a
   variety of purposes, such as an in-band management network "on top"
   of the original IGP topology, maintaining separate IGP routing
   domains for isolated multicast or IPv6 islands within the backbone,
   or forcing a subset of an address space to follow a different
   topology.

1.  Introduction

   Maintaining multiple MTs for IS-IS [ISO10589] [RFC1195] in a
   backwards-compatible manner necessitates several extensions to the
   packet encoding and additional Shortest Path First (SPF) procedures.
   The problem can be partitioned into the forming of adjacencies and
   advertising of prefixes and reachable intermediate systems within
   each topology.  Having put all the necessary additional information
   in place, it must be properly used by MT capable SPF computation.
   The following sections describe each of the problems separately.  To
   simplify the text, "standard" IS-IS topology is defined to be MT ID
   #0 (zero).

Przygienda, et al.          Standards Track                     [Page 1]
RFC 5120                         M-ISIS                    February 2008

1.1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.2.  Definitions of Terms Used in This Document

   CSNP Complete Sequence Number Packet.  Used to describe all the
        contents of a link state database of IS-IS.

   DIS  Designated Intermediate System.  The intermediate system elected
        to advertise the pseudo-node for a broadcast network.

   IIH  IS-IS Hello.  Packets that are used to discover adjacent
        intermediate systems.

   LSP  Link State Packet.  Packet generated by an intermediate system
        and lists adjacent systems, prefixes, and other information.

   PSNP Partial Sequence Number Packet.  Used to request information
        from an adjacent intermediate system's link state database.

   SPF  Shortest Path First.  An algorithm that takes a database of
        nodes within a domain and builds a tree of connectivity along
        the shortest paths through the entire network.

2.  Maintaining MT Adjacencies

   Each adjacency formed MUST be classified as belonging to a set of MTs
   on the interface.  This is achieved by adding a new TLV into IIH
   packets that advertises to which topologies the interface belongs.
   If MT #0 is the only MT on the interface, it is optional to advertise
   it in the new TLV.  Thus, not including such a TLV in the IIH implies
   MT ID #0 capability only.  Through this exchange of MT capabilities,
   a router is able to advertise the IS TLVs in LSPs with common MT set
   over those adjacencies.

   The case of adjacency contains multiple MTs on an interface, and if
   there exists an overlapping IP address space among the topologies,
   additional mechanisms MUST be used to resolve the topology identity
   of the incoming IP packets on the interface.  See further discussion
   in Section 8.2.2 of this document.

Przygienda, et al.          Standards Track                     [Page 2]
RFC 5120                         M-ISIS                    February 2008

2.1.  Forming Adjacencies on Point-to-Point Interfaces

   Adjacencies on point-to-point interfaces are formed as usual with
   IS-IS routers not implementing MT extensions.  If a local router does
   not participate in certain MTs, it will not advertise those MT IDs in
   its IIHs and thus will not include that neighbor within its LSPs.  On
   the other hand, if an MT ID is not detected in the remote side's