One document matched: draft-ietf-isis-fs-lsp-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-isis-fs-lsp-01.txt"
ipr="pre5378Trust200902">
<front>
<title abbrev="draft-ietf-isis-fs-lsp-01.txt">IS-IS Flooding Scope
LSPs</title>
<author fullname="Les Ginsberg" initials="L" surname="Ginsberg">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>510 McCarthy Blvd.</street>
<city>Milpitas</city>
<code>95035</code>
<region>CA</region>
<country>USA</country>
</postal>
<email>ginsberg@cisco.com</email>
</address>
</author>
<author fullname="Stefano Previdi" initials="S" surname="Previdi">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Via Del Serafico 200</street>
<city>Rome</city>
<code>0144</code>
<country>Italy</country>
</postal>
<email>sprevidi@cisco.com</email>
</address>
</author>
<author fullname="Yi Yang" initials="Y" surname="Yang">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>7100-9 Kit Creek Road</street>
<city>Research Triangle Park</city>
<code>27709-4987</code>
<region>North Carolina</region>
<country>USA</country>
</postal>
<email>yiya@cisco.com</email>
</address>
</author>
<date day="07" month="October" year="2013"/>
<area>Routing Area</area>
<workgroup>Networking Working Group</workgroup>
<keyword>Sample</keyword>
<abstract>
<t>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 wide scope or domain wide
scope. There are existing use cases where support of other flooding
scopes are desirable. This document defines new Protocol Data Units
(PDUs) which 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 TLVs and
sub-TLVs which are encoded using 16 bit fields for type and length.</t>
<t>The protocol extensions defined in this document are not backwards
compatible with existing implementations and so must be deployed with
care.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>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 Protocol Data Units (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 sub-domain. 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 which the Update Process currently provides
for L1 and L2 scopes. This document defines these new PDUs and the
modified Update Process rules which are to be used in supporting new
flooding scopes.</t>
<t>New deployment cases have introduced the need for reliable and
efficient circuit scoped flooding. For example, Appointed Forwarder
information as defined in [RFC6326] needs to be flooded reliably and
efficiently to all RBridges on a broadcast circuit. Currently, only
Intermediate System to Intermediate System 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 scoped
flooding in order to provide a solution for such cases.</t>
<t>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 which can be used to overcome
this limitation if needed. While the [RFC5311] solution is viable, in
order to be interoperable with routers which 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.
As the introduction of new PDUs required to support new flooding scopes
is by definition not interoperable with legacy routers, it is possible
to simultaneously introduce an alternative solution to the limited LSP
set carrying capacity as part of the extensions defined in this
document. This capability is also defined in this document.</t>
<t>Standard IS-IS TLVs (Type/Length/Value) are encoded using an eight
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 which use a 16 bit type field and a
16 bit length field.</t>
<t>The PDU type field in the common header for all IS-IS PDUs is a 5 bit
field. The possible PDU types supported by the protocol are therefore
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.</t>
</section>
<section title="Extended TLVs">
<t>Standard TLVs as defined in [IS-IS] as well as standard sub-TLVs
(first introduced in [RFC5305]) have an eight 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 which 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 which uniquely identifes 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.</t>
<t>This document introduces extended TLVs and extended sub-TLVs. These
are encoded using a 16 bit type field and a 16 bit length field.</t>
<section title="Use of Extended TLVs and Extended sub-TLVs">
<t>The following restrictions apply to the use of extended TLVs and
extended sub-TLVs:</t>
<t><list style="symbols">
<t>Extended TLVs and extended sub-TLVs are permitted only in
Flooding Scoped PDUs which have a flooding scope designated for
their use (defined later in this document)</t>
<t>A given flooding scope supports the use of either standard TLVs
and standard sub-TLVs or the use of extended TLVs and extended
sub-TLVs but not both</t>
<t>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</t>
<t>If additional levels of TLVs (e.g., sub-sub-TLVs) are
introduced in the future then the size of the type/length fields
in these new sub-types MUST match the size used in the parent</t>
<t>The 16 bit type and length fields are encoded in network byte
order</t>
<t>Use of extended TLVs and extended sub-TLVs does not alter in
any way the maximum size of PDUs which may sent or received</t>
</list></t>
</section>
<section title="Use of Standard Code Points in Extended TLVs and Extended sub-TLVs">
<t>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:</t>
<t><list style="symbols">
<t>The eight bit type is encoded as an unsigned 16 bit integer</t>
<t>The eight bit length field is replaced by the 16 bit length
field</t>
<t>The length MAY take on values greater than 255</t>
</list></t>
</section>
</section>
<section title=" Definition of New PDUs">
<t>In support of new flooding scopes the following new PDUs are
required:</t>
<t><list style="symbols">
<t>Flooding Scoped LSPs (FS-LSPs)</t>
<t>Flooding Scoped Complete Sequence Number PDUs (FS-CSNPs)</t>
<t>Flooding Scoped Partial Sequence Number PDUs (FS-PSNPs)</t>
</list></t>
<t>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.</t>
<t>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. The maximum area addresses checks specified in
[IS-IS] are therefore not performed on FS PDUs.</t>
<section title="Flooding Scoped LSP Format">
<t>An FS-LSP has the following format:</t>
<t><figure>
<artwork><![CDATA[ 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 (Subject to assignment by IANA) 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.
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 TLV and
extended sub-TLVss.
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 Source ID to 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 which are allowed in an FS-LSP are specific to
the defined scope.
]]></artwork>
</figure></t>
</section>
<section title="Flooding Scoped CSNP Format">
<t>An FS-CSNP has the following format:</t>
<figure>
<artwork><![CDATA[ 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 (Subject to assignment by IANA) 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-TLVss.
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 Numbers 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 which are allowed in an FS-CSNP are
limited to those TLVs which are supported by standard CSNP.
]]></artwork>
</figure>
<t/>
</section>
<section title="Flooding Scope PSNP Format">
<t>An FS-PSNP has the following format:</t>
<figure>
<artwork><![CDATA[ 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 (Subject to assignment by IANA) 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 TLV and
extended sub-TLVss.
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 Numbers PDU
Variable Length Fields which are allowed in an FS-PSNP are
limited to those TLVs which are supported by standard PSNPs.
]]></artwork>
</figure>
</section>
</section>
<section title="Flooding Scope Update Process Operation">
<t>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. There is therefore an additional instance of
the Update Process for each supported flooding scope.</t>
<t>Operation of the scope specific Update Process follows the Update
Process specification in [IS-IS]. The circuit(s) on which FS-LSPs are
flooded are limited to those circuits which 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.</t>
<t>Consistent support of a given flooding scope on a circuit by all
routers operating on that circuit is required.</t>
<section title="Scope Types">
<t>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).</t>
<t>A flooding scope may be limited to all circuits enabled for L1
routing (area scope).</t>
<t>A flooding scope may be limited to all circuits enabled for L2
routing (L2 sub-domain scope).</t>
<t>Additional scopes may be defined which include all circuits enabled
for either L1 or L2 routing (domain-wide scope).</t>
</section>
<section title="Operation on Point-to-Point Circuits">
<t>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. 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
SRM bit to be cleared for all FS-LSPs with the matching scope which
are currently marked for flooding on that circuit.</t>
</section>
<section title="Operation on Broadcast Circuits">
<t>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].</t>
<t>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.</t>
<t>It is possible that a scope may be defined which 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.</t>
</section>
<section title="Use of Authentication">
<t>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 LSP/CSNP/PSNP PDUs is considered sufficient.</t>
</section>
<section title="Priority Flooding">
<t>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 which 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.</t>
</section>
</section>
<section title="Deployment Considerations">
<t>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 PDUs 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 flooding of the FS-LSPs may be
compromised. Therefore all routers in the flooding domain for a given
scope SHOULD support both FS PDUs and the specified scope before use of
that scope can be enabled.</t>
<t>The U bit in FS-PSNPs provides a means to suppress retransmissions of
unsupported scopes. Routers which 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 which is unsupported. Routers which 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.</t>
</section>
<section title="Graceful Restart Interactions">
<t>[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.</t>
</section>
<section title="Multi-instance Interactions">
<t>In cases where FS-PDUs are associated with a non-zero instance the
use of IID-TLVs in FS-PDUs follows the rules for use in LSPs, CSNPs,
PSNPs as defined in [RFC6822].</t>
</section>
<section title="Circuit Scoped Flooding">
<t>This document defines four circuit scoped flooding identifiers:</t>
<t><list style="symbols">
<t>Level 1 circuit scope (L1CS) - this uses standard TLVs and
standard sub-TLVs</t>
<t>Level 2 circuit scope (L2CS) - this uses standard TLVs and
standard sub-TLVs</t>
<t>Extended Level 1 circuit scope (E-L1CS) - this uses extended TLVs
and extended sub-TLVs</t>
<t>Extended Level 2 circuit scope (E-L1CS) - this uses extended TLVs
and extended sub-TLVs</t>
</list></t>
<t>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 scoped FS-LSPs consists of the set of FS-LSPs which both
have matching circuit scope and are transmitted (locally generated) or
received on a specific circuit.</t>
<t>The set of TLVs which may be included in such FS-LSPs is specific to
the given use case and is outside the scope of this document.</t>
</section>
<section title="Extending LSP Set Capacity">
<t>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:</t>
<t><list style="symbols">
<t>Level 1 Scope (L1FS) - this uses standard TLVs and standard
sub-TLVs</t>
<t>Level 2 Scope (L2FS) - this uses standard TLVs and standard
sub-TLVs</t>
<t>Extended Level 1 Scope (E-L1FS) - this uses extended TLVs and
extended sub-TLVs</t>
<t>Extended Level 2 Scope (E-L2FS) - this uses extended TLVs and
extended sub-TLVs</t>
</list></t>
<t>L1FS and E-L1FS LSPs are flooded on all L1 circuits. L2FS and E-L2FS
LSPs are flooded on all L2 circuits.</t>
<t>The FS LSP ID Extended format is used in these PDUs. This provides
64K of additional LSPs which may be generated by a single system at each
level.</t>
<t>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:</t>
<t><list style="symbols">
<t>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 set to be usable</t>
<t>Information in an LxFS LSP (e.g. IS-Neighbor information) which
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</t>
<t>TLVs which are restricted to standard LSP #0 MUST NOT appear in
LxFS LSPs.</t>
</list></t>
<t>There are no further restrictions as to what TLVs may be advertised
in FS-LSPs.</t>
</section>
<section title="Domain Scoped Flooding">
<t>Existing support for flooding information domain wide (i.e. to L1
routers in all areas as well as to routers in the Level 2 sub-domain)
requires the use of leaking procedures between levels. For further
details see [RFC4971]. This is sufficient when the data being flooded
domain-wide 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-wide
flooding. FS-LSPs with this scope MUST be flooded on all circuits
regardless of what level(s) are supported on that circuit.</t>
<t><list style="symbols">
<t>Domain Scope (DSFS) - this uses standard TLVs and standard
sub-TLVs</t>
<t>Extended Domain Scope (E-DSFS) - this uses extended TLVs and
extended sub-TLVs</t>
</list></t>
<t>The FS LSP ID Extended format is used in these PDUs.</t>
<t>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 scoped DSFS and E-DSFS LSPs to
advertise an identifier which 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.</t>
<t>When IS-IS is deployed in support of Layer 3 routing for IPv4 and/or
IPv6 then FS-LSP #0 with domain-wide scope MUST include at least one of
the following TLVs:</t>
<t><list style="symbols">
<t>IPv4 Traffic Engineering Router ID (TLV 134)</t>
<t>IPv6 Traffic Engineering Router ID (TLV 140)</t>
</list></t>
<t>When IS-IS is deployed in support of Layer 2 routing, current
standards (e.g. [RFC6325]) only support a single area. Therefore
domain-wide scope is not yet applicable. When the Layer 2 standards are
updated to include multi-area support the identifiers which can be used
to support inter-area reachability will be defined - at which point the
use of domain-wide scope for Layer 2 can be fully defined.</t>
</section>
<section title="Announcing Support for Flooding Scopes">
<t>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.</t>
<t>ISs supporting FS-PDUs MAY announce supported scopes in IIH PDUs. To
do so a new TLV is defined.</t>
<t><figure>
<artwork><![CDATA[Scoped Flooding Support
Type: 243 (suggested - to be assigned by IANA)
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-Point IIH L1, L2 and domain-wide scopes MAY
be advertised.
In Level 1 LAN IIHs L1 and domain-wide scopes MAY be advertised.
In Level 2 LAN IIHs L2 and domain-wide scopes MAY be advertised.
]]></artwork>
</figure></t>
<t>Information in this TLV MUST NOT be considered in adjacency
formation.</t>
<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.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document requires the definition of three new PDU types that
need to be reflected in the ISIS PDU registry. Values below are
suggested values subject to assignment by IANA.</t>
<figure>
<artwork><![CDATA[
Value Description
---- ---------------------
10 FS-LSP
11 FS-CSNP
12 FS-PSNP
]]></artwork>
</figure>
<t>This document requires that a new IANA registry be created to control
the assignment of scope identifiers in FS-PDUs. The registration
procedure is "Expert Review" as defined in [RFC5226]. Suggested registry
name is "LSP Flooding Scoped Identifier Registry". A scope identifier is
a number from 1-127 inclusive. Values 1 - 63 are reserved for PDUs which
use standard TLVs and standard sub-TLVs. Values 64 - 127 are reserved
for PDUs which use extended TLVs and extended sub-TLVs. The following
scope identifiers are defined by this document. Values are suggested
values subject to assignment by IANA.</t>
<figure>
<artwork><![CDATA[
Value Description FS LSP ID Format TLV Format
----- ------------------------------ ---------------- ----------
1 Level 1 Circuit Flooding Scope Extended Standard
2 Level 2 Circuit Flooding Scope Extended Standard
3 Level 1 Flooding Scope Extended Standard
4 Level 2 Flooding Scope Extended Standard
5 Domain-wide Flooding Scope Extended Standard
64 Level 1 Circuit Flooding Scope Extended Extended
65 Level 2 Circuit Flooding Scope Extended Extended
66 Level 1 Flooding Scope Extended Extended
67 Level 2 Flooding Scope Extended Extended
68 Domain-wide Flooding Scope Extended Extended
]]></artwork>
</figure>
<t>This document requires the definition of a new IS-IS TLV to be
reflected in the "IS-IS TLV Codepoints" registry:</t>
<t><figure>
<artwork><![CDATA[Type Description IIH LSP SNP Purge
---- ------------ --- --- --- -----
243 Circuit Scoped Flooding Support Y N N N
]]></artwork>
</figure></t>
<t>The IANA TLV codepoints registry is 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.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Security concerns for IS-IS are addressed in [IS-IS], [RFC5304], and
[RFC5310].</t>
<t>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.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors wish to thank Ayan Banerjee, Donald Eastlake, Hannes
Gredler, and Mike Shand for their comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.4971'?>
<?rfc include='reference.RFC.5226'?>
<?rfc include='reference.RFC.5304'?>
<?rfc include='reference.RFC.5305'?>
<?rfc include='reference.RFC.5306'?>
<?rfc include='reference.RFC.5310'?>
<?rfc include='reference.RFC.6822'?>
<?rfc ?>
<reference anchor="IS-IS">
<front>
<title>Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in conjunction with
the protocol for providing the connectionless-mode Network Service
(ISO 8473), ISO/IEC 10589:2002, Second Edition.</title>
<author fullname="ISO "International Organization for Standardization""/>
<date month="Nov" year="2002"/>
</front>
</reference>
<reference anchor="IEEEaq">
<front>
<title>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, 29
June 2012.</title>
<author fullname="IEEE "Institute of Electrical and Electronics Engineers""/>
<date year="2012"/>
</front>
</reference>
</references>
<references title="Informational References">
<?rfc include='reference.RFC.5311'?>
<?rfc include='reference.RFC.6325'?>
<?rfc include='reference.RFC.6326'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 23:05:39 |