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/ |