One document matched: draft-ginsberg-isis-rfc4971bis-00.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-ginsberg-isis-rfc4971bis-00.txt"
ipr="pre5378Trust200902">
<front>
<title abbrev="isis-rfc4971bis">IS-IS Extensions for Advertising Router
Info</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="Mach (Guoyi) Chen" initials="M" surname="Chen">
<organization>Huawei Technologies Co., Ltd</organization>
<address>
<postal>
<street>KuiKe Building, No. 9 Xinxi Rd. Hai-Dian District</street>
<city>Beijing</city>
<code>100085</code>
<country>P.R. China</country>
</postal>
<email>mach.chen@huawei.com</email>
</address>
</author>
<date day="7" month="October" year="2015"/>
<area>Routing Area</area>
<workgroup>Networking Working Group</workgroup>
<keyword>Sample</keyword>
<abstract>
<t>This document defines a new optional Intermediate System to
Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple
sub-TLVs, which allows a router to announce its capabilities within an
IS-IS level or the entire routing domain.</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>There are several situations where it is useful for the IS-IS
[ISO10589] [RFC1195] routers to learn the capabilities of the other
routers of their IS-IS level, area, or routing domain. For the sake of
illustration, three examples related to MPLS Traffic Engineering (TE)
are described here:</t>
<t><list style="numbers">
<t>Mesh-group: the setting up of a mesh of TE Label Switched Paths
(LSPs) [RFC5305] requires some significant configuration effort.
[RFC4972] proposes an auto-discovery mechanism whereby every Label
Switching Router (LSR) of a mesh advertises its mesh-group
membership by means of IS-IS extensions.</t>
<t>Point to Multipoint TE LSP (RFC4875). A specific sub-TLV
[RFC5073] allows an LSR to advertise its Point To Multipoint
capabilities ([RFC4875] and [RFC4461]).</t>
<t>Inter-area traffic engineering: Advertisement of the IPv4 and/or
the IPv6 Traffic Engineering Router IDs.</t>
</list></t>
<t>The use of IS-IS for Path Computation Element (PCE) discovery may
also be considered and will be discussed in the PCE WG.</t>
<t>The capabilities mentioned above require the specification of new
sub-TLVs carried within the CAPABILITY TLV defined in this document.</t>
<t>Note that the examples above are provided for the sake of
illustration. This document proposes a generic capability advertising
mechanism that is not limited to MPLS Traffic Engineering.</t>
<t>This document defines a new optional IS-IS TLV named CAPABILITY,
formed of multiple sub-TLVs, which allows a router to announce its
capabilities within an IS-IS level or the entire routing domain. The
applications mentioned above require the specification of new sub- TLVs
carried within the CAPABILITY TLV defined in this document.</t>
<t>Definition of these sub-TLVs is outside the scope of this
document.</t>
</section>
<section title="IS-IS Router CAPABILITY TLV">
<t>The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type,
1 octet that specifies the number of bytes in the value field, and a
variable length value field that starts with 4 octets of Router ID,
indicating the source of the TLV, and followed by 1 octet of flags.</t>
<t>A set of optional sub-TLVs may follow the flag field. Sub-TLVs are
formatted as described in [RFC5305].</t>
<t><figure>
<artwork><![CDATA[ TYPE: 242
LENGTH: from 5 to 255
VALUE:
Router ID (4 octets)
Flags (1 octet)
Set of optional sub-TLVs (0-250 octets)
Flags
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |D|S|
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>Currently two bit flags are defined.</t>
<t>S bit (0x01): If the S bit is set(1), the IS-IS Router CAPABILITY TLV
MUST be flooded across the entire routing domain. If the S bit is not
set(0), the TLV MUST NOT be leaked between levels. This bit MUST NOT be
altered during the TLV leaking.</t>
<t>D bit (0x02): When the IS-IS Router CAPABILITY TLV is leaked from
level-2 to level-1, the D bit MUST be set. Otherwise, this bit MUST be
clear. IS-IS Router capability TLVs with the D bit set MUST NOT be
leaked from level-1 to level-2. This is to prevent TLV looping.</t>
<t>The Router CAPABILITY TLV is OPTIONAL. As specified in Section 3,
more than one Router CAPABILITY TLV from the same source MAY be
present.</t>
<t>This document does not specify how an application may use the Router
Capability TLV and such specification is outside the scope of this
document.</t>
</section>
<section anchor="IANA" title="Elements of Procedure">
<t>The Router ID SHOULD be identical to the value advertised in the
Traffic Engineering Router ID TLV [RFC5305]. If no Traffic Engineering
Router ID is assigned the Router ID SHOULD be identical to an IP
Interface Address [RFC1195] advertised by the originating IS. If the
originating node does not support IPv4, then the reserved value 0.0.0.0
MUST be used in the Router ID field and the IPv6 TE Router ID sub-TLV
[RFC5316] MUST be present in the TLV. Router CAPABILITY TLVs which have
a Router ID of 0.0.0.0 and do NOT have the IPv6 TE Router ID sub-TLV
present MUST be ignored.</t>
<t>When advertising capabilities with different flooding scopes, a
router MUST originate a minimum of two Router CAPABILITY TLVs, each TLV
carrying the set of sub-TLVs with the same flooding scope. For instance,
if a router advertises two sets of capabilities, C1 and C2, with an
area/level scope and routing domain scope respectively, C1 and C2 being
specified by their respective sub-TLV(s), the router will originate two
Router CAPABILITY TLVs:</t>
<t><figure>
<artwork><![CDATA[ - One Router CAPABILITY TLV with the S flag cleared, carrying the
sub-TLV(s) relative to C1. This Router CAPABILITY TLV will not be
leaked into another level.
- One Router CAPABILITY TLV with the S flag set, carrying the sub-
TLV(s) relative to C2. This Router CAPABILITY TLV will be leaked
into other IS-IS levels. When the TLV is leaked from level-2 to
level-1, the D bit will be set in the level-1 LSP advertisement.
]]></artwork>
</figure></t>
<t>In order to prevent the use of stale capabilities, a system MUST NOT
use a Capability TLV present in an LSP of a system that is not currently
reachable via Level-x paths, where "x" is the level (1 or 2) in which
the sending system advertised the TLV. This requirement applies
regardless of whether or not the sending system is the originator of the
Capabilities TLV. Note that leaking a Capabilities TLV is one of the
uses that is prohibited under these conditions.</t>
<t><figure>
<artwork><![CDATA[ Example: If Level-1 router A generates a Capability TLV and floods
it to two L1/L2 routers, S and T, they will flood it into the
Level-2 domain. Now suppose the Level-1 area partitions, such
that A and S are in one partition and T is in another. IP routing
will still continue to work, but if A now issues a revised version
of the CAP TLV, or decides to stop advertising it, S will follow
suit, but T will continue to advertise the old version until the
LSP times out.]]></artwork>
</figure></t>
<t>Routers in other areas have to choose whether to trust T's copy of
A's capabilities or S's copy of A's information and, they have no
reliable way to choose. By making sure that T stops leaking A's
information, this removes the possibility that other routers will use
stale information from A.</t>
<t>In IS-IS, the atomic unit of the update process is a TLV - or more
precisely, in the case of TLVs that allow multiple entries to appear in
the value field (e.g., IS-neighbors), the atomic unit is an entry in the
value field of a TLV. If an update to an entry in a TLV is advertised in
an LSP fragment different from the LSP fragment associated with the old
advertisement, the possibility exists that other systems can temporarily
have either 0 copies of a particular advertisement or 2 copies of a
particular advertisement, depending on the order in which new copies of
the LSP fragment that had the old advertisement and the fragment that
has the new advertisement arrive at other systems.</t>
<t>Wherever possible, an implementation SHOULD advertise the update to a
capabilities TLV in the same LSP fragment as the advertisement that it
replaces. Where this is not possible, the two affected LSP fragments
should be flooded as an atomic action.</t>
<t>Systems that receive an update to an existing capability TLV can
minimize the potential disruption associated with the update by
employing a holddown time prior to processing the update so as to allow
for the receipt of multiple LSP fragments associated with the same
update prior to beginning processing.</t>
<t>Where a receiving system has two copies of a capabilities TLV from
the same system that have different settings for a given attribute, the
procedure used to choose which copy shall be used is undefined.</t>
</section>
<section title="Interoperability with Routers Not Supporting the Capability TLV">
<t>Routers that do not support the Router CAPABILITY TLV MUST silently
ignore the TLV(s) and continue processing other TLVs in the same LSP.
Routers that do not support specific sub-TLVs carried within a Router
CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs and
continue processing those sub-TLVs that are supported in the Router
CAPABILITY TLV. How partial support may impact the operation of the
capabilities advertised within the Router CAPABILITY TLV is outside the
scope of this document.</t>
<t>In order for Router CAPABILITY TLVs with domain-wide scope originated
by L1 Routers to be flooded across the entire domain, at least one L1/L2
Router in every area of the domain MUST support the Router CAPABILITY
TLV.</t>
<t>If leaking of the CAPABILITY TLV is required, the entire CAPABILITY
TLV MUST be leaked into another level even though it may contain some of
the unsupported sub-TLVs.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Any new security issues raised by the procedures in this document
depend upon the opportunity for LSPs to be snooped and modified, the
ease/difficulty of which has not been altered. As the LSPs may now
contain additional information regarding router capabilities, this new
information would also become available to an attacker. Specifications
based on this mechanism need to describe the security considerations
around the disclosure and modification of their information. Note that
an integrity mechanism, such as the one defined in [RFC5304] or
[RFC5310], should be applied if there is high risk resulting from
modification of capability information.</t>
</section>
<section title="IANA Considerations">
<t>IANA assigned a new IS-IS TLV code-point for the newly defined IS-IS
TLV type named the IS-IS Router CAPABILITY TLV and defined in this
document. The assigned value is 242.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>For the original version of RFC 4971 the authors thanked Jean-Louis
Le Roux, Paul Mabey, Andrew Partan, and Adrian Farrel for their useful
comments.</t>
<t>For this new version the authors would like to thank Kris Michielsen
for calling the problem associated w an IPv6 only router to our
attention.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.1195"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.5073'?>
<?rfc include='reference.RFC.5304'?>
<?rfc include='reference.RFC.5305'?>
<?rfc include='reference.RFC.5310'?>
<?rfc include='reference.RFC.5316'?>
<reference anchor="ISO10589">
<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)</title>
<author>
<organization abbrev="ISO">International Organization for
Standardization</organization>
</author>
<date month="Nov" year="2002"/>
</front>
<seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>
</reference>
</references>
<references title="Informational References">
<?rfc include='reference.RFC.4461'?>
<?rfc include='reference.RFC.4875'?>
<?rfc include='reference.RFC.4972'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:07:20 |