From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5311.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc5311.txt (limited to 'doc/rfc/rfc5311.txt') diff --git a/doc/rfc/rfc5311.txt b/doc/rfc/rfc5311.txt new file mode 100644 index 0000000..58a7d8f --- /dev/null +++ b/doc/rfc/rfc5311.txt @@ -0,0 +1,675 @@ + + + + + + +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 a + simpler, and therefore preferred, solution to the problem. + +2. Specification of Requirements + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [BCP14]. + +3. Definition of Commonly Used Terms + + This section provides definitions for terms that are used throughout + the text. The terminology is consistent with that used in RFC 3786. + + Originating System: A physical IS running the IS-IS protocol. As + this document describes a method that allows a single physical IS to + originate LSPs on behalf of multiple virtual ISs, the Originating + System represents the single physical IS. + + Normal system-id: The system-id of an Originating System as defined + by [IS-IS]. + + Additional system-id: A system-id other than the "Normal system-id" + that is assigned by the network administrator to an Originating + System in order to allow the generation of Extended LSPs. The + Additional system-id, like the Normal system-id, must be unique + throughout the routing area (Level-1) or domain (Level-2). + + Original LSP: An LSP using the Normal system-id in its LSP ID. + + Extended LSP: An LSP using an Additional system-id in its LSP ID. + + LSP set: All LSPs of a given level having the same system ID and + Pseudonode ID. (The LSPID field then only varies in the LSP number + octet.) This constitutes the complete set of link state information + at a given level originated using that system ID/Pseudonode ID. This + term is defined to resolve the ambiguity between a logical LSP and a + single Link State PDU -- which is sometimes called an LSP fragment. + The latter is the unit of information handled by the update process. + + Extended LSP set: An LSP set consisting of LSPs using an Additional + system-id. + + Extension-capable IS: An IS implementing the mechanisms described in + this document. + + + + +McPherson, et al. Standards Track [Page 3] + +RFC 5311 Simplified Extension of LSP Space for IS-IS February 2009 + + + Virtual IS: The system, identified by an Additional system-id, + advertised as originating the Extended LSPs. These LSPs specify the + Additional system-id in their LSP IDs. + +4. Utilizing Additional System IDs + + This extension allows an Originating System to be assigned additional + system-ids that may be used to generate additional LSP sets. The + additional system-ids are subject to the same restrictions as normal + system-ids, i.e., when used at Level-1, the additional system-id MUST + be unique within the Level-1 area. When used at Level-2, the + additional system-id MUST be unique within the domain. + + Extended LSPs are treated by the IS-IS Update Process in the same + manner as normal LSPs, i.e., the same rules as to generation, + flooding, purging, etc. apply. In particular, if the Extended LSP + with LSP number zero and remaining lifetime > 0 is not present for a + particular additional system-id, then none of the Extended LSPs in + that Extended LSP set shall be processed. + +4.1. Additional Information in Extended LSPs + + The LSP number zero of an Extended LSP set MUST include the new IS + alias ID TLV defined in Section 4.4. This allows the Extended LSP + set to be associated with the Originating System that generated the + LSP(s). + +4.2. Extended LSP Restrictions + + The following restrictions on the information that may appear in an + Extended LSP are defined in order to avoid interoperability issues + with systems that do not support the extensions defined in this + document. All TLV references are based on the current definitions in + the IANA IS-IS TLV Codepoints Registry. + +4.2.1. TLVs That MUST NOT Appear + + The following TLVs MUST NOT appear in an Extended LSP: + + TLV Name (#) + ----------- + ES Neighbors (3) + Part. DIS (4) + Prefix Neighbors (5) + + + + + + + +McPherson, et al. Standards Track [Page 4] + +RFC 5311 Simplified Extension of LSP Space for IS-IS February 2009 + + + If any of the TLVs listed above appear in an Extended LSP, an + Extension Capable IS MUST ignore those TLVs on receipt and SHOULD + report an error. Other TLVs in that Extended LSP set MUST be + processed normally. + +4.2.2. Leaf Advertisements in Extended LSPs + + Advertisement of leaf information in Extended LSPs is allowed. + Inclusion of such information requires the advertisement of a + neighbor between the Originating System and the Virtual IS associated + with the Extended LSP set in which the leaf advertisements appear. + See Section 4.2.3. + + When leaf advertisements for multiple topologies (see [RFC5120]) are + included in an Extended LSP set, the multi-topology TLV (229) MUST + include all topologies for which a leaf advertisement is included. + + The following TLVs fall into this category: + + TLV Name (#) + ----------- + IP Int. Reach (128) + IP Ext. Address (130) + The extended IP reachability TLV (135) + MT IP Reach (235) + IPv6 IP Reach (236) + MT IPv6 IP Reach (237) + +4.2.3. IS Neighbor Advertisement Restrictions + + Advertisement of IS Neighbor Reachability in an Extended LSP is + restricted to advertisement of neighbor reachability to the + Originating System. A neighbor to the Originating System MUST be + advertised in Extended LSPs. If multi-topology capability [RFC5120] + is supported, an MT IS Neighbor advertisement to the Originating + System IS MUST be included for every topology advertised in the + Extended LSP set. Neighbor advertisement(s) to the Originating + System in an Extended LSP MUST use a non-zero metric and SHOULD use a + metric of MaxLinkMetric-1. + + The restrictions defined here apply to all TLVs used to advertise + neighbor reachability. These include the following TLVs: + + TLV Name (#) + ----------- + IIS Neighbors (2) + The extended IS reachability TLV (22) + MT-ISN (222) + + + +McPherson, et al. Standards Track [Page 5] + +RFC 5311 Simplified Extension of LSP Space for IS-IS February 2009 + + +4.2.4. Area Addresses + + LSP number zero of an Extended LSP set MUST include an Area Address + TLV. The set of area addresses advertised MUST be a subset of the + set of Area Addresses advertised in the normal LSP number zero at the + corresponding level. Preferably, the advertisement SHOULD be + syntactically identical to that included in the normal LSP number + zero at the corresponding level. + +4.2.5. Overload, Attached, Partition Repair Bits + + The Overload (OL), Attached (ATT), and Partition Repair (P) bits MUST + be set to 0 in all Extended LSPs. + + Note that ISs NOT supporting these extensions will interpret these + bits normally in Extended LSPs they receive. If the ATT bit were set + in an Extended LSP, this could indicate that the Virtual IS is + attached to other areas when the Originating System is not. This + might cause legacy systems to use the Virtual IS as a default exit + point from the area. + +4.3. Originating LSP Requirements + + The Original LSP set MUST include a neighbor to the Virtual IS + associated with each Extended LSP set generated. If multi-topology + capability [RFC5120] is supported, an MT IS Neighbor advertisement to + the Virtual IS MUST be included for every topology advertised in the + Extended LSP set. The neighbor advertisement(s) in the Original LSP + MUST specify a metric of zero. This guarantees that the two-way + connectivity check between Originating System and Virtual IS will + succeed and that the cost of reaching the Virtual IS is the same as + the cost to reach the Originating System. + + + + + + + + + + + + + + + + + + + +McPherson, et al. Standards Track [Page 6] + +RFC 5311 Simplified Extension of LSP Space for IS-IS February 2009 + + +4.4. IS Alias ID TLV (IS Alias ID) + + The IS-Alias TLV allows extension-capable ISs to recognize the + Originating System of an Extended LSP set. It identifies the Normal + system-id of the Originating System. + + Type 24 + Length # of octets in the value field (7 to 255) + Value + + No. of octets + +-----------------------+ + | Normal System-id | 6 + +-----------------------+ + | Sub-TLV length | 1 + +-----------------------+ + | Sub-TLVs (optional) | 0 to 248 + +-----------------------+ + + Normal system-id + + The Normal system-id of the Originating System. + + Sub-TLVs length + + Total length of all sub-TLVs. + + Sub-TLVs + + No sub-TLVs are defined in this document. Should future + extensions define sub-TLVs, the sub-TLVs MUST be formatted as + described in [RFC5305]. + +4.5. New TLVs in Support of IS Neighbor Attributes + + One of the major sources of additional information in LSPs is the + sub-TLV information associated with the extended IS reachability TLV + (22) and MT-ISN TLV (222). This includes (but is not limited to) + information required in support of Traffic Engineering (TE) as + defined in [RFC5305] and [RFC5307]. The restrictions defined in this + document prohibit the presence of TLV 22 and/or TLV 222 in Extended + LSPs except to advertise the neighbor relationship to the Originating + System. In the event that there is a need to advertise in Extended + LSPs such information associated with neighbors of the Originating + System, it is necessary to define new TLVs to carry the sub-TLV + information. + + + + + +McPherson, et al. Standards Track [Page 7] + +RFC 5311 Simplified Extension of LSP Space for IS-IS February 2009 + + + Two new TLVs are therefore defined. + + 1) IS Neighbor Attribute TLV (23). It is identical in format to the + extended IS reachability TLV (22). + + 2) MT IS Neighbor Attribute TLV (223). It is identical in format to + the MT-ISN TLV (222). + + These new TLVs MAY be included in Original LSPs or Extended LSPs. + Regardless of the type of LSP in which the TLVs appear, the + information pertains to the neighbor relationship between the + Originating System and the IS identified in the TLV. + + These TLVs MUST NOT be used to infer that a neighbor relationship + exists in the absence of TLV 22 or TLV 222 (whichever applies) in the + Originating LSP set for the specified neighbor. This restriction is + necessary in order to maintain compatibility with systems that do not + support these extensions. + +5. Comparison with the RFC 3786 Solution + + This document utilizes the same basic mechanism (additional system- + ids) as RFC 3786 to allow an originating system to generate more than + 256 LSPs. It differs from RFC 3786 in that it restricts the content + of Extended LSPs to information that does NOT impact the building of + a Shortest Path Tree (SPT). + + Legacy IS-IS implementations which do not support the extensions + defined in this document see the Extended LSPs as information + associated with a system that is reachable only via the Originating + System. As no other systems are reachable via the Virtual ISs, the + Shortest Path First (SPF) calculation in legacy ISs is therefore + consistent with that performed by extension-capable ISs. There is + therefore no need for the two different operating modes defined in + RFC 3786. + + There is also no need for the special handling of the original LSP + set and the Extended LSP set(s) as a single Logical LSP during the + SPF as specified in Section 5 of RFC 3786. + +6. Deployment Considerations + + There are a number of deployment considerations that limit the + usefulness of Extended LSPs unless all systems are extension-capable + ISs. + + + + + + +McPherson, et al. Standards Track [Page 8] + +RFC 5311 Simplified Extension of LSP Space for IS-IS February 2009 + + +6.1. Advertising New TLVs in Extended LSPs + + As Extended LSPs MAY be utilized to advertise TLVs associated with + other protocol extensions (definition of which is outside the scope + of this document) and/or the extensions defined in Section 4.4 of + this document, it is obvious that the utilization of the information + in Extended LSPs by legacy IS-IS implementations will be limited. + The implication of this is that as implementations are revised to + support the protocol extensions that define new TLVs/sub-TLVs that + MAY be advertised in Extended LSPs; the implementation SHOULD also be + revised to support the extensions defined in this document so that it + is capable of processing the new information whether it appears in + normal or Extended LSPs. + +6.2. Reachability and Non-SPF TLV Staleness + + In cases where non-SPF information is advertised in LSPs, it is + necessary to determine whether the system that originated the + advertisement is reachable in order to guarantee that a receiving IS + does not use or leak stale information. As long as the OL bit is NOT + set by the Originating System in normal LSPs, reachability to the + Virtual IS will be consistent with reachability to the Originating + System. Therefore, no special rules are required in this case. + +6.3. Normal LSP OL State and Use of Extended LSPs + + If the Originating System sets the OL bit in a normal LSP, legacy + systems will see the Virtual ISs associated with that Originating + System as unreachable and therefore will not use the information in + the corresponding Extended LSPs. Under these circumstances, + Extension-capable ISs MUST also see the Virtual ISs as unreachable. + This avoids potential routing loops in cases where leaf information + is advertised in Extended LSPs. + +6.4. Moving Neighbor Attribute INFO LSPs + + Section 4.4 defines new TLVs that MAY be used to advertise neighbor + attribute information in Extended LSPs. In cases where neighbor + attribute information associated with the same context (e.g., the + same link) appears in both an Original LSP and in one or more + Extended LSP sets, the following rules apply for each attribute: + + o If the attribute information does not conflict, it MUST be + considered additive. + + o If the attribute information conflicts, then the information in the + Original LSP, if present, MUST be used. If no information is + + + + +McPherson, et al. Standards Track [Page 9] + +RFC 5311 Simplified Extension of LSP Space for IS-IS February 2009 + + + in the Original LSP, then the information from the Extended LSP + with the lowest system-id SHALL be preferred. + + o In cases where information about the same neighbor/link/attribute + appears in both TLV 22 and TLV 23 (or TLV 222 and TLV 223 for the + same MTID) then the information in TLV 22 (or TLV 222) MUST be used + and the information in TLV 23 (or TLV 223) MUST be ignored. + + Utilization of the new TLVs for neighbor attribute information would + provide additional benefits that include: + + o Elimination of the need for redundant IS neighbor TLVs to be + processed as part of the SPF. + + o Easier support for a set of TE information associated with a single + link that exceeds the 255-byte TLV limit by allowing the + interpretation of multiple TLVs to be considered additive rather + than mutually exclusive. + +6.5. Advertising Leaf INFO Extended LSPs + + The need to advertise leaf information in Extended LSPs may arise + because of extensive leaking of inter-level information or because + of the support of multiple topologies as described in [RFC5120]. + When leaf information is advertised in Extended LSPs, these LSPs + now contain information that MUST be processed in order to + correctly update the forwarding plane of an IS. This may increase + the frequency of events that trigger forwarding plane updates by + ISs in the network. It is therefore recommended that, when + possible, leaf information be restricted to the normal LSP set. + +7. Security Considerations + + This document raises no new security issues for IS-IS. For general + security considerations for IS-IS, see [RFC5304]. + +8. IANA Considerations + + + This document defines the following new ISIS TLVs that are + reflected in the ISIS TLV codepoint registry: + + Type Description IIH LSP SNP + ---- ----------------------------------- --- --- --- + 23 IS Neighbor Attribute n y n + 24 IS Alias ID n y n + 223 MT IS Neighbor Attribute n y n + + + + +McPherson, et al. Standards Track [Page 10] + +RFC 5311 Simplified Extension of LSP Space for IS-IS February 2009 + + +9. References + +9.1. Normative References + + [IS-IS] ISO, "Intermediate system to Intermediate system routeing + information exchange protocol for use in conjunction with + the Protocol for providing the Connectionless-mode Network + Service (ISO 8473)," ISO/IEC 10589:2002, Second Edition. + + [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic + Engineering", RFC 5305, October 2008. + + [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions + in Support of Generalized Multi-Protocol Label Switching + (GMPLS)", RFC 5307, October 2008. + + [BCP14] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi + Topology (MT) Routing in Intermediate System to + Intermediate Systems (IS-ISs)", RFC 5120, February 2008. + +9.2. Informative References + + [RFC3786] Hermelin, A., Previdi, S., and M. Shand, "Extending the + Number of Intermediate System to Intermediate System (IS- + IS) Link State PDU (LSP) Fragments Beyond the 256 Limit", + RFC 3786, May 2004. + + [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic + Authentication", RFC 5304, October 2008. + + + + + + + + + + + + + + + + + + + +McPherson, et al. Standards Track [Page 11] + +RFC 5311 Simplified Extension of LSP Space for IS-IS February 2009 + + +Authors' Addresses + + Danny McPherson (editor) + Arbor Networks, Inc. + EMail: danny@arbor.net + + Les Ginsberg + Cisco Systems + EMail: ginsberg@cisco.com + + Stefano Previdi + Cisco Systems + EMail: sprevidi@cisco.com + + Mike Shand + Cisco Systems + EMail: mshand@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McPherson, et al. Standards Track [Page 12] + -- cgit v1.2.3