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)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
|
Reviews |
|
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5120 (Proposed Standard)
|
|
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
Show full document text