Simplified Extension of Link State PDU (LSP) Space for IS-IS
RFC 5311
Document | Type |
RFC - Proposed Standard
(February 2009; No errata)
Obsoletes RFC 3786
|
|
---|---|---|---|
Authors | Mike Shand , Stefano Previdi , Les Ginsberg , Danny McPherson | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5311 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ross Callon | ||
Send notices to | (None) |
Network Working Group D. McPherson, Ed. Request for Comments: 5311 Arbor Networks Obsoletes: 3786 L. Ginsberg S. Previdi M. Shand Cisco Systems February 2009 Simplified Extension of Link State PDU (LSP) Space for IS-IS 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. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes a simplified method for extending the Link State PDU (LSP) space beyond the 256 LSP limit. This method is intended as a preferred replacement for the method defined in RFC 3786. McPherson, et al. Standards Track [Page 1] RFC 5311 Simplified Extension of LSP Space for IS-IS February 2009 Table of Contents 1. Overview ........................................................2 2. Specification of Requirements ...................................3 3. Definition of Commonly Used Terms ...............................3 4. Utilizing Additional System IDs .................................4 4.1. Additional Information in Extended LSPs ....................4 4.2. Extended LSP Restrictions ..................................4 4.2.1. TLVs That MUST NOT Appear ...........................4 4.2.2. Leaf Advertisements in Extended LSPs ................5 4.2.3. IS Neighbor Advertisement Restrictions ..............5 4.2.4. Area Addresses ......................................6 4.2.5. Overload, Attached, Partition Repair Bits ...........6 4.3. Originating LSP Requirements ...............................6 4.4. IS Alias ID TLV (IS Alias ID) ..............................7 4.5. New TLVs in Support of IS Neighbor Attributes ..............7 5. Comparison with the RFC 3786 Solution ...........................8 6. Deployment Considerations .......................................8 6.1. Advertising New TLVs in Extended LSPs ......................9 6.2. Reachability and Non-SPF TLV Staleness .....................9 6.3. Normal LSP OL State and Use of Extended LSPs ...............9 6.4. Moving Neighbor Attribute INFO LSPs ........................9 6.5. Advertising Leaf INFO Extended LSPs .......................10 7. Security Considerations ........................................10 8. IANA Considerations ............................................10 9. References .....................................................11 9.1. Normative References ......................................11 9.2. Informative References ....................................11 1. Overview [IS-IS] defines the set of LSPs that may be originated by a system at each level. This set is limited to 256 LSPs. [IS-IS] also defines a maximum value for an LSP (originatingLxLSPBufferSize) as 1492 bytes. The carrying capacity of an LSP set, while bounded, has thus far been sufficient for advertisements associated with an area/domain in existing deployment scenarios. However, the definition of additional information to be included in LSPs (e.g., multi-topology support, traffic engineering information, router capabilities, etc.) has the potential to exceed the carrying capacity of an LSP set. This issue first drew interest when traffic engineering extensions were introduced. This interest resulted in the solution defined in [RFC3786]. However, that solution suffers from restrictions required to maintain interoperability with systems that do not support the extensions. McPherson, et al. Standards Track [Page 2] RFC 5311 Simplified Extension of LSP Space for IS-IS February 2009 This document defines extensions that allow a system to exceed the 256 LSP limit and do so in a way that has no interoperability issues with systems that do not support the extension. It is seen as aShow full document text