RFC 7356
IS-IS Flooding Scope Link State PDUs (LSPs)
IS-IS Flooding Scope Link State PDUs (LSPs) 🦋
Okay bestie, this is RFC 7356 ✨. It's an Internet Standards Track document from the IETF, published in September 2014 🎀. The authors are L. Ginsberg, S. Previdi, and Y. Yang, all from Cisco Systems 💅. It has ISSN 2070-1721 🌸. The title block doesn't list anything it obsoletes or updates, so nothing gets replaced here 🙈.
Abstract
okay so IS-IS is already super good at flooding info to its peers reliably and efficiently 🔥, but right now the flooding scopes are only area scope or domain scope 🌈. Some use cases really want other scopes, so this doc defines new PDUs for those new scopes 💖. The new PDUs also give extra space for info aimed at the scopes we already have ✨. On top of that, it defines extended TLVs and sub-TLVs that use 16-bit fields for Type and Length 🧚.
ngl the big catch is that these extensions are not backwards compatible with existing implementations, so they must be deployed with care 💀. Be careful out there 🫶.
Status of This Memo
This is an Internet Standards Track document 👑.
It's a product of the Internet Engineering Task Force (IETF) 🌸. It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 💅. For more on Internet Standards, check Section 2 of RFC 5741 🦋.
Info about the current status, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc7356 🎀.
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) as in effect on the date of publication 📜. Please read these docs carefully, because they describe your rights and restrictions 🙈. Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come 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 people controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process 😭. So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works may not be created outside it. The exception is formatting it for publication as an RFC or translating it into languages other than English 🫶.
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 . . . . . . . . . . . . . . . . . 221. Introduction 💅
So the Update Process, as defined by [IS-IS], gives reliable and efficient flooding of info to all routers in a given flooding scope 🌸. Right now the protocol supports two flooding scopes and their PDUs ✨. Level 1 (L1) Link State PDUs (LSPs) get flooded to all routers in an area 🎀. Level 2 (L2) LSPs get flooded to all routers in the Level 2 subdomain 🦋.
The basic Update Process works on any subset of the routers in a topology, as long as that topology isn't partitioned 🌈. So it's totally possible to add new PDUs for other flooding scopes and reuse the same Update Process machinery, getting the same reliability and efficiency that L1 and L2 already get 🔥. This doc defines those new PDUs and the modified Update Process rules you'd use for the new scopes 🧚.
New deployments need reliable and efficient circuit scope flooding 👑. For example, Appointed Forwarder info, as defined in [RFC7176], has to be flooded reliably and efficiently to all Routing Bridges (RBridges) on a broadcast circuit 💖. Right now only IS-IS Hellos (IIHs) have the matching scope, but IIHs are unreliable 😭. Individual IIHs can get lost without messing up correct protocol operation 🙈. To get reliability when the info is bigger than one PDU can carry, you'd have to resend it periodically even when nothing changed 💀. When the info is large, that's inefficient and still doesn't guarantee reliability 😩. This doc defines circuit scope flooding to fix that 🫶.
Another limit in [IS-IS] is how much an LSP set can carry 🍓. [RFC5311] points out that each system can originate at most 256 LSPs per level, and each LSP is capped by the minimum Maximum Transmission Unit (MTU) of any link used to flood LSPs ✨. [RFC5311] defines a backwards-compatible extension to get around this if you need it 🌈. But that solution has to stay interoperable with routers that don't support the extension, so it puts some restrictions on what can and can't be advertised in the Extended LSPs, and it requires allocating multiple unique system IDs to one router 😬. A more flexible, less constraining solution is possible if you don't need interoperability with legacy routers 🧚. The new PDUs for the new flooding scopes already aren't interoperable with legacy routers, so this doc also introduces an alternative fix for the limited LSP set capacity of L1 and L2 LSPs at the same time 👑. That capability is defined here too 💜.
Standard IS-IS TLVs use an 8-bit type and an 8-bit length 🎀. If info about a single object is more than 255 octets, you need multiple TLVs to encode everything 🌸. This doc 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 5 bits 🔥. So the protocol can only have a maximum of 32 PDU types 😭. To avoid needing new PDU types all the time, the new PDUs in this doc are defined so that multiple flooding scopes can share the same PDU type 💅. That means if you need new flooding scopes later, you can reuse the same PDU type 🫶.
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 from [IS-IS], and standard sub-TLVs (first introduced in [RFC5305]), both have an 8-bit Type field and an eight-bit Length field 💖. That caps a single TLV or sub-TLV at 255 octets 🙈. With sub-TLVs being used more and more, it's getting more likely that the info about one object needs more than 255 octets 😩. When that happens, the info gets split across multiple TLVs 💀. That's less efficient, because the info that uniquely identifies the object has to be repeated in every TLV ✨. It also makes the receiving side more complicated, since it has to collect all the info about the object from the multiple TLVs and make sure it got everything 🧚.
This doc introduces extended TLVs and extended sub-TLVs 👑. Both are encoded with 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 using extended TLVs and extended sub-TLVs 💅:
- 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) ✨
- A given flooding scope supports either standard TLVs and standard sub-TLVs, or extended TLVs and extended sub-TLVs, but not both 🌸
- 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 🚫
- 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 🎀
- The 16-bit Type and Length fields are encoded in network byte order 🌐
- Use of extended TLVs and extended sub-TLVs does not alter in any way the maximum size of PDUs that may be sent or received 🦋
2.2. Use of Standard Code Points in Extended TLVs and Extended Sub-TLVs 💅
okay so standard TLV and standard sub-TLV code points from the IANA "IS-IS TLV Codepoints" registry MAY be used in extended TLVs and extended sub-TLVs 🫶 Encoding follows whatever each standard TLV and standard sub-TLV already says, with a few glow-ups:
- The 8-bit Type field is encoded as an unsigned 16-bit integer where the 8 most significant bits (MSBs) are all 0 ✨
- The 8-bit Length field is replaced by the 16-bit Length field 🎀
- The length MAY take on values greater than 255 🌈
3. Definition of New PDUs 🧚
bestie, for the new flooding scopes we need three brand new PDUs. They're required:
- Flooding Scope LSPs (FS-LSPs) 💜
- Flooding Scope Complete Sequence Number PDUs (FS-CSNPs) 🦋
- Flooding Scope Partial Sequence Number PDUs (FS-PSNPs) 🌸
Each of these is deliberately given a header that looks as much like the matching PDU types already in [IS-IS] as possible. Could they have redesigned the header fields from scratch? Sure, maybe. But keeping the existing formats means implementers can reuse their current PDU processing logic, which is honestly the smart move 🧠✨
Also, in every FS PDU, the Maximum Area Addresses field from the header of the matching standard PDU has been swapped out for a Scope field. So the maximum area addresses checks in [IS-IS] are NOT performed on FS PDUs 🙈
3.1. Flooding Scoped LSP Format 🎀
An FS-LSP looks like this:
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].
- 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
+-------------------------+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. 💖
3.2. Flooding Scoped CSNP Format 🦋
An FS-CSNP looks like this:
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
- 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. 🎀
3.3. Flooding Scope PSNP Format 🌸
An FS-PSNP looks like this:
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. 🫧
- 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 ✨
Okay so, the Update Process from [IS-IS] keeps an LSDB (Link State Database) for each level it supports 🗂️. Each level-specific LSDB holds the full set of LSPs generated by every router working in that level's scope. FS-LSPs add more LSDBs (FS-LSDBs), one for each extra scope 🌸. The FS-LSPs in each FS-LSDB are all the FS-LSPs generated by every router operating in that scope. So every flooding scope gets its own instance of the Update Process 💅.
The scope-specific Update Process follows the Update Process spec in [IS-IS], so nothing new to memorize there 🙈. FS-LSPs only get flooded on the circuits that take part in the given scope. FS-CSNPs and FS-PSNPs get the same treatment, so they're only sent and received on circuits in that scope too 🦋.
Consistent support of a given flooding scope on a circuit is required, meaning every router on that circuit has to support it ✨.
4.1. Scope Types
A flooding scope can be limited to a single circuit, which is the circuit scope 🔌. Circuit scopes can also be narrowed by level, giving us the L1 Circuit Scope and the L2 Circuit Scope 🎀.
A flooding scope can be limited to all circuits that are enabled for L1 routing. That's the area scope 🏡.
A flooding scope can be limited to all circuits enabled for L2 routing. That's the L2 subdomain scope 🌈.
Extra scopes can also be defined to cover all circuits enabled for either L1 or L2 routing. That's the domain scope 🌍.
4.2. Operation on Point-to-Point Circuits
When a new adjacency forms, all the FS-LSDBs on that circuit need to get synchronized, no exceptions 🫶. So FS-CSNPs for every supported scope MUST be sent once the new adjacency reaches the UP state 🚀. The Send Receive Message (SRM) bit MUST be set for all FS-LSPs tied to the scopes supported on that circuit 💖.
Here's a fun one: getting an FS-PSNP with the U bit equal to 1 tells you the neighbor doesn't support that scope, even though it does support FS PDUs 🙃. When that happens, the SRM bit MUST be cleared for all FS-LSPs with the matching scope that are currently marked for flooding on that circuit 🧹.
4.3. Operation on Broadcast Circuits
FS PDUs go to the same destination address(es) as standard PDUs for the given protocol instance 📬. If you want the list of defined destination addresses, check out [IS-IS], [IEEEaq], [RFC6822], and [RFC6325] 📚.
The Designated Intermediate System (DIS) on a broadcast circuit is the one in charge of generating periodic scope-specific FS-CSNPs for all supported scopes 👑. A scope-specific DIS is NOT elected, because all routers on a circuit MUST support a consistent set of flooding scopes 💅.
A scope might be defined that isn't level specific. In that case, the DIS for each level enabled on a broadcast circuit MUST independently send FS PDUs for that scope to the matching level-specific destination address 🎯. Heads up though, this can lead to redundant flooding of FS-LSPs for that scope 🙈.
4.4. Use of Authentication
Authentication TLVs MAY be included in FS PDUs 🔐. When authentication is in use, the scope is used first to pick the authentication configuration that applies 🧩. After that, the authentication check runs as normal ✅. Scope-specific authentication MAY be used, but sharing authentication across 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 in use, the set of LSPs an IS generates can get pretty big 📦. So it can be handy to flag the LSPs that carry higher-priority information. Those LSPs have the P bit set to 1 in the Scope field of the LSP header 🚩. Those flagged LSPs SHOULD be flooded at a higher priority than LSPs with the P bit set to 0 ⚡. This is only suggested behavior for whoever originates the LSP, so it's a suggestion, not a rule 🤷♀️. And when an LSP gets purged, the original state of the P bit MUST be preserved 💜.
5. Deployment Considerations 🎀
Introducing new PDU types is incompatible with legacy implementations 😬. Legacy implementations don't support the FS-specific Update process(es). So flooding FS-LSPs across the defined scope is unreliable when not every router in that scope supports FS PDUs 💀. Legacy implementations will likely treat receiving an FS PDU as an error too 🙅♀️. Even when every router in a given scope supports FS PDUs, flooding of the FS-LSPs may still be compromised if not all routers in that scope's flooding domain support that scope 😭. So when you deploy a new flooding scope, correct operation requires that both FS PDUs and the new scope are supported by all routers in the flooding domain of the new scope 🫶.
The U bit in FS-PSNPs is the tool for suppressing retransmissions of unsupported scopes 🧯. Routers that support FS PDUs SHOULD support sending PSNPs with the U bit equal to 1 when they receive an FS-LSP with an unsupported scope 📨. Routers that support FS PDUs SHOULD also trigger management notifications when they receive FS PDUs for unsupported scopes, and when they receive PSNPs with the U bit equal to 1 🔔.
6. Graceful Restart Interactions 🔄
[RFC5306] defines protocol extensions for graceful restart of a routing instance 🌷. Synchronizing all supported FS-LSDBs is required for database synchronization to be complete 🧩. This involves additional T2 timers ⏱️. Receiving a PSNP with the U bit equal to 1 means FS-LSDB synchronization with that neighbor counts as complete for that scope ✅. For more details, see [RFC5306] 📖.
7. Multi-instance Interactions 🧚
When FS-PDUs are associated with a non-zero instance, Instance Identifier TLVs (IID-TLVs) in FS-PDUs follow the same rules used in LSPs, CSNPs, and PSNPs, as defined in [RFC6822] 🦋.
8. Circuit Scope Flooding 🔌
This document defines four circuit scope flooding identifiers 💖:
- Level 1 Circuit Scope (L1CS): uses standard TLVs and standard sub-TLVs 🌸
- Level 2 Circuit Scope (L2CS): uses standard TLVs and standard sub-TLVs 🌸
- Extended Level 1 Circuit Scope (E-L1CS): uses extended TLVs and extended sub-TLVs ✨
- Extended Level 2 Circuit Scope (E-L2CS): 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 they're flooded on 🎯. When received, such FS-LSPs MUST NOT be flooded on any other circuit 🚫. These PDUs use the FS LSP ID Extended format 🧾. The FS-LSDB linked to circuit scope FS-LSPs holds the set of FS-LSPs that both have matching circuit scopes and are transmitted (locally generated) or received on one specific circuit 💜.
The set of TLVs that may be included in these FS-LSPs depends on the specific use case, and it's outside the scope of this document 🍃.
9. Extending LSP Set Capacity 📈
The need for more space in the set of LSPs generated by a single IS was laid out in [RFC5311] 🙌. When legacy interoperability isn't a requirement, FS-LSPs cover that need without having to assign alias system-ids to a single IS 🪄. Four flooding scopes are defined for this purpose 👑:
- Level 1 Flooding Scope (L1FS): uses standard TLVs and standard sub-TLVs 🌷
- Level 2 Flooding Scope (L2FS): uses standard TLVs and standard sub-TLVs 🌷
- Extended Level 1 Flooding Scope (E-L1FS): uses extended TLVs and extended sub-TLVs 💫
- Extended Level 2 Flooding Scope (E-L2FS): uses extended TLVs and extended sub-TLVs 💫
L1FS and E-L1FS LSPs get flooded on all L1 circuits 🛣️. L2FS and E-L2FS LSPs get flooded on all L2 circuits 🛤️.
These PDUs use the FS LSP ID Extended format, which gives 64 K of additional LSPs that a single system can generate at each level 🤯.
LxFS and E-LxFS LSPs are used by the level-specific Decision Process (defined in [IS-IS]) the same way standard LSPs are, meaning as additional information sourced by the same IS 🧠. There are a few restrictions, though 👀:
- A valid version of standard LSP #0 from the same IS at the corresponding level MUST be present in the LSDB for the LxFS/E-LxFS set to be usable 🔑.
- Information in an LxFS or E-LxFS LSP (for example, 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 🚧.
- TLVs restricted to standard LSP #0 MUST NOT appear in LxFS LSPs 🙅♀️.
Other than those, there are no further restrictions on what TLVs may be advertised in FS-LSPs 🎉.
10. Domain Scope Flooding 🌍
Right now, flooding information across a whole domain (so to L1 routers in all areas and to routers in the Level 2 subdomain) needs leaking procedures between levels 🔁. For more details, see [RFC4971] 📖. That works fine when the data being flooded is made up of individual TLVs 👍. But if you want to keep track of which IS originated the complete contents of a PDU, then supporting flooding of the unchanged PDU is the way to go 🫶. So this document defines two flooding scopes for domain flooding 🧚:
- Domain Flooding Scope (DFS): uses standard TLVs and standard sub-TLVs 🌸
- Extended Domain Flooding Scope (E-DFS): uses extended TLVs and extended sub-TLVs ✨
FS-LSPs with this scope MUST be flooded on all circuits, no matter which level(s) each circuit supports 🌊.
These PDUs use the FS LSP ID Extended format 🧾.
Using the information in FS-LSPs for a given scope depends on figuring out whether the IS that originated the FS-LSP is reachable 🔍. Domain scopes make this tricky, because no single IS has the full topology view across all areas 😵💫. So the originator of domain scope DSFS and E-DSFS LSPs MUST advertise an identifier that lets an IS receiving that FS-LSP work out whether the source is currently reachable 🗺️. Which identifier is needed depends on the "address-families" being advertised 🧩.
When IS-IS is deployed to support Layer 3 routing for IPv4 and/or IPv6, FS-LSP #0 with domain scope MUST include at least one of the following TLVs 💎:
- IPv4 Traffic Engineering Router ID (TLV 134)
- IPv6 Traffic Engineering Router ID (TLV 140)
When IS-IS is deployed to support Layer 2 routing, current standards (for example, [RFC6325]) only support a single area 🏝️. So domain scope isn't applicable yet 🙃. Once the Layer 2 standards get updated to include multi-area support, the identifiers that can support inter-area reachability will be defined. At that point, domain scope for Layer 2 can be fully defined 🌈.
11. Announcing Support for Flooding Scopes ✨
Okay so, announcing support for flooding scopes is lowkey super useful 🫶. It helps you check that full support has actually been deployed, and it helps you figure out why FS-LSPs for a given scope aren't getting flooded everywhere. Main character debugging energy 🕵️♀️💅.
ISs supporting FS-PDUs MAY announce supported scopes in IIH PDUs. To do that, there's a brand new TLV 🎀.
Scope Flooding Support
Type: 243
Length: 1 - 127
Value
No. of octets
+----------------------+
|R| Supported Scope | 1
+----------------------+
: :
+----------------------+
|R| Supported Scope | 1
+----------------------+This TLV is a list of the circuit scopes supported on this circuit, plus any other non-circuit-flooding scopes that are supported. Iconic 👑.
The 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. Not me thinking this would affect adjacencies 🙅♀️. It doesn't.
Whether information in this TLV is used to determine when FS-LSPs associated with a locally supported scope are flooded is an implementation choice. 🧚
12. IANA Considerations 🌈
This document defines three new PDU types, and they show up in the "IS-IS PDU Registry". 🦋
Value Description
---- ---------------------
10 FS-LSP
11 FS-CSNP
12 FS-PSNPThere's also a brand new IANA registry for 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 the 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) UnassignedThe 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 NThe IANA "IS-IS TLV Codepoints" registry has been extended to allow codepoints less than or equal to 65535 🎉. Codepoints greater than 255 can only be used in PDUs designated to support extended TLVs. This registry also now points 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 as 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. 😭 Serious business, bestie, so take it seriously. 🚨
14. Acknowledgements 🫶
The authors wish to thank Ayan Banerjee, Donald Eastlake, Hannes Gredler, and Mike Shand for their comments. Iconic squad 💜.
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.
[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.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📦 where this page comes from
- ietf: rfc7356 2014-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms