rfc5316.txt   draft-ietf-lsr-isis-rfc5316bis-00.txt >
Network Working Group M. Chen Internet Engineering Task Force M. Chen
Request for Comments: 5316 R. Zhang Internet-Draft Huawei
Category: Standards Track Huawei Technologies Co., Ltd Obsoletes: 5316 (if approved) L. Ginsberg
X. Duan Intended status: Standards Track Cisco Systems
Expires: May 19, 2021 S. Previdi
Huawei Technologies
D. Xiaodong
China Mobile China Mobile
December 2008 November 15, 2020
ISIS Extensions in Support of Inter-Autonomous System (AS) ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and
MPLS and GMPLS Traffic Engineering GMPLS Traffic Engineering
draft-ietf-lsr-isis-rfc5316bis-00
Abstract
This document describes extensions to the Intermediate System to
Intermediate System (IS-IS) protocol to support Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
(TE) for multiple Autonomous Systems (ASs). It defines IS-IS
extensions for the flooding of TE information about inter-AS links,
which can be used to perform inter-AS TE path computation.
No support for flooding information from within one AS to another AS
is proposed or defined in this document.
This document obsoletes RFC 5316.
Requirements Language
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This document specifies an Internet standards track protocol for the This Internet-Draft is submitted in full conformance with the
Internet community, and requests discussion and suggestions for provisions of BCP 78 and BCP 79.
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Copyright (c) 2008 IETF Trust and the persons identified as the Internet-Drafts are draft documents valid for a maximum of six months
document authors. All rights reserved. and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This document is subject to BCP 78 and the IETF Trust's Legal This Internet-Draft will expire on May 19, 2021.
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Copyright Notice
This document describes extensions to the ISIS (ISIS) protocol to Copyright (c) 2020 IETF Trust and the persons identified as the
support Multiprotocol Label Switching (MPLS) and Generalized MPLS document authors. All rights reserved.
(GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems
(ASes). It defines ISIS-TE extensions for the flooding of TE
information about inter-AS links, which can be used to perform inter-
AS TE path computation.
No support for flooding information from within one AS to another AS This document is subject to BCP 78 and the IETF Trust's Legal
is proposed or defined in this document. Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ....................................................2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document ..........................3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
2. Problem Statement ...............................................3 2.1. A Note on Non-Objectives . . . . . . . . . . . . . . . . 4
2.1. A Note on Non-Objectives ...................................4 2.2. Per-Domain Path Determination . . . . . . . . . . . . . . 5
2.2. Per-Domain Path Determination ..............................4 2.3. Backward Recursive Path Computation . . . . . . . . . . . 6
2.3. Backward Recursive Path Computation ........................6 3. Extensions to ISIS-TE . . . . . . . . . . . . . . . . . . . . 7
3. Extensions to ISIS-TE ...........................................7 3.1. Inter-AS Reachability TLV . . . . . . . . . . . . . . . . 8
3.1. Inter-AS Reachability TLV ..................................7 3.2. TE Router ID . . . . . . . . . . . . . . . . . . . . . . 9
3.2. TE Router ID ...............................................9 3.3. Sub-TLVs for Inter-AS Reachability TLV . . . . . . . . . 10
3.3. Sub-TLV Detail .............................................9 3.3.1. Remote AS Number Sub-TLV . . . . . . . . . . . . . . 10
3.3.1. Remote AS Number Sub-TLV ............................9 3.3.2. IPv4 Remote ASBR ID Sub-TLV . . . . . . . . . . . . . 10
3.3.2. IPv4 Remote ASBR ID Sub-TLV ........................10 3.3.3. IPv6 Remote ASBR ID Sub-TLV . . . . . . . . . . . . . 11
3.3.3. IPv6 Remote ASBR ID Sub-TLV ........................11 3.3.4. IPv6 Local ASBR ID sub-TLV . . . . . . . . . . . . . 12
3.3.4. IPv4 TE Router ID sub-TLV ..........................11 3.4. Sub-TLVs for IS-IS Router Capability TLV . . . . . . . . 13
3.3.5. IPv6 TE Router ID sub-TLV ..........................12 3.4.1. IPv4 TE Router ID sub-TLV . . . . . . . . . . . . . . 13
4. Procedure for Inter-AS TE Links ................................12 3.4.2. IPv6 TE Router ID sub-TLV . . . . . . . . . . . . . . 13
4.1. Origin of Proxied TE Information ..........................14 4. Procedure for Inter-AS TE Links . . . . . . . . . . . . . . . 14
5. Security Considerations ........................................14 4.1. Origin of Proxied TE Information . . . . . . . . . . . . 15
6. IANA Considerations ............................................15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6.1. Inter-AS Reachability TLV .................................15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6.2. Sub-TLVs for the Inter-AS Reachability TLV ................15 6.1. Inter-AS Reachability TLV . . . . . . . . . . . . . . . . 17
6.3. Sub-TLVs for the IS-IS Router Capability TLV ..............17 6.2. Sub-TLVs for the Inter-AS Reachability TLV . . . . . . . 17
7. Acknowledgments ................................................17 6.3. Sub-TLVs for the IS-IS Router Capability TLV . . . . . . 17
8. References .....................................................17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References ......................................17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References ....................................17 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Changes to RFC 5316 . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
[ISIS-TE] defines extensions to the ISIS protocol [ISIS] to support [RFC5305] defines extensions to the IS-IS protocol [RFC1195] to
intra-area Traffic Engineering (TE). The extensions provide a way of support intra-area Traffic Engineering (TE). The extensions provide
encoding the TE information for TE-enabled links within the network a way of encoding the TE information for TE-enabled links within the
(TE links) and flooding this information within an area. The network (TE links) and flooding this information within an area. The
extended IS reachability TLV and traffic engineering router ID TLV, extended IS reachability TLV and traffic engineering router ID TLV,
which are defined in [ISIS-TE], are used to carry such TE which are defined in [RFC5305], are used to carry such TE
information. The extended IS reachability TLV has several nested information. The extended IS reachability TLV has several nested
sub-TLVs that describe the TE attributes for a TE link. sub-TLVs that describe the TE attributes for a TE link.
[ISIS-TE-V3] and [GMPLS-TE] define similar extensions to ISIS [ISIS] [RFC6119] and [RFC5307] define similar extensions to IS-IS in support
in support of IPv6 and GMPLS traffic engineering, respectively. of IPv6 and Generalized Multiprotocol Label Switching (GMPLS) TE
respectively.
Requirements for establishing Multiprotocol Label Switching (MPLS) TE 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 [INTER-AS-TE-REQ]. As described in [INTER- (ASes) are described in [RFC4216]. As described in [RFC4216], a
AS-TE-REQ], a method SHOULD provide the ability to compute a path method SHOULD provide the ability to compute a path spanning multiple
spanning multiple ASes. So a path computation entity that may be the ASes. So a path computation entity that may be the head-end Label
head-end Label Switching Router (LSR), an AS Border Router (ASBR), or Switching Router (LSR), an AS Border Router (ASBR), or a Path
a Path Computation Element (PCE [PCE]) needs to know the TE Computation Element (PCE) [RFC4655] needs to know the TE information
information not only of the links within an AS, but also of the links not only of the links within an AS, but also of the links that
that connect to other ASes. connect to other ASes.
In this document, a new TLV, which is referred to as the inter-AS In this document, a new TLV, which is referred to as the inter-AS
reachability TLV, is defined to advertise inter-AS TE information, reachability TLV, is defined to advertise inter-AS TE information,
and three new sub-TLVs are defined for inclusion in the inter-AS three new sub-TLVs are defined for inclusion in the inter-AS
reachability TLV to carry the information about the remote AS number reachability TLV to carry the information about the remote AS number
and remote ASBR ID. The sub-TLVs defined in [ISIS-TE], [ISIS-TE-V3], and remote ASBR ID. The sub-TLVs defined in [RFC5305][RFC6119] and
and other documents for inclusion in the extended IS reachability TLV other documents for inclusion in the extended IS reachability TLV for
for describing the TE properties of a TE link are applicable to be 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 TLV for describing the TE
properties of an inter-AS TE link as well. Also, two more new sub- properties of an inter-AS TE link as well. Also, two more new sub-
TLVs are defined for inclusion in the IS-IS router capability TLV to TLVs are defined for inclusion in the IS-IS router capability TLV to
carry the TE Router ID when the TE Router ID needs to reach all carry the TE Router ID when the TE Router ID needs to reach all
routers within an entire ISIS routing domain. The extensions are routers within an entire ISIS routing domain. The extensions are
equally applicable to IPv4 and IPv6 as identical extensions to equally applicable to IPv4 and IPv6 as identical extensions to
[ISIS-TE] and [ISIS-TE-V3]. Detailed definitions and procedures are [RFC5305] and [RFC6119]. Detailed definitions and procedures are
discussed in the following sections. discussed in the following sections.
This document does not propose or define any mechanisms to advertise This document does not propose or define any mechanisms to advertise
any other extra-AS TE information within ISIS. See Section 2.1 for a any other extra-AS TE information within ISIS. See Section 2.1 for a
full list of non-objectives for this work. full list of non-objectives for this work.
1.1. Conventions Used in This Document
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].
2. Problem Statement 2. Problem Statement
As described in [INTER-AS-TE-REQ], in the case of establishing an As described in [RFC4216], in the case of establishing an inter-AS TE
inter-AS TE LSP that traverses multiple ASes, the Path message LSP that traverses multiple ASes, the Path message [RFC3209] may
[RFC3209] may include the following elements in the Explicit Route include the following elements in the Explicit Route Object (ERO) in
Object (ERO) in order to describe the path of the LSP: order to describe the path of the LSP:
- a set of AS numbers as loose hops, and/or o a set of AS numbers as loose hops; and/or
- a set of LSRs including ASBRs as loose hops. o a set of LSRs including ASBRs as loose hops.
Two methods for determining inter-AS paths are currently being Two methods for determining inter-AS paths are currently being
discussed. The per-domain method [PD-PATH] determines the path one discussed. The per-domain method [RFC5152] determines the path one
domain at a time. The backward recursive method [BRPC] uses domain at a time. The backward recursive method [RFC5441] uses
cooperation between PCEs to determine an optimum inter-domain path. cooperation between PCEs to determine an optimum inter-domain path.
The sections that follow examine how inter-AS TE link information The sections that follow examine how inter-AS TE link information
could be useful in both cases. could be useful in both cases.
2.1. A Note on Non-Objectives 2.1. A Note on Non-Objectives
It is important to note that this document does not make any change 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 [INTER-AS-TE-REQ]. the requirements set out in [RFC4216].
The following features are explicitly excluded: The following features are explicitly excluded:
o There is no attempt to distribute TE information from within one o There is no attempt to distribute TE information from within one
AS to another AS. AS to another AS.
o There is no mechanism proposed to distribute any form of TE o There is no mechanism proposed to distribute any form of TE
reachability information for destinations outside the AS. reachability information for destinations outside the AS.
o There is no proposed change to the PCE architecture or usage. o There is no proposed change to the PCE architecture or usage.
o TE aggregation is not supported or recommended. o TE aggregation is not supported or recommended.
o There is no exchange of private information between ASes. o There is no exchange of private information between ASes.
o No ISIS adjacencies are formed on the inter-AS link. o No ISIS adjacencies are formed on the inter-AS link.
2.2. Per-Domain Path Determination 2.2. Per-Domain Path Determination
In the per-domain method of determining an inter-AS path for an In the per-domain method of determining an inter-AS path for an MPLS-
MPLS-TE LSP, when an LSR that is an entry-point to an AS receives a TE LSP, when an LSR that is an entry-point to an AS receives a Path
Path message from an upstream AS with an ERO containing a next hop message from an upstream AS with an ERO containing a next hop that is
that is an AS number, it needs to find which LSRs (ASBRs) within the an AS number, it needs to find which LSRs (ASBRs) within the local AS
local AS are connected to the downstream AS. That way, it can are connected to the downstream AS. That way, it can compute a TE
compute a TE LSP segment across the local AS to one of those LSRs and LSP segment across the local AS to one of those LSRs and forward the
forward the Path message to that LSR and hence into the next AS. See Path message to that LSR and hence into the next AS. See Figure 1
Figure 1 for an example. for an example.
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 1: Inter-AS Reference Model Figure 1: Inter-AS Reference Model
skipping to change at page 5, line 26 skipping to change at page 5, line 51
(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. exit ASBR.
Once the Path message reaches the exit ASBR, any choice of inter-AS 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. that computed the segment.
More details can be found in Section 4 of [PD-PATH], which clearly More details can be found in Section 4 of [RFC5152], which clearly
points out why advertising of inter-AS links is desired. points out why advertising of inter-AS links is desired.
To enable R5 to make the correct choice of exit ASBR, the following To enable R5 to make the correct choice of exit ASBR, the following
information is needed: information is needed:
o List of all inter-AS TE links for the local AS. o List of all inter-AS TE links for the local AS.
o TE properties of each inter-AS TE link. o TE properties of each inter-AS TE link.
o AS number of the neighboring AS connected to by each inter-AS TE o AS number of the neighboring AS connected to by each inter-AS TE
link. link.
o Identity (TE Router ID) of the neighboring ASBR connected to by o Identity (TE Router ID) of the neighboring ASBR connected to by
each inter-AS TE link. each inter-AS TE link.
In GMPLS networks, further information may also be required to select In GMPLS networks, further information may also be required to select
the correct TE links as defined in [GMPLS-TE]. the correct TE links as defined in [RFC5307].
The example above shows how this information is needed at the entry- The example above shows how this information is needed at the entry-
point ASBRs for each AS (or the PCEs that provide computation 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. that have start points (ingress nodes) within the AS.
2.3. Backward Recursive Path Computation 2.3. Backward Recursive Path Computation
Another scenario using PCE techniques has the same problem. [BRPC] Another scenario using PCE techniques has the same problem.
defines a PCE-based TE LSP computation method (called Backward [RFC5441] defines a PCE-based TE LSP computation method (called
Recursive Path Computation) to compute optimal inter-domain Backward Recursive Path Computation) to compute optimal inter-domain
constrained MPLS-TE or GMPLS LSPs. In this path computation method, constrained MPLS-TE or GMPLS LSPs. In this path computation method,
a specific set of traversed domains (ASes) are assumed to be selected a specific set of traversed domains (ASes) are assumed to be selected
before computation starts. Each downstream PCE in domain(i) returns before computation starts. Each downstream PCE in domain(i) returns
to its upstream neighbor PCE in domain(i-1) a multipoint-to-point to its upstream neighbor PCE in domain(i-1) a multipoint-to-point
tree of potential paths. Each tree consists of the set of paths from tree of potential paths. Each tree consists of the set of paths from
all boundary nodes located in domain(i) to the destination where each all boundary nodes located in domain(i) to the destination where each
path satisfies the set of required constraints for the TE LSP path satisfies the set of required constraints for the TE LSP
(bandwidth, affinities, etc.). (bandwidth, affinities, etc.).
So a PCE needs to select boundary nodes (that is, ASBRs) that provide So a PCE needs to select boundary nodes (that is, ASBRs) that provide
skipping to change at page 6, line 39 skipping to change at page 7, line 16
/ : : / : :
/ : : / : :
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 Figure 2: BRPC for Inter-AS Reference Model
The figure shows three ASes (AS1, AS2, and AS3), three PCEs (PCE1, 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 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 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 ASBRs in AS3. PCE1, PCE2, and PCE3 cooperate to perform inter-AS
path computation and are responsible for path segment computation path computation and are responsible for path segment computation
within their own domain(s). within their own domain(s).
If an inter-AS TE LSP is planned to be established from R1 to R12, If an inter-AS TE LSP is planned to be established from R1 to R12,
the traversed domains are assumed to be selected: AS1->AS2->AS3, and the traversed domains are assumed to be selected: AS1->AS2->AS3, and
skipping to change at page 7, line 32 skipping to change at page 8, line 10
form of TE reachability information for destinations outside the AS, form of TE reachability information for destinations outside the AS,
does not change the PCE architecture or usage, does not suggest or does not change the PCE architecture or usage, does not suggest or
recommend any form of TE aggregation, and does not feed private recommend any form of TE aggregation, and does not feed private
information between ASes. See Section 2.1. information between ASes. See Section 2.1.
In this document, for the advertisement of inter-AS TE links, a new In this document, for the advertisement of inter-AS TE links, a new
TLV, which is referred to as the inter-AS reachability TLV, is TLV, which is referred to as the inter-AS reachability TLV, is
defined. Three new sub-TLVs are also defined for inclusion in the defined. Three new sub-TLVs are also defined for inclusion in the
inter-AS reachability TLV to carry the information about the inter-AS reachability TLV to carry the information about the
neighboring AS number and the remote ASBR ID of an inter-AS link. neighboring AS number and the remote ASBR ID of an inter-AS link.
The sub-TLVs defined in [ISIS-TE], [ISIS-TE-V3], and other documents The sub-TLVs defined in [RFC5305], [RFC6119], and other documents for
for inclusion in the extended IS reachability TLV are applicable to inclusion in the extended IS reachability TLV are applicable to be
be included in the inter-AS reachability TLV for inter-AS TE links included in the inter-AS reachability TLV for inter-AS TE links
advertisement. Also, two other new sub-TLVs are defined for advertisement. Also, two other new sub-TLVs are defined for
inclusion in the IS-IS router capability TLV to carry the TE Router 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 ID when the TE Router ID is needed to reach all routers within an
entire ISIS routing domain. entire ISIS routing domain.
While some of the TE information of an inter-AS TE link may be 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 dependency on where such protocols are processed, this mechanism
carries all the information needed for the required TE operations. carries all the information needed for the required TE operations.
3.1. Inter-AS Reachability TLV 3.1. Inter-AS Reachability TLV
The inter-AS reachability TLV has type 141 (see Section 6.1) and The inter-AS reachability TLV has type 141 (see Section 6.1) and
contains a data structure consisting of: contains a data structure consisting of:
o 4 octets of Router ID 4 octets of Router ID
o 3 octets of default metric 3 octets of default metric
o 1 octet of control information, consisting of: 1 octet of control information, consisting of:
- 1 bit of flooding-scope information (S bit) 1 bit of flooding-scope information (S bit)
- 1 bit of up/down information (D bit) 1 bit of up/down information (D bit)
- 6 bits reserved 6 bits reserved
o 1 octet of length of sub-TLVs 1 octet of length of sub-TLVs
o 0-246 octets of sub-TLVs, where each sub-TLV consists of a 0-246 octets of sub-TLVs, where each sub-TLV consists of a sequence
sequence of: of:
- 1 octet of sub-type 1 octet of sub-type
- 1 octet of length of the value field of the sub-TLV 1 octet of length of the value field of the sub-TLV
- 0-244 octets of value 0-244 octets of value
Compared to the extended reachability TLV, which is defined in Compared to the extended reachability TLV which is defined in
[ISIS-TE], the inter-AS reachability TLV replaces the "7 octets of [RFC5305], the inter-AS reachability TLV replaces the "7 octets of
System ID and Pseudonode Number" field with a "4 octets of Router ID" System ID and Pseudonode Number" field with a "4 octets of Router ID"
field and introduces an extra "control information" field, which field and introduces an extra "control information" field, which
consists of a flooding-scope bit (S bit), an up/down bit (D bit), and consists of a flooding-scope bit (S bit), an up/down bit (D bit), and
6 reserved bits. 6 reserved bits.
The Router ID field of the inter-AS reachability TLV is 4 octets in The Router ID field of the inter-AS reachability TLV is 4 octets in
length, which contains the Router ID of the router who generates the length, which contains the IPv4 Router ID of the router who generates
inter-AS reachability TLV. The Router ID MUST be unique within the the inter-AS reachability TLV. The Router ID SHOULD be identical to
ISIS area. If the router generates inter-AS reachability TLV with the value advertised in the Traffic Engineering Router ID TLV
entire ISIS routing domain flooding scope, then the Router ID MUST [RFC5305]. If no Traffic Engineering Router ID is assigned, the
also be unique within the entire ISIS routing domain. The Router ID Router ID SHOULD be identical to an IP Interface Address [RFC1195]
could be used to indicate the source of the inter-AS reachability advertised by the originating IS. If the originating node does not
TLV. support IPv4, then the reserved value 0.0.0.0 MUST be used in the
Router ID field and the IPv6 Router ID sub-TLV MUST be present in the
inter-AS reachability TLV. The Router ID could be used to indicate
the source of the inter-AS reachability TLV.
The flooding procedures for inter-AS reachability TLV are identical The flooding procedures for inter-AS reachability 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 [GENINFO]. These procedures have been previously Section 4 of [RFC6823]. These procedures have been previously
discussed in [ISIS-CAP]. The flooding-scope bit (S bit) SHOULD be discussed in [RFC7981]. The flooding-scope bit (S bit) SHOULD be set
set to 0 if the flooding scope is to be limited to within the single to 0 if the flooding scope is to be limited to within the single IGP
IGP area to which the ASBR belongs. It MAY be set to 1 if the area to which the ASBR belongs. It MAY be set to 1 if the
information is intended to reach all routers (including area border information is intended to reach all routers (including area border
routers, ASBRs, and PCEs) in the entire ISIS routing domain. The routers, ASBRs, and PCEs) in the entire ISIS routing domain. The
choice between the use of 0 or 1 is an AS-wide policy choice, and choice between the use of 0 or 1 is an AS-wide policy choice, and
configuration control SHOULD be provided in ASBR implementations that configuration control SHOULD be provided in ASBR implementations that
support the advertisement of inter-AS TE links. support the advertisement of inter-AS TE links.
The sub-TLVs defined in [ISIS-TE], [ISIS-TE-V3], and other documents The sub-TLVs defined in [RFC5305], [RFC6119], and other documents for
for describing the TE properties of a TE link are also applicable to describing the TE properties of a TE link are also applicable to the
the inter-AS reachability TLV for describing the TE properties of an inter-AS reachability TLV for describing the TE properties of an
inter-AS TE link. Apart from these sub-TLVs, three new sub-TLVs are Inter-AS TE link. Apart from these sub-TLVs, four new sub-TLVs are
defined for inclusion in the inter-AS reachability TLV defined in defined for inclusion in the inter-AS reachability TLV defined in
this document: this document:
Sub-TLV type Length Name Sub-TLV type Length Name
------------ ------ --------------------------- ------------ ------ ---------------------------
24 4 remote AS number 24 4 remote AS number
25 4 IPv4 remote ASBR identifier 25 4 IPv4 remote ASBR identifier
26 16 IPv6 remote ASBR identifier 26 16 IPv6 remote ASBR identifier
TBD1 16 IPv6 Router ID
The detailed definitions of the three new sub-TLVs are described in Detailed definitions of the four new sub-TLVs are described in
Section 3.3. Sections 3.3.1, 3.3.2, 3.3.3, and 3.3.4.
3.2. TE Router ID 3.2. TE Router ID
The IPv4 TE Router ID TLV and IPv6 TE Router ID TLV, which are The IPv4 TE Router ID TLV and IPv6 TE Router ID TLV, which are
defined in [ISIS-TE] and [ISIS-TE-V3] respectively, only have area defined in [RFC5305] and [RFC6119] respectively, only have area
flooding-scope. When performing inter-AS TE, the TE Router ID MAY be flooding-scope. When performing inter-AS TE, the TE Router ID MAY be
needed to reach all routers within an entire ISIS routing domain and needed to reach all routers within an entire ISIS routing domain and
it MUST have the same flooding scope as the inter-AS reachability TLV it MUST have the same flooding scope as the Inter-AS Reachability TLV
does. does.
[ISIS-CAP] defines a generic advertisement mechanism for ISIS, which [RFC7981] defines a generic advertisement mechanism for ISIS which
allows a router to advertise its capabilities within an ISIS area or allows a router to advertise its capabilities within an ISIS area or
an entire ISIS routing domain. [ISIS-CAP] also points out that the an entire ISIS routing domain. [RFC7981] also points out that the TE
TE Router ID is a candidate to be carried in the IS-IS router Router ID is a candidate to be carried in the IS-IS router capability
capability TLV when performing inter-area TE. TLV when performing inter-area TE.
This document uses such mechanism for TE Router ID advertisement when This document uses such mechanism for TE Router ID advertisement when
the TE Router ID is needed to reach all routers within an entire ISIS the TE Router ID is needed to reach all routers within an entire ISIS
Routing domain. Two new sub-TLVs are defined for inclusion in the Routing domain. Two new sub-TLVs are defined for inclusion in the
IS-IS router capability TLV to carry the IPv4 and IPv6 TE Router IDs, IS-IS Router Capability TLV to carry the TE Router IDs.
respectively:
Sub-TLV type Length Name Sub-TLV type Length Name
------------ ------ ----------------- ------------ ------ -----------------
11 4 IPv4 TE Router ID 11 4 IPv4 TE Router ID
12 16 IPv6 TE Router ID 12 16 IPv6 TE Router ID
Detailed definitions of the two new sub-TLVs are described in Section Detailed definitions of the new sub-TLV are described in
3.3. Section 3.4.1 and 3.4.2.
3.3. Sub-TLV Detail 3.3. Sub-TLVs for Inter-AS Reachability TLV
3.3.1. Remote AS Number Sub-TLV 3.3.1. Remote AS Number Sub-TLV
A new sub-TLV, the remote AS number sub-TLV, is defined for inclusion A new sub-TLV, the remote AS number sub-TLV, is defined for inclusion
in the inter-AS reachability TLV when advertising inter-AS links. in the inter-AS reachability TLV when advertising inter-AS links.
The remote AS number sub-TLV specifies the AS number of the The remote AS number sub-TLV specifies the AS number of the
neighboring AS to which the advertised link connects. neighboring AS to which the advertised link connects.
The remote AS number sub-TLV is TLV type 24 (see Section 6.2) and is The remote AS number sub-TLV is TLV type 24 (see Section 6.2) and is
4 octets in length. The format is as follows: 4 octets in length. The format is as follows:
0 1 2 3 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Remote AS number field has 4 octets. When only 2 octets are used The remote AS number field has 4 octets. When only 2 octets are used
for the AS number, as in current deployments, the left (high-order) 2 for the AS number, as in current deployments, the left (high-order) 2
octets MUST be set to 0. The remote AS number sub-TLV MUST be octets MUST be set to 0. The remote AS number sub-TLV MUST be
included when a router advertises an inter-AS TE link. included when a router advertises an inter-AS TE link.
3.3.2. IPv4 Remote ASBR ID Sub-TLV 3.3.2. IPv4 Remote ASBR ID Sub-TLV
A new sub-TLV, which is referred to as the IPv4 remote ASBR ID sub- A new sub-TLV, which is referred to as the IPv4 remote ASBR ID sub-
TLV, is defined for inclusion in the inter-AS reachability TLV when TLV, is defined for inclusion in the inter-AS reachability TLV when
advertising inter-AS links. The IPv4 remote ASBR ID sub-TLV advertising inter-AS links. The IPv4 remote ASBR ID sub-TLV
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. This could be any stable and advertised inter-AS link connects. This could be any stable and
routable IPv4 address of the remote ASBR. Use of the TE Router ID as routable IPv4 address of the remote ASBR. Use of the TE Router ID as
specified in the Traffic Engineering router ID TLV [ISIS-TE] is specified in the Traffic Engineering router ID TLV [RFC5305] is
RECOMMENDED. RECOMMENDED.
The IPv4 remote ASBR ID sub-TLV is TLV type 25 (see Section 6.2) and The IPv4 remote ASBR ID sub-TLV is TLV type 25 (see Section 6.2) and
is 4 octets in length. The format of the IPv4 remote ASBR ID sub-TLV is 4 octets in length. The format of the IPv4 remote ASBR ID sub-TLV
is as follows: is as follows:
0 1 2 3 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 |
skipping to change at page 11, line 13 skipping to change at page 11, line 35
reachability TLV. reachability TLV.
3.3.3. IPv6 Remote ASBR ID Sub-TLV 3.3.3. IPv6 Remote ASBR ID Sub-TLV
A new sub-TLV, which is referred to as the IPv6 remote ASBR ID sub- A new sub-TLV, which is referred to as the IPv6 remote ASBR ID sub-
TLV, is defined for inclusion in the inter-AS reachability TLV when TLV, is defined for inclusion in the inter-AS reachability TLV when
advertising inter-AS links. The IPv6 remote ASBR ID sub-TLV advertising inter-AS links. The IPv6 remote ASBR ID sub-TLV
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. This could be any stable and advertised inter-AS link connects. This could be any stable and
routable IPv6 address of the remote ASBR. Use of the TE Router ID as routable IPv6 address of the remote ASBR. Use of the TE Router ID as
specified in the IPv6 Traffic Engineering router ID TLV [ISIS-TE-V3] specified in the IPv6 Traffic Engineering router ID TLV [RFC6119] is
is RECOMMENDED. RECOMMENDED.
The IPv6 remote ASBR ID sub-TLV is TLV type 26 (see Section 6.2) and The IPv6 remote ASBR ID sub-TLV is TLV type 26 (see Section 6.2) and
is 16 octets in length. The format of the IPv6 remote ASBR ID sub- is 16 octets in length. The format of the IPv6 remote ASBR ID sub-
TLV is as follows: TLV is as follows:
0 1 2 3 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 37 skipping to change at page 12, line 22
| Remote ASBR ID (continued) | | Remote ASBR ID (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote ASBR ID (continued) | | Remote ASBR ID (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote ASBR ID (continued) | | Remote ASBR ID (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 remote ASBR ID sub-TLV MUST be included if the neighboring The IPv6 remote ASBR ID sub-TLV MUST be included if the neighboring
ASBR has an IPv6 address. If the neighboring ASBR does not have an ASBR has an IPv6 address. If the neighboring ASBR does not have an
IPv6 address, the IPv4 remote ASBR ID sub-TLV MUST be included IPv6 address, the IPv4 remote ASBR ID sub-TLV MUST be included
instead. An IPv4 remote ASBR ID sub-TLV and IPv6 remote ASBR ID instead. An IPv4 remote ASBR ID sub-TLV and IPv6 remote ASBR ID sub-
sub-TLV MAY both be present in an extended IS reachability TLV. TLV MAY both be present in an extended IS reachability TLV.
3.3.4. IPv4 TE Router ID sub-TLV 3.3.4. IPv6 Local ASBR ID sub-TLV
The IPv6 Local ASBR ID sub-TLV is TLV type TBD1 (see Section 6.3) and
is 16 octets in length. The format of the IPv6 Router ID sub-TLV is
as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local ASBR ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local ASBR ID (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local ASBR ID (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local ASBR ID (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 Local ASBR ID SHOULD be identical to the value advertised in
the IPv6 Traffic Engineering Router ID TLV [RFC6119].
If the originating node does not support IPv4, the IPv6 Local ASBR ID
sub-TLV MUST be present in the inter-AS reachability TLV. Inter-AS
reachability TLVs which have a Router ID of 0.0.0.0 and do NOT have
the IPv6 Local ASBR ID sub-TLV present MUST be ignored.
3.4. Sub-TLVs for IS-IS Router Capability TLV
3.4.1. IPv4 TE Router ID sub-TLV
The IPv4 TE Router ID sub-TLV is TLV type 11 (see Section 6.3) and is The IPv4 TE Router ID sub-TLV is TLV type 11 (see Section 6.3) and is
4 octets in length. The format of the IPv4 TE Router ID sub-TLV is 4 octets in length. The format of the IPv4 TE Router ID sub-TLV is
as follows: as follows:
0 1 2 3 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv4 TE Router ID SHOULD be identical to the value advertised in
the IPv4 Traffic Engineering Router ID TLV [RFC5305].
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
ISIS routing domain, the IS-IS Router capability TLV MUST be included ISIS routing domain, the IS-IS Router capability TLV MUST be included
in its LSP. If an ASBR supports Traffic Engineering for IPv4 and if 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 sub-TLV MUST 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 Router ID, the be included. If the ASBR does not have an IPv4 TE Router ID, the
IPv6 TE Router sub-TLV MUST be included instead. An IPv4 TE Router IPv6 TE Router sub-TLV MUST be included instead. An IPv4 TE Router
ID sub-TLV and IPv6 TE Router ID sub-TLV MAY both be present in an ID sub-TLV and IPv6 TE Router ID sub-TLV MAY both be present in an
IS-IS router capability TLV. IS-IS router capability TLV.
3.3.5. IPv6 TE Router ID sub-TLV 3.4.2. IPv6 TE Router ID sub-TLV
The IPv6 TE Router ID sub-TLV is TLV type 12 (see Section 6.3) and is The IPv6 TE Router ID sub-TLV is TLV type 12 (see Section 6.3) and is
4 octets in length. The format of the IPv6 TE Router ID sub-TLV is 16 octets in length. The format of the IPv6 TE Router ID sub-TLV is
as follows: as follows:
0 1 2 3 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 TE Router ID SHOULD be identical to the value advertised in
the IPv6 Traffic Engineering Router ID TLV [RFC6119].
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
ISIS routing domain, the IS-IS router capability TLV MUST be included ISIS routing domain, the IS-IS router capability TLV MUST be included
in its LSP. If an ASBR supports Traffic Engineering for IPv6 and if 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 sub-TLV MUST 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 Router ID, the be included. If the ASBR does not have an IPv6 TE Router ID, the
IPv4 TE Router sub-TLV MUST be included instead. An IPv4 TE Router IPv4 TE Router sub-TLV MUST be included instead. An IPv4 TE Router
ID sub-TLV and IPv6 TE Router ID sub-TLV MAY both be present in an ID sub-TLV and IPv6 TE Router ID sub-TLV MAY both be present in an
IS-IS router capability TLV. IS-IS router capability TLV.
4. Procedure for Inter-AS TE Links 4. Procedure for Inter-AS TE Links
When TE is enabled on an inter-AS link and the link is up, the ASBR 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 ISIS-TE SHOULD advertise this link using the normal procedures for [RFC5305].
[ISIS-TE]. When either the link is down or TE is disabled on the When either the link is down or TE is disabled on the link, the ASBR
link, the ASBR SHOULD withdraw the advertisement. When there are SHOULD withdraw the advertisement. When there are changes to the TE
changes to the TE parameters for the link (for example, when the parameters for the link (for example, when the available bandwidth
available bandwidth changes), the ASBR SHOULD re-advertise the link changes), the ASBR SHOULD re-advertise the link but MUST take
but MUST take precautions against excessive re-advertisements. precautions against excessive re-advertisements.
Hellos MUST NOT be exchanged over the inter-AS link, and Hellos MUST NOT be exchanged over the inter-AS link, and
consequently, an ISIS adjacency MUST NOT be formed. consequently, an ISIS adjacency MUST NOT be formed.
The information advertised comes from the ASBR's knowledge of the TE The information advertised comes from the ASBR's knowledge of the TE
capabilities of the link, the ASBR's knowledge of the current status 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 and usage of the link, and configuration at the ASBR of the remote AS
number and remote ASBR TE Router ID. number and remote ASBR TE Router ID.
Legacy routers receiving an advertisement for an inter-AS TE link are 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 able to ignore it because they do not know the new TLV and sub-TLVs
that are defined in Section 3 of this document. They will continue that are defined in Section 3 of this document. They will continue
to flood the LSP, but will not attempt to use the information to flood the LSP, but will not attempt to use the information
received. received.
In the current operation of ISIS TE, the LSRs at each end of a TE In the current operation of ISIS TE, the LSRs at each end of a TE
link emit LSAs describing the link. The databases in the LSRs then link emit LSPs describing the link. The databases in the LSRs then
have two entries (one locally generated, the other from the peer) have two entries (one locally generated, the other from the peer)
that describe the different 'directions' of the link. This enables that describe the different 'directions' of the link. This enables
Constrained Shortest Path First (CSPF) to do a two-way check on the Constrained Shortest Path First (CSPF) to do a two-way check on the
link when performing path computation and eliminate it from link when performing path computation and eliminate it from
consideration unless both directions of the link satisfy the required consideration unless both directions of the link satisfy the required
constraints. constraints.
In the case we are considering here (i.e., of a TE link to another 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 AS), there is, by definition, no IGP peering and hence no
bidirectional TE link information. In order for the CSPF route bidirectional TE link information. In order for the CSPF route
computation entity to include the link as a candidate path, we have computation entity to include the link as a candidate path, we have
to find a way to get LSAs describing its (bidirectional) TE to find a way to get LSPs describing its (bidirectional) TE
properties into the TE database. properties into the TE database.
This is achieved by the ASBR advertising, internally to its AS, 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 LSA describing its own side of a link; ASBR will normally generate a 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 LSA that describes that device's 'view' of the generate an additional LSP that describes that device's 'view' of the
link. link.
Only some essential TE information for the link needs to be Only some essential TE information for the link needs to be
advertised; i.e., the Interface Address, the remote AS number, and advertised; i.e., the Interface Address, the remote AS number, and
the remote ASBR ID of an inter-AS TE link. the remote ASBR ID of an inter-AS TE link.
Routers or PCEs that are capable of processing advertisements of Routers or PCEs that are capable of processing advertisements of
inter-AS TE links SHOULD NOT use such links to compute paths that inter-AS TE links SHOULD NOT use such links to compute paths that
exit an AS to a remote ASBR and then immediately re-enter the AS exit an AS to a remote ASBR and then immediately re-enter the AS
through another TE link. Such paths would constitute extremely rare through another TE link. Such paths would constitute extremely rare
skipping to change at page 14, line 29 skipping to change at page 16, line 18
advantageous, to obtain some of the required configuration advantageous, to obtain some of the required configuration
information from BGP. Whether and how to utilize these possibilities information from BGP. Whether and how to utilize these possibilities
is an implementation matter. is an implementation matter.
5. Security Considerations 5. Security Considerations
The protocol extensions defined in this document are relatively minor The protocol extensions defined in this document are relatively minor
and can be secured within the AS in which they are used by the and can be secured within the AS in which they are used by the
existing ISIS security mechanisms (e.g., using the cleartext existing ISIS security mechanisms (e.g., using the cleartext
passwords or Hashed Message Authentication Codes - Message Digest 5 passwords or Hashed Message Authentication Codes - Message Digest 5
(HMAC-MD5) algorithm, which are defined in [ISIS] and [RFC5304], (HMAC-MD5) algorithm, which are defined in [RFC1195] and [RFC5304]
respectively). separately).
There is no exchange of information between ASes, and no change to There is no exchange of information between ASes, and no change to
the ISIS security relationship between the ASes. In particular, the ISIS security relationship between the ASes. In particular,
since no ISIS adjacency is formed on the inter-AS links, there is no since no ISIS adjacency is formed on the inter-AS links, there is no
requirement for ISIS security between the ASes. requirement for ISIS security between the ASes.
Some of the information included in these new advertisements (e.g., Some of the information included in these new advertisements (e.g.,
the remote AS number and the remote ASBR ID) is obtained manually the remote AS number and the remote ASBR ID) is obtained manually
from a neighboring administration as part of a commercial from a neighboring administration as part of a commercial
relationship. The source and content of this information should be relationship. The source and content of this information should be
carefully checked before it is entered as configuration information carefully checked before it is entered as configuration information
at the ASBR responsible for advertising the inter-AS TE links. at the ASBR responsible for advertising the inter-AS TE links.
It is worth noting that in the scenario we are considering, a Border It is worth noting that in the scenario we are considering, a Border
Gateway Protocol (BGP) peering may exist between the two ASBRs and Gateway Protocol (BGP) peering may exist between the two ASBRs and
that this could be used to detect inconsistencies in configuration that this could be used to detect inconsistencies in configuration
(e.g., the administration that originally supplied the information (e.g., the administration that originally supplied the information
may be lying, or some manual mis-configurations or mistakes may be may be lying, or some manual mis-configurations or mistakes may be
made by the operators). For example, if a different remote AS number made by the operators). For example, if a different remote AS number
is received in a BGP OPEN [BGP] from that locally configured to is received in a BGP OPEN [RFC4271] from that locally configured to
ISIS-TE, as we describe here, then local policy SHOULD be applied to ISIS-TE, as we describe here, then local policy SHOULD be applied to
determine whether to alert the operator to a potential mis- determine whether to alert the operator to a potential mis-
configuration or to suppress the ISIS advertisement of the inter-AS configuration or to suppress the IS-IS advertisement of the inter-AS
TE link. Note further that if BGP is used to exchange TE information TE link. Note further that if BGP is used to exchange TE information
as described in Section 4.1, the inter-AS BGP session SHOULD be as described in Section 4.1, the inter-AS BGP session SHOULD be
secured using mechanisms as described in [BGP] to provide secured using mechanisms as described in [RFC4271] to provide
authentication and integrity checks. authentication and integrity checks.
For a discussion of general security considerations for IS-IS, see For a discussion of general security considerations for IS-IS, see
[RFC5304]. [RFC5304].
6. IANA Considerations 6. IANA Considerations
IANA has made the following allocations from registries under its IANA is requested to make the following allocations from registries
control. under its control.
6.1. Inter-AS Reachability TLV 6.1. Inter-AS Reachability TLV
This document defines the following new ISIS TLV type, described in This document defines the following new ISI-IS TLV type, described in
Section 3.1, which has been registered in the ISIS TLV codepoint Section 3.1, which has been registered in the IS-IS TLV codepoint
registry: registry:
Type Description IIH LSP SNP Type Description IIH LSP SNP Purge
---- ---------------------- --- --- --- ---- ---------------------- --- --- --- -----
141 inter-AS reachability n y n 141 inter-AS reachability n y n n
information information
6.2. Sub-TLVs for the Inter-AS Reachability TLV 6.2. Sub-TLVs for the Inter-AS Reachability TLV
This document defines the following new sub-TLV types (described in This document defines the following new sub-TLV types (described in
Sections 3.3.1, 3.3.2, and 3.3.3) of top-level TLV 141 (see Section Sections 3.3.1, 3.3.2, 3.3.3, and, 3.3.4) of top-level TLV 141 (see
6.1 above), which have been registered in the ISIS sub-TLV registry Section 6.1 above). Three of these sub-TLVs have been registered in
for TLV 141. Note that these three new sub-TLVs SHOULD NOT appear in the IS-IS sub-TLV registry for TLVs 22, 23, 25, 141, 222, and 223 by
TLV 22 (or TLV 222) and MUST be ignored in TLV 22 (or TLV 222). [RFC5316]. One additional sub-TLV (IPv6 local ASBR identifier) is
introduced by this document and needs to be added to the same
Type Description registry. Note that all four sub-TLVs SHOULD NOT appear in TLVs 22,
---- ------------------------------ 23, 25, 222, or 223 and MUST be ignored if they are included in any
24 remote AS number of these TLVs.
25 IPv4 remote ASBR Identifier
26 IPv6 remote ASBR Identifier
As described above in Section 3.1, the sub-TLVs defined in [ISIS-TE],
[ISIS-TE-V3], and 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 inter-AS reachability TLV when adverting inter-AS TE
links.
IANA has updated the registry that was specified as "Sub-TLVs for TLV
22" to be named "Sub-TLVs for TLVs 22, 141, and 222". Three new
columns have been added to the registry to show in which TLVs the
sub-TLVs may be present. All sub-TLVs currently defined may be
present in all three TLVs, hence the registry (with the definition of
the new sub-TLVs defined here) should read as follows.
TLV TLV TLV Type Description 22 23 25 141 222 223 Reference
Type Description 22 141 222 Reference ---- ----------------------------- --- --- --- --- --- --- ---------
------- ------------------------------------ --- --- --- --------- 24 remote AS number n n n y n n [This.I-D]
0 Unassigned y y y 25 IPv4 remote ASBR identifier n n n y n n [This.I-D]
1 Unassigned y y y 26 IPv6 remote ASBR identifier n n n y n n [This.I-D]
2 Unassigned y y y TBD1 IPv6 local ASBR identifier n n n y n n [This.I-D]
3 Administrative group (color) y y y [RFC5305]
4 Link Local/Remote Identifiers y y y
[RFC4205][RFC5307]
5 Unassigned y y y
6 IPv4 interface address y y y [RFC5305]
7 Unassigned y y y
8 IPv4 neighbor address y y y [RFC5305]
9 Maximum link bandwidth y y y [RFC5305]
10 Maximum reservable link bandwidth y y y [RFC5305]
11 Unreserved bandwidth y y y [RFC5305]
12 Unassigned y y y
13 Unassigned y y y
14 Unassigned y y y
15 Unassigned y y y
16 Unassigned y y y
17 Unassigned y y y
18 TE Default metric y y y [RFC5305]
19 Link-attributes y y y [RFC5029]
20 Link Protection Type y y y
[RFC4205][RFC5307]
21 Interface Switching Capability Desc y y y
[RFC4205][RFC5307]
22 Bandwidth Constraints y y y [RFC4124]
23 Unconstrained TE LSP Count (sub-)TLV y y y [RFC5330]
24 remote AS number n y n [RFC5316]
25 IPv4 remote ASBR identifier n y n [RFC5316]
26 IPv6 remote ASBR identifier n y n [RFC5316]
27-249 Unassigned
250-254 Reserved for Cisco-specific exts
255 Reserved for future expansion
Further sub-TLVs may be defined in the future for inclusion in any of As described above in Section 3.1, the sub-TLVs which are defined in
the TLVs 22, 141, or 222. The re-naming of the registry as above [RFC5305], [RFC6119] and other documents for describing the TE
ensures that there is no accidental overlap of sub-TLV codepoints. properties of an TE link are applicable to describe an inter-AS TE
The introduction of the columns within the registry clarify the use link and MAY be included in the inter-AS reachability TLV when
of the sub-TLVs. adverting inter-AS TE links.
6.3. Sub-TLVs for the IS-IS Router Capability TLV 6.3. Sub-TLVs for the IS-IS Router Capability TLV
This document defines the following new sub-TLV types, described in This document defines the following new sub-TLV types, described in
Sections 3.3.4 and 3.3.5, of top-level TLV 242 (which is defined in Sections 3.4.1 and 3.4.2, of top-level TLV 242 (which is defined in
[ISIS-CAP]) that have been registered in the ISIS sub-TLV registry [RFC7981]) that have been registered in the IS-IS sub-TLV registry
for TLV 242: for TLV 242:
Type Description Length Type Description Length
---- ------------------------------ -------- ---- ------------------------------ --------
11 IPv4 TE Router ID 4 11 IPv4 TE Router ID 4
12 IPv6 TE Router ID 16 12 IPv6 TE Router ID 16
7. Acknowledgments 7. Acknowledgements
The authors would like to thank Adrian Farrel, Jean-Louis Le Roux, For the original version of [RFC5316] the authors would like to thank
Christian Hopps, Les Ginsberg, and Hannes Gredler for their review Adrian Farrel, Jean-Louis Le Roux, Christian Hopps, Les Ginsberg, and
and comments on this document. Hannes Gredler for their review and comments on this document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
Requirement Levels", BCP 14, RFC 2119, March 1997. dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Srinivasan, V., and G. Swallow, "RSVP-TE: Requirement Levels", BCP 14, RFC 2119,
Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC2119, March 1997,
December 2001. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Authentication", RFC 5304, October 2008. Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
and dual environments", RFC 1195, December 1990. Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
February 2011, <https://www.rfc-editor.org/info/rfc6119>.
[ISIS-CAP] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
Ed., "Intermediate System to Intermediate System 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
(IS-IS) Extensions for Advertising Router May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Information", RFC 4971, July 2007.
8.2. Informative References 8.2. Informative References
[INTER-AS-TE-REQ] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
Inter-Autonomous System (AS) Traffic Engineering and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
(TE) Requirements", RFC 4216, November 2005. Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[PD-PATH] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, [RFC4216] Zhang, R., Ed. and J. Vasseur, Ed., "MPLS Inter-Autonomous
"A Per-Domain Path Computation Method for System (AS) Traffic Engineering (TE) Requirements",
Establishing Inter-Domain Traffic Engineering (TE) RFC 4216, DOI 10.17487/RFC4216, November 2005,
Label Switched Paths (LSPs)", RFC 5152, February <https://www.rfc-editor.org/info/rfc4216>.
2008.
[BRPC] Vasseur, JP., Ed., Zhang, R., Bitar, N., JL. Le [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Roux, "A Backward Recursive PCE-Based Computation Border Gateway Protocol 4 (BGP-4)", RFC 4271,
(BRPC) Procedure to Compute Shortest Inter-Domain DOI 10.17487/RFC4271, January 2006,
Traffic Engineering Label Switched Paths", Work in <https://www.rfc-editor.org/info/rfc4271>.
Progress, April 2008.
[PCE] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Computation Element (PCE)-Based Architecture", RFC Element (PCE)-Based Architecture", RFC 4655,
4655, August 2006. DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[ISIS-TE] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
Engineering", RFC 5305, October 2008. Per-Domain Path Computation Method for Establishing Inter-
Domain Traffic Engineering (TE) Label Switched Paths
(LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008,
<https://www.rfc-editor.org/info/rfc5152>.
[ISIS-TE-V3] Harrison, J., Berger, J., and Bartlett, M., "IPv6 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Traffic Engineering in IS-IS", Work in Progress, Authentication", RFC 5304, DOI 10.17487/RFC5304, October
June 2008. 2008, <https://www.rfc-editor.org/info/rfc5304>.
[GMPLS-TE] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
Extensions in Support of Generalized Multi-Protocol in Support of Generalized Multi-Protocol Label Switching
Label Switching (GMPLS)", RFC 5307, October 2008. (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<https://www.rfc-editor.org/info/rfc5307>.
[BGP] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
"A Border Gateway Protocol 4 (BGP-4)", RFC 4271, Support of Inter-Autonomous System (AS) MPLS and GMPLS
January 2006. Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
December 2008, <https://www.rfc-editor.org/info/rfc5316>.
[GENINFO] L. Ginsberg., Previdi, S., and M. Shand, [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
"Advertising Generic Information in IS-IS", Work in "A Backward-Recursive PCE-Based Computation (BRPC)
Progress, June 2008. Procedure to Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched Paths", RFC 5441,
DOI 10.17487/RFC5441, April 2009,
<https://www.rfc-editor.org/info/rfc5441>.
[RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising
Generic Information in IS-IS", RFC 6823,
DOI 10.17487/RFC6823, December 2012,
<https://www.rfc-editor.org/info/rfc6823>.
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
for Advertising Router Information", RFC 7981,
DOI 10.17487/RFC7981, October 2016,
<https://www.rfc-editor.org/info/rfc7981>.
Appendix A. Changes to RFC 5316
This document makes the following changes to RFC 5316.
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
address may not be available. This document specifies:
1. The Router ID SHOULD be identical to the value advertised in the
Traffic Engineering Router ID TLV (134) if available.
2. 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.
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 new IPv6
Local ASBR identifier sub-TLV MUST be present in the TLV.
Authors' Addresses Authors' Addresses
Mach (Guoyi) Chen Mach(Guoyi) Chen
Huawei Technologies Co., Ltd Huawei
KuiKe Building, No.9 Xinxi Rd.
Hai-Dian District
Beijing, 100085
P.R. China
EMail: mach@huawei.com Email: mach.chen@huawei.com
Renhai Zhang Les Ginsberg
Huawei Technologies Co., Ltd Cisco Systems
KuiKe Building, No.9 Xinxi Rd.
Hai-Dian District
Beijing, 100085
P.R. China
EMail: zhangrenhai@huawei.com Email: ginsberg@cisco.com
Stefano Previdi
Huawei Technologies
IT
Email: stefano@previdi.net
Xiaodong Duan Xiaodong Duan
China Mobile China Mobile
53A, Xibianmennei Ave.
Xunwu District
Beijing, China
EMail: duanxiaodong@chinamobile.com Email: duanxiaodong@chinamobile.com
 End of changes. 95 change blocks. 
316 lines changed or deleted 370 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/