Network Working Group Amir Hermelin Internet Draft Charlotte's Web Networks, Inc. Expiration Date: November 2001 Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit draft-hermelin-ext-lsp-frags-01.txt Status 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 document describes a mechanism that allows a system to originate more than 256 LSP fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. The document describes behaviors that are backwards compatible with ISIS implementations that do not support this feature. These behaviors are specified in a way that allows previous implementations to correctly process the extended fragment information. A. Hermelin Expires November 2001 [Page 1] Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 1. Introduction In the IS-IS protocol, a system floods its link-state information in Link State Protocol Data Units, or LSPs for short. These logical LSPs can become quite large, therefore the protocol specifies a means of fragmenting this information into multiple LSP fragments. The number of fragments a system can generate is limited by ISO 10589 [1] to 256 fragments, where each fragment's size is also limited. Hence, there is a limit on the amount of link-state information a system can generate. A number of factors can contribute to exceeding this limit: - Introduction of new TLVs and sub-TLVs to be included in LSPs. - The use of LSPs to propagate various types of information (such as traffic-engineering information). - The growing size of route tables and AS topologies. This document describes a mechanism to relax the limit on the number of LSP fragments, while providing behavior that would allow previous implementations to correctly process fragments exceeding this limit. 1.1 Definitions of Commonly Used Terms This section provides definitions for terms that are used throughout the text. Originating System A router running the IS-IS protocol. Original system-id The system-id of an originating system. Extended system-id An additional system-id that is assigned by the network administrator. Each extended system-id allows generation of 256 additional, or extended, LSP fragments. The extended system-id, like the original system-id, must be unique throughout the routing domain. Virtual System The system, identified by an extended system-id, advertised as originating the extended LSP fragments. These fragments specify the extended system-id in their LSP IDs. Original LSP An LSP using the original system-id in its LSP ID. A. Hermelin Expires November 2001 [Page 2] Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 Extended LSP An LSP using an extended system-id in its LSP ID. LSP set A group of LSP fragments constituting a logical LSP. These share a specific system-id and pseudonode number, and differ only in their LSP (or fragment) Number. Extended LSP set A group of LSP fragments using an extended system-id, and originated by the originating system. These fragments appear to other routers as having been originated by the virtual system identified by an extended system-id. 1.2 Overview Using additional system-ids assigned to the originating system, that system can advertise the excess link-state information in extended LSPs under these extended system-ids. It would do so as if other routers, or "virtual systems", were advertising this information. These extended LSPs will also have the specified limit on their LSP fragments; however, the originating system may generate extended LSPs under numerous virtual systems. The originating system will not advertise its extended system-ids to any of its neighbors; it will always use its original system-id in IS Hellos [3] and IS-IS Hellos. As a result, no adjacencies will be formed with other systems using extended system-ids, and the originating system would be the only one advertising adjacencies to its extended system-ids, as described below. The originating system must include connectivity information in its original LSPs (the LSPs with the original system-id in their LSP ID) to all virtual systems for which extended LSPs are generated by it. This is to ensure other routers correctly process the extra information in their SPF calculation. The metric for these connections should be zero, since the cost of reaching a virtual system is the same as the cost of reaching its originating system. To other routers, virtual systems would appear reachable only through their originating system, hence loss of connectivity to the originating system means loss of connectivity to all of its information, including that advertised in its extended LSPs. Furthermore, the cost of reaching information advertised in non- extended LSPs is the same as the cost of reaching information advertised in the new extended LSPs, with an additional hop. A. Hermelin Expires November 2001 [Page 3] Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 +---------------------------------------------+ | Originating System | | system-id = S | | ( extended system-ids = S', S'' ) | +---------------------------------------------+ | /\ | /\ cost=0 | |cost=max cost=0 | |cost=max | | | | \/ | \/ | +------------------+ +------------------+ | Virtual System | | Virtual System | | system-id = S' | | system-id = S'' | +------------------+ +------------------+ Figure 1. Advertising connections to virtual systems The generation of extended LSPs is discussed in section 2. Not all link-state information that can be advertised in the original LSPs can be advertised in extended LSPs; this is discussed in further detail in section 3. However, most "leaf" information, i.e. information that serves only as leaves in a shortest path tree, can be advertised in extended LSPs. Other routers exhibit the same behavior for this information as for information advertised in the original LSPs, with a few minor exceptions noted in section 5. Extended LSPs can be purged, in the same manner as original LSPs. This is discussed in section 4. 2. Generating Extended LSP Fragments When new extended LSP fragments are generated, these fragments should be generated as specified in ISO 10589 [1]. Furthermore, a system will treat its extended LSPs the same as it treats its original LSPs, with the exceptions noted in section 3. Specifically, creating, flooding, renewing, purging and all other operations are similar for both original and extended LSPs, unless stated otherwise. The extended LSPs will use one of the extended system-ids configured for the router, in their LSP ID. An extended LSP Number zero should be generated for every extended LSP set, to allow a router's SPF calculation to consider those fragments in that set. Additionally, when an extended LSP belonging to extended system-id S' is first created, the original LSP must specify S' as a neighbor, with metric set to zero. This is to ensure other routers will consider the extended LSP in their SPF A. Hermelin Expires November 2001 [Page 4] Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 calculations, as well as consider the cost of reaching the virtual system S' the same as the cost of reaching its originating system. Furthermore, the extended LSP must specify the original system-id as a neighbor, with metric set to MaxLinkMetric. Where relevant, this adjacency should be considered as point-to-point. Note, that the restriction specified in ISO 10589 section 7.2.5 holds: if an LSP Number zero of the originating system is not present, none of that system's neighbor entries would be processed during SPF, hence none of its extended LSPs would be processed as well. Extended LSPs with number zero will be regarded in the same special manner as specified in 10589 for LSPs with number zero, and will include the same type of extra information as specified in 10589 and RFC 1195 [2]. So, for example, when a system reissues its LSP Number zero due to an area address change, it should reissue all extended LSPs with number zero as well. 3. Exceptions when Encoding Extended LSP Fragments 3.1 The LSP Header The LSP header of an extended LSP fragment should include the same settings as for non-extended LSP fragments with the exceptions noted below: 3.1.1 The Pseudonode ID The Pseudonode ID, which is part of the LSP ID, should be set to zero on all extended LSP fragments. 3.1.2 The Attached Bits The Attached (ATT) bits should be set to zero for all four metric types, on all extended LSPs. This is for two main reasons: - If a virtual system is reachable, so is its originating system. It is preferable, then, that an L1 IS chooses the originating system and not the virtual system as its nearest L2 exit point, as connectivity to the virtual system has a higher probability of being lost (a result of the extended LSP no longer being advertised). This could cause unnecessary processing on some implementations. - Some implementations which support weighted multipath, might set A. Hermelin Expires November 2001 [Page 5] Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 multipath weights according to the number of ISs that can be reached via each path. So, for example, if there are two nearest L2 ISs to a particular L1-only system, each reachable via different interfaces, and one is generating an extended LSP, then the L1 system might forward more traffic towards that destination (i.e. give it a stronger weight), as it would think it is forwarding traffic towards two L2 ISs. 3.1.3 The Partition Repair Bit The Partition Repair (P) bit should be set to zero on all extended LSPs. This is for the same reasons as for the Attached bits. 3.2 TLVs Extended LSPs can contain any TLVs that original LSPs can contain, with the exceptions noted below. 3.2.1 IS Neighbors TLV An Extended LSP must specify only the originating system as a neighbor, with the metric set to MaxLinkMetric. No other neighbors may be specified in an Extended LSP, as this would not satisfy the bi-directionality check in the SPF calculation. Where relevant, this adjacency should be considered as point-to-point. 3.2.2 ES Neighbors TLV ISO 10589 [1] section 7.3.7 specifies inserting an ES Neighbor TLV in L1 LSPs, with the system ID of the router. RFC 1195 [2] relieves IP- only routers of this requirement. However, for routers that do insert this ESN TLV in L1 LSPs (whether IP-only or OSI-capable), then in an extended LSP, the relevant extended system-id should be used. Furthermore, OSI-capable routers should accept packets destined for this extended system-id. 4. Purging Extended LSP Fragments ISO 10589 [1] section 7.3.4.4 note 21 suggests that an implementation keeps the number of LSP fragments within a certain limit based on the optimal (minimal) number of fragments needed. Section 7.3.4.6 also recommends that an IS purge its empty LSPs to conserve resources. A. Hermelin Expires November 2001 [Page 6] Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 These recommendations hold for the extended LSP fragments as well. However, an extended LSP Number zero should not be purged until all of the fragments in its set (i.e. belonging to a particular virtual system-id), are empty as well. This is to ensure implementations consider the fragments in their SPF calculations, as specified in section 7.2.5. When all the extended LSP fragments of a particular extended system- id S' have been purged, the originating system should remove the adjacency information to S' from its original LSPs. 5. Compatibility Issues Previous implementations will interpret TLVs in extended LSPs in the same manner that they interpret TLVs in original LSPs, due to the zero metric adjacencies from the originating system to its virtual systems. However, applications that take hop count into consideration, will misinterpret the destinations appearing in extended LSPs as being one hop further than they really are. This is due to the extra neighbor hop needed to reach these LSPs. There are two solutions to this problem: - Add extra information to specify that an adjacency should not be considered for any purpose of hop counting. - Restrict information that might be subject to hop counting, such as traffic engineering information, to appear only in the original LSPs. These restrictions should be applied with care, as too many of them could re-introduce the problem of limited LSP fragments. 6. Security Considerations This document raises no new security issues for IS-IS. 7. Acknowledgments The author would like to thank Tony Li, Radia Perlman, and Mike Shand for helpful ideas and suggestions on the subject. 8. References [1] ISO 10589, "Intermediate System to Intermediate System Intra- Domain Routeing Exchange Protocol for use in Conjunction with the A. Hermelin Expires November 2001 [Page 7] Internet Draft draft-hermelin-ext-lsp-frags-01.txt May 2001 Protocol for Providing the Connectionless-mode Network Service (ISO 8473)" [2] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", R.W. Callon, Dec. 1990 [3] ISO 9542, "End System to Intermediate System Routeing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service (ISO 8473)", March 1988 9. Author's Address Amir Hermelin Charlotte's Web Networks, Inc. 2 Hamada St. Yokneam Moshava, 26000 ISRAEL Email: amir@cwnt.com Phone: +972 4 9592203 Fax: +972 4 9593325 A. Hermelin Expires November 2001 [Page 8]