M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)
RFC 5120
Document | Type | RFC - Proposed Standard (February 2008; No errata) | |
---|---|---|---|
Authors | Naiming Shen , Nischal Sheth , Tony Przygienda | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5120 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Russ Housley | ||
Send notices to | (None) |
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'sShow full document text