Internet Engineering Task Force Tony Przygienda (Redback)
INTERNET DRAFT Naiming Shen (Redback)
Nischal Sheth (Juniper)
April 2002
M-ISIS: Multi Topology Routing in IS-IS
<draft-ietf-isis-wg-multi-topology-03.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This draft describes an optional implementation technique within
IS-IS used today by many ISPs for routing within their clouds.
IS-IS is an interior gateway routing protocol developed originally
by OSI and used with IP extensions as IGP. This draft describes how
to run within a single ISIS domain a set of independent IP
topologies that we call Multi-Topologies (MTs), or Multiple views
of Topology. This MT extension can be used for variety of purposes
such as an in-band management network ``on top'' of the original
IGP topology, maintain separate IGP routing domains for isolated
multicast or IPv6 islands within the backbone, force a subset of an
address space to follow a different topology, or even maintain a
restricted number of protocol based VPNs.
1. Introduction
Maintaining multiple MTs for ISIS [ISO10589 , RFC1195] in a
backwards-compatible manner necessitates several extensions to the
packet encoding and additional SPF procedures. The problem can
Przygienda, Shen, Sheth Expires October 2002 [Page 1]
Internet Draft M-ISIS April 2002
be partitioned into 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 computations. The following
sections describe each of the problems separately. To simplify the
text, ``normal'' IS-IS topology is defined to be MT ID #0 (zero).
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as
defined in RFC 2119 [RFC2119].
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 which topologies the interface belongs
to. And 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 adjacencies in LSPs
with common MT set over those adjacencies.
As a simplifying side-effect, boundaries between levels will be the
same for all MTs.
In the case of adjacency contains multiple MTs on an interface, and
if there exists overlapping IP address space among the topologies,
additional mechanism MAY be used to resolve the topology identity of
the incoming packets on the interface.
2.1. Forming Adjacencies on Point-to-Point Interfaces
Adjacencies on point-to-point interfaces are formed as usual with
ISIS routers not implementing MT extensions. If local router does
not participate in certain MTs, it will not advertise those MTIDs
in it's IIHs and thus will not include that neighbor within it's
topology based LSPs. On the other hand, if a MTID is not
detected in remote side's IIHs, the local router MUST NOT include
that neighbor within it's MT LSPs. The local router SHOULD NOT form
adjacency if they don't have at least one common MT set over the
interface.
2.2. Forming Adjacencies on Broadcast Interfaces
On a LAN, all the routers on the LAN which implement the MT
extension MAY advertise their MT capability TLV in their IIHs.
A MT capable router MUST include according MT PNode in its LSP
MT IS Reachable TLV if there is at least one adjacency on the LAN
interface which belongs to this MT or it MAY include this MT PNode
in it's LSP if the LAN interface participates in this MT set.
Przygienda, Shen, Sheth Expires October 2002 [Page 2]
Internet Draft M-ISIS April 2002
Two Routers on a LAN SHALL always establish adjacency regardless
whether they have common MT set or not. This is to ensure all
the routers on the LAN can correctly elect the same DIS. The IS
SHOULD NOT include the MT IS TLV in its LSP if none of the
adjacencies on the LAN contains this MT.
The DIS, CSNP and PSNP functions are not changed by MT extension.
3. Advertising MT Reachable Intermediate Systems in LSPs
A router MUST include within its LSPs in the Reachable Intermediate
Systems TLVs only adjacent nodes that are participating in the
according topology and advertise such TLVs only if it participates
itself in the according topology. Standard Reachable Intermediate
Systems TLV is acting here as MT ID #0 equivalent of the newly
introduced MT Reachable Intermediate Systems TLV. A router MAY
announce the adjacency of IS TLVs for a given MT if this interface
participates in the LAN or it MUST announce the IS TLV when there is
at least one adjacency on the interface belongs to this MT.
Since it is not possible to prevent a router that does not understand
MT extensions from being responsible for generation of the according
PNode, it is not possible either to introduce special TLVs in the
PNode LSPs nor run distinct DIS elections per MT. Therefore, a
generated PNode by DIS MUST contain in its IS Reachable TLV all nodes
on the LAN as usual regardless of their MT capabilities. In other
words, there is no change to the pseudo-node LSP construction.
4. MTs and Overload, Partition and Attached Bits
As stated earlier, all MTs share the same set of L1-L2 boundaries and
NETs. However, a router could for each of the MTs become potentially
partitioned, overloaded and attached independently. To prevent
unnecessary complexity, MT extensions does not support partition
repair. Besides that, overload bit is assumed to be shared for all
topologies. MT other than ID #0 MUST use the same overload bit
during the computation. Attached bit is part of the MT TLV being
distributed within a node's LSP fragment 0.
5. Advertising MT Specific IP Prefixes
Each of the MTs commands its own address space so a new TLV is
necessary for prefixes stored in MTs other than MT ID #0. To
make the encoding less confusing when same prefixes are present in
multiple MTs and accelerate SPF per MT, rather than adding a sub-TLV
in TE extensions, a new TLV is introduced for that purpose that
closely follows TE encoding [LS01].
Przygienda, Shen, Sheth Expires October 2002 [Page 3]
Internet Draft M-ISIS April 2002
6. Multi-Topology SPF Computation
Each MT MUST run each own instance of the decision process.
Overload bit and LAN PNode LSPs are shared for all topologies
during computation. Reverse connectivity check within SPF MUST
follow the according MT to assure the bi-directional reachability.
The results of each computation MAY be stored in a separate RIB
if otherwise overlapping addresses in different topologies could
lead to undesirable routing behavior such as forwarding loops. The
forwarding logic and configuration need to ensure the same MT is
traversed from the source to the destination for packets. The
nexthops derived from the MT SPF MUST belong to the adjacencies
conforming to the same MT for correct forwarding.
7. LSP Flooding
The LSP flooding mechanism is not changed by MT extension.
An implementation MAY have the option to use additional MT
information in the LSP and on the adjacency to reduce some of the
unnecessary LSP flooding. If a receiving interface and an outgoing
interface don't share any common MT set, the implementation MAY
have the option not to flood this LSP out on that interface. Since
the fragment zero LSP contains the MTID, the MT capability of any
LSP can be identified. If the LSP and the adjacencies of an outgoing
interface do not share any common MT capability, the implementation
MAY have the option not to flood this LSP out on that interface. An
implementation MAY want to have the operators to control those
optimization base on network topology and environment to ensure
the LSP flooding reliability.
8. Packet Encoding
Three new TLVs are added to support MT extensions. One of them is
common for the LSPs and IIHs. Encoding of Intermediate System TLV
and IPv4 Reachable Prefixes is tied to traffic engineering
extensions to simplify the implementation effort. The main reasons
we choose using new TLVs instead of using sub-TLVs inside existing
TLV type-22 and type-135 are: In many cases, multi-topologies are
non-congruent, using sub-TLV approach will not save LSP space; Many
sub-TLVs are already being used in TLV type-22, and many more are
being proposed while there is a maximum limit on the TLV size,
for this extension, we have a choice not to take away more space
from the existing TLVs; If traffic engineering or some other
applications are being applied per topology level later, the new
TLVs can automatically inherit the same attributes already defined
for the ``normal'' IPv4 topology without going through long standard
process to redefine them per topology.
Przygienda, Shen, Sheth Expires October 2002 [Page 4]
Internet Draft M-ISIS April 2002
8.1. Multi-Topology TLV
TLV number of this TLV is 229. It contains one or more
multi-topology the router is participating in (including MT ID #0)
the following structure
TLV type 229
Length total length of the value field, it should be 2
times the number of topology.
Value 2 bytes of MT ID and control starting from most
significant bits.
1 bit indicating the existence of sub-TLVs for the MT
1 bit presenting the ATTACH bit for the MT
(only valid in LSP fragment #0 and for MTs other
than ID #0, otherwise reserved)
2 reserved bits
12 least significant bits are the MT ID
This MT TLV can advertise up to 127 topologies and it can occur
multiple times if needed within IIHs and LSP fragment 0. Any other
occurrence of this TLV MUST be ignored. Lack of MT TLV in hellos and
fragment 0 LSP MUST be interpreted as participation of the
advertising interface or router in MT ID #0 only. If a router
advertises MT TLV, it has to advertise all the topologies it
participate in, specifically including topology ID #0 also.
8.2. MT Intermediate Systems TLV
TLV number of this TLV is 222. It is aligned with extended IS
reachability TLV type 22 beside an additional two bytes in front at
the beginning of the TLV.
2 bytes of MT membership
4 bits (most significant) are reserved
12 least significant bits are the MT ID
0-251 octets of structures used in TLV type 22.
This TLV can occur multiple times.
8.3. Multi-Topology Reachable IPv4 Prefixes TLV
TLV number of this TLV is 235. It is aligned with extended IS
reachability TLV type 135 beside an additional two bytes in front.
2 bytes of MT membership
4 bits (most significant) are reserved
12 least significant bits are the MT ID
0-251 octets of structures used in TLV type 135.
This TLV can occur multiple times.
Przygienda, Shen, Sheth Expires October 2002 [Page 5]
Internet Draft M-ISIS April 2002
A new sub-TLV for this MT Reachable IPv4 Prefixes TLV is proposed:
Sub-TLV type 117
Length 4 octets
Name MT IPv4 Prefix Color
The value of 1 of this sub-TLV is reserved for MT Management
Prefix color.
If the MT Management Prefix color is present in this TLV, a MT based
SPF computation MAY also need to install this prefix into the
``standard'' or ``management'' RIB. This MAY be necessary for
example in the case of MT based network management.
8.4. Multi-Topology Reachable IPv6 Prefixes TLV
TLV number of this TLV is 237. It is aligned with IPv6 Reachability
TLV type 236 beside an additional two bytes in front.
2 bytes of MT membership
4 bits (most significant) are reserved
12 least significant bits are the MT ID
0-251 octets of structures used in TLV type 236 [H01].
This TLV can occur multiple times.
This TLV is used for general purpose IPv6 topologies. For ``normal''
or ``default'' IPv6 topology, MT ID #2, the router MAY advertise
either the TLV type 236 [H01] or TLV type 237 with MT ID #2 as its
membership, or advertise both of them. The ``default'' IPv6 topology
MUST understand both Reachable IPv6 Prefixes TLVs.
8.5. Reserved MT ID Values
Certain MT topologies are assigned to serve pre-determined purposes:
- MT ID #0: Equivalent to the ``standard'' topology.
- MT ID #1: Reserved for In-Band Management Purposes.
- MT ID #2: Reserved for IPv6 Routing Topology.
- MT ID #3: Reserved for Multicast Routing Topology.
- MT ID #4-#4094: Reserved for IETF consensus.
- MT ID #4095: Reserved for development, experimental and
proprietary features.
9. Acknowledgments
The authors would like to thank Andrew Partan, Dino Farinacci,
Derek Yeung, Alex Zinin, Stefano Previdi, Heidi Ou, Steve Luong,
Przygienda, Shen, Sheth Expires October 2002 [Page 6]
Internet Draft M-ISIS April 2002
and Mike Shand for the discussion, their review, comments and
contributions to this draft.
10. Security Consideration
ISIS security applies to the work presented. No specific security
issues with the proposed solutions are known.
11. References
[ISO10589] ISO. Intermediate System to Intermediate System Routing
Exchange Protocol for Use in Conjunction with the Protocol
for Providing the Connectionless-Mode Network Service.
ISO 10589, 1992.
[RFC1195] R. Callon. Use of OSI ISIS for Routing in TCP/IP and
Dual Environments. RFC 1195, December 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[LS01] T. Li and H. Smit. IS-IS Extensions for Traffic
Engineering. draft-ietf-isis-traffic-04.txt, August 2001
(work in progress)
[H01] C. Hoops. Routing IPv6 with IS-IS.
draft-ietf-isis-ipv6-02.txtwork-in-progress, April 2001
(work in progress)
12. Authors' Addresses
Tony Przygienda
Redback Networks
350 Holger Way
San Jose, CA, 95134 USA
prz@redback.com
Naiming Shen
Redback Networks
350 Holger Way
San Jose, CA, 95134 USA
naiming@redback.com
Nischal Sheth
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
nsheth@juniper.net
Przygienda, Shen, Sheth Expires October 2002 [Page 7]