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.
AbstractThis 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. 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).
RFC2119]. Section 8.2.2 of this document.
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. RFC3784].
conforming to the same MT for correct forwarding. It is recommended for the administrators to ensure consistent configuration of all routers in the domain to prevent undesirable forwarding behavior. No attempt is made in this document to allow one topology to calculate routes using the routing information from another topology inside SPF. Even though it is possible to redistribute and leak routes from another IS-IS topology or from external sources, the exact mechanism is beyond the scope of this document. RFC3784] to simplify the implementation effort. The main reasons we chose to use new TLVs instead of using sub-TLVs inside existing TLV type-22 and type-135 are: 1. In many cases, multi-topologies are non-congruent, using the sub-TLV approach will not save LSP space; 2. 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, from the existing TLVs; 3. 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 "standard" topology without going through long standard process to redefine them per topology.
Bit O represents the OVERLOAD bit for the MT (only valid in LSP fragment zero for MTs other than ID #0, otherwise SHOULD be set to 0 on transmission and ignored on receipt). Bit A represents the ATTACH bit for the MT (only valid in LSP fragment zero for MTs other than ID #0, otherwise SHOULD be set to 0 on transmission and ignored on receipt). Bits R are reserved, SHOULD be set to 0 on transmission and ignored on receipt. MT ID is a 12-bit field containing the ID of the topology being announced. This MT TLV can advertise up to 127 MTs. It is announced in IIHs and LSP fragment 0, and can occur multiple times. The resulting MT set SHOULD be the union of all the MT TLV occurrences in the packet. Any other IS-IS PDU occurrence of this TLV MUST be ignored. Lack of MT TLV in hellos and fragment zero LSPs 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 MTs it participates in, specifically including topology ID #0 also.
MT ID is a 12-bit field containing the non-zero MT ID of the topology being announced. The TLV MUST be ignored if the ID is zero. This is to ensure the consistent view of the standard unicast topology. After the 2-byte MT membership format, the MT IS content is in the same format as extended IS TLV, type 22 [RFC3784]. It can contain up to 23 neighbors of the same MT if no sub-TLVs are used. This TLV can occur multiple times. RFC3784]. This TLV can occur multiple times.
RFC3567], SHOULD be applied if there is high risk resulting from modification of multi-topology information. As described in Section 8.2.2, multiple topologies share an interface in the same address space, some mechanism beyond IS-IS needs to be used to select the right forwarding table for an inbound packet. A misconfiguration on the system or a packet with a spoofed source address, for example, can lead to packet loss or unauthorized use of premium network resource.
IANA has created a new registry, "IS-IS Multi-Topology Parameters", with the assignments listed in Section 7.5 of this document and registration policies [RFC2434] for future assignments. The MT ID values range 6-3995 are allocated through Expert Review; values in the range of 3996-4095 are reserved for Private Use. In all cases, assigned values are to be registered with IANA. [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] Callon, R., "Use of OSI IS-IS 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. [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3567] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003. [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004. [H01] C. Hopps, "Routing IPv6 with IS-IS", Work in Progress.
Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com.