summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5311.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5311.txt')
-rw-r--r--doc/rfc/rfc5311.txt675
1 files changed, 675 insertions, 0 deletions
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]
+