Internet Engineering Task Force T. Przygienda, N. Shen, N. Sheth INTERNET DRAFT Redback, Redback, Juniper February 2001 M-ISIS: Multi Topology Routing in IS-IS 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 [ISO90 , Cal90a , Cal90b] 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, transport multiple overlapping IP address spaces in the same protocol, force a subset of an address space to follow a different topology, or finally, even maintain a restricted number of protocol based VPNs. 1. Introduction Maintaining multiple MTs for ISIS in a backwards-compatible manner necessitates several extensions to the packet encoding and additional SPF procedures. The problem can be partitioned into Przygienda, Shen, Sheth Expires August 2001 [Page 1] Internet Draft M-ISIS February 2001 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, ``usual'' IS-IS topology is defined to be MT ID #0 (zero). 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 MAY 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. The DIS, CSNP and PSNP functions are not changed by MT extension. Przygienda, Shen, Sheth Expires August 2001 [Page 2] Internet Draft M-ISIS February 2001 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 [LS99]. 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 Przygienda, Shen, Sheth Expires August 2001 [Page 3] Internet Draft M-ISIS February 2001 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 LSP MAY not need to be flooded 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 LSP MAY not need to be flooded out on that interface. An implementation MAY want to have the operators to control those optimization base on network 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'' topology without going through long standard process to redefine them per topology. 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 x code - 229 x length - total length of the value field, it should be 2 times the number of topology. Przygienda, Shen, Sheth Expires August 2001 [Page 4] Internet Draft M-ISIS February 2001 x value - 2 bytes of MT ID and control starting from most significant bits. 1 bit indicating the existence of sub-TLVs 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. 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. Przygienda, Shen, Sheth Expires August 2001 [Page 5] Internet Draft M-ISIS February 2001 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. 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-#8190: Reserved for IETF consensus. - MT ID #8191: 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 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 [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. INTERNET-RFC, Internet Engineering Task Force, February 1990. [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual Environments. INTERNET-RFC, Internet Engineering Task Force, December 1990. [ISO90] ISO. Information Technology - Telecommunications and Information Exchange between Systems - Intermediate System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service. ISO, 1990. [LS99] T. Li and H. Smit. IS-IS Extensions for Traffic Engineering. work-in-progress, Internet Engineering Task Force, 1999. Przygienda, Shen, Sheth Expires August 2001 [Page 6] Internet Draft M-ISIS February 2001 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 August 2001 [Page 7]