IS-IS Flooding Scope Link State PDUs (LSPs)
New IS-IS packets that flood link state data to scopes beyond an area or the Level 2 subdomain, with room for far more of it.
Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <https://www.rfc-editor.org/info/rfc7356>.
@misc{rfc7356,
series = {Request for Comments},
number = 7356,
howpublished = {RFC 7356},
publisher = {RFC Editor},
doi = {10.17487/RFC7356},
url = {https://www.rfc-editor.org/info/rfc7356},
author = {L. Ginsberg and S. Previdi and Y. Yang},
title = {{IS-IS Flooding Scope Link State PDUs (LSPs)}},
pagetotal = 23,
year = 2014,
month = sep,
} RFC text
Contents
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.
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.
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.
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.
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
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.
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].
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 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
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 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.
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.
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.
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.
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.
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.
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.
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.
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
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.
[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
ISO Plain Language
On this page
§1Why New Flooding Scopes
The Update Process, as defined by IS-IS, provides reliable and efficient flooding of information to all the routers in a given flooding scope. Currently the protocol supports two flooding scopes and the associated packets. Level 1 link state packets are flooded to all the routers in an area, and Level 2 packets are flooded to all the 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 packets in support of other flooding scopes and use the same Update Process machinery to provide the same reliability and efficiency it currently provides for the Level 1 and Level 2 scopes. The RFC defines these new packets and the modified Update Process rules to be used in supporting new flooding scopes.
New deployment cases have introduced the need for reliable and efficient circuit scope flooding. Appointed Forwarder information, as defined in RFC 7176, for example, needs to be flooded reliably and efficiently to all the Routing Bridges on a broadcast circuit. Currently only IS-IS Hellos have the matching scope, and those are unreliable, in that individual Hellos may be lost without affecting correct operation of the protocol. Providing reliability in cases where the set of information to be flooded exceeds the carrying capacity of a single packet requires sending the information periodically even when nothing has changed. When the information content is large this is inefficient and still gives no guarantee of reliability, so the RFC defines circuit scope flooding as a solution.
Another existing limitation is the carrying capacity of an LSP set. As noted in RFC 5311, the set of LSPs a system may originate at each level is limited to 256, and the maximum size of each is limited by the smallest Maximum Transmission Unit of any link used to flood them. That document defines a backwards-compatible extension to overcome the limitation if needed, but to stay interoperable with routers that do not support it, it restricts what can be advertised in the Extended LSPs and requires a router to be given several unique system IDs. A more flexible solution is possible where interoperability with legacy routers is not required. By definition, the introduction of new packets is not interoperable with legacy routers, so an alternative solution to the limited LSP set carrying capacity of Level 1 and Level 2 LSPs can be introduced at the same time.
IS-IS works by flooding: every router sends its link state information to its neighbours, which forward it onwards, until the whole area has the same picture. The set of routers that receive it is the flooding scope, and IS-IS has two built in.
Two new needs have appeared. Sometimes the information should reach only the routers on one circuit, for example the Routing Bridges on a shared broadcast segment. The only IS-IS message with that reach is the Hello, and Hellos are allowed to be lost. The other need is more space: a router can publish only 256 link state packets at each level, and the workaround in RFC 5311 costs it several system IDs.
This RFC defines new packets that reuse the existing flooding machinery, so reach and reliability are the operator's to choose.
§2Extended TLVs
Standard IS-IS TLVs, and the standard sub-TLVs first introduced in RFC 5305, have an 8-bit type field and an 8-bit length field. This constrains the information in a single TLV or sub-TLV to 255 octets. With the increasing use of sub-TLVs, it becomes more likely that the information about a single object that has to be advertised exceeds 255 octets, and in that case the information is encoded in multiple TLVs. That is less efficient, because the information that identifies the object has to be repeated in each TLV, and it adds implementation complexity on the receiving side, which must ensure that all the information about the object has been collected from the multiple TLVs.
The RFC therefore introduces extended TLVs and extended sub-TLVs, encoded with a 16-bit type field and a 16-bit length field. Six restrictions apply to their use. They are permitted only in Flooding Scope packets that have a flooding scope designated for their use. A given flooding scope supports either the standard TLVs and sub-TLVs or the extended ones, but not both. Extended TLVs and extended sub-TLVs MUST be used together, so standard sub-TLVs inside an extended TLV, or extended sub-TLVs inside a standard TLV, are invalid. If further levels of TLVs are introduced in future, the size of the type and length fields in those new sub-types MUST match the size used in the parent. The 16-bit fields are encoded in network byte order. And their use does not alter in any way the maximum size of packet that may be sent or received.
Standard TLV and sub-TLV code points from the IANA IS-IS TLV Codepoints registry MAY be used in extended TLVs and extended sub-TLVs. The encoding is as specified for each of them, with three differences: the 8-bit type field is encoded as an unsigned 16-bit integer whose 8 most significant bits are all zero, the 8-bit length field is replaced by the 16-bit length field, and the length may take values greater than 255.
The information IS-IS carries is organised into type-length-value fields, and each one has a type number and a length that are each one byte long. That caps the contents of a single field at 255 bytes. When one object needs more description than that, the description is split across several fields, and the identifying part has to be repeated in each one, which wastes space and complicates the receiving code.
The extended form simply doubles the type and length fields to two bytes each, so one field can carry much more. The rules are strict: a scope uses either the short form or the long form, never a mixture, and the long form may only appear in the new flooding packets.
| Aspect | Standard TLV | Extended TLV |
|---|---|---|
| Type field | 8 bits | 16 bits, with the 8 most significant bits all zero for a standard code point |
| Length field | 8 bits | 16 bits |
| Maximum content | 255 octets | Greater than 255 octets |
| Where it may appear | Any IS-IS packet | Only in the new flooding scope packets, in a scope reserved for extended forms |
§3The Three New Packet Types
Three new packets are required to support the new flooding scopes: Flooding Scope LSPs, Flooding Scope Complete Sequence Number packets, and Flooding Scope Partial Sequence Number packets. Each is intentionally defined with a header as similar in format as possible to the corresponding packet type currently defined in IS-IS. Although it might have been possible to eliminate or redefine header fields in a new way, the existing formats are retained so that implementations can reuse as much of their existing packet processing logic as possible.
In all three, the Maximum Area Addresses field in the header of the corresponding standard packet has been replaced with a Scope field, so the maximum area address checks of IS-IS are not performed on these packets.
The FS-LSP carries the usual fixed header, with a PDU type of 10, followed by the FS LSP ID, which holds the system ID of the source in one of two formats: the standard format, with a source ID, a pseudonode ID and an FS LSP Number; or the extended format, with a source ID and a two-octet Extended FS LSP Number. Which format is used is specific to the scope and MUST be defined when that scope is defined. It then carries a sequence number, a checksum over the contents from the Source ID onwards, a byte whose bits hold the overload flag and the type of the Intermediate System, and the variable-length fields, which are specific to the scope.
The scope field holds seven bits of scope plus a priority bit. The value 0 is reserved and MUST NOT be used, and received FS-LSPs with a scope of 0 MUST be ignored and MUST NOT be flooded. If the priority bit is set, the LSP SHOULD be flooded at high priority. Scopes 1 to 63 are reserved for use with standard TLVs and standard sub-TLVs, and scopes 64 to 127 for use with extended TLVs and extended sub-TLVs.
The FS-CSNP has a PDU type of 11 and, besides the fixed header, carries the source ID, the FS LSP ID of the first FS-LSP with the specified scope in the range covered by the packet, and the FS LSP ID of the last one. The FS-PSNP has a PDU type of 12 and carries the source ID. Its scope field also has an unsupported bit, where a value of 1 means the specified flooding scope is unsupported, and in that case no variable-length field other than authentication may be included in the packet.
Three new kinds of packet are needed, and they deliberately look almost identical to the packets they sit alongside, so that the code which handles those can be reused. The one visible change is in the header: the field that says which area the packet belongs to is replaced by a field that says which flooding scope it belongs to.
Each carries the scope in seven bits, with one bit left over. In the link state packet that spare bit means flood this one at high priority, and in the partial sequence number packet it means this scope is not supported here.
The link state packet also carries an identifier for itself in one of two shapes. The short shape holds a one-byte number, the long one a two-byte number, which is what lets a router publish far more of them.
- 10FS-LSP — The flooding scope link state packet, carrying the information to be flooded.
- 11FS-CSNP — The flooding scope complete sequence number packet, used to summarise and to request the whole range of packets in a scope.
- 12FS-PSNP — The flooding scope partial sequence number packet, used to request specific packets and to say that a scope is not supported.
§4Running the Update Process for a New Scope
The Update Process maintains a Link State Database for each level it supports. Each level-specific database holds the full set of LSPs generated by all the routers operating in that level-specific scope. The introduction of FS-LSPs creates an additional database for each additional scope supported, holding the FS-LSPs generated by the routers operating in that scope. There is therefore 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 circuits on which FS-LSPs are flooded are limited to those circuits participating in the given scope, and the sending and receiving of FS-CSNPs and FS-PSNPs is limited to the circuits participating in that scope. Consistent support of a given flooding scope on a circuit by all the routers operating on that circuit is required.
On a point-to-point circuit, when a new adjacency is formed, the synchronisation of all the FS databases supported on that circuit is required, so FS-CSNPs for all supported scopes MUST be sent when the new adjacency reaches the UP state, and the Send Receive Message bit MUST be set for all the FS-LSPs associated with the scopes supported on that circuit. Receipt of an FS-PSNP with the unsupported bit equal to 1 indicates that the neighbour does not support that scope, although it does support the new packets, and this MUST cause the Send Receive Message bit to be cleared for all the FS-LSPs with the matching scope that are currently marked for flooding on that circuit.
On a broadcast circuit, the new packets are sent to the same destination addresses as the standard packets for the given protocol instance. The Designated Intermediate System has the responsibility to generate periodic scope-specific FS-CSNPs for all supported scopes. A scope-specific Designated Intermediate System is NOT elected, because all the routers on a circuit must support a consistent set of flooding scopes. It is possible for a scope to be defined that is not level specific, in which case the Designated Intermediate System for each level enabled on the circuit must independently send the new packets for that scope to the appropriate level-specific destination address, which may result in redundant flooding.
Authentication TLVs MAY be included in the new packets. When authentication is in use, the scope is used first to select the applicable authentication configuration, and the authentication check is then performed as normal; scope-specific authentication MAY be used, but sharing authentication among several scopes and with the standard packets is considered sufficient. When the extended identifier format is used, the set of LSPs generated by a router may be large, so the priority bit may be used to identify those that hold information of higher priority, and such LSPs SHOULD be flooded at a higher priority than those without it. When an LSP is purged, the original state of the priority bit MUST be preserved.
Every scope gets its own copy of the flooding machinery, its own database and its own set of rules, and the rules are the existing ones with the scope substituted for the level.
On a point-to-point link, the two routers synchronise their databases as soon as the link comes up, which means sending the summary packets for every scope the link supports. If the far end says it does not support one of the scopes, the near end stops trying to flood that scope on the link.
On a broadcast segment, the designated router takes responsibility for the periodic summary packets, and it is not elected for a scope, because every router on the segment has to agree on which scopes are in use.
§8The Scopes That Are Defined
A flooding scope may be limited to a single circuit, which is a circuit scope, and circuit scopes may be further limited by level, giving a Level 1 Circuit Scope and a Level 2 Circuit Scope. A scope may be limited to all the circuits enabled for Level 1 routing, which is an area scope, or to all the circuits enabled for Level 2 routing, which is the Level 2 subdomain scope. Additional scopes may be defined that include all the circuits enabled for either Level 1 or Level 2 routing, which is a domain scope.
The RFC defines four circuit scope flooding identifiers: Level 1 Circuit Scope, which uses standard TLVs and standard sub-TLVs; Level 2 Circuit Scope, on the same basis; Extended Level 1 Circuit Scope, which uses extended TLVs and extended sub-TLVs; and Extended Level 2 Circuit Scope, on the extended basis. FS-LSPs with the scope field set to one of these values contain information specific to the circuit on which they are flooded, and when received they MUST NOT be flooded on any other circuit. The extended identifier format is used in these packets. The database associated with circuit scope FS-LSPs consists of the set of FS-LSPs that both have matching circuit scopes and are transmitted locally or received on a specific circuit. The set of TLVs that may be included in such packets is specific to the use case and outside the scope of the document.
The RFC also uses the new packets to extend the LSP set capacity. When legacy interoperability is not a requirement, the use of FS-LSPs meets the need articulated in RFC 5311 without requiring alias system IDs to be assigned to a router. Four flooding scopes are defined for this purpose: Level 1 Flooding Scope and Level 2 Flooding Scope, using standard TLVs, and Extended Level 1 Flooding Scope and Extended Level 2 Flooding Scope, using extended TLVs. The Level 1 pair is flooded on all Level 1 circuits and the Level 2 pair on all Level 2 circuits. The extended identifier format is used in these packets, which provides 64 K of additional LSPs that may be generated by a single system at each level. These packets are used by the level-specific Decision Process in the same manner as standard LSPs, as additional information sourced by the same router, subject to three restrictions: a valid version of the standard LSP number 0 from the same router at the corresponding level MUST be present in the database for the set to be usable; information in an extended LSP that supports using the originating router as a transit node MUST NOT be used when the overload bit is set in the corresponding standard LSP number 0; and TLVs restricted to the standard LSP number 0 MUST NOT appear.
Domain scope flooding addresses the need to flood information throughout a domain, that is, to Level 1 routers in all areas as well as to routers in the Level 2 subdomain. Existing support for this uses leaking procedures between levels, which is sufficient when the data being flooded consists of individual TLVs. If it is desired to retain the identity of the originating router for the complete contents of a packet, then support for flooding the unchanged packet is desirable, and the RFC therefore defines two scopes for domain flooding: Domain Flooding Scope, using standard TLVs, and Extended Domain Flooding Scope, using extended TLVs. These packets MUST be flooded on all circuits regardless of what levels are supported on that circuit.
Using information in a domain scope FS-LSP depends on determining the reachability of the router that originated it, and no single router has the full view of the topology across all areas. The originator must therefore advertise an identifier that lets a receiving router decide whether the source is currently reachable. When IS-IS is deployed in support of Layer 3 routing for IPv4 or IPv6, the domain scoped FS-LSP number 0 MUST include at least one of the IPv4 Traffic Engineering Router ID, TLV 134, or the IPv6 Traffic Engineering Router ID, TLV 140. When IS-IS is deployed for Layer 2 routing, current standards support only a single area, so domain scope is not yet applicable.
Four kinds of scope are defined, and each comes in two versions: one that uses the short type and length fields and one that uses the long ones. The version with the long fields has a scope number between 64 and 127.
A circuit scope reaches only the routers on one segment, and information sent in it never leaves that segment. A level scope reaches every router at that level, and it is what lets a router publish far more link state packets than the standard 256, because each packet's identifier has two bytes instead of one.
A domain scope reaches everything, across all the areas and the Level 2 part. The catch is that no single router knows the whole topology, so the originator has to include an identifier that lets the receivers work out whether it is still reachable.
- 1Level 1 Circuit Flooding Scope — Standard TLVs and sub-TLVs.
- 2Level 2 Circuit Flooding Scope — Standard TLVs and sub-TLVs.
- 3Level 1 Flooding Scope — Standard TLVs and sub-TLVs.
- 4Level 2 Flooding Scope — Standard TLVs and sub-TLVs.
- 5Domain Flooding Scope — Standard TLVs and sub-TLVs.
- 64Level 1 Circuit Flooding Scope — Extended TLVs and sub-TLVs.
- 65Level 2 Circuit Flooding Scope — Extended TLVs and sub-TLVs.
- 66Level 1 Flooding Scope — Extended TLVs and sub-TLVs.
- 67Level 2 Flooding Scope — Extended TLVs and sub-TLVs.
- 68Domain Flooding Scope — Extended TLVs and sub-TLVs.
- Circuit scopeLimited to the routers on a single circuit, and further limited by level. Information in it is never flooded on any other circuit.
- Area scopeLimited to all the circuits enabled for Level 1 routing.
- Level 2 subdomain scopeLimited to all the circuits enabled for Level 2 routing.
- Domain scopeIncludes all the circuits enabled for either Level 1 or Level 2 routing, so it crosses every area of the domain.
§5Deployment and Announcing Support
The introduction of new packet types is incompatible with legacy implementations. Legacy implementations do not support the scope-specific Update Process, so flooding of the FS-LSPs throughout the defined scope is unreliable when not all the routers in the scope support the new packets, and legacy implementations will likely treat the receipt of one of the new packets as an error. Even when all the routers in a given scope support the new packets, if not all the routers in the flooding domain for that scope support the scope itself, flooding may be compromised. Correct operation therefore requires that both the new packets and the new scope be supported by all the routers in the flooding domain of the new scope.
The unsupported bit in the FS-PSNP provides a means to suppress retransmissions of unsupported scopes. Routers that support the new packets SHOULD support sending an FS-PSNP with the unsupported bit equal to 1 when an FS-LSP is received with an unsupported scope, and SHOULD trigger management notifications when the new packets are received for unsupported scopes and when an FS-PSNP with the unsupported bit equal to 1 is received.
Announcements of support for a flooding scope may be useful in validating that full support has been deployed, and in isolating the reasons for incomplete flooding of FS-LSPs for a given scope. Routers supporting the new packets MAY announce the supported scopes in the Hello packets, using a new TLV called Scope Flooding Support, of type 243 and length 1 to 127, whose value is a list of supported scopes, one octet each. In a point-to-point Hello, the Level 1, Level 2, domain and all circuit scopes may be advertised. In a Level 1 LAN Hello, the Level 1, domain and Level 1 circuit scopes may be advertised, and the Level 2 scopes MUST NOT be. In a Level 2 LAN Hello, the Level 2, domain and Level 2 circuit scopes may be advertised, and the Level 1 scopes MUST NOT be. Information in this TLV MUST NOT be considered in adjacency formation, and whether it is used to decide when FS-LSPs of a locally supported scope are flooded is an implementation choice.
The new packets are not understood by older routers, and an older router will probably treat receiving one as an error. So every router that has to be reached by a new scope has to be running the new code before that scope is used, and not only the routers in the scope itself but the whole flooding domain around it.
Two mechanisms help an operator find out what is wrong. A router that receives a packet for a scope it does not support can send back a message saying so, which stops the sender repeating the flood. And each router can list the scopes it supports in its Hello packets, so an operator can compare the lists and see where the gaps are.
§13Security Considerations
Security concerns for IS-IS are addressed in IS-IS itself, in RFC 5304 and in RFC 5310. The new packets introduced are subject to the same security issues as their standard counterparts, and to the extent that the additional packets represent additional load for the routers in the network, they increase the opportunity for denial-of-service attacks.
The new packets carry the same kind of information and are authenticated in the same way as the packets they replace, so they carry the same risks. The one extra risk is that there are more of them, and more traffic to flood is more traffic for an attacker to aim at.