rfc9346xml2.original.xml   rfc9346.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc [
<?rfc toc="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocompact="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc tocdepth="3"?> <!ENTITY nbhy "&#8209;">
<?rfc tocindent="yes"?> <!ENTITY wj "&#8288;">
<?rfc symrefs="yes"?> ]>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<?rfc inline="yes"?> std"
<?rfc compact="yes"?> consensus="true" docName="draft-ietf-lsr-isis-rfc5316bis-07" number="9346" ipr="
<?rfc subcompact="no"?> trust200902" obsoletes="5316" updates="" xml:lang="en" tocInclude="true" tocDept
<rfc category="std" docName="draft-ietf-lsr-isis-rfc5316bis-07" h="3"
ipr="trust200902" obsoletes="5316"> symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.15.0 -->
<front> <front>
<title abbrev="ISIS Extensions for Inter-AS TE">IS-IS Extensions in <title abbrev="IS-IS Extensions for Inter-AS TE">IS-IS Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic
Engineering</title> Engineering</title>
<seriesInfo name="RFC" value="9346"/>
<author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen"> <author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<email>mach.chen@huawei.com</email> <email>mach.chen@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Les Ginsberg" initials="L." surname="Ginsberg"> <author fullname="Les Ginsberg" initials="L." surname="Ginsberg">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<email>ginsberg@cisco.com</email> <email>ginsberg@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Stefano Previdi" initials="S." surname="Previdi"> <author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<code/> <code/>
<country>Italy</country>
<country>IT</country>
</postal> </postal>
<email>stefano@previdi.net</email> <email>stefano@previdi.net</email>
</address> </address>
</author> </author>
<author fullname="Xiaodong Duan" initials="X." surname="Duan">
<author fullname="Xiaodong Duan" initials="D." surname="Xiaodong">
<organization>China Mobile</organization> <organization>China Mobile</organization>
<address> <address>
<email>duanxiaodong@chinamobile.com</email> <email>duanxiaodong@chinamobile.com</email>
</address> </address>
</author> </author>
<date year="2023" month="January"/>
<date year="2022"/> <area>rtg</area>
<workgroup>lsr</workgroup>
<area>LSR Working Group</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>ISIS</keyword> <keyword>ISIS</keyword>
<keyword>Inter-AS</keyword> <keyword>Inter-AS</keyword>
<keyword>TE</keyword> <keyword>TE</keyword>
<abstract> <abstract>
<t>This document describes extensions to the Intermediate System to <t>This document describes extensions to the Intermediate System to
Intermediate System (IS-IS) protocol to support Multiprotocol Label Intermediate System (IS-IS) protocol to support Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE)
for multiple Autonomous Systems (ASs). It defines IS-IS extensions for for multiple Autonomous Systems (ASes). It defines IS-IS extensions for
the flooding of TE information about inter-AS links, which can be used the flooding of TE information about inter-AS links, which can be used
to perform inter-AS TE path computation.</t> to perform inter-AS TE path computation.</t>
<t>No support for flooding information from within one AS to another AS <t>No support for flooding information from within one AS to another AS
is proposed or defined in this document.</t> is proposed or defined in this document.</t>
<t> This document builds on RFC 5316 by adding support for IPv6-only <t> This document builds on RFC 5316 by adding support for IPv6-only
operation.</t> operation.</t>
<t>This document obsoletes RFC 5316.</t> <t>This document obsoletes RFC 5316.</t>
</abstract> </abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
they appear in all capitals, as shown here.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="INTRO" title="Introduction"> <section anchor="INTRO" numbered="true" toc="default">
<t><xref target="RFC5305"/> defines extensions to the IS-IS protocol <name>Introduction</name>
<xref target="RFC1195"/> to support intra-area Traffic Engineering (TE). <t><xref target="RFC5305" format="default"/> defines extensions to the IS-
IS protocol
<xref target="RFC1195" format="default"/> to support intra-area Traffic En
gineering (TE).
The extensions provide a way of encoding the TE information for The extensions provide a way of encoding the TE information for
TE-enabled links within the network (TE links) and flooding this TE-enabled links within the network (TE links) and flooding this
information within an area. The extended IS reachability TLV and traffic information within an area. The extended IS reachability TLV and Traffic
engineering router ID TLV, which are defined in <xref Engineering router ID TLV, which are defined in <xref target="RFC5305" for
target="RFC5305"/>, are used to carry such TE information. The extended mat="default"/>, are used to carry such TE information. The extended
IS reachability TLV has several nested sub-TLVs that describe the TE IS reachability TLV has several nested sub-TLVs that describe the TE
attributes for a TE link.</t> attributes for a TE link.</t>
<t><xref target="RFC6119" format="default"/> and <xref target="RFC5307" fo
<t><xref target="RFC6119"/> and <xref target="RFC5307"/> define similar rmat="default"/> define similar
extensions to IS-IS in support of IPv6 and Generalized Multiprotocol extensions to IS-IS in support of IPv6 and
Label Switching (GMPLS) TE respectively.</t> GMPLS TE, respectively.</t>
<t>Requirements for establishing Multiprotocol Label Switching (MPLS) TE <t>Requirements for establishing Multiprotocol Label Switching (MPLS) TE
Label Switched Paths (LSPs) that cross multiple Autonomous Systems Label Switched Paths (LSPs) that cross multiple Autonomous Systems
(ASes) are described in <xref target="RFC4216"/>. As described in <xref (ASes) are described in <xref target="RFC4216" format="default"/>. As desc
target="RFC4216"/>, a method SHOULD provide the ability to compute a ribed in <xref target="RFC4216" format="default"/>, a method <bcp14>SHOULD</bcp1
4> provide the ability to compute a
path spanning multiple ASes. So a path computation entity that may be path spanning multiple ASes. So a path computation entity that may be
the head-end Label Switching Router (LSR), an AS Border Router (ASBR), the head-end Label Switching Router (LSR), an AS Border Router (ASBR),
or a Path Computation Element (PCE) <xref target="RFC4655"/> needs to or a Path Computation Element (PCE) <xref target="RFC4655" format="default
know the TE information not only of the links within an AS, but also of "/> needs to
know the TE information not only of the links within an AS but also of
the links that connect to other ASes.</t> the links that connect to other ASes.</t>
<t>In this document, the Inter-AS
<t>In this document, a new TLV, which is referred to as the inter-AS Reachability Information TLV is defined to advertise inter-AS TE informati
reachability TLV, is defined to advertise inter-AS TE information, and on, and
three new sub-TLVs are defined for inclusion in the inter-AS reachability four sub-TLVs are defined for inclusion in the Inter-AS Reachability
TLV to carry the information about the remote AS number and remote Information TLV to carry the information about the Remote AS Number, Remot
ASBR ID. The sub-TLVs defined in e
<xref target="RFC5305"/><xref target="RFC6119"/> ASBR Identifier, and IPv6 Local ASBR Identifier. The sub-TLVs defined in
<xref target="RFC5305" format="default"/>, <xref target="RFC6119" format="
default"/>,
and other documents for inclusion in the extended IS reachability TLV and other documents for inclusion in the extended IS reachability TLV
for describing the TE properties of a TE link are applicable to be for describing the TE properties of a TE link are applicable to be
included in the Inter-AS Reachability TLV for describing the TE included in the Inter-AS Reachability Information TLV for describing the T
properties of an inter-AS TE link as well. Also, two more new sub- TLVs E
are defined for inclusion in the IS-IS router capability TLV to carry properties of an inter-AS TE link as well. Also, two more sub-TLVs
are defined for inclusion in the IS-IS Router CAPABILITY TLV to carry
the TE Router ID when the TE Router ID is needed to reach all routers the TE Router ID when the TE Router ID is needed to reach all routers
within an entire IS-IS routing domain. The extensions are equally within an entire IS-IS routing domain. The extensions are equally
applicable to applicable to
IPv4 and IPv6 as identical extensions to <xref target="RFC5305"/> and IPv4 and IPv6 as identical extensions to <xref target="RFC5305" format="de
<xref target="RFC6119"/>. Detailed definitions and procedures are fault"/> and
<xref target="RFC6119" format="default"/>. Detailed definitions and proced
ures are
discussed in the following sections.</t> discussed in the following sections.</t>
<t>This document does not propose or define any mechanisms to advertise <t>This document does not propose or define any mechanisms to advertise
any other extra-AS TE information within IS-IS. See Section 2.1 for a any other extra-AS TE information within IS-IS. See <xref target="non-obje ctives" format="default"/> for a
full list of non-objectives for this work.</t> full list of non-objectives for this work.</t>
<section>
<name>Requirements Language</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as s
hown here.</t>
</section>
</section> </section>
<section anchor="_PROB" numbered="true" toc="default">
<section anchor="_PROB" title="Problem Statement"> <name>Problem Statement</name>
<t>As described in <xref target="RFC4216"/>, in the case of establishing <t>As described in <xref target="RFC4216" format="default"/>, in the case
an inter-AS TE LSP that traverses multiple ASes, the Path message <xref of establishing
target="RFC3209"/> may include the following elements in the Explicit an inter-AS TE LSP that traverses multiple ASes, the Path message <xref ta
rget="RFC3209" format="default"/> may include the following elements in the Expl
icit
Route Object (ERO) in order to describe the path of the LSP:</t> Route Object (ERO) in order to describe the path of the LSP:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>a set of AS numbers as loose hops and/or</li>
<t>a set of AS numbers as loose hops; and/or</t> <li>a set of LSRs including ASBRs as loose hops.</li>
</ul>
<t>a set of LSRs including ASBRs as loose hops.</t>
</list></t>
<t>Two methods for determining inter-AS paths have been described <t>Two methods for determining inter-AS paths have been described
elsewhere. The per-domain method <xref target="RFC5152"/> determines the elsewhere. The per-domain method <xref target="RFC5152" format="default"/>
path one domain at a time. The backward recursive method <xref determines the
target="RFC5441"/> uses cooperation between PCEs to determine an optimum path one domain at a time. The backward-recursive method <xref target="RFC
5441" format="default"/> uses cooperation between PCEs to determine an optimum
inter-domain path. The sections that follow examine how inter-AS TE link inter-domain path. The sections that follow examine how inter-AS TE link
information could be useful in both cases.</t> information could be useful in both cases.</t>
<section numbered="true" toc="default" anchor="non-objectives">
<section title="A Note on Non-Objectives"> <name>A Note on Non-objectives</name>
<t>It is important to note that this document does not make any change <t>It is important to note that this document does not make any change
to the confidentiality and scaling assumptions surrounding the use of to the confidentiality and scaling assumptions surrounding the use of
ASes in the Internet. In particular, this document is conformant to ASes in the Internet. In particular, this document is conformant to
the requirements set out in <xref target="RFC4216"/>.</t> the requirements set out in <xref target="RFC4216" format="default"/>.</
t>
<t>The following features are explicitly excluded:</t> <t>The following features are explicitly excluded:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>There is no attempt to distribute TE information from within
<t>There is no attempt to distribute TE information from within one AS to another AS.</li>
one AS to another AS.</t> <li>There is no mechanism proposed to distribute any form of TE
reachability information for destinations outside the AS.</li>
<t>There is no mechanism proposed to distribute any form of TE <li>There is no proposed change to the PCE architecture or
reachability information for destinations outside the AS.</t> usage.</li>
<li>TE aggregation is not supported or recommended.</li>
<t>There is no proposed change to the PCE architecture or <li>There is no exchange of private information between ASes.</li>
usage.</t> <li>No IS-IS adjacencies are formed on the inter-AS link.</li>
</ul>
<t>TE aggregation is not supported or recommended.</t>
<t>There is no exchange of private information between ASes.</t>
<t>No IS-IS adjacencies are formed on the inter-AS link.</t>
</list></t>
</section> </section>
<section numbered="true" toc="default" anchor="determiniation">
<section title="Per-Domain Path Determination"> <name>Per-Domain Path Determination</name>
<t>In the per-domain method of determining an inter-AS path for an <t>In the per-domain method of determining an inter-AS path for an
MPLS-TE LSP, when an LSR that is an entry-point to an AS receives a MPLS-TE LSP, when an LSR that is an entry-point to an AS receives a
Path message from an upstream AS with an ERO containing a next hop Path message from an upstream AS with an ERO containing a next hop
that is an AS number, it needs to find which LSRs (ASBRs) within the that is an AS number, it needs to find which LSRs (ASBRs) within the
local AS are connected to the downstream AS. That way, it can compute local AS are connected to the downstream AS. That way, it can compute
a TE LSP segment across the local AS to one of those LSRs and forward a TE LSP segment across the local AS to one of those LSRs and forward
the Path message to that LSR and hence into the next AS. See Figure 1 the Path message to that LSR and hence into the next AS. See Figure 1
for an example.</t> for an example.</t>
<figure>
<t><figure> <name>Inter-AS Reference Model</name>
<artwork><![CDATA[ R1------R3----R5-----R7------R9-----R <artwork name="" type="" align="left" alt=""><![CDATA[
11 R1------R3----R5-----R7------R9-----R11
| | \ | / | | | \ | / |
| | \ | ---- | | | \ | ---- |
| | \ | / | | | \ | / |
R2------R4----R6 --R8------R10----R12 R2------R4----R6 --R8------R10----R12
: : : :
<-- AS1 -->:<---- AS2 --->:<--- AS3 ---> <-- AS1 -->:<---- AS2 --->:<--- AS3 --->
Figure 1: Inter-AS Reference Model
]]></artwork> ]]></artwork>
</figure>The figure shows three ASes (AS1, AS2, and AS3) and twelve </figure>
<t>The figure shows three ASes (AS1, AS2, and AS3) and twelve
LSRs (R1 through R12). R3 and R4 are ASBRs in AS1. R5, R6, R7, and R8 LSRs (R1 through R12). R3 and R4 are ASBRs in AS1. R5, R6, R7, and R8
are ASBRs in AS2. R9 and R10 are ASBRs in AS3.</t> are ASBRs in AS2. R9 and R10 are ASBRs in AS3.</t>
<t>If an inter-AS TE LSP is planned to be established from R1 to R12, <t>If an inter-AS TE LSP is planned to be established from R1 to R12,
the AS sequence will be: AS1, AS2, AS3.</t> the AS sequence will be: AS1, AS2, AS3.</t>
<t>Suppose that the Path message enters AS2 from R3. The next hop in <t>Suppose that the Path message enters AS2 from R3. The next hop in
the ERO shows AS3, and R5 must determine a path segment across AS2 to the ERO shows AS3, and R5 must determine a path segment across AS2 to
reach AS3. It has a choice of three exit points from AS2 (R6, R7, and reach AS3. It has a choice of three exit points from AS2 (R6, R7, and
R8), and it needs to know which of these provide TE connectivity to R8), and it needs to know which of these provide TE connectivity to
AS3, and whether the TE connectivity (for example, available AS3 and whether the TE connectivity (for example, available
bandwidth) is adequate for the requested LSP.</t> bandwidth) is adequate for the requested LSP.</t>
<t>Alternatively, if the next hop in the ERO is an entry ASBR for AS3 <t>Alternatively, if the next hop in the ERO is an entry ASBR for AS3
(say R9), R5 needs to know which of its exit ASBRs has a TE link that (say R9), R5 needs to know which of its exit ASBRs has a TE link that
connects to R9. Since there may be multiple ASBRs that are connected connects to R9. Since there may be multiple ASBRs that are connected
to R9 (both R7 and R8 in this example), R5 also needs to know the TE to R9 (both R7 and R8 in this example), R5 also needs to know the TE
properties of the inter-AS TE links so that it can select the correct properties of the inter-AS TE links so that it can select the correct
exit ASBR.</t> exit ASBR.</t>
<t>Once the Path message reaches the exit ASBR, any choice of inter-AS <t>Once the Path message reaches the exit ASBR, any choice of inter-AS
TE link can be made by the ASBR if not already made by the entry ASBR TE link can be made by the ASBR if not already made by the entry ASBR
that computed the segment.</t> that computed the segment.</t>
<t>More details can be found in <xref target="RFC5152" section="4" secti
<t>More details can be found in Section 4 of <xref target="RFC5152"/>, onFormat="of" format="default"/>,
which clearly points out why advertising of inter-AS links is which clearly points out why advertising of inter-AS links is
desired.</t> desired.</t>
<t>To enable R5 to make the correct choice of exit ASBR, the following <t>To enable R5 to make the correct choice of exit ASBR, the following
information is needed:</t> information is needed:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>List of all inter-AS TE links for the local AS.</li>
<t>List of all inter-AS TE links for the local AS.</t> <li>TE properties of each inter-AS TE link.</li>
<li>AS number of the neighboring AS connected to by each inter-AS
<t>TE properties of each inter-AS TE link.</t> TE link.</li>
<li>Identity (TE Router ID) of the neighboring ASBR connected to by
<t>AS number of the neighboring AS connected to by each inter-AS each inter-AS TE link.</li>
TE link.</t> </ul>
<t>In GMPLS networks, further information may also be required
<t>Identity (TE Router ID) of the neighboring ASBR connected to by to select the correct TE links as defined in <xref target="RFC5307" form
each inter-AS TE link.</t> at="default"/>.</t>
</list>In GMPLS networks, further information may also be required
to select the correct TE links as defined in <xref
target="RFC5307"/>.</t>
<t>The example above shows how this information is needed at the <t>The example above shows how this information is needed at the
entry-point ASBRs for each AS (or the PCEs that provide computation entry-point ASBRs for each AS (or the PCEs that provide computation
services for the ASBRs). However, this information is also needed services for the ASBRs). However, this information is also needed
throughout the local AS if path computation functionality is fully throughout the local AS if path computation functionality is fully
distributed among LSRs in the local AS, for example to support LSPs distributed among LSRs in the local AS, for example, to support LSPs
that have start points (ingress nodes) within the AS.</t> that have start points (ingress nodes) within the AS.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Backward Recursive Path Computation"> <name>Backward-Recursive Path Computation</name>
<t>Another scenario using PCE techniques has the same problem. <xref <t>Another scenario using PCE techniques has the same problem. <xref tar
target="RFC5441"/> defines a PCE-based TE LSP computation method get="RFC5441" format="default"/> defines a PCE-based TE LSP computation method
(called Backward Recursive Path Computation) to compute optimal (called "Backward-Recursive Path Computation (BRPC)") to compute optimal
inter-domain constrained MPLS-TE or GMPLS LSPs. In this path inter-domain constrained MPLS-TE or GMPLS LSPs. In this path
computation method, a specific set of traversed domains (ASes) are computation method, a specific set of traversed domains (ASes) are
assumed to be selected before computation starts. Each downstream PCE assumed to be selected before computation starts. Each downstream PCE
in domain(i) returns to its upstream neighbor PCE in domain(i-1) a in domain(i) returns to its upstream neighbor PCE in domain(i-1) a
multipoint-to-point tree of potential paths. Each tree consists of the multipoint-to-point tree of potential paths. Each tree consists of the
set of paths from all boundary nodes located in domain(i) to the set of paths from all boundary nodes located in domain(i) to the
destination where each path satisfies the set of required constraints destination where each path satisfies the set of required constraints
for the TE LSP (bandwidth, affinities, etc.).</t> for the TE LSP (bandwidth, affinities, etc.).</t>
<t>So a PCE needs to select boundary nodes (that is, ASBRs) that <t>So a PCE needs to select boundary nodes (that is, ASBRs) that
provide connectivity from the upstream AS. In order for the tree of provide connectivity from the upstream AS. In order for the tree of
paths provided by one PCE to its neighbor to be correlated, the paths provided by one PCE to its neighbor to be correlated, the
identities of the ASBRs for each path need to be referenced. Thus, the identities of the ASBRs for each path need to be referenced. Thus, the
PCE must know the identities of the ASBRs in the remote AS that are PCE must know the identities of the ASBRs in the remote AS that are
reached by any inter-AS TE link, and, in order to provide only reached by any inter-AS TE link, and, in order to provide only
suitable paths in the tree, the PCE must know the TE properties of the suitable paths in the tree, the PCE must know the TE properties of the
inter-AS TE links. See the following figure as an example.<figure> inter-AS TE links. See the following figure as an example.</t>
<artwork><![CDATA[ PCE1<------>PCE2<-------->PCE3 <figure>
<name>BRPC for Inter-AS Reference Model</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
PCE1<------>PCE2<-------->PCE3
/ : : / : :
/ : : / : :
R1------R3----R5-----R7------R9-----R11 R1------R3----R5-----R7------R9-----R11
| | \ | / | | | \ | / |
| | \ | ---- | | | \ | ---- |
| | \ | / | | | \ | / |
R2------R4----R6 --R8------R10----R12 R2------R4----R6 --R8------R10----R12
: : : :
<-- AS1 -->:<---- AS2 --->:<--- AS3 ---> <-- AS1 -->:<---- AS2 --->:<--- AS3 --->
Figure 2: BRPC for Inter-AS Reference Model
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The figure shows three ASes (AS1, AS2, and AS3), three PCEs (PCE1, <t>The figure shows three ASes (AS1, AS2, and AS3), three PCEs (PCE1,
PCE2, and PCE3), and twelve LSRs (R1 through R12). R3 and R4 are ASBRs PCE2, and PCE3), and twelve LSRs (R1 through R12). R3 and R4 are ASBRs
in AS1. R5, R6, R7, and R8 are ASBRs in AS2. R9 and R10 are ASBRs in in AS1. R5, R6, R7, and R8 are ASBRs in AS2. R9 and R10 are ASBRs in
AS3. PCE1, PCE2, and PCE3 cooperate to perform inter-AS path AS3. PCE1, PCE2, and PCE3 cooperate to perform inter-AS path
computation and are responsible for path segment computation within computation and are responsible for path segment computation within
their own domain(s).</t> their own domain(s).</t>
<t> If an inter-AS TE LSP is planned to be established from R1 to R12,
<t>If an inter-AS TE LSP is planned to be established from R1 to R12, the traversed domains are assumed to be selected (AS1-&gt;AS2-&gt;AS3), a
the traversed domains are assumed to be selected: AS1-&gt;AS2-&gt;AS3, nd
and the PCE chain is: PCE1-&gt;PCE2-&gt;PCE3. First, the path the PCE chain is PCE1-&gt;PCE2-&gt;PCE3. First, the path
computation request originated from the PCC (R1) is relayed by PCE1 computation request originated from the Path Computation Client (PCC) (R
1) is relayed by PCE1
and PCE2 along the PCE chain to PCE3. Then, PCE3 begins to compute the and PCE2 along the PCE chain to PCE3. Then, PCE3 begins to compute the
path segments from the entry boundary nodes that provide connection path segments from the entry boundary nodes that provide connection
from AS2 to the destination (R12). But, to provide suitable path from AS2 to the destination (R12). But, to provide suitable path
segments, PCE3 must determine which entry boundary nodes provide segments, PCE3 must determine which entry boundary nodes provide
connectivity to its upstream neighbor AS (identified by its AS connectivity to its upstream neighbor AS (identified by its AS
number), and must know the TE properties of the inter-AS TE links. In number) and must know the TE properties of the inter-AS TE links. In
the same way, PCE2 also needs to determine the entry boundary nodes the same way, PCE2 also needs to determine the entry boundary nodes
according to its upstream neighbor AS and the inter-AS TE link according to its upstream neighbor AS and the inter-AS TE link
capabilities.</t> capabilities.</t>
<t>Thus, to support BRPC, the same
<t>Thus, to support Backward Recursive Path Computation, the same information listed in <xref target="determiniation" format="default"/> i
information listed in Section 2.2 is required. The AS number of the s required. The AS number of the
neighboring AS connected to by each inter-AS TE link is particularly neighboring AS connected to by each inter-AS TE link is particularly
important.</t> important.</t>
</section> </section>
</section> </section>
<section anchor="_SOL" numbered="true" toc="default">
<section anchor="_SOL" title="Extensions to ISIS-TE"> <name>Extensions to IS-IS TE</name>
<t>Note that this document does not define mechanisms for distribution <t>Note that this document does not define mechanisms for distribution
of TE information from one AS to another, does not distribute any form of TE information from one AS to another, does not distribute any form
of TE reachability information for destinations outside the AS, does not of TE reachability information for destinations outside the AS, does not
change the PCE architecture or usage, does not suggest or recommend any change the PCE architecture or usage, does not suggest or recommend any
form of TE aggregation, and does not feed private information between form of TE aggregation, and does not feed private information between
ASes. See Section 2.1.</t> ASes. See <xref target="non-objectives" format="default"/>.</t>
<t>In this document,
<t>In this document, for the advertisement of inter-AS TE links, a new the Inter-AS Reachability Information TLV is defined for the advertisement
TLV, which is referred to as the inter-AS reachability TLV, is defined. of inter-AS TE links.
Three new sub-TLVs are also defined for inclusion in the inter-AS Four sub-TLVs are also defined for inclusion in the Inter-AS
reachability TLV to carry the information about the neighboring AS Reachability Information TLV to carry the information about the neighborin
number and the remote ASBR ID of an inter-AS link. The sub-TLVs defined g AS
in <xref target="RFC5305"/>, <xref target="RFC6119"/>, and other number, the Remote ASBR Identifier, and IPv6 Local ASBR Identifier of an i
nter-AS link. The sub-TLVs defined
in <xref target="RFC5305" format="default"/>, <xref target="RFC6119" forma
t="default"/>, and other
documents for inclusion in the extended IS reachability TLV are documents for inclusion in the extended IS reachability TLV are
applicable to be included in the inter-AS reachability TLV for inter-AS applicable to be included in the Inter-AS Reachability Information TLV for
TE links advertisement.</t> the advertisement of inter-AS
TE links.</t>
<t>This document also defines two new sub-TLVs for <t>This document also defines two sub-TLVs for
inclusion in the IS-IS router capability TLV to carry the TE Router ID inclusion in the IS-IS Router CAPABILITY TLV to carry the TE Router ID
when the TE Router ID is needed to reach all routers within an entire when the TE Router ID is needed to reach all routers within an entire
IS-IS routing domain.</t> IS-IS routing domain.</t>
<t>While some of the TE information of an inter-AS TE link may be <t>While some of the TE information of an inter-AS TE link may be
available within the AS from other protocols, in order to avoid any available within the AS from other protocols, in order to avoid any
dependency on where such protocols are processed, this mechanism carries dependency on where such protocols are processed, this mechanism carries
all the information needed for the required TE operations.</t> all the information needed for the required TE operations.</t>
<section anchor="_RID" numbered="true" toc="default">
<section anchor="_RID" title="Choosing the TE Router ID Value"> <name>Choosing the TE Router ID Value</name>
<t>Subsequent sections specify advertisement of a TE Router ID value <t>Subsequent sections specify advertisement of a TE Router ID value
for IPv4 and/or IPv6. This section defines how this value is for IPv4 and/or IPv6. This section defines how this value is
chosen. </t> chosen. </t>
<t>A TE Router ID <bcp14>MUST</bcp14> be an address that is unique withi
<t>A TE Router ID MUST be an address which is unique within the IS-IS n the IS-IS
domain and stable i.e., it can always be referenced in a path that domain and stable, i.e., it can always be referenced in a path that
will be reachable from multiple hops away, regardless of the state will be reachable from multiple hops away, regardless of the state
of the node's interfaces.</t> of the node's interfaces.</t>
<t>When advertising an IPv4 address as a TE Router ID, if the
<t>When advertising an IPv4 address as a TE Router ID, if the Traffic Traffic Engineering router ID TLV <xref target="RFC5305" format="default"
Engineering Router ID TLV <xref target="RFC5305"/> is being advertised, /> is being advertised,
then the address SHOULD be identical to the address in the Traffic then the address <bcp14>SHOULD</bcp14> be identical to the address in the
Engineering Router ID TLV. The TE Router ID MAY be identical to an IP Traffic
Interface Address <xref target="RFC1195"/> advertised by the Engineering router ID TLV. The TE Router ID <bcp14>MAY</bcp14> be identic
al to an IP
Interface Address <xref target="RFC1195" format="default"/> advertised by
the
originating IS so long as the address meets the requirements specified originating IS so long as the address meets the requirements specified
above.</t> above.</t>
<t>When advertising an IPv6 address as a TE Router ID, if the IPv6 TE
<t>When advertising an IPv6 address as a TE Router ID, if the IPv6 TE Router ID TLV <xref target="RFC6119" format="default"/> is being advertis
Router ID TLV <xref target="RFC6119"/> is being advertised, then the ed, then the
address SHOULD be identical to the address in the IPv6 TE Router ID TLV. address <bcp14>SHOULD</bcp14> be identical to the address in the IPv6 TE
The TE Router ID MAY be identical to a non-link-local IPv6 Router ID TLV.
The TE Router ID <bcp14>MAY</bcp14> be identical to a non-link-local IPv6
Interface Address advertised by the originating IS in a Link State Interface Address advertised by the originating IS in a Link State
PDU using the IPv6 Intf. Addr TLV <xref target="RFC5308"/> so long as PDU using the IPv6 Interface Address TLV <xref target="RFC5308" format="d efault"/> so long as
the address meets the requirements specified above.</t> the address meets the requirements specified above.</t>
</section> </section>
<section numbered="true" toc="default" anchor="inter-as">
<section title="Inter-AS Reachability TLV"> <name>Inter-AS Reachability Information TLV</name>
<t>The inter-AS reachability TLV has type 141 (see Section 6.1) and <t>The Inter-AS Reachability Information TLV has type 141 (see <xref ta
rget="inter-as-reachability" format="default"/>) and
contains a data structure consisting of:</t> contains a data structure consisting of:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t><figure> 0 1 2 3
<artwork><![CDATA[ 0 1 2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID (4 octets) | | Router ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| default metric | (3 octets) | Default Metric | (3 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (1 octet) | Flags | (1 octet)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|sub-TLVs length| (1 octet) |Sub-TLVs Length| (1 octet)
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
| sub-TLVs ... (0-246 octets) | Sub-TLVs ... (0-246 octets)
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork>
Flags consists of the following: <t>Flags consists of the following:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|S|D| Rsvd | |S|D| Rsvd |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
where:
S bit: If the S bit is set(1), the Inter-AS Reachability 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.
D bit: When the Inter-AS Reachability TLV is leaked from
Level 2 (L2) to Level 1 (L1), the D bit MUST be set. Otherwise, this
bit MUST be clear. Inter-AS Reachability TLVs with the D bit set
MUST NOT be leaked from Level 1 to Level 2. This is to prevent TLV
looping.
Reserved(Rsvd) bits MUST be zero when originated and ignored
when received.
]]></artwork> ]]></artwork>
</figure>Compared to the extended reachability TLV which is defined <t>where:</t>
in <xref target="RFC5305"/>, the inter-AS reachability TLV replaces <dl newline="false" spacing="normal">
<dt>S bit:</dt>
<dd>If the S bit is set(1), the Inter-AS Reachability Information TLV
<bcp14>MUST</bcp14> be flooded across the entire routing domain. If the S bi
t is
not set(0), the TLV <bcp14>MUST NOT</bcp14> be leaked between levels. This b
it <bcp14>MUST
NOT</bcp14> be altered during the TLV leaking.</dd>
<dt>D bit:</dt>
<dd>When the Inter-AS Reachability Information TLV is leaked from
Level 2 (L2) to Level 1 (L1), the D bit <bcp14>MUST</bcp14> be set. Otherwis
e, this
bit <bcp14>MUST</bcp14> be clear. Inter-AS Reachability Information TLVs wit
h the D bit set
<bcp14>MUST NOT</bcp14> be leaked from Level 1 to Level 2. This is to prevent
TLV
looping.</dd>
<dt>Reserved (Rsvd):</dt>
<dd>Reserved bits <bcp14>MUST</bcp14> be zero when originated and ignored
when received.</dd>
</dl>
<t>Compared to the extended IS reachability TLV, which is defined
in <xref target="RFC5305" format="default"/>, the Inter-AS Reachability
Information TLV replaces
the "7 octets of System ID and Pseudonode Number" field with a "4 the "7 octets of System ID and Pseudonode Number" field with a "4
octets of Router ID" field and introduces an extra "control octets of Router ID" field and introduces an extra "control
information" field, which consists of a flooding-scope bit (S bit), an information" field, which consists of a flooding-scope bit (S bit), an
up/down bit (D bit), and 6 reserved bits.</t> up/down bit (D bit), and 6 reserved bits.</t>
<t>The Router ID field of the Inter-AS Reachability Information TLV is 4
<t>The Router ID field of the inter-AS reachability TLV is 4 octets in octets in
length and has a value as defined in <xref target="_RID"/>. If the length and has a value as defined in <xref target="_RID" format="default
"/>. If the
originating node does not support IPv4, then the reserved value 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 Router ID 0.0.0.0 <bcp14>MUST</bcp14> be used in the Router ID field, and the IPv6
sub-TLV MUST be present in the inter-AS reachability TLV. The Router Router ID
ID could be used to indicate the source of the inter-AS reachability sub-TLV <bcp14>MUST</bcp14> be present in the Inter-AS Reachability Info
TLV.</t> rmation TLV. The Router
ID could be used to indicate the source of the Inter-AS Reachability
<t>The flooding procedures for inter-AS reachability TLV are identical Information TLV.</t>
<t>The flooding procedures for the Inter-AS Reachability Information TLV
are identical
to the flooding procedures for the GENINFO TLV, which are defined in to the flooding procedures for the GENINFO TLV, which are defined in
Section 4 of <xref target="RFC6823"/>. These procedures have been <xref target="RFC6823" section="4" sectionFormat="of" format="default"/>
previously discussed in <xref target="RFC7981"/>. The flooding-scope . These procedures have been
bit (S bit) SHOULD be set to 0 if the flooding scope is to be limited previously discussed in <xref target="RFC7981" format="default"/>. The f
to within the single IGP area to which the ASBR belongs. It MAY be set looding-scope
bit (S bit) <bcp14>SHOULD</bcp14> be set to 0 if the flooding scope is t
o be limited
to within the single IGP area to which the ASBR belongs. It <bcp14>MAY</
bcp14> be set
to 1 if the information is intended to reach all routers (including to 1 if the information is intended to reach all routers (including
area border routers, ASBRs, and PCEs) in the entire IS-IS routing area border routers, ASBRs, and PCEs) in the entire IS-IS routing
domain. The choice between the use of 0 or 1 is an AS-wide policy domain. The choice between the use of 0 or 1 is an AS-wide policy
choice, and configuration control SHOULD be provided in ASBR choice, and configuration control <bcp14>SHOULD</bcp14> be provided in A SBR
implementations that support the advertisement of inter-AS TE implementations that support the advertisement of inter-AS TE
links.</t> links.</t>
<t>The sub-TLVs defined in <xref target="RFC5305" format="default"/>, <x
<t>The sub-TLVs defined in <xref target="RFC5305"/>, <xref ref target="RFC6119" format="default"/>, and other documents for describing the
target="RFC6119"/>, and other documents for describing the TE TE
properties of a TE link are also applicable to the inter-AS properties of a TE link are also applicable to the Inter-AS
reachability TLV for describing the TE properties of an Inter-AS TE Reachability Information TLV for describing the TE properties of an inte
link. Apart from these sub-TLVs, four new sub-TLVs are defined for r-AS TE
inclusion in the inter-AS reachability TLV defined in this link. Apart from these sub-TLVs, four sub-TLVs are defined for
inclusion in the Inter-AS Reachability Information TLV defined in this
document:</t> document:</t>
<table align="center">
<t><figure> <thead>
<artwork><![CDATA[Sub-TLV type Length Name <tr>
24 4 remote AS number <th>Sub-TLV type</th>
25 4 IPv4 remote ASBR identifier <th>Length</th>
26 16 IPv6 remote ASBR identifier <th>Name</th>
TBD1 16 IPv6 local ASBR identifier </tr>
]]></artwork> </thead>
</figure>Detailed definitions of the four new sub-TLVs are described <tbody>
in Sections 3.3.1, 3.3.2, 3.3.3, and 3.3.4.</t> <tr>
<td>24</td>
<td>4</td>
<td>Remote AS Number</td>
</tr>
<tr>
<td>25</td>
<td>4</td>
<td>IPv4 Remote ASBR Identifier</td>
</tr>
<tr>
<td>26</td>
<td>16</td>
<td>IPv6 Remote ASBR Identifier</td>
</tr>
<tr>
<td>45</td>
<td>16</td>
<td>IPv6 Local ASBR Identifier</td>
</tr>
</tbody>
</table>
<t>Detailed definitions of these four sub-TLVs are described
in Sections <xref target="remote-as" format="counter"/>, <xref target="i
pv4-remote" format="counter"/>, <xref target="ipv6-remote" format="counter"/>, a
nd <xref target="ipv6-local" format="counter"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="TE Router ID"> <name>TE Router ID</name>
<t>The Traffic Engineering router ID TLV and IPv6 TE Router ID TLV, <t>The Traffic Engineering router ID TLV and IPv6 TE Router ID TLV,
which are which are
defined in <xref target="RFC5305"/> and <xref target="RFC6119"/> defined in <xref target="RFC5305" format="default"/> and <xref target="R
respectively, only have area flooding-scope. When performing inter-AS FC6119" format="default"/>,
TE, the TE Router ID MAY be needed to reach all routers within an respectively, only have area flooding scope. When performing inter-AS
entire IS-IS routing domain and it MUST have the same flooding scope TE, the TE Router ID <bcp14>MAY</bcp14> be needed to reach all routers w
as the Inter-AS Reachability TLV does.</t> ithin an
entire IS-IS routing domain, and it <bcp14>MUST</bcp14> have the same fl
<t><xref target="RFC7981"/> defines a generic advertisement mechanism ooding scope
for IS-IS which allows a router to advertise its capabilities within as the Inter-AS Reachability Information TLV does.</t>
an IS-IS area or an entire IS-IS routing domain. <xref <t><xref target="RFC7981" format="default"/> defines a generic advertise
target="RFC7981"/> also points out that the TE Router ID is a ment mechanism
candidate to be carried in the IS-IS router capability TLV when for IS-IS, which allows a router to advertise its capabilities within
an IS-IS area or an entire IS-IS routing domain. <xref target="RFC7981"
format="default"/> also points out that the TE Router ID is a
candidate to be carried in the IS-IS Router CAPABILITY TLV when
performing inter-area TE.</t> performing inter-area TE.</t>
<t>This document uses such mechanism for TE Router ID advertisement <t>This document uses such mechanism for TE Router ID advertisement
when the TE Router ID is needed to reach all routers within an entire when the TE Router ID is needed to reach all routers within an entire
IS-IS Routing domain. Two new sub-TLVs are defined for inclusion in IS-IS routing domain. Two sub-TLVs are defined for inclusion in
the IS-IS Router Capability TLV to carry the TE Router IDs.</t> the IS-IS Router CAPABILITY TLV to carry the TE Router IDs.</t>
<table align="center">
<t><figure> <thead>
<artwork><![CDATA[Sub-TLV type Length Name <tr>
11 4 IPv4 TE Router ID <th>Sub-TLV type</th>
12 16 IPv6 TE Router ID <th>Length</th>
]]></artwork> <th>Name</th>
</figure>Detailed definitions of the new sub-TLVs are described in </tr>
Section 3.4.1 and 3.4.2.</t> </thead>
<tbody>
<tr>
<td>11</td>
<td>4</td>
<td>IPv4 TE Router ID</td>
</tr>
<tr>
<td>12</td>
<td>16</td>
<td>IPv6 TE Router ID</td>
</tr>
</tbody>
</table>
<t>Detailed definitions of these sub-TLVs are described in
Sections <xref target="remote-as" format="counter"/> and <xref target="i
pv4-remote" format="counter"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Sub-TLVs for Inter-AS Reachability TLV"> <name>Sub-TLVs for Inter-AS Reachability Information TLV</name>
<section title="Remote AS Number Sub-TLV "> <section numbered="true" toc="default" anchor="remote-as">
<t>A new sub-TLV, the remote AS number sub-TLV, is defined for <name>Remote AS Number Sub-TLV</name>
inclusion in the inter-AS reachability TLV when advertising inter-AS <t>The Remote AS Number sub-TLV is defined for
links. The remote AS number sub-TLV specifies the AS number of the inclusion in the Inter-AS Reachability Information TLV when advertisin
g inter-AS
links. The Remote AS Number sub-TLV specifies the AS number of the
neighboring AS to which the advertised link connects.</t> neighboring AS to which the advertised link connects.</t>
<t>The Remote AS Number sub-TLV is TLV type 24 (see <xref target="sub-
<t>The remote AS number sub-TLV is TLV type 24 (see Section 6.2) and tlv-inter-as" format="default"/>) and
is 4 octets in length. The format is as follows:</t> is 4 octets in length. The format is as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t><figure> 0 1 2 3
<artwork><![CDATA[ 0 1 2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote AS Number | | Remote AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>The remote AS number field has 4 octets. When only 2 <t>The Remote AS Number field has 4 octets. When only 2
octets are used for the AS number, the octets are used for the AS number, the
left (high-order) 2 octets MUST be set to 0. The remote AS number left (high-order) 2 octets <bcp14>MUST</bcp14> be set to 0. The Remote
sub-TLV MUST be included when a router advertises an inter-AS TE AS Number
sub-TLV <bcp14>MUST</bcp14> be included when a router advertises an in
ter-AS TE
link.</t> link.</t>
</section> </section>
<section numbered="true" toc="default" anchor="ipv4-remote">
<section title="IPv4 Remote ASBR ID Sub-TLV"> <name>IPv4 Remote ASBR Identifier Sub-TLV</name>
<t>A new sub-TLV, which is referred to as the IPv4 remote ASBR ID <t>The IPv4 Remote ASBR Identifier
sub-TLV, is defined for inclusion in the inter-AS reachability TLV sub-TLV is defined for inclusion in the Inter-AS Reachability Informat
when advertising inter-AS links. The IPv4 remote ASBR ID sub-TLV ion TLV
when advertising inter-AS links. The IPv4 Remote ASBR Identifier sub-T
LV
specifies the IPv4 identifier of the remote ASBR to which the specifies the IPv4 identifier of the remote ASBR to which the
advertised inter-AS link connects. The value advertised is selected advertised inter-AS link connects. The value advertised is selected
as defined in <xref target="_RID"/>.</t> as defined in <xref target="_RID" format="default"/>.</t>
<t>The IPv4 Remote ASBR Identifier sub-TLV is TLV type 25 (see <xref t
<t>The IPv4 remote ASBR ID sub-TLV is TLV type 25 (see Section 6.2) arget="sub-tlv-inter-as" format="default"/>)
and is 4 octets in length. The format of the IPv4 remote ASBR ID and is 4 octets in length. The format of the IPv4 Remote ASBR Identifi
er
sub-TLV is as follows:</t> sub-TLV is as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t><figure> 0 1 2 3
<artwork><![CDATA[ 0 1 2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote ASBR ID | | Remote ASBR Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>The IPv4 remote ASBR ID sub-TLV MUST be included if the <t>The IPv4 Remote ASBR Identifier sub-TLV <bcp14>MUST</bcp14> be incl
neighboring ASBR has an IPv4 address. The value advertised is selected uded if the
as defined in <xref target="_RID"/>. If the neighboring ASBR does neighboring ASBR has an IPv4 address. If the neighboring ASBR does
not have an IPv4 address, the IPv6 not have an IPv4 address, the IPv6
remote ASBR ID sub-TLV MUST be included instead. An IPv4 remote ASBR Remote ASBR Identifier sub-TLV <bcp14>MUST</bcp14> be included instead
ID sub-TLV and IPv6 remote ASBR ID sub-TLV MAY both be present in an . An IPv4 Remote ASBR
Identifier sub-TLV and IPv6 Remote ASBR Identifier sub-TLV <bcp14>MAY<
/bcp14> both be present in an
extended IS reachability TLV.</t> extended IS reachability TLV.</t>
</section> </section>
<section numbered="true" toc="default" anchor="ipv6-remote">
<section title="IPv6 Remote ASBR ID Sub-TLV"> <name>IPv6 Remote ASBR Identifier Sub-TLV</name>
<t>A new sub-TLV, which is referred to as the IPv6 remote ASBR ID <t>The IPv6 Remote ASBR Identifier
sub-TLV, is defined for inclusion in the inter-AS reachability TLV sub-TLV is defined for inclusion in the Inter-AS Reachability Informat
when advertising inter-AS links. The IPv6 remote ASBR ID sub-TLV ion TLV
when advertising inter-AS links. The IPv6 Remote ASBR Identifier sub-T
LV
specifies the IPv6 identifier of the remote ASBR to which the specifies the IPv6 identifier of the remote ASBR to which the
advertised inter-AS link connects. The value advertised is selected advertised inter-AS link connects. The value advertised is selected
as defined in <xref target="_RID"/>.</t> as defined in <xref target="_RID" format="default"/>.</t>
<t>The IPv6 Remote ASBR Identifier sub-TLV is TLV type 26 (see <xref t
<t>The IPv6 remote ASBR ID sub-TLV is TLV type 26 (see Section 6.2) arget="sub-tlv-inter-as" format="default"/>)
and is 16 octets in length. The format of the IPv6 remote ASBR ID and is 16 octets in length. The format of the IPv6 Remote ASBR Identif
ier
sub-TLV is as follows:</t> sub-TLV is as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t><figure> 0 1 2 3
<artwork><![CDATA[ 0 1 2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote ASBR ID | | Remote ASBR Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote ASBR ID (continued) | | Remote ASBR Identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote ASBR ID (continued) | | Remote ASBR Identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote ASBR ID (continued) | | Remote ASBR Identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>The IPv6 remote ASBR ID sub-TLV MUST be included if the <t>The IPv6 Remote ASBR Identifier sub-TLV <bcp14>MUST</bcp14> be incl uded if the
neighboring ASBR has an IPv6 address. If the neighboring ASBR does neighboring ASBR has an IPv6 address. If the neighboring ASBR does
not have an IPv6 address, the IPv4 remote ASBR ID sub-TLV MUST be not have an IPv6 address, the IPv4 Remote ASBR Identifier sub-TLV <bcp
included instead. An IPv4 remote ASBR ID sub-TLV and IPv6 remote 14>MUST</bcp14> be
ASBR ID sub-TLV MAY both be present in an extended IS reachability included instead. An IPv4 Remote ASBR Identifier sub-TLV and IPv6 Remo
te
ASBR Identifier sub-TLV <bcp14>MAY</bcp14> both be present in an exten
ded IS reachability
TLV.</t> TLV.</t>
</section> </section>
<section numbered="true" toc="default" anchor="ipv6-local">
<section title="IPv6 Local ASBR ID sub-TLV"> <name>IPv6 Local ASBR Identifier Sub-TLV</name>
<t>The IPv6 Local ASBR ID sub-TLV is TLV type TBD1 (see Section 6.3) <t>The IPv6 Local ASBR Identifier sub-TLV is defined for inclusion in t
and is 16 octets in length. The format of the IPv6 Local ASBR ID he
Inter-AS Reachability Information TLV when advertising inter-AS links. The I
Pv6
Local ASBR Identifier sub-TLV specifies the IPv6 identifier of the remote
ASBR to which the advertised inter-AS link connects. The value
advertised is selected as defined in <xref target="_RID" format="default"/>.<
/t>
<t>The IPv6 Local ASBR Identifier sub-TLV is TLV type 45 (see <xref ta
rget="sub-tlv-inter-as" format="default"/>)
and is 16 octets in length. The format of the IPv6 Local ASBR Identifi
er
sub-TLV is as follows:</t> sub-TLV is as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure> 0 1 2 3
<artwork><![CDATA[ 0 1 2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local ASBR ID | | Local ASBR Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local ASBR ID (continued) | | Local ASBR Identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local ASBR ID (continued) | | Local ASBR Identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local ASBR ID (continued) | | Local ASBR Identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>
<t>The value advertised is selected as defined in
<xref target="_RID"/>.</t>
<t>If the originating node does not support IPv4, the IPv6 Local <t>If the originating node does not support IPv4, the IPv6 Local
ASBR ID sub-TLV MUST be present in the inter-AS reachability TLV. ASBR Identifier sub-TLV <bcp14>MUST</bcp14> be present in the Inter-AS
Inter-AS reachability TLVs which have a Router ID of 0.0.0.0 and do Reachability Information TLV.
not have the IPv6 Local ASBR ID sub-TLV present MUST be ignored.</t> Inter-AS Reachability Information TLVs that have a Router ID of 0.0.0.
0 and do
not have the IPv6 Local ASBR Identifier sub-TLV present <bcp14>MUST</b
cp14> be ignored.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Sub-TLVs for IS-IS Router Capability TLV"> <name>Sub-TLVs for IS-IS Router CAPABILITY TLV</name>
<section title="IPv4 TE Router ID sub-TLV"> <section numbered="true" toc="default">
<t>The IPv4 TE Router ID sub-TLV is TLV type 11 (see Section 6.3) <name>IPv4 TE Router ID Sub-TLV</name>
<t>The IPv4 TE Router ID sub-TLV is TLV type 11 (see <xref target="sub
-tlv-is-is" format="default"/>)
and is 4 octets in length. The format of the IPv4 TE Router ID and is 4 octets in length. The format of the IPv4 TE Router ID
sub-TLV is as follows:</t> sub-TLV is as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t><figure> 0 1 2 3
<artwork><![CDATA[0 1 2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router ID | | TE Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> <t>The value advertised is selected as defined in
<xref target="_RID" format="default"/>.</t>
<t>The value advertised is selected as defined in
<xref target="_RID"/>.</t>
<t>When the TE Router ID is needed to reach all routers within an <t>When the TE Router ID is needed to reach all routers within an
entire IS-IS routing domain, the IS-IS Router capability TLV MUST be entire IS-IS routing domain, the IS-IS Router CAPABILITY TLV <bcp14>MU ST</bcp14> be
included in its LSP. If an ASBR supports Traffic Engineering for included in its LSP. If an ASBR supports Traffic Engineering for
IPv4 and if the ASBR has an IPv4 TE Router ID, the IPv4 TE Router ID IPv4 and if the ASBR has an IPv4 TE Router ID, the IPv4 TE Router ID
sub-TLV MUST be included. If the ASBR does not have an IPv4 TE sub-TLV <bcp14>MUST</bcp14> be included. If the ASBR does not have an
Router ID, the IPv6 TE Router sub-TLV MUST be included instead. An IPv4 TE
IPv4 TE Router ID sub-TLV and IPv6 TE Router ID sub-TLV MAY both be Router ID, the IPv6 TE Router ID sub-TLV <bcp14>MUST</bcp14> be includ
present in an IS-IS router capability TLV.</t> ed instead. An
IPv4 TE Router ID sub-TLV and IPv6 TE Router ID sub-TLV <bcp14>MAY</bc
p14> both be
present in an IS-IS Router CAPABILITY TLV.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="IPv6 TE Router ID sub-TLV"> <name>IPv6 TE Router ID Sub-TLV</name>
<t>The IPv6 TE Router ID sub-TLV is TLV type 12 (see Section 6.3) <t>The IPv6 TE Router ID sub-TLV is TLV type 12 (see <xref target="sub
-tlv-is-is" format="default"/>)
and is 16 octets in length. The format of the IPv6 TE Router ID and is 16 octets in length. The format of the IPv6 TE Router ID
sub-TLV is as follows:</t> sub-TLV is as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t><figure> 0 1 2 3
<artwork><![CDATA[0 1 2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router ID | | TE Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router ID (continued) | | TE Router ID (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router ID (continued) | | TE Router ID (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router ID (continued) | | TE Router ID (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> <t>The value advertised is selected as defined in
<xref target="_RID" format="default"/>.</t>
<t>The value advertised is selected as defined in
<xref target="_RID"/>.</t>
<t>When the TE Router ID is needed to reach all routers within an <t>When the TE Router ID is needed to reach all routers within an
entire IS-IS routing domain, the IS-IS router capability TLV MUST be entire IS-IS routing domain, the IS-IS Router CAPABILITY TLV <bcp14>MU ST</bcp14> be
included in its LSP. If an ASBR supports Traffic Engineering for included in its LSP. If an ASBR supports Traffic Engineering for
IPv6 and if the ASBR has an IPv6 TE Router ID, the IPv6 TE Router ID IPv6 and if the ASBR has an IPv6 TE Router ID, the IPv6 TE Router ID
sub-TLV MUST be included. If the ASBR does not have an IPv6 TE sub-TLV <bcp14>MUST</bcp14> be included. If the ASBR does not have an
Router ID, the IPv4 TE Router sub-TLV MUST be included instead. An IPv6 TE
IPv4 TE Router ID sub-TLV and IPv6 TE Router ID sub-TLV MAY both be Router ID, the IPv4 TE Router ID sub-TLV <bcp14>MUST</bcp14> be includ
present in an IS-IS router capability TLV.</t> ed instead. An
IPv4 TE Router ID sub-TLV and IPv6 TE Router ID sub-TLV <bcp14>MAY</bc
p14> both be
present in an IS-IS Router CAPABILITY TLV.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="_Procedure" numbered="true" toc="default">
<section anchor="_Procedure" title="Procedure for Inter-AS TE Links"> <name>Procedure for Inter-AS TE Links</name>
<t>When TE is enabled on an inter-AS link and the link is up, the ASBR <t>When TE is enabled on an inter-AS link and the link is up, the ASBR
SHOULD advertise this link using the normal procedures for <xref <bcp14>SHOULD</bcp14> advertise this link using the normal procedures for
target="RFC5305"/>. When either the link is down or TE is disabled on <xref target="RFC5305" format="default"/>. When either the link is down or TE is
the link, the ASBR SHOULD withdraw the advertisement. When there are disabled on
the link, the ASBR <bcp14>SHOULD</bcp14> withdraw the advertisement. When
there are
changes to the TE parameters for the link (for example, when the changes to the TE parameters for the link (for example, when the
available bandwidth changes), the ASBR SHOULD re-advertise the link but available bandwidth changes), the ASBR <bcp14>SHOULD</bcp14> re-advertise
MUST take precautions against excessive re-advertisements.</t> the link but
<bcp14>MUST</bcp14> take precautions against excessive re-advertisements.<
<t>Hellos MUST NOT be exchanged over the inter-AS link, and /t>
consequently, an IS-IS adjacency MUST NOT be formed.</t> <t>Hellos <bcp14>MUST NOT</bcp14> be exchanged over the inter-AS link, and
consequently, an IS-IS adjacency <bcp14>MUST NOT</bcp14> be formed.</t>
<t>The information advertised comes from the ASBR's knowledge of the TE <t>The information advertised comes from the ASBR's knowledge of the TE
capabilities of the link, the ASBR's knowledge of the current status and capabilities of the link, the ASBR's knowledge of the current status and
usage of the link, and configuration at the ASBR of the remote AS number usage of the link, and configuration at the ASBR of the Remote AS Number
and remote ASBR TE Router ID.</t> and remote ASBR TE Router ID.</t>
<t>Legacy routers receiving an advertisement for an inter-AS TE link are <t>Legacy routers receiving an advertisement for an inter-AS TE link are
able to ignore it because they do not know the new TLV and sub-TLVs that able to ignore it because they do not know the TLV and sub-TLVs that
are defined in Section 3 of this document. They will continue to flood are defined in <xref target="_SOL" format="default"/> of this document. Th
the LSP, but will not attempt to use the information received.</t> ey will continue to flood
the LSP but will not attempt to use the information received.</t>
<t>In the current operation of ISIS-TE, the LSRs at each end of a TE <t>In the current operation of IS-IS TE, the LSRs at each end of a TE
link emit LSPs describing the link. The databases in the LSRs then have link emit LSPs describing the link. The databases in the LSRs then have
two entries (one locally generated, the other from the peer) that two entries (one locally generated, the other from the peer) that
describe the different 'directions' of the link. This enables describe the different 'directions' of the link. This enables
Constrained Shortest Path First (CSPF) to do a two-way check on the link Constrained Shortest Path First (CSPF) to do a two-way check on the link
when performing path computation and eliminate it from consideration when performing path computation and eliminate it from consideration
unless both directions of the link satisfy the required constraints.</t> unless both directions of the link satisfy the required constraints.</t>
<t>In the case we are considering here (i.e., of a TE link to another <t>In the case we are considering here (i.e., of a TE link to another
AS), there is, by definition, no IGP peering and hence no bidirectional AS), there is, by definition, no IGP peering and hence no bidirectional
TE link information. In order for the CSPF route computation entity to TE link information. In order for the CSPF route computation entity to
include the link as a candidate path, we have to find a way to get LSPs include the link as a candidate path, we have to find a way to get LSPs
describing its (bidirectional) TE properties into the TE database.</t> describing its (bidirectional) TE properties into the TE database.</t>
<t>This is achieved by the ASBR advertising, internally to its AS, <t>This is achieved by the ASBR advertising, internally to its AS,
information about both directions of the TE link to the next AS. The information about both directions of the TE link to the next AS. The
ASBR will normally generate an LSP describing its own side of a link; ASBR will normally generate an LSP describing its own side of a link;
here we have it 'proxy' for the ASBR at the edge of the other AS and here, we have it 'proxy' for the ASBR at the edge of the other AS and
generate an additional LSP that describes that device's 'view' of the generate an additional LSP that describes that device's 'view' of the
link.</t> link.</t>
<t>Only some essential TE information for the link needs to be <t>Only some essential TE information for the link needs to be
advertised; i.e., the Interface Address, the remote AS number, and the advertised, i.e., the Interface Address, the Remote AS Number, and the
remote ASBR ID of an inter-AS TE link.</t> Remote ASBR Identifier of an inter-AS TE link.</t>
<t>Routers or PCEs that are capable of processing advertisements of <t>Routers or PCEs that are capable of processing advertisements of
inter-AS TE links SHOULD NOT use such links to compute paths that exit inter-AS TE links <bcp14>SHOULD NOT</bcp14> use such links to compute path s that exit
an AS to a remote ASBR and then immediately re-enter the AS through an AS to a remote ASBR and then immediately re-enter the AS through
another TE link. Such paths would constitute extremely rare occurrences another TE link. Such paths would constitute extremely rare occurrences
and SHOULD NOT be allowed except as the result of specific policy and <bcp14>SHOULD NOT</bcp14> be allowed except as the result of specific policy
configurations at the router or PCE computing the path.</t> configurations at the router or PCE computing the path.</t>
<section numbered="true" toc="default" anchor="te-info">
<section title="Origin of Proxied TE Information"> <name>Origin of Proxied TE Information</name>
<t>Section 4 describes how an ASBR advertises TE link information as a <t><xref target="_Procedure" format="default"/> describes how an ASBR ad
proxy for its neighbor ASBR, but does not describe where this vertises TE link information as a
proxy for its neighbor ASBR but does not describe where this
information comes from.</t> information comes from.</t>
<t>Although the source of the information described in <xref target="_Pr
<t>Although the source of the information described in Section 4 ocedure" format="default"/>
is outside the scope of is outside the scope of
this document, it is possible that it will be a configuration this document, it is possible that it will be a configuration
requirement at the ASBR, as are other local properties of the TE link. requirement at the ASBR, as are other local properties of the TE link.
Further, where BGP is used to exchange IP routing information between Further, where BGP is used to exchange IP routing information between
the ASBRs, a certain amount of additional local configuration about the ASBRs, a certain amount of additional local configuration about
the link and the remote ASBR is likely to be available.</t> the link and the remote ASBR is likely to be available.</t>
<t>We note further that it is possible, and may be operationally <t>We note further that it is possible, and may be operationally
advantageous, to obtain some of the required configuration information advantageous, to obtain some of the required configuration information
from BGP. Whether and how to utilize these possibilities is an from BGP. Whether and how to utilize these possibilities is an
implementation matter.</t> implementation matter.</t>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>The protocol extensions defined in this document are relatively minor <t>The protocol extensions defined in this document are relatively minor
and can be secured within the AS in which they are used by the existing and can be secured within the AS in which they are used by the existing
IS-IS security mechanisms (e.g., using the cleartext passwords or Hashed IS-IS security mechanisms (e.g., using the cleartext passwords or Hashed
Message Authentication Codes, Message Authentication Codes,
which are defined in <xref target="RFC1195"/>, <xref which are defined in <xref target="RFC1195" format="default"/>, <xref targ
target="RFC5304"/>, and <xref target="RFC5310"/> separately).</t> et="RFC5304" format="default"/>, and <xref target="RFC5310" format="default"/> s
eparately).</t>
<t>There is no exchange of information between ASes, and no change to <t>There is no exchange of information between ASes and no change to
the IS-IS security relationship between the ASes. In particular, since the IS-IS security relationship between the ASes. In particular, since
no IS-IS adjacency is formed on the inter-AS links, there is no no IS-IS adjacency is formed on the inter-AS links, there is no
requirement for IS-IS security between the ASes.</t> requirement for IS-IS security between the ASes.</t>
<t>Some of the information included in these advertisements (e.g.,
<t>Some of the information included in these new advertisements (e.g., the Remote AS Number and the Remote ASBR Identifier) is obtained manually
the remote AS number and the remote ASBR ID) is obtained manually from a from a
neighboring administration as part of a commercial relationship. The neighboring administration as part of a commercial relationship. The
source and content of this information should be carefully checked source and content of this information should be carefully checked
before it is entered as configuration information at the ASBR before it is entered as configuration information at the ASBR
responsible for advertising the inter-AS TE links.</t> responsible for advertising the inter-AS TE links.</t>
<t>It is worth noting that, in the scenario we are considering, a Border
<t>It is worth noting that in the scenario we are considering, a Border
Gateway Protocol (BGP) peering may exist between the two ASBRs and that Gateway Protocol (BGP) peering may exist between the two ASBRs and that
this could be used to detect inconsistencies in configuration (e.g., the this could be used to detect inconsistencies in configuration (e.g., the
administration that originally supplied the information may provide administration that originally supplied the information may provide
incorrect information, or incorrect information, or
some manual mis-configurations or mistakes may be made by the some manual misconfigurations or mistakes may be made by the
operators). For example, if a different remote AS number is received in operators). For example, if a different Remote AS Number is received in
a BGP OPEN <xref target="RFC4271"/> from that locally configured to a BGP OPEN <xref target="RFC4271" format="default"/> from that locally con
ISIS-TE, as we describe here, then local policy SHOULD be applied to figured to
determine whether to alert the operator to a potential mis-configuration IS-IS TE, as we describe here, then local policy <bcp14>SHOULD</bcp14> be
applied to
determine whether to alert the operator to a potential misconfiguration
or to suppress the IS-IS advertisement of the inter-AS TE link. or to suppress the IS-IS advertisement of the inter-AS TE link.
Advertisement of incorrect information could result in an inter-AS TE Advertisement of incorrect information could result in an inter-AS TE
LSP that traverses an unintended AS. Note LSP that traverses an unintended AS. Note
further that if BGP is used to exchange TE information as described in further that, if BGP is used to exchange TE information as described in
Section 4.1, the inter-AS BGP session SHOULD be secured using mechanisms <xref target="te-info" format="default"/>, the inter-AS BGP session <bcp14
such as described in <xref target="RFC5925"/> to provide authentication >SHOULD</bcp14> be secured using mechanisms
such as described in <xref target="RFC5925" format="default"/> to provide
authentication
and integrity checks.</t> and integrity checks.</t>
<t>For a discussion of general security considerations for IS-IS, see <t>For a discussion of general security considerations for IS-IS, see
<xref target="RFC5304"/>.</t> <xref target="RFC5304" format="default"/>.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>IANA is requested to make the following allocations from registries <section numbered="true" toc="default" anchor="inter-as-reachability">
under its control.</t> <name>Inter-AS Reachability Information TLV</name>
<t>IANA has registered the following IS-IS TLV type, described
<section title="Inter-AS Reachability TLV"> in <xref target="_RID" format="default"/>, in the "IS-IS Top-Level TLV C
<t>This document defines the following new IS-IS TLV type, described odepoints"
in Section 3.1, which has been registered in the IS-IS TLV codepoint
registry:</t> registry:</t>
<table align="center">
<t><figure> <thead>
<artwork><![CDATA[ Type Description IIH LSP <tr>
SNP Purge Reference <th>Value</th>
---- ---------------------- --- --- --- ----- --------- <th>Name</th>
141 inter-AS reachability n y n n [This.I-D] <th>IIH</th>
information <th>LSP</th>
]]></artwork> <th>SNP</th>
</figure></t> <th>Purge</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>141</td>
<td>Inter-AS Reachability Information</td>
<td>n</td>
<td>y</td>
<td>n</td>
<td>n</td>
<td>RFC 9346</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default" anchor="sub-tlv-inter-as">
<section title="Sub-TLVs for the Inter-AS Reachability TLV"> <name>Sub-TLVs for the Inter-AS Reachability Information TLV</name>
<t>This document defines the following new sub-TLV types (described in <t>IANA has registered the following sub-TLV types of top-level TLV
Sections 3.3.1, 3.3.2, 3.3.3, and, 3.3.4) of top-level TLV 141 (see 141 (see <xref target="inter-as-reachability" format="default"/>) in
Section 6.1 above). Three of these sub-TLVs have been registered in the "IS-IS Sub-TLVs for TLVs Advertising Neighbor Information"
the IS-IS Sub-TLVs for TLVs Advertising Neighbor Information registry registry. These sub-TLVs are described in Sections <xref
by <xref target="RFC5316"/>. One additional sub-TLV (IPv6 local ASBR target="remote-as" format="counter"/>, <xref target="ipv4-remote"
identifier) is introduced by this document and needs to be added to format="counter"/>, <xref target="ipv6-remote" format="counter"/>, and
the same registry. </t> <xref target="ipv6-local" format="counter"/>.
</t>
<t><figure> <table align="center">
<artwork><![CDATA[ Type Description 22 23 25 <thead>
141 222 223 Reference <tr>
---- ----------------------------- --- --- --- --- --- --- --------- <th>Value</th>
24 remote AS number n n n y n n [This.I-D] <th>Description</th>
25 IPv4 remote ASBR identifier n n n y n n [This.I-D] <th>22</th>
26 IPv6 remote ASBR identifier n n n y n n [This.I-D] <th>23</th>
TBD1 IPv6 local ASBR identifier n n n y n n [This.I-D] <th>25</th>
<th>141</th>
]]></artwork> <th>222</th>
</figure>As described above in Section 3.1, the sub-TLVs which are <th>223</th>
defined in <xref target="RFC5305"/>, <xref target="RFC6119"/> and <th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>24</td>
<td>Remote AS Number</td>
<td>n</td>
<td>n</td>
<td>n</td>
<td>y</td>
<td>n</td>
<td>n</td>
<td>RFC 9346</td>
</tr>
<tr>
<td>25</td>
<td>IPv4 Remote ASBR Identifier</td>
<td>n</td>
<td>n</td>
<td>n</td>
<td>y</td>
<td>n</td>
<td>n</td>
<td>RFC 9346</td>
</tr>
<tr>
<td>26</td>
<td>IPv6 Remote ASBR Identifier</td>
<td>n</td>
<td>n</td>
<td>n</td>
<td>y</td>
<td>n</td>
<td>n</td>
<td>RFC 9346</td>
</tr>
<tr>
<td>45</td>
<td>IPv6 Local ASBR Identifier</td>
<td>n</td>
<td>n</td>
<td>n</td>
<td>y</td>
<td>n</td>
<td>n</td>
<td>RFC 9346</td>
</tr>
</tbody>
</table>
<t>As described in <xref target="_RID" format="default"/>, the sub-TLVs
that are
defined in <xref target="RFC5305" format="default"/>, <xref target="RFC6
119" format="default"/>, and
other documents for describing the TE properties of a TE link are other documents for describing the TE properties of a TE link are
applicable to describe an inter-AS TE link and MAY be included in the applicable to describe an inter-AS TE link and <bcp14>MAY</bcp14> be inc
inter-AS reachability TLV when adverting inter-AS TE links.</t> luded in the
Inter-AS Reachability Information TLV when adverting inter-AS TE links.<
/t>
</section> </section>
<section numbered="true" toc="default" anchor="sub-tlv-is-is">
<section title="Sub-TLVs for the IS-IS Router Capability TLV"> <name>Sub-TLVs for the IS-IS Router CAPABILITY TLV</name>
<t>This document defines the following new sub-TLV types, described in <t>IANA has registered the following sub-TLV types of top-level
Sections 3.4.1 and 3.4.2, of top-level TLV 242 (which is defined in TLV 242 (see <xref target="RFC7981" format="default"/>) in the "IS-IS
<xref target="RFC7981"/>) that have been registered in the IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV" registry. These sub-TLVs are
Sub-TLVs for IS-IS Router CAPABILITY TLV registry:</t> described in Sections <xref target="remote-as" format="counter"/> and
<xref target="ipv4-remote" format="counter"/>.
<t><figure> </t>
<artwork><![CDATA[Type Description Refer <table align="center">
ence <thead>
11 IPv4 TE Router ID [This.I-D] <tr>
12 IPv6 TE Router ID [This.I-D] <th>Type</th>
]]></artwork> <th>Description</th>
</figure></t> <th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>11</td>
<td>IPv4 TE Router ID</td>
<td>RFC 9346</td>
</tr>
<tr>
<td>12</td>
<td>IPv6 TE Router ID</td>
<td>RFC 9346</td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
<section title="Acknowledgements">
<t>For the original version of <xref target="RFC5316"/> the authors
thanked Adrian Farrel, Jean-Louis Le Roux, Christian Hopps,
and Hannes Gredler for their review and comments on this
document.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include='reference.RFC.2119'?> <name>References</name>
<references>
<?rfc include='reference.RFC.1195'?> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include='reference.RFC.4271'?> 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
<?rfc include='reference.RFC.5305'?> 195.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<?rfc include='reference.RFC.5308'?> 271.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include='reference.RFC.5925'?> 305.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include='reference.RFC.6119'?> 308.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include='reference.RFC.7981'?> 925.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<?rfc include='reference.RFC.8174'?> 119.xml"/>
</references> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
981.xml"/>
<references title="Informative References"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.3209'?> 174.xml"/>
</references>
<?rfc include='reference.RFC.4216'?> <references>
<name>Informative References</name>
<?rfc include='reference.RFC.4655'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
209.xml"/>
<?rfc include='reference.RFC.5307'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
216.xml"/>
<?rfc include='reference.RFC.5152'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
655.xml"/>
<?rfc include='reference.RFC.5316'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
307.xml"/>
<?rfc include='reference.RFC.5304'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
152.xml"/>
<?rfc include='reference.RFC.5310'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
316.xml"/>
<?rfc include='reference.RFC.5441'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
304.xml"/>
<?rfc include='reference.RFC.6823'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
310.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
441.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
823.xml"/>
</references>
</references> </references>
<section numbered="true" toc="default">
<section title="Changes to RFC 5316"> <name>Changes to RFC 5316</name>
<t>The following is a summary of the substantive changes this document <t>The following is a summary of the substantive changes this document
makes to RFC 5316. Some editorial changes were also made.</t> makes to RFC 5316. Some editorial changes were also made.</t>
<t>RFC 5316 only allowed a 32-bit Router ID in the fixed header of TLV
<t>RFC 5316 only allowed a 32 bit Router ID in the fixed header of TLV
141. This is problematic in an IPv6-only deployment where an IPv4 141. This is problematic in an IPv6-only deployment where an IPv4
address may not be available. This document specifies:</t> address may not be available. This document specifies:</t>
<ol type="1">
<t>1. The Router ID should be identical to the value advertised in the <li>The Router ID should be identical to the value advertised in the
Traffic Engineering Router ID TLV (134) if available.</t> Traffic Engineering router ID TLV (134) if available.</li>
<li>If no Traffic Engineering Router ID is assigned, the Router ID
<t>2. If no Traffic Engineering Router ID is assigned the Router ID should be identical to an IP Interface Address <xref target="RFC1195" form
should be identical to an IP Interface Address [RFC1195] advertised by at="default"/> advertised by
the originating IS.</t> the originating IS.</li>
<li>If the originating node does not support IPv4, then the reserved
<t>3. 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 Local
value 0.0.0.0 must be used in the Router ID field and the new IPv6 Local ASBR Identifier sub-TLV must be present in the TLV.</li>
ASBR identifier sub-TLV must be present in the TLV.</t> </ol>
</section>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>In the previous version of this document <xref target="RFC5316" format=
"default"/>, the authors
thanked <contact fullname="Adrian Farrel"/>, <contact fullname="Jean-Louis
Le Roux"/>, <contact fullname="Christian Hopps"/>,
and <contact fullname="Hannes Gredler"/> for their review and comments.</t
>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 164 change blocks. 
580 lines changed or deleted 716 lines changed or added

This html diff was produced by rfcdiff 1.48.