diff options
Diffstat (limited to 'doc/rfc/rfc7356.txt')
| -rw-r--r-- | doc/rfc/rfc7356.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc7356.txt b/doc/rfc/rfc7356.txt new file mode 100644 index 0000000..cc3ffbe --- /dev/null +++ b/doc/rfc/rfc7356.txt @@ -0,0 +1,1291 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Ginsberg +Request for Comments: 7356 S. Previdi +Category: Standards Track Y. Yang +ISSN: 2070-1721 Cisco Systems + September 2014 + + + IS-IS Flooding Scope Link State PDUs (LSPs) + +Abstract + + Intermediate System to Intermediate System (IS-IS) provides efficient + and reliable flooding of information to its peers; however, the + current flooding scopes are limited to either area scope or domain + scope. There are existing use cases where support of other flooding + scopes is desirable. This document defines new Protocol Data Units + (PDUs) that provide support for new flooding scopes as well as + additional space for advertising information targeted for the + currently supported flooding scopes. This document also defines + extended Type-Length-Values (TLVs) and sub-TLVs that are encoded + using 16-bit fields for Type and Length. + + The protocol extensions defined in this document are not backwards + compatible with existing implementations and so must be deployed with + care. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7356. + + + + + + + + + + + + +Ginsberg, et al. Standards Track [Page 1] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + +Copyright Notice + + Copyright (c) 2014 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. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Ginsberg, et al. Standards Track [Page 2] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 + 2. Extended TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. Use of Extended TLVs and Extended Sub-TLVs . . . . . . . 5 + 2.2. Use of Standard Code Points in Extended TLVs and Extended + Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. Definition of New PDUs . . . . . . . . . . . . . . . . . . . 6 + 3.1. Flooding Scoped LSP Format . . . . . . . . . . . . . . . 7 + 3.2. Flooding Scoped CSNP Format . . . . . . . . . . . . . . . 10 + 3.3. Flooding Scope PSNP Format . . . . . . . . . . . . . . . 12 + 4. Flooding Scope Update Process Operation . . . . . . . . . . . 13 + 4.1. Scope Types . . . . . . . . . . . . . . . . . . . . . . . 14 + 4.2. Operation on Point-to-Point Circuits . . . . . . . . . . 14 + 4.3. Operation on Broadcast Circuits . . . . . . . . . . . . . 14 + 4.4. Use of Authentication . . . . . . . . . . . . . . . . . . 15 + 4.5. Priority Flooding . . . . . . . . . . . . . . . . . . . . 15 + 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 15 + 6. Graceful Restart Interactions . . . . . . . . . . . . . . . . 16 + 7. Multi-instance Interactions . . . . . . . . . . . . . . . . . 16 + 8. Circuit Scope Flooding . . . . . . . . . . . . . . . . . . . 16 + 9. Extending LSP Set Capacity . . . . . . . . . . . . . . . . . 17 + 10. Domain Scope Flooding . . . . . . . . . . . . . . . . . . . . 18 + 11. Announcing Support for Flooding Scopes . . . . . . . . . . . 19 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 21 + 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 15.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 15.2. Informative References . . . . . . . . . . . . . . . . . 22 + +1. Introduction + + The Update Process, as defined by [IS-IS], provides reliable and + efficient flooding of information to all routers in a given flooding + scope. Currently, the protocol supports two flooding scopes and + associated PDUs. Level 1 (L1) Link State PDUs (LSPs) are flooded to + all routers in an area. Level 2 (L2) LSPs are flooded to all routers + in the Level 2 subdomain. The basic operation of the Update Process + can be applied to any subset of the routers in a given topology so + long as that topology is not partitioned. It is, therefore, possible + to introduce new PDUs in support of other flooding scopes and utilize + the same Update Process machinery to provide the same reliability and + efficiency that the Update Process currently provides for L1 and L2 + scopes. This document defines these new PDUs and the modified Update + Process rules that are to be used in supporting new flooding scopes. + + + + +Ginsberg, et al. Standards Track [Page 3] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + + New deployment cases have introduced the need for reliable and + efficient circuit scope flooding. For example, Appointed Forwarder + information, as defined in [RFC7176], needs to be flooded reliably + and efficiently to all Routing Bridges (RBridges) on a broadcast + circuit. Currently, only IS-IS Hellos (IIHs) have the matching scope + -- but IIHs are unreliable, i.e., individual IIHs may be lost without + affecting correct operation of the protocol. To provide reliability + in cases where the set of information to be flooded exceeds the + carrying capacity of a single PDU requires sending the information + periodically even when no changes in the content have occurred. When + the information content is large, this is inefficient and still does + not provide a guarantee of reliability. This document defines + circuit scope flooding in order to provide a solution for such cases. + + Another existing limitation of [IS-IS] is the carrying capacity of an + LSP set. It has been noted in [RFC5311] that the set of LSPs that + may be originated by a system at each level is limited to 256 LSPs, + and the maximum size of each LSP is limited by the minimum Maximum + Transmission Unit (MTU) of any link used to flood LSPs. [RFC5311] + has defined a backwards-compatible protocol extension that can be + used to overcome this limitation if needed. While the [RFC5311] + solution is viable, in order to be interoperable with routers that do + not support the extension, it imposes some restrictions on what can/ + cannot be advertised in the Extended LSPs and requires allocation of + multiple unique system IDs to a given router. A more flexible and + less constraining solution is possible if interoperability with + legacy routers is not a requirement. By definition, the introduction + of new PDUs required to support new flooding scopes is not + interoperable with legacy routers. It is, therefore, possible to + simultaneously introduce an alternative solution to the limited LSP + set carrying capacity of Level 1 and Level 2 LSPs as part of the + extensions defined in this document. This capability is also defined + in this document. + + Standard IS-IS TLVs are encoded using an 8-bit type and an 8-bit + length. In cases where the set of information about a single object + exceeds 255 octets, multiple TLVs are required to encode all of the + relevant information. This document introduces extended TLVs and + extended sub-TLVs that use a 16-bit Type field and a 16-bit Length + field. + + The PDU Type field in the common header for all IS-IS PDUs is a 5-bit + field. Therefore, possible PDU types supported by the protocol are + limited to a maximum of 32. In order to minimize the need to + introduce additional PDU types in the future, the new PDUs introduced + in this document are defined so as to allow multiple flooding scopes + to be associated with the same PDU type. This means if new flooding + scopes are required in the future, the same PDU type can be used. + + + +Ginsberg, et al. Standards Track [Page 4] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + +1.1. Requirements Language + + 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 [RFC2119]. + +2. Extended TLVs + + Standard TLVs as defined in [IS-IS] as well as standard sub-TLVs + (first introduced in [RFC5305]) have an 8-bit Type field and an + eight-bit Length field. This constrains the information included in + a single TLV or sub-TLV to 255 octets. With the increasing use of + sub-TLVs, it becomes more likely that the amount of information about + a single object that needs to be advertised may exceed 255 octets. + In such cases, the information is encoded in multiple TLVs. This + leads to less efficient encoding since the information that uniquely + identifies the object must be repeated in each TLV and requires + additional implementation complexity when receiving the information + to ensure that all information about the object is correctly + collected from the multiple TLVs. + + This document introduces extended TLVs and extended sub-TLVs. These + are encoded using a 16-bit Type field and a 16-bit Length field. + +2.1. Use of Extended TLVs and Extended Sub-TLVs + + The following restrictions apply to the use of extended TLVs and + extended sub-TLVs: + + o Extended TLVs and extended sub-TLVs are permitted only in Flooding + Scope PDUs that have a flooding scope designated for their use + (defined later in this document) + + o A given flooding scope supports either the use of standard TLVs + and standard sub-TLVs or the use of extended TLVs and extended + sub-TLVs, but not both + + o Extended TLVs and extended sub-TLVs MUST be used together, i.e., + using Standard sub-TLVs within an Extended TLV or using Extended + sub-TLVs within a Standard TLV is invalid + + o If additional levels of TLVs (e.g., sub-sub-TLVs) are introduced + in the future, then the size of the Type and Length fields in + these new sub-types MUST match the size used in the parent + + o The 16-bit Type and Length fields are encoded in network byte + order + + + + +Ginsberg, et al. Standards Track [Page 5] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + + o Use of extended TLVs and extended sub-TLVs does not alter in any + way the maximum size of PDUs that may sent or received + +2.2. Use of Standard Code Points in Extended TLVs and Extended Sub-TLVs + + Standard TLV and standard sub-TLV code points as defined in the IANA + "IS-IS TLV Codepoints" registry MAY be used in extended TLVs and + extended sub-TLVs. Encoding is as specified for each of the standard + TLVs and standard sub-TLVs with the following differences: + + o The 8-bit Type field is encoded as an unsigned 16-bit integer + where the 8 most significant bits (MSBs) are all 0 + + o The 8-bit Length field is replaced by the 16-bit Length field + + o The length MAY take on values greater than 255 + +3. Definition of New PDUs + + In support of new flooding scopes, the following new PDUs are + required: + + o Flooding Scope LSPs (FS-LSPs) + + o Flooding Scope Complete Sequence Number PDUs (FS-CSNPs) + + o Flooding Scope Partial Sequence Number PDUs (FS-PSNPs) + + Each of these PDUs is intentionally defined with a header as similar + in format as possible to the corresponding PDU types currently + defined in [IS-IS]. Although it might have been possible to + eliminate or redefine PDU header fields in a new way, the existing + formats are retained in order to allow maximum reuse of existing PDU + processing logic in an implementation. + + Note that in the case of all FS PDUs, the Maximum Area Addresses + field in the header of the corresponding standard PDU has been + replaced with a Scope field. Therefore, maximum area addresses + checks specified in [IS-IS] are not performed on FS PDUs. + + + + + + + + + + + + +Ginsberg, et al. Standards Track [Page 6] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + +3.1. Flooding Scoped LSP Format + + An FS-LSP has the following format: + + No. of octets + +-------------------------+ + | Intradomain Routeing | 1 + | Protocol Discriminator | + +-------------------------+ + | Length Indicator | 1 + +-------------------------+ + | Version/Protocol ID | 1 + | Extension | + +-------------------------+ + | ID Length | 1 + +-------------------------+ + |R|R|R| PDU Type | 1 + +-------------------------+ + | Version | 1 + +-------------------------+ + | Reserved | 1 + +-------------------------+ + |P| Scope | 1 + +-------------------------+ + | PDU Length | 2 + +-------------------------+ + | Remaining Lifetime | 2 + +-------------------------+ + | FS LSP ID | ID Length + 2 + +-------------------------+ + | Sequence Number | 4 + +-------------------------+ + | Checksum | 2 + +-------------------------+ + |Reserved|LSPDBOL|IS Type | 1 + +-------------------------+ + : Variable-Length Fields : Variable + +-------------------------+ + + + Intradomain Routeing Protocol Discriminator: 0x83 (as defined in + [IS-IS]). + + Length Indicator: Length of the fixed header in octets. + + Version/Protocol ID Extension: 1 + + ID Length: As defined in [IS-IS]. + + + +Ginsberg, et al. Standards Track [Page 7] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + + PDU Type: 10 - Format as defined in [IS-IS]. + + Version: 1 + + Reserved: Transmitted as zero, ignored on receipt. + + Scope: Bits 1-7 define the flooding scope. + + The value 0 is reserved and MUST NOT be used. Received FS-LSPs + with a scope of 0 MUST be ignored and MUST NOT be flooded. + + P: Bit 8 - Priority Bit. If set to 1, this LSP SHOULD be + flooded at high priority. + + Scopes (1 - 63) are reserved for use with standard TLVs and + standard sub-TLVs. + + Scopes (64 - 127) are reserved for use with extended TLVs and + extended sub-TLVs. + + PDU Length: Entire length of this PDU, in octets, including the + header. + + Remaining Lifetime: Number of seconds before this FS-LSP is + considered expired. + + FS LSP ID: The system ID of the source of the FS-LSP. One of the + following two formats is used: + + FS LSP ID Standard Format + + +-------------------------+ + | Source ID | ID Length + +-------------------------+ + | Pseudonode ID | 1 + +-------------------------+ + | FS LSP Number | 1 + +-------------------------+ + + + FS LSP ID Extended Format + + +-------------------------+ + | Source ID | ID Length + +-------------------------+ + | Extended FS LSP Number | 2 + +-------------------------+ + + + + +Ginsberg, et al. Standards Track [Page 8] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + + Which format is used is specific to the scope and MUST be defined + when the specific flooding scope is defined. + + Sequence Number: Sequence number of this FS-LSP. + + Checksum: Checksum of contents of FS-LSP from the Source ID to the + end. Checksum is computed as defined in [IS-IS]. + + Reserved/LSPDBOL/IS Type + + Bits 4-8 are reserved, which means they are transmitted as 0 + and ignored on receipt. + + LSPDBOL: Bit 3 - A value of 0 indicates no FS-LSP Database + Overload and a value of 1 indicates that the FS-LSP Database is + overloaded. The overload condition is specific to FS-LSPs with + the scope specified in the Scope field. + + IS Type: Bits 1 and 2. The type of Intermediate System as + defined in [IS-IS]. + + Variable-length fields that are allowed in an FS-LSP are specific + to the defined scope. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ginsberg, et al. Standards Track [Page 9] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + +3.2. Flooding Scoped CSNP Format + + An FS-CSNP has the following format: + + No. of octets + +-------------------------+ + | Intradomain Routeing | 1 + | Protocol Discriminator | + +-------------------------+ + | Length Indicator | 1 + +-------------------------+ + | Version/Protocol ID | 1 + | Extension | + +-------------------------+ + | ID Length | 1 + +-------------------------+ + |R|R|R| PDU Type | 1 + +-------------------------+ + | Version | 1 + +-------------------------+ + | Reserved | 1 + +-------------------------+ + |R| Scope | 1 + +-------------------------+ + | PDU Length | 2 + +-------------------------+ + | Source ID | ID Length + 1 + +-------------------------+ + | Start FS-LSP ID | ID Length + 2 + +-------------------------+ + | End FS-LSP ID | ID Length + 2 + +-------------------------+ + : Variable-Length Fields : Variable + +-------------------------+ + + + Intradomain Routeing Protocol Discriminator: 0x83 (as defined in + [IS-IS]). + + Length Indicator: Length of the fixed header in octets. + + Version/Protocol ID Extension: 1 + + ID Length: As defined in [IS-IS]. + + PDU Type: 11 - Format as defined in [IS-IS]. + + Version: 1 + + + +Ginsberg, et al. Standards Track [Page 10] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + + Reserved: Transmitted as zero, ignored on receipt. + + Scope: Bits 1-7 define the flooding scope. + + The value 0 is reserved and MUST NOT be used. Received FS- + CSNPs with a scope of 0 MUST be ignored. + + Bit 8 is Reserved, which means it is transmitted as 0 and + ignored on receipt. + + Scopes (1 - 63) are reserved for use with standard TLVs and + standard sub-TLVs. + + Scopes (64 - 127) are reserved for use with extended TLV and + extended sub-TLVs. + + PDU Length: Entire length of this PDU, in octets, including the + header. + + Source ID: The system ID of the Intermediate System (with zero + Circuit ID) generating this Sequence Number's PDU. + + Start FS-LSP ID: The FS-LSP ID of the first FS-LSP with the + specified scope in the range covered by this FS-CSNP. + + End FS-LSP ID: The FS-LSP ID of the last FS-LSP with the specified + scope in the range covered by this FS-CSNP. + + Variable-length fields that are allowed in an FS-CSNP are limited + to those TLVs that are supported by standard CSNP. + + + + + + + + + + + + + + + + + + + + + +Ginsberg, et al. Standards Track [Page 11] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + +3.3. Flooding Scope PSNP Format + + An FS-PSNP has the following format: + + No. of octets + +-------------------------+ + | Intradomain Routeing | 1 + | Protocol Discriminator | + +-------------------------+ + | Length Indicator | 1 + +-------------------------+ + | Version/Protocol ID | 1 + | Extension | + +-------------------------+ + | ID Length | 1 + +-------------------------+ + |R|R|R| PDU Type | 1 + +-------------------------+ + | Version | 1 + +-------------------------+ + | Reserved | 1 + +-------------------------+ + |U| Scope | 1 + +-------------------------+ + | PDU Length | 2 + +-------------------------+ + | Source ID | ID Length + 1 + +-------------------------+ + : Variable-Length Fields : Variable + +-------------------------+ + + Intradomain Routeing Protocol Discriminator: 0x83 (as defined in + [IS-IS]). + + Length Indicator: Length of the fixed header in octets. + + Version/Protocol ID Extension: 1 + + ID Length: As defined in [IS-IS]. + + PDU Type: 12 - Format as defined in [IS-IS]. + + Version: 1 + + Reserved: Transmitted as zero, ignored on receipt. + + + + + + +Ginsberg, et al. Standards Track [Page 12] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + + Scope: Bits 1-7 define the flooding scope. + + The value 0 is reserved and MUST NOT be used. Received FS- + PSNPs with a scope of 0 MUST be ignored. + + U: Bit 8 - A value of 0 indicates that the specified flooding + scope is supported. A value of 1 indicates that the specified + flooding scope is unsupported. When U = 1, variable-length + fields other than authentication MUST NOT be included in the + PDU. + + Scopes (1 - 63) are reserved for use with standard TLVs and + standard sub-TLVs. + + Scopes (64 - 127) are reserved for use with extended TLVs and + extended sub-TLVs. + + PDU Length: Entire length of this PDU, in octets, including the + header. + + Source ID: The system ID of the Intermediate System (with zero + Circuit ID) generating this Sequence Number's PDU. + + Variable-length fields that are allowed in an FS-PSNP are limited + to those TLVs that are supported by standard PSNPs. + +4. Flooding Scope Update Process Operation + + The Update Process, as defined in [IS-IS], maintains a Link State + Database (LSDB) for each level supported. Each level-specific LSDB + contains the full set of LSPs generated by all routers operating in + that level-specific scope. The introduction of FS-LSPs creates + additional LSDBs (FS-LSDBs) for each additional scope supported. The + set of FS-LSPs in each FS-LSDB consists of all FS-LSPs generated by + all routers operating in that scope. Therefore, there is an + additional instance of the Update Process for each supported flooding + scope. + + Operation of the scope-specific Update Process follows the Update + Process specification in [IS-IS]. The circuit(s) on which FS-LSPs + are flooded is limited to those circuits that are participating in + the given scope. Similarly, the sending/receiving of FS-CSNPs and + FS-PSNPs is limited to the circuits participating in the given scope. + + Consistent support of a given flooding scope on a circuit by all + routers operating on that circuit is required. + + + + + +Ginsberg, et al. Standards Track [Page 13] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + +4.1. Scope Types + + A flooding scope may be limited to a single circuit (circuit scope). + Circuit scopes may be further limited by level (L1 Circuit Scope / L2 + Circuit Scope). + + A flooding scope may be limited to all circuits enabled for L1 + routing (area scope). + + A flooding scope may be limited to all circuits enabled for L2 + routing (L2 subdomain scope). + + Additional scopes may be defined that include all circuits enabled + for either L1 or L2 routing (domain scope). + +4.2. Operation on Point-to-Point Circuits + + When a new adjacency is formed, synchronization of all FS-LSDBs + supported on that circuit is required; therefore, FS-CSNPs for all + supported scopes MUST be sent when a new adjacency reaches the UP + state. The Send Receive Message (SRM) bit MUST be set for all + FS-LSPs associated with the scopes supported on that circuit. + Receipt of an FS-PSNP with the U bit equal to 1 indicates that the + neighbor does not support that scope (although it does support FS + PDUs). This MUST cause the SRM bit to be cleared for all FS-LSPs + with the matching scope, which are currently marked for flooding on + that circuit. + +4.3. Operation on Broadcast Circuits + + FS PDUs are sent to the same destination address(es) as standard PDUs + for the given protocol instance. For specification of the defined + destination addresses, consult [IS-IS], [IEEEaq], [RFC6822], and + [RFC6325]. + + The Designated Intermediate System (DIS) for a broadcast circuit has + the responsibility to generate periodic scope-specific FS-CSNPs for + all supported scopes. A scope-specific DIS is NOT elected as all + routers on a circuit MUST support a consistent set of flooding + scopes. + + It is possible that a scope may be defined that is not level + specific. In such a case, the DIS for each level enabled on a + broadcast circuit MUST independently send FS PDUs for that scope to + the appropriate level-specific destination address. This may result + in redundant flooding of FS-LSPs for that scope. + + + + + +Ginsberg, et al. Standards Track [Page 14] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + +4.4. Use of Authentication + + Authentication TLVs MAY be included in FS PDUs. When authentication + is in use, the scope is first used to select the authentication + configuration that is applicable. The authentication check is then + performed as normal. Although scope-specific authentication MAY be + used, sharing of authentication among multiple scopes and/or with the + standard LSPs/CSNPs/PSNPs is considered sufficient. + +4.5. Priority Flooding + + When the FS LSP ID Extended format is used, the set of LSPs generated + by an IS may be quite large. It may be useful to identify those LSPs + in the set that contain information of higher priority. Such LSPs + will have the P bit set to 1 in the Scope field in the LSP header. + Such LSPs SHOULD be flooded at a higher priority than LSPs with the P + bit set to 0. This is a suggested behavior on the part of the + originator of the LSP. When an LSP is purged, the original state of + the P bit MUST be preserved. + +5. Deployment Considerations + + Introduction of new PDU types is incompatible with legacy + implementations. Legacy implementations do not support the + FS-specific Update process(es) and, therefore, flooding of the + FS-LSPs throughout the defined scope is unreliable when not all + routers in the defined scope support FS PDUs. Further, legacy + implementations will likely treat the reception of an FS PDU as an + error. Even when all routers in a given scope support FS PDUs, if + not all routers in the flooding domain for a given scope support that + scope, then flooding of the FS-LSPs may be compromised. When + deploying a new flooding scope, correct operation therefore requires + that both FS PDUs and the new scope be supported by all routers in + the flooding domain of the new scope. + + The U bit in FS-PSNPs provides a means to suppress retransmissions of + unsupported scopes. Routers that support FS PDUs SHOULD support the + sending of PSNPs with the U bit equal to 1 when an FS-LSP is received + with a scope that is unsupported. Routers that support FS PDUs + SHOULD trigger management notifications when FS PDUs are received for + unsupported scopes and when PSNPs with the U bit equal to 1 are + received. + + + + + + + + + +Ginsberg, et al. Standards Track [Page 15] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + +6. Graceful Restart Interactions + + [RFC5306] defines protocol extensions in support of graceful restart + of a routing instance. Synchronization of all supported FS-LSDBs is + required in order for database synchronization to be complete. This + involves the use of additional T2 timers. Receipt of a PSNP with the + U bit equal to 1 will cause FS-LSDB synchronization with that + neighbor to be considered complete for that scope. See [RFC5306] for + further details. + +7. Multi-instance Interactions + + In cases where FS-PDUs are associated with a non-zero instance, the + use of Instance Identifier TLVs (IID-TLVs) in FS-PDUs follows the + rules for use in LSPs, CSNPs, and PSNPs as defined in [RFC6822]. + +8. Circuit Scope Flooding + + This document defines four circuit scope flooding identifiers: + + o Level 1 Circuit Scope (L1CS) -- this uses standard TLVs and + standard sub-TLVs + + o Level 2 Circuit Scope (L2CS) -- this uses standard TLVs and + standard sub-TLVs + + o Extended Level 1 Circuit Scope (E-L1CS) -- this uses extended TLVs + and extended sub-TLVs + + o Extended Level 2 Circuit Scope (E-L2CS) -- this uses extended TLVs + and extended sub-TLVs + + FS-LSPs with the Scope field set to one of these values contain + information specific to the circuit on which they are flooded. When + received, such FS-LSPs MUST NOT be flooded on any other circuit. The + FS LSP ID Extended format is used in these PDUs. The FS-LSDB + associated with circuit scope FS-LSPs consists of the set of FS-LSPs + that both have matching circuit scopes and are transmitted (locally + generated) or received on a specific circuit. + + The set of TLVs that may be included in such FS-LSPs is specific to + the given use case and is outside the scope of this document. + + + + + + + + + +Ginsberg, et al. Standards Track [Page 16] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + +9. Extending LSP Set Capacity + + The need for additional space in the set of LSPs generated by a + single IS has been articulated in [RFC5311]. When legacy + interoperability is not a requirement, the use of FS-LSPs meets that + need without requiring the assignment of alias system-ids to a single + IS. Four flooding scopes are defined for this purpose: + + o Level 1 Flooding Scope (L1FS) -- this uses standard TLVs and + standard sub-TLVs + + o Level 2 Flooding Scope (L2FS) -- this uses standard TLVs and + standard sub-TLVs + + o Extended Level 1 Flooding Scope (E-L1FS) -- this uses extended + TLVs and extended sub-TLVs + + o Extended Level 2 Flooding Scope (E-L2FS) -- this uses extended + TLVs and extended sub-TLVs + + L1FS and E-L1FS LSPs are flooded on all L1 circuits. L2FS and E-L2FS + LSPs are flooded on all L2 circuits. + + The FS LSP ID Extended format is used in these PDUs. This provides + 64 K of additional LSPs that may be generated by a single system at + each level. + + LxFS and E-LxFS LSPs are used by the level-specific Decision Process + (defined in [IS-IS]) in the same manner as standard LSPs (i.e., as + additional information sourced by the same IS) subject to the + following restrictions: + + o A valid version of standard LSP #0 from the same IS at the + corresponding level MUST be present in the LSDB in order for the + LxFS/E-LxFS set to be usable. + + o Information in an LxFS of E-LxFS LSP (e.g., IS-Neighbor + information) that supports using the originating IS as a transit + node MUST NOT be used when the Overload bit is set in the + corresponding standard LSP #0. + + o TLVs that are restricted to standard LSP #0 MUST NOT appear in + LxFS LSPs. + + There are no further restrictions as to what TLVs may be advertised + in FS-LSPs. + + + + + +Ginsberg, et al. Standards Track [Page 17] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + +10. Domain Scope Flooding + + Existing support for flooding information throughout a domain (i.e., + to L1 routers in all areas as well as to routers in the Level 2 + subdomain) requires the use of leaking procedures between levels. + For further details, see [RFC4971]. This is sufficient when the data + being flooded throughout the domain consists of individual TLVs. If + it is desired to retain the identity of the originating IS for the + complete contents of a PDU, then support for flooding the unchanged + PDU is desirable. This document, therefore, defines two flooding + scopes in support of domain flooding. FS-LSPs with this scope MUST + be flooded on all circuits regardless of what level(s) is supported + on that circuit. + + o Domain Flooding Scope (DFS) -- this uses standard TLVs and + standard sub-TLVs + + o Extended Domain Flooding Scope (E-DFS) -- this uses extended TLVs + and extended sub-TLVs + + The FS LSP ID Extended format is used in these PDUs. + + Use of information in FS-LSPs for a given scope depends on + determining the reachability to the IS originating the FS-LSP. This + presents challenges for FS-LSPs with domain scopes because no single + IS has the full view of the topology across all areas. It is, + therefore, necessary for the originator of domain scope DSFS and + E-DSFS LSPs to advertise an identifier that will allow an IS who + receives such an FS-LSP to determine whether the source of the FS-LSP + is currently reachable. The identifier required depends on what + "address-families" are being advertised. + + When IS-IS is deployed in support of Layer 3 routing for IPv4 and/or + IPv6, then FS-LSP #0 with domain scope MUST include at least one of + the following TLVs: + + o IPv4 Traffic Engineering Router ID (TLV 134) + + o IPv6 Traffic Engineering Router ID (TLV 140) + + When IS-IS is deployed in support of Layer 2 routing, current + standards (e.g., [RFC6325]) only support a single area. Therefore, + domain scope is not yet applicable. When the Layer 2 standards are + updated to include multi-area support, the identifiers that can be + used to support inter-area reachability will be defined -- at which + point the use of domain scope for Layer 2 can be fully defined. + + + + + +Ginsberg, et al. Standards Track [Page 18] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + +11. Announcing Support for Flooding Scopes + + Announcements of support for flooding scope may be useful in + validating that full support has been deployed and/or in isolating + the reasons for incomplete flooding of FS-LSPs for a given scope. + + ISs supporting FS-PDUs MAY announce supported scopes in IIH PDUs. To + do so, a new TLV is defined. + + Scope Flooding Support + Type: 243 + Length: 1 - 127 + Value + No. of octets + +----------------------+ + |R| Supported Scope | 1 + +----------------------+ + : : + +----------------------+ + |R| Supported Scope | 1 + +----------------------+ + + A list of the circuit scopes supported on this circuit and other + non-circuit-flooding scopes supported. + + R bit MUST be 0 and is ignored on receipt. + + In a Point-to-Point IIH, L1, L2, domain, and all circuit scopes + MAY be advertised. + + In Level 1 LAN IIHs, L1, domain, and L1 Circuit Scopes MAY be + advertised. L2 Scopes and L2 Circuit Scopes MUST NOT be + advertised. + + In Level 2 LAN IIHs, L2, domain, and L2 Circuit Scopes MAY be + advertised. L1 Scopes and L1 Circuit Scopes MUST NOT be + advertised. + + Information in this TLV MUST NOT be considered in adjacency + formation. + + Whether information in this TLV is used to determine when FS-LSPs + associated with a locally supported scope are flooded is an + implementation choice. + + + + + + + +Ginsberg, et al. Standards Track [Page 19] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + +12. IANA Considerations + + This document includes the definition of three new PDU types that are + reflected in the "IS-IS PDU Registry". + + Value Description + ---- --------------------- + 10 FS-LSP + 11 FS-CSNP + 12 FS-PSNP + + A new IANA registry has been created to control the assignment of + scope identifiers in FS-PDUs. The registration procedure is "Expert + Review" as defined in [RFC5226]. The registry name is "LSP Flooding + Scope Identifier Registry". A scope identifier is a number from + 1-127, inclusive. Values 1 - 63 are reserved for PDUs that use + standard TLVs and standard sub-TLVs. Values 64 - 127 are reserved + for PDUs that use extended TLVs and extended sub-TLVs. The list of + Hello PDUs in which support for a given scope MAY be announced (using + Scope Flooding Support TLV) is specified for each defined scope. + + The following scope identifiers are defined by this document. + + FS LSP ID Format/ IIH Announce + Value Description TLV Format P2P L1LAN L2LAN + ----- ------------------------------ ----------------- --------------- + 1 Level 1 Circuit Flooding Scope Extended/Standard Y Y N + 2 Level 2 Circuit Flooding Scope Extended/Standard Y N Y + 3 Level 1 Flooding Scope Extended/Standard Y Y N + 4 Level 2 Flooding Scope Extended/Standard Y N Y + 5 Domain Flooding Scope Extended/Standard Y Y Y + (6-63)Unassigned + + 64 Level 1 Circuit Flooding Scope Extended/Extended Y Y N + 65 Level 2 Circuit Flooding Scope Extended/Extended Y N Y + 66 Level 1 Flooding Scope Extended/Extended Y Y N + 67 Level 2 Flooding Scope Extended/Extended Y N Y + 68 Domain Flooding Scope Extended/Extended Y Y Y + (69-127) Unassigned + + The definition of a new IS-IS TLV is reflected in the "IS-IS TLV + Codepoints" registry: + + Value Name IIH LSP SNP Purge + ---- ------------ --- --- --- ----- + 243 Scope Flooding Support Y N N N + + + + + +Ginsberg, et al. Standards Track [Page 20] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + + The IANA "IS-IS TLV Codepoints" registry has been extended to allow + definition of codepoints less than or equal to 65535. Codepoints + greater than 255 can only be used in PDUs designated to support + extended TLVs. This registry has also been updated to point to this + document as a reference (in addition to [RFC3563] and [RFC6233]). + +13. Security Considerations + + Security concerns for IS-IS are addressed in [IS-IS], [RFC5304], and + [RFC5310]. + + The new PDUs introduced are subject to the same security issues + associated with their standard LSP/CSNP/PSNP counterparts. To the + extent that additional PDUs represent additional load for routers in + the network, this increases the opportunity for denial-of-service + attacks. + +14. Acknowledgements + + The authors wish to thank Ayan Banerjee, Donald Eastlake, Hannes + Gredler, and Mike Shand for their comments. + +15. References + +15.1. Normative References + + [IEEEaq] IEEE, "Standard for Local and metropolitan area networks + -- Media Access Control (MAC) Bridges and Virtual Bridged + Local Area Networks -- Amendment 20: Shortest Path + Bridging", IEEE Std 802.1aq-2012, June 2012. + + [IS-IS] ISO/IEC 10589:2002, Second Edition, "Information + technology -- Telecommunications and information exchange + between systems -- Intermediate System to Intermediate + System intradomain routeing information exchange protocol + for use in conjunction with the protocol for providing the + connectionless-mode network service (ISO 8473)", 2002. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate + System to Intermediate System (IS-IS) Extensions for + Advertising Router Information", RFC 4971, July 2007. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + + +Ginsberg, et al. Standards Track [Page 21] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + + [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic + Authentication", RFC 5304, October 2008. + + [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic + Engineering", RFC 5305, October 2008. + + [RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", + RFC 5306, October 2008. + + [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., + and M. Fanto, "IS-IS Generic Cryptographic + Authentication", RFC 5310, February 2009. + + [RFC6822] Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D. + Ward, "IS-IS Multi-Instance", RFC 6822, December 2012. + +15.2. Informative References + + [RFC3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF + and ISO/IEC Joint Technical Committee 1/Sub Committee 6 + (JTC1/SC6) on IS-IS Routing Protocol Development", RFC + 3563, July 2003. + + [RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand, + "Simplified Extension of Link State PDU (LSP) Space for + IS-IS", RFC 5311, February 2009. + + [RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for + Purges", RFC 6233, May 2011. + + [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. + Ghanwani, "Routing Bridges (RBridges): Base Protocol + Specification", RFC 6325, July 2011. + + [RFC7176] Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt, D., + and A. Banerjee, "Transparent Interconnection of Lots of + Links (TRILL) Use of IS-IS", RFC 7176, May 2014. + + + + + + + + + + + + + + +Ginsberg, et al. Standards Track [Page 22] + +RFC 7356 IS-IS Flooding Scope LSPs September 2014 + + +Authors' Addresses + + Les Ginsberg + Cisco Systems + 510 McCarthy Blvd. + Milpitas, CA 95035 + USA + + EMail: ginsberg@cisco.com + + + Stefano Previdi + Cisco Systems + Via Del Serafico 200 + Rome 0144 + Italy + + EMail: sprevidi@cisco.com + + + Yi Yang + Cisco Systems + 7100-9 Kit Creek Road + Research Triangle Park, NC 27709-4987 + USA + + EMail: yiya@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + +Ginsberg, et al. Standards Track [Page 23] + |