draft-ietf-idr-rfc7752bis-14.txt | draft-ietf-idr-rfc7752bis-17.txt | |||
---|---|---|---|---|
Inter-Domain Routing K. Talaulikar, Ed. | Inter-Domain Routing K. Talaulikar, Ed. | |||
Internet-Draft Cisco Systems | Internet-Draft Cisco Systems | |||
Obsoletes: 7752, 9029 (if approved) 18 November 2022 | Obsoletes: 7752, 9029 (if approved) 25 August 2023 | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: 22 May 2023 | Expires: 26 February 2024 | |||
Distribution of Link-State and Traffic Engineering Information Using BGP | Distribution of Link-State and Traffic Engineering Information Using BGP | |||
draft-ietf-idr-rfc7752bis-14 | draft-ietf-idr-rfc7752bis-17 | |||
Abstract | Abstract | |||
In many environments, a component external to a network is called | In many environments, a component external to a network is called | |||
upon to perform computations based on the network topology and the | upon to perform computations based on the network topology and the | |||
current state of the connections within the network, including | current state of the connections within the network, including | |||
Traffic Engineering (TE) information. This is information typically | Traffic Engineering (TE) information. This is information typically | |||
distributed by IGP routing protocols within the network. | distributed by IGP routing protocols within the network. | |||
This document describes a mechanism by which link-state and TE | This document describes a mechanism by which link-state and TE | |||
information can be collected from networks and shared with external | information can be collected from networks and shared with external | |||
components using the BGP routing protocol. This is achieved using a | components using the BGP routing protocol. This is achieved using a | |||
new BGP Network Layer Reachability Information (NLRI) encoding | BGP Network Layer Reachability Information (NLRI) encoding format. | |||
format. The mechanism applies to physical and virtual (e.g., tunnel) | The mechanism applies to physical and virtual (e.g., tunnel) IGP | |||
IGP links. The mechanism described is subject to policy control. | links. The mechanism described is subject to policy control. | |||
Applications of this technique include Application-Layer Traffic | Applications of this technique include Application-Layer Traffic | |||
Optimization (ALTO) servers and Path Computation Elements (PCEs). | Optimization (ALTO) servers and Path Computation Elements (PCEs). | |||
This document obsoletes RFC7752 by completely replacing that | This document obsoletes RFC7752 by completely replacing that | |||
document. It makes some small changes and clarifications to the | document. It makes some small changes and clarifications to the | |||
previous specification. This document also obsoletes RFC9029 by | previous specification. This document also obsoletes RFC9029 by | |||
incorporating the updates that it made to RFC7752. | incorporating the updates that it made to RFC7752. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 2, line 4 ¶ | skipping to change at page 2, line 4 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 22 May 2023. | This Internet-Draft will expire on 26 February 2024. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2023 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 | |||
2. Motivation and Applicability . . . . . . . . . . . . . . . . 6 | 2. Motivation and Applicability . . . . . . . . . . . . . . . . 6 | |||
2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . 6 | 2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . 6 | |||
2.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 7 | 2.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 7 | |||
3. BGP Speaker Roles for BGP-LS . . . . . . . . . . . . . . . . 8 | 3. BGP Speaker Roles for BGP-LS . . . . . . . . . . . . . . . . 8 | |||
4. Advertising IGP Information into BGP-LS . . . . . . . . . . . 9 | 4. Advertising IGP Information into BGP-LS . . . . . . . . . . . 10 | |||
5. Carrying Link-State Information in BGP . . . . . . . . . . . 10 | 5. Carrying Link-State Information in BGP . . . . . . . . . . . 10 | |||
5.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 10 | 5.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
5.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 12 | 5.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 12 | |||
5.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 16 | 5.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 16 | |||
5.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . 21 | 5.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . 20 | |||
5.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . 24 | 5.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . 24 | |||
5.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . 26 | 5.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . 26 | |||
5.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 27 | 5.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 27 | |||
5.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 30 | 5.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 31 | |||
5.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 35 | 5.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 36 | |||
5.4. Private Use . . . . . . . . . . . . . . . . . . . . . . . 39 | 5.4. Private Use . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
5.5. BGP Next-Hop Information . . . . . . . . . . . . . . . . 40 | 5.5. BGP Next-Hop Information . . . . . . . . . . . . . . . . 41 | |||
5.6. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 40 | 5.6. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 42 | |||
5.7. OSPF Virtual Links and Sham Links . . . . . . . . . . . . 41 | 5.7. OSPF Virtual Links and Sham Links . . . . . . . . . . . . 42 | |||
5.8. OSPFv2 Type 4 Summary LSA & OSPFv3 Inter-Area Router | 5.8. OSPFv2 Type 4 Summary LSA & OSPFv3 Inter-Area Router | |||
LSA . . . . . . . . . . . . . . . . . . . . . . . . . . 41 | LSA . . . . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
5.9. Handling of Unreachable IGP Nodes . . . . . . . . . . . . 41 | 5.9. Handling of Unreachable IGP Nodes . . . . . . . . . . . . 43 | |||
5.10. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 43 | 5.10. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 44 | |||
5.11. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 44 | 5.11. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 45 | |||
5.12. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 45 | 5.12. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 46 | |||
6. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 45 | 6. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 47 | |||
6.1. Example: No Link Aggregation . . . . . . . . . . . . . . 46 | 6.1. Example: No Link Aggregation . . . . . . . . . . . . . . 47 | |||
6.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 46 | 6.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 48 | |||
6.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 47 | 6.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 48 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 | |||
7.1. BGP-LS Registries . . . . . . . . . . . . . . . . . . . . 47 | 7.1. BGP-LS Registries . . . . . . . . . . . . . . . . . . . . 49 | |||
7.1.1. BGP-LS NLRI Types Registry . . . . . . . . . . . . . 48 | 7.1.1. BGP-LS NLRI Types Registry . . . . . . . . . . . . . 49 | |||
7.1.2. BGP-LS Protocol-IDs Registry . . . . . . . . . . . . 48 | 7.1.2. BGP-LS Protocol-IDs Registry . . . . . . . . . . . . 50 | |||
7.1.3. BGP-LS Well-Known Instance-IDs Registry . . . . . . . 49 | 7.1.3. BGP-LS Well-Known Instance-IDs Registry . . . . . . . 51 | |||
7.1.4. BGP-LS Node Flags Registry . . . . . . . . . . . . . 49 | 7.1.4. BGP-LS Node Flags Registry . . . . . . . . . . . . . 51 | |||
7.1.5. BGP-LS MPLS Protocol Mask Registry . . . . . . . . . 50 | 7.1.5. BGP-LS MPLS Protocol Mask Registry . . . . . . . . . 52 | |||
7.1.6. BGP-LS IGP Prefix Flags Registry . . . . . . . . . . 51 | 7.1.6. BGP-LS IGP Prefix Flags Registry . . . . . . . . . . 53 | |||
7.1.7. BGP-LS TLVs Registry . . . . . . . . . . . . . . . . 51 | 7.1.7. BGP-LS TLVs Registry . . . . . . . . . . . . . . . . 53 | |||
7.2. Guidance for Designated Experts . . . . . . . . . . . . . 52 | 7.2. Guidance for Designated Experts . . . . . . . . . . . . . 54 | |||
8. Manageability Considerations . . . . . . . . . . . . . . . . 53 | 8. Manageability Considerations . . . . . . . . . . . . . . . . 55 | |||
8.1. Operational Considerations . . . . . . . . . . . . . . . 53 | 8.1. Operational Considerations . . . . . . . . . . . . . . . 55 | |||
8.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 53 | 8.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 55 | |||
8.1.2. Installation and Initial Setup . . . . . . . . . . . 54 | 8.1.2. Installation and Initial Setup . . . . . . . . . . . 56 | |||
8.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 54 | 8.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 56 | |||
8.1.4. Requirements for Other Protocols and Functional | 8.1.4. Requirements for Other Protocols and Functional | |||
Components . . . . . . . . . . . . . . . . . . . . . 54 | Components . . . . . . . . . . . . . . . . . . . . . 56 | |||
8.1.5. Impact on Network Operation . . . . . . . . . . . . . 54 | 8.1.5. Impact on Network Operation . . . . . . . . . . . . . 56 | |||
8.1.6. Verifying Correct Operation . . . . . . . . . . . . . 55 | 8.1.6. Verifying Correct Operation . . . . . . . . . . . . . 57 | |||
8.2. Management Considerations . . . . . . . . . . . . . . . . 55 | 8.2. Management Considerations . . . . . . . . . . . . . . . . 57 | |||
8.2.1. Management Information . . . . . . . . . . . . . . . 55 | 8.2.1. Management Information . . . . . . . . . . . . . . . 57 | |||
8.2.2. Fault Management . . . . . . . . . . . . . . . . . . 55 | 8.2.2. Fault Management . . . . . . . . . . . . . . . . . . 57 | |||
8.2.3. Configuration Management . . . . . . . . . . . . . . 57 | 8.2.3. Configuration Management . . . . . . . . . . . . . . 59 | |||
8.2.4. Accounting Management . . . . . . . . . . . . . . . . 58 | 8.2.4. Accounting Management . . . . . . . . . . . . . . . . 60 | |||
8.2.5. Performance Management . . . . . . . . . . . . . . . 58 | 8.2.5. Performance Management . . . . . . . . . . . . . . . 60 | |||
8.2.6. Security Management . . . . . . . . . . . . . . . . . 58 | 8.2.6. Security Management . . . . . . . . . . . . . . . . . 60 | |||
9. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 59 | 9. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 61 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 61 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 63 | |||
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 62 | 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 64 | |||
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 62 | 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 64 | |||
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 63 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 | |||
13.1. Normative References . . . . . . . . . . . . . . . . . . 63 | 13.1. Normative References . . . . . . . . . . . . . . . . . . 65 | |||
13.2. Informative References . . . . . . . . . . . . . . . . . 66 | 13.2. Informative References . . . . . . . . . . . . . . . . . 68 | |||
Appendix A. Changes from RFC 7752 . . . . . . . . . . . . . . . 68 | Appendix A. Changes from RFC 7752 . . . . . . . . . . . . . . . 70 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 70 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 72 | |||
1. Introduction | 1. Introduction | |||
The contents of a Link-State Database (LSDB) or of an IGP's Traffic | The contents of a Link-State Database (LSDB) or of an IGP's Traffic | |||
Engineering Database (TED) describe only the links and nodes within | Engineering Database (TED) describe only the links and nodes within | |||
an IGP area. Some applications, such as end-to-end Traffic | an IGP area. Some applications, such as end-to-end Traffic | |||
Engineering (TE), would benefit from visibility outside one area or | Engineering (TE), would benefit from visibility outside one area or | |||
Autonomous System (AS) to make better decisions. | Autonomous System (AS) to make better decisions. | |||
The IETF has defined the Path Computation Element (PCE) [RFC4655] as | The IETF has defined the Path Computation Element (PCE) [RFC4655] as | |||
skipping to change at page 4, line 15 ¶ | skipping to change at page 4, line 15 ¶ | |||
ALTO server [RFC5693] as an entity that generates an abstracted | ALTO server [RFC5693] as an entity that generates an abstracted | |||
network topology and provides it to network-aware applications. | network topology and provides it to network-aware applications. | |||
Both a PCE and an ALTO server need to gather information about the | Both a PCE and an ALTO server need to gather information about the | |||
topologies and capabilities of the network to be able to fulfill | topologies and capabilities of the network to be able to fulfill | |||
their function. | their function. | |||
This document describes a mechanism by which link-state and TE | This document describes a mechanism by which link-state and TE | |||
information can be collected from networks and shared with external | information can be collected from networks and shared with external | |||
components using the BGP routing protocol [RFC4271]. This is | components using the BGP routing protocol [RFC4271]. This is | |||
achieved using a new BGP Network Layer Reachability Information | achieved using a BGP Network Layer Reachability Information (NLRI) | |||
(NLRI) encoding format. The mechanism applies to physical and | encoding format. The mechanism applies to physical and virtual | |||
virtual (e.g., tunnel) links. The mechanism described is subject to | (e.g., tunnel) links. The mechanism described is subject to policy | |||
policy control. | control. | |||
A router maintains one or more databases for storing link-state | A router maintains one or more databases for storing link-state | |||
information about nodes and links in any given area. Link attributes | information about nodes and links in any given area. Link attributes | |||
stored in these databases include: local/remote IP addresses, local/ | stored in these databases include: local/remote IP addresses, local/ | |||
remote interface identifiers, link IGP metric, link TE metric, link | remote interface identifiers, link IGP metric, link TE metric, link | |||
bandwidth, reservable bandwidth, per Class-of-Service (CoS) class | bandwidth, reservable bandwidth, per Class-of-Service (CoS) class | |||
reservation state, preemption, and Shared Risk Link Groups (SRLGs). | reservation state, preemption, and Shared Risk Link Groups (SRLGs). | |||
The router's BGP Link-State (BGP-LS) process can retrieve topology | The router's BGP Link-State (BGP-LS) process can retrieve topology | |||
from these LSDBs and distribute it to a consumer, either directly or | from these LSDBs and distribute it to a consumer, either directly or | |||
via a peer BGP speaker (typically a dedicated Route Reflector), using | via a peer BGP speaker (typically a dedicated Route Reflector), using | |||
skipping to change at page 6, line 48 ¶ | skipping to change at page 6, line 48 ¶ | |||
networks that need to segment their core networks into distinct | networks that need to segment their core networks into distinct | |||
areas but still want to take advantage of MPLS-TE. | areas but still want to take advantage of MPLS-TE. | |||
Previous solutions used per-domain path computation [RFC5152]. The | Previous solutions used per-domain path computation [RFC5152]. The | |||
source router could only compute the path for the first area because | source router could only compute the path for the first area because | |||
the router only has full topological visibility for the first area | the router only has full topological visibility for the first area | |||
along the path, but not for subsequent areas. Per-domain path | along the path, but not for subsequent areas. Per-domain path | |||
computation uses a technique called "loose-hop-expansion" [RFC3209] | computation uses a technique called "loose-hop-expansion" [RFC3209] | |||
and selects the exit ABR and other ABRs or AS Border Routers (ASBRs) | and selects the exit ABR and other ABRs or AS Border Routers (ASBRs) | |||
using the IGP-computed shortest path topology for the remainder of | using the IGP-computed shortest path topology for the remainder of | |||
the path. This may lead to sub-optimal paths, makes alternate/back- | the path. This may lead to suboptimal paths, makes alternate/back-up | |||
up path computation hard, and might result in no TE path being found | path computation hard, and might result in no TE path being found | |||
when one does exist. | when one does exist. | |||
The PCE presents a computation server that may have visibility into | The PCE presents a computation server that may have visibility into | |||
more than one IGP area or AS, or may cooperate with other PCEs to | more than one IGP area or AS, or may cooperate with other PCEs to | |||
perform distributed path computation. The PCE needs access to the | perform distributed path computation. The PCE needs access to the | |||
TED for the area(s) it serves, but [RFC4655] does not describe how | TED for the area(s) it serves, but [RFC4655] does not describe how | |||
this is achieved. Many implementations make the PCE a passive | this is achieved. Many implementations make the PCE a passive | |||
participant in the IGP so that it can learn the latest state of the | participant in the IGP so that it can learn the latest state of the | |||
network, but this may be sub-optimal when the network is subject to a | network, but this may be sub-optimal when the network is subject to a | |||
high degree of churn or when the PCE is responsible for multiple | high degree of churn or when the PCE is responsible for multiple | |||
skipping to change at page 9, line 9 ¶ | skipping to change at page 9, line 9 ¶ | |||
In the illustration shown in Figure 1, the BGP Speakers can be seen | In the illustration shown in Figure 1, the BGP Speakers can be seen | |||
playing different roles in the distribution of information using BGP- | playing different roles in the distribution of information using BGP- | |||
LS. This section introduces terms that explain the different roles | LS. This section introduces terms that explain the different roles | |||
of the BGP Speakers which are then used through the rest of this | of the BGP Speakers which are then used through the rest of this | |||
document. | document. | |||
* BGP-LS Producer: The term BGP-LS Producer refers to a BGP Speaker | * BGP-LS Producer: The term BGP-LS Producer refers to a BGP Speaker | |||
that is originating link-state information into BGP. The BGP | that is originating link-state information into BGP. The BGP | |||
Speakers R1, R2, ... Rn, originate link-state information from | Speakers R1, R2, ... Rn, originate link-state information from | |||
their underlying link-state IGP protocols into BGP-LS. If R1 and | their underlying link-state IGP protocols into BGP-LS. If R1 and | |||
R2 are in the same IGP flooding domain, then they should originate | R2 are in the same IGP flooding domain, then they would ordinarily | |||
the same link-state information into BGP-LS. R1 may also source | originate the same link-state information into BGP-LS. R1 may | |||
information from sources other than IGP, e.g. its local node | also originate information from sources other than IGP, e.g. its | |||
information. | local node information. | |||
* BGP-LS Consumer: The term BGP-LS Consumer refers to a consumer | * BGP-LS Consumer: The term BGP-LS Consumer refers to a consumer | |||
application/process and not a BGP Speaker. The BGP Speakers RR1 | application/process and not a BGP Speaker. The BGP Speakers RR1 | |||
and Rn are handing off the BGP-LS information that they have | and Rn are handing off the BGP-LS information that they have | |||
collected to a consumer application. The BGP protocol | collected to a consumer application. The BGP protocol | |||
implementation and the consumer application may be on the same or | implementation and the consumer application may be on the same or | |||
different nodes. This document only covers the BGP | different nodes. This document only covers the BGP | |||
implementation. The consumer application and the design of the | implementation. The consumer application and the design of the | |||
interface between BGP and the consumer application may be | interface between BGP and the consumer application may be | |||
implementation specific and are outside the scope of this | implementation specific and are outside the scope of this | |||
document. The communication of information MUST be unidirectional | document. The communication of information MUST be unidirectional | |||
(i.e., from a BGP Speaker to the BGP-LS Consumer application) and | (i.e., from a BGP Speaker to the BGP-LS Consumer application) and | |||
a BGP-LS Consumer MUST NOT be able to send information to a BGP | a BGP-LS Consumer MUST NOT be able to send information to a BGP | |||
Speaker for origination into BGP-LS. | Speaker for origination into BGP-LS. | |||
* BGP-LS Propagator: The term BGP-LS Propagator refers to a BGP | * BGP-LS Propagator: The term BGP-LS Propagator refers to a BGP | |||
Speaker that is performing BGP protocol processing on the link- | Speaker that is performing BGP protocol processing on the link- | |||
state information. The BGP Speaker RRm propagates the BGP-LS | state information. The BGP Speaker RRm propagates the BGP-LS | |||
information between the BGP Speaker Rn and the BGP Speaker RR1. | information between the BGP Speaker Rn and the BGP Speaker RR1. | |||
The BGP implementation on RRm is doing the propagation of BGP-LS | The BGP implementation on RRm is propagating BGP-LS information. | |||
UPDATE messages and performing BGP Decision Process. Similarly, | It performs handling of BGP-LS UPDATE messages and performs the | |||
the BGP Speaker RR1 is receiving BGP-LS information from R1, R2, | BGP Decision Process as part of deciding what information is to be | |||
and RRm and propagating the information to the BGP-LS Consumer | propagated. Similarly, the BGP Speaker RR1 is receiving BGP-LS | |||
after performing BGP Decision Process. | information from R1, R2, and RRm and propagating the information | |||
to the BGP-LS Consumer after performing BGP Decision Process. | ||||
The above roles are not mutually exclusive. The same BGP Speaker may | The above roles are not mutually exclusive. The same BGP Speaker may | |||
be the BGP-LS Producer for some link-state information and BGP-LS | be the BGP-LS Producer for some link-state information and BGP-LS | |||
Propagator for some other link-state information while also providing | Propagator for some other link-state information while also providing | |||
this information to a BGP-LS Consumer. | this information to a BGP-LS Consumer. | |||
The rest of this document refers to the role when describing | The rest of this document refers to the role when describing | |||
procedures that are specific to that role. When the role is not | procedures that are specific to that role. When the role is not | |||
specified, then the said procedure applies to all BGP Speakers. | specified, then the said procedure applies to all BGP Speakers. | |||
4. Advertising IGP Information into BGP-LS | 4. Advertising IGP Information into BGP-LS | |||
The origination and propagation of IGP link-state information via BGP | The origination and propagation of IGP link-state information via BGP | |||
needs to provide a consistent and true view of the topology of the | needs to provide a consistent and accurate view of the topology of | |||
IGP domain. BGP-LS provides an abstraction of the IGP specifics and | the IGP domain. BGP-LS provides an abstraction of the IGP specifics | |||
BGP-LS Consumers may be varied types of applications. | and BGP-LS Consumers may be varied types of applications. | |||
The link-state information advertised in BGP-LS from the IGPs is | The link-state information advertised in BGP-LS from the IGPs is | |||
derived from the IGP LSDB built using the OSPF Link State | derived from the IGP LSDB built using the OSPF Link State | |||
Advertisements (LSAs) or the IS-IS Link State Packets (LSPs). | Advertisements (LSAs) or the IS-IS Link State Packets (LSPs). | |||
However, it does not serve as a true reflection of the originating | However, it does not serve as a verbatim reflection of the | |||
router's LSDB. It does not include the LSA/LSP sequence number | originating router's LSDB. It does not include the LSA/LSP sequence | |||
information since a single link-state object may be put together with | number information since a single link-state object may be put | |||
information that is coming from multiple LSAs/LSPs. Also, not all of | together with information that is coming from multiple LSAs/LSPs. | |||
the information carried in LSAs/LSPs may be required or suitable for | Also, not all of the information carried in LSAs/LSPs may be required | |||
advertisement via BGP-LS (e.g., ASBR reachability in OSPF, OSPF | or suitable for advertisement via BGP-LS (e.g., ASBR reachability in | |||
virtual links, link-local scoped information, etc.). The LSAs/LSPs | OSPF, OSPF virtual links, link-local scoped information, etc.). The | |||
that are purged or max-aged are not included in the BGP-LS | LSAs/LSPs that are purged or max-aged are not included in the BGP-LS | |||
advertisement even though they may be present in the LSDB (e.g., for | advertisement even though they may be present in the LSDB (e.g., for | |||
the IGP flooding purposes). The information from the LSAs/LSPs that | the IGP flooding purposes). The information from the LSAs/LSPs that | |||
is invalid or malformed or that which needs to be ignored per the | is invalid or malformed or that which needs to be ignored per the | |||
respective IGP protocol specifications are also not included in the | respective IGP protocol specifications are also not included in the | |||
BGP-LS advertisement. | BGP-LS advertisement. | |||
The details of the interface between IGPs and BGP for the | The details of the interface between IGPs and BGP for the | |||
advertisement of link-state information is outside the scope of this | advertisement of link-state information are outside the scope of this | |||
document. In some cases, the information derived from IGP processing | document. In some cases, the information derived from IGP processing | |||
(e.g., combination of link-state object from across multiple LSAs/ | (e.g., combination of link-state object from across multiple LSAs/ | |||
LSPs, leveraging reachability and two-way connectivity checks, etc.) | LSPs, leveraging reachability and two-way connectivity checks, etc.) | |||
is required for advertisement of link-state information into BGP-LS. | is required for advertisement of link-state information into BGP-LS. | |||
5. Carrying Link-State Information in BGP | 5. Carrying Link-State Information in BGP | |||
The link-state information is carried in BGP UPDATE messages as: (1) | The link-state information is carried in BGP UPDATE messages as: (1) | |||
BGP NLRI information carried within MP_REACH_NLRI and MP_UNREACH_NLRI | BGP NLRI information carried within MP_REACH_NLRI and MP_UNREACH_NLRI | |||
attributes that describes link, node, or prefix object, and (2) a new | attributes that describes link, node, or prefix object, and (2) a BGP | |||
BGP path attribute (BGP-LS Attribute) that carries properties of the | path attribute (BGP-LS Attribute) that carries properties of the | |||
link, node, or prefix objects such as the link and prefix metric or | link, node, or prefix objects such as the link and prefix metric or | |||
auxiliary Router-IDs of nodes, etc.. | auxiliary Router-IDs of nodes, etc. | |||
It is desirable to keep the dependencies on the protocol source of | It is desirable to keep the dependencies on the protocol source of | |||
this attribute to a minimum and represent any content in an IGP- | this attribute to a minimum and represent any content in an IGP- | |||
neutral way, such that applications that want to learn about a link- | neutral way, such that applications that want to learn about a link- | |||
state topology do not need to know about any OSPF or IS-IS protocol | state topology do not need to know about any OSPF or IS-IS protocol | |||
specifics. | specifics. | |||
This section mainly describes the procedures for a BGP-LS Producer to | This section mainly describes the procedures for a BGP-LS Producer to | |||
originate link-state information into BGP-LS. | originate link-state information into BGP-LS. | |||
5.1. TLV Format | 5.1. TLV Format | |||
Information in the new Link-State NLRIs and the BGP-LS Attribute is | Information in the Link-State NLRIs and the BGP-LS Attribute is | |||
encoded in Type/Length/Value triplets. The TLV format is shown in | encoded in Type/Length/Value triplets. The TLV format is shown in | |||
Figure 4 and applies to both the NLRI and the BGP-LS Attribute | Figure 4 and applies to both the NLRI and the BGP-LS Attribute | |||
encodings. | encodings. | |||
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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
// Value (variable) // | // Value (variable) // | |||
skipping to change at page 11, line 28 ¶ | skipping to change at page 11, line 35 ¶ | |||
types MUST be preserved and propagated within both the NLRI and the | types MUST be preserved and propagated within both the NLRI and the | |||
BGP-LS Attribute. The presence of unknown or unexpected TLVs MUST | BGP-LS Attribute. The presence of unknown or unexpected TLVs MUST | |||
NOT result in the NLRI or the BGP-LS Attribute being considered | NOT result in the NLRI or the BGP-LS Attribute being considered | |||
malformed. An example of an unexpected TLV is when a TLV is received | malformed. An example of an unexpected TLV is when a TLV is received | |||
along with an update for a link state object other than the one that | along with an update for a link state object other than the one that | |||
the TLV is specified as associated with. | the TLV is specified as associated with. | |||
To compare NLRIs with unknown TLVs, all TLVs within the NLRI MUST be | To compare NLRIs with unknown TLVs, all TLVs within the NLRI MUST be | |||
ordered in ascending order by TLV Type. If there are multiple TLVs | ordered in ascending order by TLV Type. If there are multiple TLVs | |||
of the same type within a single NLRI, then the TLVs sharing the same | of the same type within a single NLRI, then the TLVs sharing the same | |||
type MUST be in ascending order based on the value field. Comparison | type MUST be first in ascending order based on the length field | |||
of the value fields is performed by treating the entire field as | followed by ascending order based on the value field. Comparison of | |||
opaque binary data and ordered lexicographically. NLRIs having TLVs | the value fields is performed by treating the entire field as opaque | |||
which do not follow the above ordering rules MUST be considered as | binary data and ordered lexicographically (i.e., treating each byte | |||
malformed by a BGP-LS Propagator. This ensures that multiple copies | of binary data as a symbol to compare, with the symbols ordered by | |||
of the same NLRI from multiple BGP-LS Producers and the ambiguity | their numerical value). NLRIs having TLVs which do not follow the | |||
arising therefrom is prevented. | above ordering rules MUST be considered as malformed by a BGP-LS | |||
Propagator. This insistence on canonical ordering ensures that | ||||
multiple variant copies of the same NLRI from multiple BGP-LS | ||||
Producers and the ambiguity arising therefrom is prevented. | ||||
For both the NLRI and BGP-LS Attribute parts, all TLVs are considered | For both the NLRI and BGP-LS Attribute parts, all TLVs are considered | |||
as optional except where explicitly specified as mandatory or | as optional except where explicitly specified as mandatory or | |||
required in specific conditions. | required in specific conditions. | |||
The TLVs within the BGP-LS Attribute SHOULD be ordered in ascending | The TLVs within the BGP-LS Attribute SHOULD be ordered in ascending | |||
order by TLV type. BGP-LS Attribute with unordered TLVs MUST NOT be | order by TLV type. BGP-LS Attribute with unordered TLVs MUST NOT be | |||
considered malformed. | considered malformed. | |||
The origination of the same link-state information by multiple BGP-LS | The origination of the same link-state information by multiple BGP-LS | |||
skipping to change at page 12, line 30 ¶ | skipping to change at page 12, line 30 ¶ | |||
Link-State NLRI types that describe either a node, a link, or a | Link-State NLRI types that describe either a node, a link, or a | |||
prefix. | prefix. | |||
All non-VPN link, node, and prefix information SHALL be encoded using | All non-VPN link, node, and prefix information SHALL be encoded using | |||
AFI 16388 / SAFI 71. VPN link, node, and prefix information SHALL be | AFI 16388 / SAFI 71. VPN link, node, and prefix information SHALL be | |||
encoded using AFI 16388 / SAFI 72. | encoded using AFI 16388 / SAFI 72. | |||
For two BGP speakers to exchange Link-State NLRI, they MUST use BGP | For two BGP speakers to exchange Link-State NLRI, they MUST use BGP | |||
Capabilities Advertisement to ensure that they are both capable of | Capabilities Advertisement to ensure that they are both capable of | |||
properly processing such NLRI. This is done as specified in | properly processing such NLRI. This is done as specified in | |||
[RFC4760], by using capability code 1 (multi-protocol BGP), with AFI | [RFC4760], by using capability code 1 (multiprotocol BGP), with AFI | |||
16388 / SAFI 71 for BGP-LS, and AFI 16388 / SAFI 72 for BGP-LS-VPN. | 16388 / SAFI 71 for BGP-LS, and AFI 16388 / SAFI 72 for BGP-LS-VPN. | |||
New Link-State NLRI Types may be introduced in the future. Since | New Link-State NLRI Types may be introduced in the future. Since | |||
supported NLRI type values within the address family are not | supported NLRI type values within the address family are not | |||
expressed in the Multiprotocol BGP (MP-BGP) capability [RFC4760], it | expressed in the Multiprotocol BGP (MP-BGP) capability [RFC4760], it | |||
is possible that a BGP speaker has advertised support for BGP-LS but | is possible that a BGP speaker has advertised support for BGP-LS but | |||
does not support a particular Link-State NLRI type. To allow the | does not support a particular Link-State NLRI type. To allow the | |||
introduction of new Link-State NLRI types seamlessly in the future, | introduction of new Link-State NLRI types seamlessly in the future, | |||
without the need for upgrading all BGP speakers in the propagation | without the need for upgrading all BGP speakers in the propagation | |||
path (e.g., a route reflector), this document deviates from the | path (e.g., a route reflector), this document deviates from the | |||
default handling behavior specified by [RFC7606] for Link-State | default handling behavior specified by section 5.4 (paragraph 2) of | |||
address-family. An implementation MUST handle unknown Link-State | [RFC7606] for Link-State address-family. An implementation MUST | |||
NLRI types as opaque objects and MUST preserve and propagate them. | handle unknown Link-State NLRI types as opaque objects and MUST | |||
preserve and propagate them. | ||||
The format of the Link-State NLRI is shown in the following figures. | The format of the Link-State NLRI is shown in the following figures. | |||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| NLRI Type | Total NLRI Length | | | NLRI Type | Total NLRI Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
// Link-State NLRI (variable) // | // Link-State NLRI (variable) // | |||
skipping to change at page 15, line 49 ¶ | skipping to change at page 15, line 49 ¶ | |||
Table 2: Protocol Identifiers | Table 2: Protocol Identifiers | |||
The 'Direct' and 'Static configuration' protocol types SHOULD be used | The 'Direct' and 'Static configuration' protocol types SHOULD be used | |||
when BGP-LS is sourcing local information. For all information | when BGP-LS is sourcing local information. For all information | |||
derived from other protocols, the corresponding Protocol-ID MUST be | derived from other protocols, the corresponding Protocol-ID MUST be | |||
used. If BGP-LS has direct access to interface information and wants | used. If BGP-LS has direct access to interface information and wants | |||
to advertise a local link, then the Protocol-ID 'Direct' SHOULD be | to advertise a local link, then the Protocol-ID 'Direct' SHOULD be | |||
used. For modeling virtual links, such as described in Section 6, | used. For modeling virtual links, such as described in Section 6, | |||
the Protocol-ID 'Static configuration' SHOULD be used. | the Protocol-ID 'Static configuration' SHOULD be used. | |||
A router may run multiple protocol instances of OSPF or ISIS whereby | A router may run multiple protocol instances of OSPF or IS-IS whereby | |||
it becomes a border router between multiple IGP domains. Both OSPF | it becomes a border router between multiple IGP domains. Both OSPF | |||
and IS-IS may also run multiple routing protocol instances over the | and IS-IS may also run multiple routing protocol instances over the | |||
same link. See [RFC8202] and [RFC6549]. These instances define | same link. See [RFC8202] and [RFC6549]. These instances define | |||
independent IGP routing domains. The Identifier field carries a | independent IGP routing domains. The Identifier field carries an | |||
8-octet BGP-LS Instance Identifier (Instance-ID) number that is used | 8-octet BGP-LS Instance Identifier (Instance-ID) number that is used | |||
to identify the IGP routing domain where the NLRI belongs. The NLRIs | to identify the IGP routing domain where the NLRI belongs. The NLRIs | |||
representing link-state objects (nodes, links, or prefixes) from the | representing link-state objects (nodes, links, or prefixes) from the | |||
same IGP routing instance should have the same BGP-LS Instance-ID. | same IGP routing instance should have the same BGP-LS Instance-ID. | |||
NLRIs with different BGP-LS Instance-IDs are considered to be from | NLRIs with different BGP-LS Instance-IDs are considered to be from | |||
different IGP routing instances. | different IGP routing instances. | |||
To support multiple IGP instances, an implementations needs to | To support multiple IGP instances, an implementation needs to support | |||
support the configuration of unique BGP-LS Instance-IDs at the | the configuration of unique BGP-LS Instance-IDs at the routing | |||
routing protocol instance level. The BGP-LS Instance-ID 0 is | protocol instance level. The BGP-LS Instance-ID 0 is RECOMMENDED to | |||
RECOMMENDED to be used when there is only a single protocol instance | be used when there is only a single protocol instance in the network | |||
in the network where BGP-LS is operational. The network operator | where BGP-LS is operational. The network operator MUST assign the | |||
MUST assign the same BGP-LS Instance-IDs on all BGP-LS Producers | same BGP-LS Instance-IDs on all BGP-LS Producers within a given IGP | |||
within a given IGP domain. Unique BGP-LS Instance-ID MUST be | domain. Unique BGP-LS Instance-ID MUST be assigned to routing | |||
assigned to routing protocol instances operating in different IGP | protocol instances operating in different IGP domains. This can | |||
domains. This can allow the BGP-LS Consumer to build an accurate | allow the BGP-LS Consumer to build an accurate segregated multi- | |||
segregated multi-domain topology based on the BGP-LS Instance-ID. | domain topology based on the BGP-LS Instance-ID. | |||
When the above-described semantics and recommendations are not | When the above-described semantics and recommendations are not | |||
followed, a BGP-LS Consumer may see more than one link-state objects | followed, a BGP-LS Consumer may see more than one link-state objects | |||
for the same node, link, or prefix (each with a different BGP-LS | for the same node, link, or prefix (each with a different BGP-LS | |||
Instance-ID) when there are multiple BGP-LS Producers deployed. This | Instance-ID) when there are multiple BGP-LS Producers deployed. This | |||
may also result in the BGP-LS Consumers getting an inaccurate | may also result in the BGP-LS Consumers getting an inaccurate | |||
network-wide topology. | network-wide topology. | |||
Each Node Descriptor, Link Descriptor, and Prefix Descriptor consists | Each Node Descriptor, Link Descriptor, and Prefix Descriptor consists | |||
of one or more TLVs, as described in the following sections. These | of one or more TLVs, as described in the following sections. These | |||
skipping to change at page 17, line 39 ¶ | skipping to change at page 17, line 39 ¶ | |||
We define an "IGP domain" to be the set of nodes (hence, by extension | We define an "IGP domain" to be the set of nodes (hence, by extension | |||
links and prefixes) within which each node has a unique IGP | links and prefixes) within which each node has a unique IGP | |||
representation by using the combination of OSPF Area-ID, Router-ID, | representation by using the combination of OSPF Area-ID, Router-ID, | |||
Protocol-ID, Multi-Topology ID, and BGP-LS Instance-ID. The problem | Protocol-ID, Multi-Topology ID, and BGP-LS Instance-ID. The problem | |||
is that BGP may receive node/link/prefix information from multiple | is that BGP may receive node/link/prefix information from multiple | |||
independent "IGP domains", and we need to distinguish between them. | independent "IGP domains", and we need to distinguish between them. | |||
Moreover, we can't assume there is always one and only one IGP domain | Moreover, we can't assume there is always one and only one IGP domain | |||
per AS. During IGP transitions, it may happen that two redundant | per AS. During IGP transitions, it may happen that two redundant | |||
IGPs are in place. | IGPs are in place. | |||
Furthermore, in deployments where BGP-LS is used to advertise | ||||
topology from multiple-ASes, the AS Number is used to distinguish | ||||
topology information reported from different ASes. | ||||
The BGP-LS Instance-ID carried in the Identifier field as described | The BGP-LS Instance-ID carried in the Identifier field as described | |||
earlier along with a set of sub-TLVs described in Section 5.2.1.4, | earlier along with a set of sub-TLVs described in Section 5.2.1.4, | |||
allows specification of a flexible key for any given node/link | allows specification of a flexible key for any given node/link | |||
information such that the global uniqueness of the NLRI is ensured. | information such that the global uniqueness of the NLRI is ensured. | |||
Since the BGP-LS Instance-ID is operator assigned, its allocation | ||||
scheme can ensure that each IGP domain is uniquely identified even | ||||
across a multi-AS network. | ||||
5.2.1.2. Local Node Descriptors | 5.2.1.2. Local Node Descriptors | |||
The Local Node Descriptors TLV contains Node Descriptors for the node | The Local Node Descriptors TLV contains Node Descriptors for the node | |||
anchoring the local end of the link. This is a mandatory TLV in all | anchoring the local end of the link. This is a mandatory TLV in all | |||
three types of NLRIs (node, link, and prefix). The Type is 256. The | three types of NLRIs (node, link, and prefix). The Type is 256. The | |||
length of this TLV is variable. The value contains one or more Node | length of this TLV is variable. The value contains one or more Node | |||
Descriptor Sub-TLVs defined in Section 5.2.1.4. | Descriptor Sub-TLVs defined in Section 5.2.1.4. | |||
0 1 2 3 | 0 1 2 3 | |||
skipping to change at page 19, line 29 ¶ | skipping to change at page 19, line 29 ¶ | |||
The sub-TLV values in Node Descriptor TLVs are defined as follows: | The sub-TLV values in Node Descriptor TLVs are defined as follows: | |||
Autonomous System: Opaque value (32-bit AS Number). This is an | Autonomous System: Opaque value (32-bit AS Number). This is an | |||
optional TLV. The value SHOULD be set to the AS Number associated | optional TLV. The value SHOULD be set to the AS Number associated | |||
with the BGP process originating the link-state information. An | with the BGP process originating the link-state information. An | |||
implementation MAY provide a configuration option on the BGP-LS | implementation MAY provide a configuration option on the BGP-LS | |||
Producer to use a different value; e.g., to avoid collisions when | Producer to use a different value; e.g., to avoid collisions when | |||
using private AS numbers. | using private AS numbers. | |||
BGP-LS Identifier: Opaque value (32-bit ID). This is an optional | BGP-LS Identifier: Opaque value (32-bit ID). This is an optional | |||
TLV. Its original purpose was that, in conjunction with | TLV which has been deprecated by this document (refer to | |||
Autonomous System Number (ASN), it would uniquely identify the | Appendix A for more details). It MAY be advertised for | |||
BGP-LS domain and that the combination of ASN and BGP-LS ID would | compatibility with [RFC7752] implementations. See the final | |||
be globally unique. However, the BGP-LS Instance-ID carried in | paragraph of this section for further considerations and | |||
the Identifier field in the fixed part of the NLRI also provides a | recommended default value. | |||
similar functionality. Hence the inclusion of the BGP-LS | ||||
Identifier TLV is not necessary. If advertised, all BGP-LS | ||||
speakers within an IGP flooding-set (set of IGP nodes within which | ||||
an LSP/LSA is flooded) MUST use the same (ASN, BGP-LS ID) tuple | ||||
and if an IGP domain consists of multiple flooding-sets, then all | ||||
BGP-LS speakers within the IGP domain SHOULD use the same (ASN, | ||||
BGP-LS ID) tuple. | ||||
OSPF Area-ID: Used to identify the 32-bit area to which the | OSPF Area-ID: Used to identify the 32-bit area to which the | |||
information advertised in the NLRI belongs. This is a mandatory | information advertised in the NLRI belongs. This is a mandatory | |||
TLV when originating information from OSPF that is derived from | TLV when originating information from OSPF that is derived from | |||
area-scope LSAs. The OSPF Area Identifier allows different NLRIs | area-scope LSAs. The OSPF Area Identifier allows different NLRIs | |||
of the same router to be differentiated on a per-area basis. It | of the same router to be differentiated on a per-area basis. It | |||
is not used for NLRIs when carrying information that is derived | is not used for NLRIs when carrying information that is derived | |||
from AS-scope LSAs as that information is not associated with a | from AS-scope LSAs as that information is not associated with a | |||
specific area. | specific area. | |||
skipping to change at page 21, line 22 ¶ | skipping to change at page 21, line 11 ¶ | |||
representation of a logical link. To fully describe a single logical | representation of a logical link. To fully describe a single logical | |||
link, two anchor routers advertise a half-link each, i.e., two Link | link, two anchor routers advertise a half-link each, i.e., two Link | |||
NLRIs are advertised for a given point-to-point link. | NLRIs are advertised for a given point-to-point link. | |||
A link between two nodes is not considered as complete (or available) | A link between two nodes is not considered as complete (or available) | |||
unless it is described by the two Link NLRIs corresponding to the | unless it is described by the two Link NLRIs corresponding to the | |||
half-link representation from the pair of anchor nodes. This check | half-link representation from the pair of anchor nodes. This check | |||
is similar to the 'two-way connectivity check' that is performed by | is similar to the 'two-way connectivity check' that is performed by | |||
link-state IGPs. | link-state IGPs. | |||
An implementation may end up suppressing the advertisement of a Link | An implementation MAY suppress the advertisement of a Link NLRI, | |||
NLRI, corresponding to a half-link, from a link-state IGP unless the | corresponding to a half-link, from a link-state IGP unless the IGP | |||
IGP has verified that the link is being reported in the IS-IS LSP or | has verified that the link is being reported in the IS-IS LSP or OSPF | |||
OSPF Router LSA by both the nodes connected by that link. This 'two- | Router LSA by both the nodes connected by that link. This 'two-way | |||
way connectivity check' is performed by link-state IGPs during their | connectivity check' is performed by link-state IGPs during their | |||
computation and may be leveraged before passing information for any | computation and can be leveraged before passing information for any | |||
half-link that is reported from these IGPs into BGP-LS. This ensures | half-link that is reported from these IGPs into BGP-LS. This ensures | |||
that only those Link State IGP adjacencies which are established get | that only those Link State IGP adjacencies which are established get | |||
reported via Link NLRIs. Such a 'two-way connectivity check' may be | reported via Link NLRIs. Such a 'two-way connectivity check' could | |||
also required in certain cases (e.g., with OSPF) to obtain the proper | be also required in certain cases (e.g., with OSPF) to obtain the | |||
link identifiers of the remote node. | proper link identifiers of the remote node. | |||
The format and semantics of the Value fields in most Link Descriptor | The format and semantics of the Value fields in most Link Descriptor | |||
TLVs correspond to the format and semantics of value fields in IS-IS | TLVs correspond to the format and semantics of value fields in IS-IS | |||
Extended IS Reachability sub-TLVs, defined in [RFC5305], [RFC5307], | Extended IS Reachability sub-TLVs, defined in [RFC5305], [RFC5307], | |||
and [RFC6119]. Although the encodings for Link Descriptor TLVs were | and [RFC6119]. Although the encodings for Link Descriptor TLVs were | |||
originally defined for IS-IS, the TLVs can carry data sourced by | originally defined for IS-IS, the TLVs can carry data sourced by | |||
either IS-IS or OSPF. | either IS-IS or OSPF. | |||
The following TLVs are defined as Link Descriptors in the Link NLRI: | The following TLVs are defined as Link Descriptors in the Link NLRI: | |||
skipping to change at page 22, line 39 ¶ | skipping to change at page 22, line 39 ¶ | |||
The information about a link present in the LSA/LSP originated by the | The information about a link present in the LSA/LSP originated by the | |||
local node of the link determines the set of TLVs in the Link | local node of the link determines the set of TLVs in the Link | |||
Descriptor of the link. | Descriptor of the link. | |||
If interface and neighbor addresses, either IPv4 or IPv6, are | If interface and neighbor addresses, either IPv4 or IPv6, are | |||
present, then the interface/neighbor address TLVs MUST be | present, then the interface/neighbor address TLVs MUST be | |||
included, and the Link Local/Remote Identifiers TLV MUST NOT be | included, and the Link Local/Remote Identifiers TLV MUST NOT be | |||
included in the Link Descriptor. The Link Local/Remote | included in the Link Descriptor. The Link Local/Remote | |||
Identifiers TLV MAY be included in the link attribute when | Identifiers TLV MAY be included in the link attribute when | |||
available. IPv6 link-local addresses MUST NOT be carried in the | available. IPv4/IPv6 link-local addresses MUST NOT be carried in | |||
IPv6 interface/neighbor address TLVs (261/262) as descriptors of a | the IPv4/IPv6 interface/neighbor address TLVs (259/260/261/262) as | |||
link as they are not considered unique. | descriptors of a link as they are not considered unique. | |||
If interface and neighbor addresses are not present and the link | If interface and neighbor addresses are not present and the link | |||
local/remote identifiers are present, then the Link Local/Remote | local/remote identifiers are present, then the Link Local/Remote | |||
Identifiers TLV MUST be included in the Link Descriptor. The Link | Identifiers TLV MUST be included in the Link Descriptor. The Link | |||
Local/Remote Identifiers MUST be included in the Link Descriptor | Local/Remote Identifiers MUST be included in the Link Descriptor | |||
also in the case of links having only IPv6 link-local addressing | also in the case of links having only IPv6 link-local addressing | |||
on them. | on them. | |||
The Multi-Topology Identifier TLV MUST be included as a Link | The Multi-Topology Identifier TLV MUST be included as a Link | |||
Descriptor if the underlying IGP link object is associated with a | Descriptor if the underlying IGP link object is associated with a | |||
skipping to change at page 26, line 21 ¶ | skipping to change at page 26, line 21 ¶ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 14: IP Reachability Information TLV Format | Figure 14: IP Reachability Information TLV Format | |||
The Type and Length fields of the TLV are defined in Table 5. The | The Type and Length fields of the TLV are defined in Table 5. The | |||
following two fields determine the reachability information of the | following two fields determine the reachability information of the | |||
address family. The Prefix Length field contains the length of the | address family. The Prefix Length field contains the length of the | |||
prefix in bits. The IP Prefix field contains an IP address prefix, | prefix in bits. The IP Prefix field contains an IP address prefix, | |||
followed by the minimum number of trailing bits needed to make the | followed by the minimum number of trailing bits needed to make the | |||
end of the field fall on an octet boundary. Any trailing bits MUST | end of the field fall on an octet boundary. Any trailing bits MUST | |||
be set to 0. Thus the IP Prefix field contains the most significant | be set to 0. Thus, the IP Prefix field contains the most significant | |||
octets of the prefix, i.e., 1 octet for prefix length 1 up to 8, 2 | octets of the prefix, i.e., 1 octet for prefix length 1 up to 8, 2 | |||
octets for prefix length 9 to 16, 3 octets for prefix length 17 up to | octets for prefix length 9 to 16, 3 octets for prefix length 17 up to | |||
24, 4 octets for prefix length 25 up to 32, etc. | 24, 4 octets for prefix length 25 up to 32, etc. | |||
5.3. The BGP-LS Attribute | 5.3. The BGP-LS Attribute | |||
The BGP-LS Attribute (assigned value 29 by IANA) is an optional, non- | The BGP-LS Attribute (assigned value 29 by IANA) is an optional, non- | |||
transitive BGP attribute that is used to carry link, node, and prefix | transitive BGP attribute that is used to carry link, node, and prefix | |||
parameters and attributes. It is defined as a set of Type/Length/ | parameters and attributes. It is defined as a set of Type/Length/ | |||
Value (TLV) triplets, described in the following section. This | Value (TLV) triplets, described in the following section. This | |||
attribute SHOULD only be included with Link-State NLRIs. This | attribute SHOULD only be included with Link-State NLRIs. The use of | |||
attribute MUST be ignored for all other address families. | this attribute for other address families is outside the scope of | |||
this document. | ||||
The Node Attribute TLVs, Link Attribute TLVs, and Prefix Attribute | The Node Attribute TLVs, Link Attribute TLVs, and Prefix Attribute | |||
TLVs are sets of TLVs that may be encoded in the BGP-LS Attribute | TLVs are sets of TLVs that may be encoded in the BGP-LS Attribute | |||
associated with a Node NLRI, Link NLRI, and Prefix NLRI respectively. | associated with a Node NLRI, Link NLRI, and Prefix NLRI respectively. | |||
The size of the BGP-LS Attribute may potentially grow large depending | The size of the BGP-LS Attribute may potentially grow large depending | |||
on the amount of link-state information associated with a single | on the amount of link-state information associated with a single | |||
Link-State NLRI. The BGP specification [RFC4271] mandates a maximum | Link-State NLRI. The BGP specification [RFC4271] mandates a maximum | |||
BGP message size of 4096 octets. It is RECOMMENDED that an | BGP message size of 4096 octets. It is RECOMMENDED that an | |||
implementation supports [RFC8654] to accommodate a larger size of | implementation supports [RFC8654] to accommodate a larger size of | |||
information within the BGP-LS Attribute. BGP-LS Producers MUST | information within the BGP-LS Attribute. BGP-LS Producers MUST | |||
ensure that they limit the TLVs included in the BGP-LS Attribute to | ensure that the TLVs included in the BGP-LS Attribute does not result | |||
ensure that a BGP UPDATE message for a single Link-State NLRI does | in a BGP UPDATE message for a single Link-State NLRI that crosses the | |||
not cross the maximum limit for a BGP message. The determination of | maximum limit for a BGP message. | |||
the types of TLVs to be included may be made by the BGP-LS Producer | ||||
based on the BGP-LS Consumer applications requirement and is outside | An implementation MAY adopt mechanisms to avoid this problem that may | |||
the scope of this document. When a BGP-LS Propagator finds that it | be based the BGP-LS Consumer applications' requirement; these | |||
is exceeding the maximum BGP message size due to the addition or | mechanisms are beyond the scope of this specification. However, if | |||
update of some other BGP Attribute (e.g. AS_PATH), it MUST consider | an implementation chooses to mitigate the problem by excluding some | |||
the BGP-LS Attribute to be malformed, apply the "Attribute Discard" | TLVs from the BGP-LS Attribute, this exclusion SHOULD be done | |||
error-handling approach [RFC7606], and handle the propagation as | consistently by all BGP-LS Producers within a given BGP-LS domain. | |||
described in Section 8.2.2. When a BGP-LS Propagator needs to | In the event of inconsistent exclusion of TLVs from the BGP-LS | |||
perform "Attribute Discard" for reducing the BGP UPDATE message size | Attribute, the result would be a differing set of attributes of the | |||
as specified in section 4 of [RFC8654], it MUST first discard the | link-state object being propagated to BGP-LS Consumers based on the | |||
BGP-LS Attribute to enable the detection and diagnosis of this error | BGP decision process at BGP-LS Propagators. | |||
condition as discussed in Section 8.2.2. This brings the deployment | ||||
consideration that the consistent propagation of BGP-LS information | When a BGP-LS Propagator finds that it is exceeding the maximum BGP | |||
with a BGP UPDATE message size larger than 4096 octets can only | message size due to the addition or update of some other BGP | |||
happen along a set of BGP Speakers that all support [RFC8654]. | Attribute (e.g. AS_PATH), it MUST consider the BGP-LS Attribute to | |||
be malformed, apply the "Attribute Discard" error-handling approach | ||||
[RFC7606], and handle the propagation as described in Section 8.2.2. | ||||
When a BGP-LS Propagator needs to perform "Attribute Discard" for | ||||
reducing the BGP UPDATE message size as specified in section 4 of | ||||
[RFC8654], it MUST first discard the BGP-LS Attribute to enable the | ||||
detection and diagnosis of this error condition as discussed in | ||||
Section 8.2.2. This brings the deployment consideration that the | ||||
consistent propagation of BGP-LS information with a BGP UPDATE | ||||
message size larger than 4096 octets can only happen along a set of | ||||
BGP Speakers that all support [RFC8654]. | ||||
5.3.1. Node Attribute TLVs | 5.3.1. Node Attribute TLVs | |||
The following Node Attribute TLVs are defined for the BGP-LS | The following Node Attribute TLVs are defined for the BGP-LS | |||
Attribute associated with a Node NLRI: | Attribute associated with a Node NLRI: | |||
+================+================+==========+===============+ | +================+================+==========+===============+ | |||
| TLV Code Point | Description | Length | Reference | | | TLV Code Point | Description | Length | Reference | | |||
| | | | (RFC/Section) | | | | | | (RFC/Section) | | |||
+================+================+==========+===============+ | +================+================+==========+===============+ | |||
skipping to change at page 28, line 41 ¶ | skipping to change at page 29, line 23 ¶ | |||
+-----+--------------+------------+ | +-----+--------------+------------+ | |||
| 'B' | ABR Bit | [RFC2328] | | | 'B' | ABR Bit | [RFC2328] | | |||
+-----+--------------+------------+ | +-----+--------------+------------+ | |||
| 'R' | Router Bit | [RFC5340] | | | 'R' | Router Bit | [RFC5340] | | |||
+-----+--------------+------------+ | +-----+--------------+------------+ | |||
| 'V' | V6 Bit | [RFC5340] | | | 'V' | V6 Bit | [RFC5340] | | |||
+-----+--------------+------------+ | +-----+--------------+------------+ | |||
Table 7: Node Flag Bits Definitions | Table 7: Node Flag Bits Definitions | |||
The bits that are not defined MUST be set to 0 by the originator and | ||||
MUST be ignored by the receiver. | ||||
5.3.1.2. IS-IS Area Identifier TLV | 5.3.1.2. IS-IS Area Identifier TLV | |||
An IS-IS node can be part of only a single IS-IS area. However, a | An IS-IS node can be part of only a single IS-IS area. However, a | |||
node can have multiple synonymous area addresses. Each of these area | node can have multiple synonymous area addresses. Each of these area | |||
addresses is carried in the IS-IS Area Identifier TLV. If multiple | addresses is carried in the IS-IS Area Identifier TLV. If multiple | |||
area addresses are present, multiple TLVs are used to encode them. | area addresses are present, multiple TLVs are used to encode them. | |||
The IS-IS Area Identifier TLV may be present in the BGP-LS Attribute | The IS-IS Area Identifier TLV may be present in the BGP-LS Attribute | |||
only when advertised in the Link-State Node NLRI. | only when advertised in the Link-State Node NLRI. | |||
0 1 2 3 | 0 1 2 3 | |||
skipping to change at page 29, line 21 ¶ | skipping to change at page 29, line 51 ¶ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 16: IS-IS Area Identifier TLV Format | Figure 16: IS-IS Area Identifier TLV Format | |||
5.3.1.3. Node Name TLV | 5.3.1.3. Node Name TLV | |||
The Node Name TLV is optional. The encoding semantics for the node | The Node Name TLV is optional. The encoding semantics for the node | |||
name has been borrowed from [RFC5301]. The Value field identifies | name has been borrowed from [RFC5301]. The Value field identifies | |||
the symbolic name of the router node. This symbolic name can either | the symbolic name of the router node. This symbolic name can either | |||
be the Fully Qualified Domain Name (FQDN) for the router, or it can | be the Fully Qualified Domain Name (FQDN) for the router, or it can | |||
be a subset of the FQDN (e.g., a hostname), or it can be any string | be a substring of the FQDN (e.g., a hostname), or it can be any | |||
that an operator wants to use for the router. The use of FQDN or a | string that an operator wants to use for the router. The use of FQDN | |||
subset of it is strongly RECOMMENDED. The maximum length of the Node | or a substring of it is strongly RECOMMENDED. The maximum length of | |||
Name TLV is 255 octets. | the Node Name TLV is 255 octets. | |||
The Value field is encoded in 7-bit ASCII. If a user interface for | The Value field is encoded in 7-bit ASCII. If a user interface for | |||
configuring or displaying this field permits Unicode characters, that | configuring or displaying this field permits Unicode characters, that | |||
the user interface is responsible for applying the ToASCII and/or | the user interface is responsible for applying the ToASCII and/or | |||
ToUnicode algorithm as described in [RFC5890] to achieve the correct | ToUnicode algorithm as described in [RFC5890] to achieve the correct | |||
format for transmission or display. | format for transmission or display. | |||
[RFC5301] describes an IS-IS-specific extension and [RFC5642] | [RFC5301] describes an IS-IS-specific extension and [RFC5642] | |||
describes an OSPF extension for the advertisement of Node Name which | describes an OSPF extension for the advertisement of Node Name which | |||
may be encoded in the Node Name TLV. | may be encoded in the Node Name TLV. | |||
skipping to change at page 30, line 21 ¶ | skipping to change at page 31, line 5 ¶ | |||
field or new protocol extensions to the protocol as advertised in the | field or new protocol extensions to the protocol as advertised in the | |||
NLRI header Protocol-ID field for which there is no protocol-neutral | NLRI header Protocol-ID field for which there is no protocol-neutral | |||
representation in the BGP Link-State NLRI. The primary use of the | representation in the BGP Link-State NLRI. The primary use of the | |||
Opaque Node Attribute TLV is to bridge the document lag between a new | Opaque Node Attribute TLV is to bridge the document lag between a new | |||
IGP link-state attribute and its protocol-neutral BGP-LS extension | IGP link-state attribute and its protocol-neutral BGP-LS extension | |||
being defined. Once the protocol-neutral BGP-LS extensions are | being defined. Once the protocol-neutral BGP-LS extensions are | |||
defined, the BGP-LS implementations may still need to advertise the | defined, the BGP-LS implementations may still need to advertise the | |||
information both within the Opaque Attribute TLV and the new TLV | information both within the Opaque Attribute TLV and the new TLV | |||
definition for incremental deployment and transition. | definition for incremental deployment and transition. | |||
In the case of OSPF, this TLV may be used only to advertise the TLVs | In the case of OSPF, this TLV MUST NOT be used to advertise TLVs | |||
in the OSPF Router Information (RI) LSA [RFC7770]. | other than those in the OSPF Router Information (RI) LSA [RFC7770]. | |||
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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
// Opaque node attributes (variable) // | // Opaque node attributes (variable) // | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 18: Opaque Node Attribute Format | Figure 18: Opaque Node Attribute Format | |||
skipping to change at page 32, line 40 ¶ | skipping to change at page 33, line 28 ¶ | |||
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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|L|R| Reserved | | |L|R| Reserved | | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
Figure 19: MPLS Protocol Mask TLV | Figure 19: MPLS Protocol Mask TLV | |||
The following bits are defined and the reserved bits MUST be set to | The following bits are defined, and the reserved bits MUST be set to | |||
zero and SHOULD be ignored on receipt: | zero and SHOULD be ignored on receipt: | |||
+=====+=============================================+===========+ | +=====+=============================================+===========+ | |||
| Bit | Description | Reference | | | Bit | Description | Reference | | |||
+=====+=============================================+===========+ | +=====+=============================================+===========+ | |||
| 'L' | Label Distribution Protocol (LDP) | [RFC5036] | | | 'L' | Label Distribution Protocol (LDP) | [RFC5036] | | |||
+-----+---------------------------------------------+-----------+ | +-----+---------------------------------------------+-----------+ | |||
| 'R' | Extension to RSVP for LSP Tunnels (RSVP-TE) | [RFC3209] | | | 'R' | Extension to RSVP for LSP Tunnels (RSVP-TE) | [RFC3209] | | |||
+-----+---------------------------------------------+-----------+ | +-----+---------------------------------------------+-----------+ | |||
Table 9: MPLS Protocol Mask TLV Codes | Table 9: MPLS Protocol Mask TLV Codes | |||
The bits that are not defined MUST be set to 0 by the originator and | ||||
MUST be ignored by the receiver. | ||||
5.3.2.3. TE Default Metric TLV | 5.3.2.3. TE Default Metric TLV | |||
The TE Default Metric TLV carries the Traffic Engineering metric for | The TE Default Metric TLV carries the Traffic Engineering metric for | |||
this link. The length of this TLV is fixed at 4 octets. If a source | this link. The length of this TLV is fixed at 4 octets. If a source | |||
protocol uses a metric width of fewer than 32 bits, then the high- | protocol uses a metric width of fewer than 32 bits, then the high- | |||
order bits of this field MUST be padded with zero. | order bits of this field MUST be padded with zero. | |||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
skipping to change at page 33, line 26 ¶ | skipping to change at page 34, line 19 ¶ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| TE Default Link Metric | | | TE Default Link Metric | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 20: TE Default Metric TLV Format | Figure 20: TE Default Metric TLV Format | |||
5.3.2.4. IGP Metric TLV | 5.3.2.4. IGP Metric TLV | |||
The IGP Metric TLV carries the metric for this link. The length of | The IGP Metric TLV carries the metric for this link. The length of | |||
this TLV is variable, depending on the metric width of the underlying | this TLV is variable, depending on the metric width of the underlying | |||
protocol. IS-IS small metrics have a length of 1 octet. Since the | protocol. IS-IS small metrics are of 6-bit size, but are encoded in | |||
ISIS small metrics are of 6-bit size, the two most significant bits | a 1 octet field; therefore the two most significant bits of the field | |||
MUST be set to 0 and MUST be ignored by the receiver. OSPF link | MUST be set to 0 by the originator and MUST be ignored by the | |||
metrics have a length of 2 octets. IS-IS wide metrics have a length | receiver. OSPF link metrics have a length of 2 octets. IS-IS wide | |||
of 3 octets. | metrics have a length of 3 octets. | |||
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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
// IGP Link Metric (variable length) // | // IGP Link Metric (variable length) // | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 21: IGP Metric TLV Format | Figure 21: IGP Metric TLV Format | |||
skipping to change at page 34, line 41 ¶ | skipping to change at page 35, line 41 ¶ | |||
field or new protocol extensions to the protocol as advertised in the | field or new protocol extensions to the protocol as advertised in the | |||
NLRI header Protocol-ID field for which there is no protocol-neutral | NLRI header Protocol-ID field for which there is no protocol-neutral | |||
representation in the BGP Link-State NLRI. The primary use of the | representation in the BGP Link-State NLRI. The primary use of the | |||
Opaque Link Attribute TLV is to bridge the document lag between a new | Opaque Link Attribute TLV is to bridge the document lag between a new | |||
IGP link-state attribute and its 'protocol-neutral' BGP-LS extension | IGP link-state attribute and its 'protocol-neutral' BGP-LS extension | |||
being defined. Once the protocol-neutral BGP-LS extensions are | being defined. Once the protocol-neutral BGP-LS extensions are | |||
defined, the BGP-LS implementations may still need to advertise the | defined, the BGP-LS implementations may still need to advertise the | |||
information both within the Opaque Attribute TLV and the new TLV | information both within the Opaque Attribute TLV and the new TLV | |||
definition for incremental deployment and transition. | definition for incremental deployment and transition. | |||
In the case of OSPFv2, this TLV may be used to only advertise | In the case of OSPFv2, this TLV MUST NOT be used to advertise | |||
information carried using the TLVs in the OSPFv2 Extended Link Opaque | information carried using TLVs other than those in the OSPFv2 | |||
LSA [RFC7684]. In the case of OSPFv3, this TLV may be used only to | Extended Link Opaque LSA [RFC7684]. In the case of OSPFv3, this TLV | |||
advertise the TLVs in the OSPFv3 E-Router-LSA or E-Link-LSA | MUST NOT be used to advertise TLVs other than those in the OSPFv3 E- | |||
[RFC8362]. | Router-LSA or E-Link-LSA [RFC8362]. | |||
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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
// Opaque link attributes (variable) // | // Opaque link attributes (variable) // | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 23: Opaque Link Attribute TLV Format | Figure 23: Opaque Link Attribute TLV Format | |||
5.3.2.7. Link Name TLV | 5.3.2.7. Link Name TLV | |||
The Link Name TLV is optional. The Value field identifies the | The Link Name TLV is optional. The Value field identifies the | |||
symbolic name of the router link. This symbolic name can either be | symbolic name of the router link. This symbolic name can either be | |||
the FQDN for the link, or it can be a subset of the FQDN, or it can | the FQDN for the link, or it can be a substring of the FQDN, or it | |||
be any string that an operator wants to use for the link. The use of | can be any string that an operator wants to use for the link. The | |||
FQDN or a subset of it is strongly RECOMMENDED. The maximum length | use of FQDN or a substring of it is strongly RECOMMENDED. The | |||
of the Link Name TLV is 255 octets. | maximum length of the Link Name TLV is 255 octets. | |||
The Value field is encoded in 7-bit ASCII. If a user interface for | The Value field is encoded in 7-bit ASCII. If a user interface for | |||
configuring or displaying this field permits Unicode characters, that | configuring or displaying this field permits Unicode characters, that | |||
the user interface is responsible for applying the ToASCII and/or | the user interface is responsible for applying the ToASCII and/or | |||
ToUnicode algorithm as described in [RFC5890] to achieve the correct | ToUnicode algorithm as described in [RFC5890] to achieve the correct | |||
format for transmission or display. | format for transmission or display. | |||
How a router derives and injects link names is outside of the scope | How a router derives and injects link names is outside of the scope | |||
of this document. | of this document. | |||
skipping to change at page 36, line 37 ¶ | skipping to change at page 37, line 37 ¶ | |||
The IGP Flags TLV contains one octet of IS-IS and OSPF flags and bits | The IGP Flags TLV contains one octet of IS-IS and OSPF flags and bits | |||
originally assigned to the prefix. The IGP Flags TLV is encoded as | originally assigned to the prefix. The IGP Flags TLV is encoded as | |||
follows: | 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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|D|N|L|P|Reservd| | |D|N|L|P| | | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
Figure 25: IGP Flag TLV Format | Figure 25: IGP Flag TLV Format | |||
The Value field contains bits defined according to the table below | The Value field contains bits defined according to the table below: | |||
and the reserved bits MUST be set to zero and SHOULD be ignored on | ||||
receipt: | ||||
+=====+===========================+===========+ | +=====+===========================+===========+ | |||
| Bit | Description | Reference | | | Bit | Description | Reference | | |||
+=====+===========================+===========+ | +=====+===========================+===========+ | |||
| 'D' | IS-IS Up/Down Bit | [RFC5305] | | | 'D' | IS-IS Up/Down Bit | [RFC5305] | | |||
+-----+---------------------------+-----------+ | +-----+---------------------------+-----------+ | |||
| 'N' | OSPF "no unicast" Bit | [RFC5340] | | | 'N' | OSPF "no unicast" Bit | [RFC5340] | | |||
+-----+---------------------------+-----------+ | +-----+---------------------------+-----------+ | |||
| 'L' | OSPF "local address" Bit | [RFC5340] | | | 'L' | OSPF "local address" Bit | [RFC5340] | | |||
+-----+---------------------------+-----------+ | +-----+---------------------------+-----------+ | |||
| 'P' | OSPF "propagate NSSA" Bit | [RFC5340] | | | 'P' | OSPF "propagate NSSA" Bit | [RFC5340] | | |||
+-----+---------------------------+-----------+ | +-----+---------------------------+-----------+ | |||
Table 11: IGP Flag Bits Definitions | Table 11: IGP Flag Bits Definitions | |||
The bits that are not defined MUST be set to 0 by the originator and | ||||
MUST be ignored by the receiver. | ||||
5.3.3.2. IGP Route Tag TLV | 5.3.3.2. IGP Route Tag TLV | |||
The IGP Route Tag TLV carries original IGP Tags (IS-IS [RFC5130] or | The IGP Route Tag TLV carries original IGP Tags (IS-IS [RFC5130] or | |||
OSPF) of the prefix and is encoded as follows: | OSPF) of the prefix and is encoded 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 39, line 21 ¶ | skipping to change at page 40, line 34 ¶ | |||
field or new protocol extensions to the protocol as advertised in the | field or new protocol extensions to the protocol as advertised in the | |||
NLRI header Protocol-ID field for which there is no protocol-neutral | NLRI header Protocol-ID field for which there is no protocol-neutral | |||
representation in the BGP Link-State NLRI. The primary use of the | representation in the BGP Link-State NLRI. The primary use of the | |||
Opaque Prefix Attribute TLV is to bridge the document lag between a | Opaque Prefix Attribute TLV is to bridge the document lag between a | |||
new IGP link-state attribute and its protocol-neutral BGP-LS | new IGP link-state attribute and its protocol-neutral BGP-LS | |||
extension being defined. Once the protocol-neutral BGP-LS extensions | extension being defined. Once the protocol-neutral BGP-LS extensions | |||
are defined, the BGP-LS implementations may still need to advertise | are defined, the BGP-LS implementations may still need to advertise | |||
the information both within the Opaque Attribute TLV and the new TLV | the information both within the Opaque Attribute TLV and the new TLV | |||
definition for incremental deployment and transition. | definition for incremental deployment and transition. | |||
In the case of OSPFv2, this TLV may be used to only advertise | In the case of OSPFv2, this TLV MUST NOT be used to advertise | |||
information carried using the TLVs in the OSPFv2 Extended Prefix | information carried using TLVs other than those in the OSPFv2 | |||
Opaque LSA [RFC7684]. In the case of OSPFv3, this TLV may be used | Extended Prefix Opaque LSA [RFC7684]. In the case of OSPFv3, this | |||
only to advertise the TLVs in the OSPFv3 E-Inter-Area-Prefix-LSA, E- | TLV MUST NOT be used to advertise TLVs other than those in the OSPFv3 | |||
Intra-Area-Prefix-LSA, E-AS-External-Prefix-LSA, and E-NSSA-LSA | E-Inter-Area-Prefix-LSA, E-Intra-Area-Prefix-LSA, E-AS-External- | |||
[RFC8362]. | Prefix-LSA, and E-NSSA-LSA [RFC8362]. | |||
The format of the TLV is as follows: | The format of the 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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
// Opaque Prefix Attributes (variable) // | // Opaque Prefix Attributes (variable) // | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
skipping to change at page 39, line 51 ¶ | skipping to change at page 41, line 16 ¶ | |||
5.4. Private Use | 5.4. Private Use | |||
TLVs for Vendor Private use are supported using the code point range | TLVs for Vendor Private use are supported using the code point range | |||
reserved as indicated in Section 7. For such TLV use in the NLRI or | reserved as indicated in Section 7. For such TLV use in the NLRI or | |||
BGP-LS Attribute, the format as described in Section 5.1 is to be | BGP-LS Attribute, the format as described in Section 5.1 is to be | |||
used and a 4-octet field MUST be included as the first field in the | used and a 4-octet field MUST be included as the first field in the | |||
value to carry the Enterprise Code. For a private use NLRI Type, a 4 | value to carry the Enterprise Code. For a private use NLRI Type, a 4 | |||
octet field MUST be included as the first field in the NLRI | octet field MUST be included as the first field in the NLRI | |||
immediately following the Total NLRI Length field of the Link-State | immediately following the Total NLRI Length field of the Link-State | |||
NLRI format as described in Section 5.2 to carry the Enterprise Code. | NLRI format as described in Section 5.2 to carry the Enterprise Code | |||
The Enterprise Codes are listed at <http://www.iana.org/assignments/ | [ENTNUM]. This enables the use of vendor-specific extensions without | |||
enterprise-numbers>. This enables the use of vendor-specific | conflicts. | |||
extensions without conflicts. | ||||
Multiple instances of private-use TLVs MAY appear in the BGP-LS | Multiple instances of private-use TLVs MAY appear in the BGP-LS | |||
Attribute. | Attribute. | |||
5.5. BGP Next-Hop Information | 5.5. BGP Next-Hop Information | |||
BGP link-state information for both IPv4 and IPv6 networks can be | BGP link-state information for both IPv4 and IPv6 networks can be | |||
carried over either an IPv4 BGP session or an IPv6 BGP session. If | carried over either an IPv4 BGP session or an IPv6 BGP session. If | |||
an IPv4 BGP session is used, then the next-hop in the MP_REACH_NLRI | an IPv4 BGP session is used, then the next-hop in the MP_REACH_NLRI | |||
SHOULD be an IPv4 address. Similarly, if an IPv6 BGP session is | SHOULD be an IPv4 address. Similarly, if an IPv6 BGP session is | |||
skipping to change at page 40, line 29 ¶ | skipping to change at page 41, line 42 ¶ | |||
described in [RFC4760]. The Length field of the next-hop address | described in [RFC4760]. The Length field of the next-hop address | |||
will specify the next-hop address family. If the next-hop length is | will specify the next-hop address family. If the next-hop length is | |||
4, then the next-hop is an IPv4 address; if the next-hop length is | 4, then the next-hop is an IPv4 address; if the next-hop length is | |||
16, then it is a global IPv6 address; and if the next-hop length is | 16, then it is a global IPv6 address; and if the next-hop length is | |||
32, then there is one global IPv6 address followed by a link-local | 32, then there is one global IPv6 address followed by a link-local | |||
IPv6 address. The link-local IPv6 address should be used as | IPv6 address. The link-local IPv6 address should be used as | |||
described in [RFC2545]. For VPN Subsequent Address Family Identifier | described in [RFC2545]. For VPN Subsequent Address Family Identifier | |||
(SAFI), as per custom, an 8-byte Route Distinguisher set to all zero | (SAFI), as per custom, an 8-byte Route Distinguisher set to all zero | |||
is prepended to the next-hop. | is prepended to the next-hop. | |||
The BGP Next-Hop attribute is used by each BGP-LS speaker to validate | The BGP Next-Hop is used by each BGP-LS speaker to validate the NLRI | |||
the NLRI it receives. In case identical NLRIs are sourced by | it receives. In case identical NLRIs are sourced by multiple BGP-LS | |||
multiple BGP-LS Producers, the BGP Next-Hop attribute is used to | Producers, the BGP Next-Hop is used to tiebreak as per the standard | |||
tiebreak as per the standard BGP path decision process. This | BGP path decision process. This specification doesn't mandate any | |||
specification doesn't mandate any rule regarding the rewrite of the | rule regarding the rewrite of the BGP Next-Hop. | |||
BGP Next-Hop attribute. | ||||
5.6. Inter-AS Links | 5.6. Inter-AS Links | |||
The main source of TE information is the IGP, which is not active on | The main source of TE information is the IGP, which is not active on | |||
inter-AS links. In some cases, the IGP may have information of | inter-AS links. In some cases, the IGP may have information of | |||
inter-AS links [RFC5392] [RFC5316]. In other cases, an | inter-AS links [RFC5392] [RFC9346]. In other cases, an | |||
implementation SHOULD provide a means to inject inter-AS links into | implementation SHOULD provide a means to inject inter-AS links into | |||
BGP-LS. The exact mechanism used to advertise the inter-AS links is | BGP-LS. The exact mechanism used to advertise the inter-AS links is | |||
outside the scope of this document. | outside the scope of this document. | |||
5.7. OSPF Virtual Links and Sham Links | 5.7. OSPF Virtual Links and Sham Links | |||
In an OSPF [RFC2328] [RFC5340] network, OSPF virtual links serve to | In an OSPF [RFC2328] [RFC5340] network, OSPF virtual links serve to | |||
connect physically separate components of the backbone to establish/ | connect physically separate components of the backbone to establish/ | |||
maintain continuity of the backbone area. While OSPF virtual links | maintain continuity of the backbone area. While OSPF virtual links | |||
are modeled as point-to-point unnumbered links in the OSPF topology, | are modeled as point-to-point unnumbered links in the OSPF topology, | |||
their characteristics and purpose are different from other types of | their characteristics and purpose are different from other types of | |||
links in the OSPF topology. They are advertised using a distinct | links in the OSPF topology. They are advertised using a distinct | |||
"virtual link" type in OSPF LSAs. The mechanism for the | "virtual link" type in OSPF LSAs. The mechanism for the | |||
advertisement of OSPF virtual links via BGP-LS is outside the scope | advertisement of OSPF virtual links via BGP-LS is outside the scope | |||
of this document. | of this document. | |||
In an OSPF network, sham links [RFC4577] [RFC6565] are used to | In an OSPF network, sham links [RFC4577] [RFC6565] are used to | |||
provide intra-area connectivity between VRFs on PE routers over the | provide intra-area connectivity between VPN Routing and Forwarding | |||
VPN provider's network. These links are advertised in OSPF as point- | (VRF) instances on PE routers over the VPN provider's network. These | |||
to-point unnumbered links and represent connectivity over a service | links are advertised in OSPF as point-to-point unnumbered links and | |||
provider network using encapsulation mechanisms like MPLS. As such, | represent connectivity over a service provider network using | |||
the mechanism for the advertisement of OSPF sham links follows the | encapsulation mechanisms like MPLS. As such, the mechanism for the | |||
same procedures as other point-to-point unnumbered links as described | advertisement of OSPF sham links follows the same procedures as other | |||
previously in this document. | point-to-point unnumbered links as described previously in this | |||
document. | ||||
5.8. OSPFv2 Type 4 Summary LSA & OSPFv3 Inter-Area Router LSA | 5.8. OSPFv2 Type 4 Summary LSA & OSPFv3 Inter-Area Router LSA | |||
OSPFv2 [RFC2328] defines the Type 4 Summary LSA and OSPFv3 [RFC5340] | OSPFv2 [RFC2328] defines the Type 4 Summary LSA and OSPFv3 [RFC5340] | |||
the Inter-area-router-LSA for an Area Border Router (ABR) to | the Inter-area-router-LSA for an Area Border Router (ABR) to | |||
advertise reachability to an AS Border Router (ASBR) that is external | advertise reachability to an AS Border Router (ASBR) that is external | |||
to the area yet internal to the AS. The nature of information | to the area yet internal to the AS. The nature of information | |||
advertised by OSPF using this type of LSA does not map to either a | advertised by OSPF using this type of LSA does not map to either a | |||
node or a link or a prefix as discussed in this document. Therefore, | node or a link or a prefix as discussed in this document. Therefore, | |||
the mechanism for the advertisement of the information carried by | the mechanism for the advertisement of the information carried by | |||
skipping to change at page 42, line 39 ¶ | skipping to change at page 44, line 7 ¶ | |||
derives from R6's stale Router LSA. | derives from R6's stale Router LSA. | |||
At the same time, R6 has removed the link R6-R5 from its Router LSA, | At the same time, R6 has removed the link R6-R5 from its Router LSA, | |||
and this updated LSA is available at R3. Similarly, R3 also has a | and this updated LSA is available at R3. Similarly, R3 also has a | |||
stale copy of R5's Router LSA having the link R5-R6 in it. Based on | stale copy of R5's Router LSA having the link R5-R6 in it. Based on | |||
its LSDB, R3 will advertise only the half-link R5-R6 that it has | its LSDB, R3 will advertise only the half-link R5-R6 that it has | |||
derived from R5's stale Router LSA. | derived from R5's stale Router LSA. | |||
Now, the BGP-LS Consumer receives both the Link NLRIs corresponding | Now, the BGP-LS Consumer receives both the Link NLRIs corresponding | |||
to the half-links from R2 and R3 via RR0. When viewed together, it | to the half-links from R2 and R3 via RR0. When viewed together, it | |||
would not detect or realize that area 1 is partitioned. Also if R2 | would not detect or realize that area 1 is partitioned. Also, if R2 | |||
continues to report Node and Prefix NLRIs corresponding to the stale | continues to report Node and Prefix NLRIs corresponding to the stale | |||
copy of R4 and R6's Router LSAs then RR0 could prefer them over the | copy of R4 and R6's Router LSAs then RR0 could prefer them over the | |||
valid Node and Prefix NLRIs for R4 and R6 that it is receiving from | valid Node and Prefix NLRIs for R4 and R6 that it is receiving from | |||
R3 depending on RR0's BGP decision process. This would result in the | R3 depending on RR0's BGP decision process. This would result in the | |||
BGP-LS Consumer getting stale and inaccurate topology information. | BGP-LS Consumer getting stale and inaccurate topology information. | |||
This problem scenario is avoided if R2 were to not advertise the | This problem scenario is avoided if R2 were to not advertise the | |||
link-state information corresponding to R4 and R6 and if R3 were to | link-state information corresponding to R4 and R6 and if R3 were to | |||
not advertise similarly for R1 and R5. | not advertise similarly for R1 and R5. | |||
A BGP-LS Producer SHOULD withdraw all link-state objects advertised | A BGP-LS Producer SHOULD withdraw all link-state objects advertised | |||
skipping to change at page 44, line 28 ¶ | skipping to change at page 45, line 44 ¶ | |||
The Link NLRI of (Node1, Pseudonode1) is encoded as follows: | The Link NLRI of (Node1, Pseudonode1) is encoded as follows: | |||
* Local Node Descriptor | * Local Node Descriptor | |||
TLV #515: IGP Router-ID: 192.0.2.1 | TLV #515: IGP Router-ID: 192.0.2.1 | |||
TLV #514: OSPF Area-ID: ID:0.0.0.0 | TLV #514: OSPF Area-ID: ID:0.0.0.0 | |||
* Remote Node Descriptor | * Remote Node Descriptor | |||
TLV #515: IGP Router-ID: 192.0.2.1:10.1.1.1 | TLV #515: IGP Router-ID: 192.0.2.1:198.51.100.1 | |||
TLV #514: OSPF Area-ID: ID:0.0.0.0 | TLV #514: OSPF Area-ID: ID:0.0.0.0 | |||
The Link NLRI of (Pseudonode1, Node2) is encoded as follows: | The Link NLRI of (Pseudonode1, Node2) is encoded as follows: | |||
* Local Node Descriptor | * Local Node Descriptor | |||
TLV #515: IGP Router-ID: 192.0.2.1:198.51.100.1 | TLV #515: IGP Router-ID: 192.0.2.1:198.51.100.1 | |||
TLV #514: OSPF Area-ID: ID:0.0.0.0 | TLV #514: OSPF Area-ID: ID:0.0.0.0 | |||
* Remote Node Descriptor | * Remote Node Descriptor | |||
TLV #515: IGP Router-ID: 192.0.2.2 | TLV #515: IGP Router-ID: 192.0.2.2 | |||
TLV #514: OSPF Area-ID: ID:0.0.0.0 | TLV #514: OSPF Area-ID: ID:0.0.0.0 | |||
198.51.100.1/24 198.51.100.2/24 | 198.51.100.1/24 198.51.100.2/24 | |||
+-------------+ +-------------+ +-------------+ | +-------------+ +-------------+ +-------------+ | |||
skipping to change at page 47, line 34 ¶ | skipping to change at page 49, line 27 ¶ | |||
7. IANA Considerations | 7. IANA Considerations | |||
As this document obsoletes [RFC7752] and [RFC9029], IANA is requested | As this document obsoletes [RFC7752] and [RFC9029], IANA is requested | |||
to change all registration information that references those | to change all registration information that references those | |||
documents to instead reference this document. | documents to instead reference this document. | |||
IANA has assigned address family number 16388 (BGP-LS) in the | IANA has assigned address family number 16388 (BGP-LS) in the | |||
"Address Family Numbers" registry. | "Address Family Numbers" registry. | |||
IANA has assigned SAFI values 71 (BGP-LS) and 72 (BGP-LS-VPN) in the | IANA has assigned SAFI values 71 (BGP-LS) and 72 (BGP-LS-VPN) in the | |||
"SAFI Values" sub-registry under the "Subsequent Address Family | "SAFI Values" registry under the "Subsequent Address Family | |||
Identifiers (SAFI) Parameters" registry. | Identifiers (SAFI) Parameters" registry group. | |||
IANA has assigned value 29 (BGP-LS Attribute) in the "BGP Path | IANA has assigned value 29 (BGP-LS Attribute) in the "BGP Path | |||
Attributes" sub-registry under the "Border Gateway Protocol (BGP) | Attributes" registry under the "Border Gateway Protocol (BGP) | |||
Parameters" registry. | Parameters" registry group. | |||
IANA has created a new "Border Gateway Protocol - Link-State (BGP-LS) | IANA has created a "Border Gateway Protocol - Link-State (BGP-LS) | |||
Parameters" registry at <https://www.iana.org/assignments/bgp-ls- | Parameters" registry group at <https://www.iana.org/assignments/bgp- | |||
parameters>. | ls-parameters>. | |||
This section also incorporates all the changes to the allocation | This section also incorporates all the changes to the allocation | |||
procedures for the BGP-LS IANA registries as well as the guidelines | procedures for the BGP-LS IANA registry group as well as the | |||
for designated experts introduced by [RFC9029]. | guidelines for designated experts introduced by [RFC9029]. | |||
7.1. BGP-LS Registries | 7.1. BGP-LS Registries | |||
All of the registries listed in the following sub-sections are BGP-LS | All of the registries listed in the following subsections are BGP-LS | |||
specific and are accessible under this registry. | specific and are accessible under this registry. | |||
7.1.1. BGP-LS NLRI Types Registry | 7.1.1. BGP-LS NLRI Types Registry | |||
The "BGP-LS NLRI Types" registry has been set up for assignment for | The "BGP-LS NLRI Types" registry has been set up for assignment for | |||
the two-octet sized code-points for BGP-LS NLRI types and populated | the two-octet sized code-points for BGP-LS NLRI types and populated | |||
with the values shown below: | with the values shown below: | |||
+=============+===========================+=================+ | +=============+===========================+=================+ | |||
| Type | NLRI Type | Reference | | | Type | NLRI Type | Reference | | |||
skipping to change at page 49, line 36 ¶ | skipping to change at page 51, line 36 ¶ | |||
A range is reserved for Private Use [RFC8126]. All other allocations | A range is reserved for Private Use [RFC8126]. All other allocations | |||
within the registry are to be made using the "Expert Review" policy | within the registry are to be made using the "Expert Review" policy | |||
[RFC8126] that requires documentation of the proposed use of the | [RFC8126] that requires documentation of the proposed use of the | |||
allocated value and approval by the Designated Expert assigned by the | allocated value and approval by the Designated Expert assigned by the | |||
IESG. | IESG. | |||
7.1.3. BGP-LS Well-Known Instance-IDs Registry | 7.1.3. BGP-LS Well-Known Instance-IDs Registry | |||
The "BGP-LS Well-Known Instance-IDs" registry that was set up via | The "BGP-LS Well-Known Instance-IDs" registry that was set up via | |||
[RFC7752] is no longer required. IANA is requested to remove this | [RFC7752] is no longer required. IANA is requested to mark this | |||
registry. | registry as obsolete and to change its registration procedure to | |||
"registry closed". | ||||
7.1.4. BGP-LS Node Flags Registry | 7.1.4. BGP-LS Node Flags Registry | |||
The "BGP-LS Node Flags" registry is requested to be created for the | The "BGP-LS Node Flags" registry is requested to be created for the | |||
one octet-sized flags field of the Node Flag Bits TLV (1024) and | one octet-sized flags field of the Node Flag Bits TLV (1024) and | |||
populated with the initial values shown below: | populated with the initial values shown below: | |||
+=====+======================+=================+ | +=====+======================+=================+ | |||
| Bit | Description | Reference | | | Bit | Description | Reference | | |||
+=====+======================+=================+ | +=====+======================+=================+ | |||
skipping to change at page 52, line 26 ¶ | skipping to change at page 54, line 26 ¶ | |||
In all cases of review by the designated expert described here, the | In all cases of review by the designated expert described here, the | |||
designated expert is expected to check the clarity of purpose and use | designated expert is expected to check the clarity of purpose and use | |||
of the requested code points. The following points apply to the | of the requested code points. The following points apply to the | |||
registries discussed in this document: | registries discussed in this document: | |||
1. Application for a code point allocation may be made to the | 1. Application for a code point allocation may be made to the | |||
designated experts at any time and MUST be accompanied by | designated experts at any time and MUST be accompanied by | |||
technical documentation explaining the use of the code point. | technical documentation explaining the use of the code point. | |||
Such documentation SHOULD be presented in the form of an | Such documentation SHOULD be presented in the form of an | |||
Internet-Draft but MAY arrive in any form that can be reviewed | Internet-Draft, but MAY arrive in any form that can be reviewed | |||
and exchanged amongst reviewers. | and exchanged among reviewers. | |||
2. The designated experts SHOULD only consider requests that arise | 2. The designated experts SHOULD only consider requests that arise | |||
from Internet-Drafts that have already been accepted as working | from Internet-Drafts that have already been accepted as working | |||
group documents or that are planned for progression as AD- | group documents or that are planned for progression as AD- | |||
Sponsored documents in the absence of a suitably chartered | Sponsored documents in the absence of a suitably chartered | |||
working group. | working group. | |||
3. In the case of working group documents, the designated experts | 3. In the case of working group documents, the designated experts | |||
MUST check with the working group chairs that there is a | MUST check with the working group chairs that there is a | |||
consensus within the working group to allocate at this time. In | consensus within the working group to allocate at this time. In | |||
skipping to change at page 54, line 5 ¶ | skipping to change at page 56, line 5 ¶ | |||
information has a different impact than regular BGP updates, which | information has a different impact than regular BGP updates, which | |||
need to change the forwarding state for an entire router. | need to change the forwarding state for an entire router. | |||
Distribution of the BGP-LS NLRIs SHOULD be handled by dedicated route | Distribution of the BGP-LS NLRIs SHOULD be handled by dedicated route | |||
reflectors in most deployments providing a level of isolation and | reflectors in most deployments providing a level of isolation and | |||
fault containment between different BGP address families. In the | fault containment between different BGP address families. In the | |||
event of dedicated route reflectors not being available, other | event of dedicated route reflectors not being available, other | |||
alternate mechanisms like separation of BGP instances or separate BGP | alternate mechanisms like separation of BGP instances or separate BGP | |||
sessions (e.g. using different addresses for peering) for Link-State | sessions (e.g. using different addresses for peering) for Link-State | |||
information distribution SHOULD be used. | information distribution SHOULD be used. | |||
It is RECOMMENDED that operators deploying BGP-LS enable at least two | It is RECOMMENDED that operators deploying BGP-LS enable two or more | |||
or more BGP-LS Producers in each IGP flooding domain to achieve | BGP-LS Producers in each IGP flooding domain to achieve redundancy in | |||
redundancy in the origination of link-state information into BGP-LS. | the origination of link-state information into BGP-LS. It is also | |||
It is also RECOMMENDED that operators ensure BGP peering designs that | RECOMMENDED that operators ensure BGP peering designs that ensure | |||
ensure redundancy in the BGP update propagation paths (e.g., using at | redundancy in the BGP update propagation paths (e.g., using at least | |||
least a pair of route reflectors) and ensuring that BGP-LS Consumers | a pair of route reflectors) and ensuring that BGP-LS Consumers are | |||
are receiving the topology information from at least two BGP-LS | receiving the topology information from at least two BGP-LS Speakers. | |||
Speakers. | ||||
In a multi-domain IGP network, the correct provisioning of the BGP-LS | In a multi-domain IGP network, the correct provisioning of the BGP-LS | |||
Instance-IDs on the BGP-LS Producers is required for consistent | Instance-IDs on the BGP-LS Producers is required for consistent | |||
reporting of the multi-domain link-state topology. Refer to | reporting of the multi-domain link-state topology. Refer to | |||
Section 5.2 for more details. | Section 5.2 for more details. | |||
8.1.2. Installation and Initial Setup | 8.1.2. Installation and Initial Setup | |||
Configuration parameters defined in Section 8.2.3 SHOULD be | Configuration parameters defined in Section 8.2.3 SHOULD be | |||
initialized to the following default values: | initialized to the following default values: | |||
skipping to change at page 56, line 14 ¶ | skipping to change at page 58, line 14 ¶ | |||
* The rule regarding the ordering of TLVs been followed as described | * The rule regarding the ordering of TLVs been followed as described | |||
in Section 5.1. | in Section 5.1. | |||
* For NLRIs carrying either a Local or Remote Node Descriptor TLV, | * For NLRIs carrying either a Local or Remote Node Descriptor TLV, | |||
there is not more than one instance of a sub-TLV present. | there is not more than one instance of a sub-TLV present. | |||
When the error that is determined allows for the router to skip the | When the error that is determined allows for the router to skip the | |||
malformed NLRI(s) and continue the processing of the rest of the BGP | malformed NLRI(s) and continue the processing of the rest of the BGP | |||
UPDATE message (e.g. when the TLV ordering rule is violated), then it | UPDATE message (e.g. when the TLV ordering rule is violated), then it | |||
MUST handle such malformed NLRIs as 'Treat-as-withdraw'. In other | MUST handle such malformed NLRIs as 'NLRI discard' (i.e., processing | |||
similar to what is described in section 5.4 of [RFC7606]). In other | ||||
cases, where the error in the NLRI encoding results in the inability | cases, where the error in the NLRI encoding results in the inability | |||
to process the BGP UPDATE message (e.g. length related encoding | to process the BGP UPDATE message (e.g. length related encoding | |||
errors), then the router SHOULD handle such malformed NLRIs as 'AFI/ | errors), then the router SHOULD handle such malformed NLRIs as 'AFI/ | |||
SAFI disable' when other AFI/SAFI besides BGP-LS are being advertised | SAFI disable' when other AFI/SAFI besides BGP-LS are being advertised | |||
over the same session. Alternately, the router MUST perform a | over the same session. Alternately, the router MUST perform a | |||
'session reset' when the session is only being used for BGP-LS or if | 'session reset' when the session is only being used for BGP-LS or if | |||
'AFI/SAFI disable' action is not possible. | 'AFI/SAFI disable' action is not possible. | |||
A BGP-LS Attribute MUST NOT be considered malformed or invalid based | A BGP-LS Attribute MUST NOT be considered malformed or invalid based | |||
on the inclusion/exclusion of TLVs or contents of the TLV fields | on the inclusion/exclusion of TLVs or contents of the TLV fields | |||
skipping to change at page 58, line 17 ¶ | skipping to change at page 60, line 17 ¶ | |||
neighbors. | neighbors. | |||
An implementation SHOULD allow the operator to specify the maximum | An implementation SHOULD allow the operator to specify the maximum | |||
number of Link-State NLRIs stored in a router's Routing Information | number of Link-State NLRIs stored in a router's Routing Information | |||
Base (RIB). | Base (RIB). | |||
An implementation SHOULD allow the operator to create abstracted | An implementation SHOULD allow the operator to create abstracted | |||
topologies that are advertised to neighbors and create different | topologies that are advertised to neighbors and create different | |||
abstractions for different neighbors. | abstractions for different neighbors. | |||
An implementation MUST allow the operator to configure a 8-octet BGP- | An implementation MUST allow the operator to configure an 8-octet | |||
LS Instance-ID. Refer to Section 5.2 for guidance to the operator | BGP-LS Instance-ID. Refer to Section 5.2 for guidance to the | |||
for the configuration of BGP-LS Instance-ID. | operator for the configuration of BGP-LS Instance-ID. | |||
An implementation SHOULD allow the operator to configure ASN and BGP- | An implementation SHOULD allow the operator to configure ASN and BGP- | |||
LS identifiers (refer to Section 5.2.1.4). | LS identifiers (refer to Section 5.2.1.4). | |||
An implementation SHOULD allow the operator to configure limiting of | An implementation SHOULD allow the operator to configure limiting of | |||
maximum size of a BGP-LS UPDATE message to 4096 bytes on a BGP-LS | maximum size of a BGP-LS UPDATE message to 4096 bytes on a BGP-LS | |||
Producer or to allow larger values when they know that [RFC8654] is | Producer or to allow larger values when they know that [RFC8654] is | |||
supported on all BGP-LS Speakers. | supported on all BGP-LS Speakers. | |||
8.2.4. Accounting Management | 8.2.4. Accounting Management | |||
skipping to change at page 61, line 47 ¶ | skipping to change at page 63, line 47 ¶ | |||
reflects on the consumer applications instead of BGP routing | reflects on the consumer applications instead of BGP routing | |||
functionalities. | functionalities. | |||
Additionally, it may be considered that the export of link-state and | Additionally, it may be considered that the export of link-state and | |||
TE information as described in this document constitutes a risk to | TE information as described in this document constitutes a risk to | |||
confidentiality of mission-critical or commercially sensitive | confidentiality of mission-critical or commercially sensitive | |||
information about the network. BGP peerings are not automatic and | information about the network. BGP peerings are not automatic and | |||
require configuration; thus, it is the responsibility of the network | require configuration; thus, it is the responsibility of the network | |||
operator to ensure that only trusted BGP Speakers are configured to | operator to ensure that only trusted BGP Speakers are configured to | |||
receive such information. Similar security considerations also arise | receive such information. Similar security considerations also arise | |||
on the interface between BGP Speaker and BGP-LS Consumers but their | on the interface between BGP Speaker and BGP-LS Consumers, but their | |||
discussion is outside the scope of this document. | discussion is outside the scope of this document. | |||
11. Contributors | 11. Contributors | |||
The following persons contributed significant text to RFC7752 and | The following persons contributed significant text to RFC7752 and | |||
this document. They should be considered co-authors. | this document. They should be considered co-authors. | |||
Hannes Gredler | Hannes Gredler | |||
Rtbrick | Rtbrick | |||
Email: hannes@rtbrick.com | Email: hannes@rtbrick.com | |||
skipping to change at page 63, line 20 ¶ | skipping to change at page 65, line 20 ¶ | |||
Ginsberg, Liem Nguyen, Manish Bhardwaj, Matt Miller, Mike Shand, | Ginsberg, Liem Nguyen, Manish Bhardwaj, Matt Miller, Mike Shand, | |||
Peter Psenak, Rex Fernando, Richard Woundy, Steven Luong, Tamas | Peter Psenak, Rex Fernando, Richard Woundy, Steven Luong, Tamas | |||
Mondal, Waqas Alam, Vipin Kumar, Naiming Shen, Carlos Pignataro, | Mondal, Waqas Alam, Vipin Kumar, Naiming Shen, Carlos Pignataro, | |||
Balaji Rajagopalan, Yakov Rekhter, Alvaro Retana, Barry Leiba, and | Balaji Rajagopalan, Yakov Rekhter, Alvaro Retana, Barry Leiba, and | |||
Ben Campbell for their comments on RFC7752. | Ben Campbell for their comments on RFC7752. | |||
13. References | 13. References | |||
13.1. Normative References | 13.1. Normative References | |||
[ENTNUM] IANA, "Private Enterprise Numbers", | ||||
<https://www.iana.org/assignments/enterprise-numbers/>. | ||||
[ISO10589] International Organization for Standardization, | [ISO10589] International Organization for Standardization, | |||
"Intermediate System to Intermediate System intra-domain | "Intermediate System to Intermediate System intra-domain | |||
routeing information exchange protocol for use in | routeing information exchange protocol for use in | |||
conjunction with the protocol for providing the | conjunction with the protocol for providing the | |||
connectionless-mode network service (ISO 8473)", ISO/ | connectionless-mode network service (ISO 8473)", ISO/ | |||
IEC 10589, November 2002. | IEC 10589, November 2002. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
skipping to change at page 64, line 25 ¶ | skipping to change at page 66, line 25 ¶ | |||
[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the | [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the | |||
Provider/Customer Edge Protocol for BGP/MPLS IP Virtual | Provider/Customer Edge Protocol for BGP/MPLS IP Virtual | |||
Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, | Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, | |||
June 2006, <https://www.rfc-editor.org/info/rfc4577>. | June 2006, <https://www.rfc-editor.org/info/rfc4577>. | |||
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, | [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, | |||
"Multiprotocol Extensions for BGP-4", RFC 4760, | "Multiprotocol Extensions for BGP-4", RFC 4760, | |||
DOI 10.17487/RFC4760, January 2007, | DOI 10.17487/RFC4760, January 2007, | |||
<https://www.rfc-editor.org/info/rfc4760>. | <https://www.rfc-editor.org/info/rfc4760>. | |||
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., Pillay- | [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. | |||
Esnault, P., and RFC Publisher, "Multi-Topology (MT) | Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", | |||
Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June | RFC 4915, DOI 10.17487/RFC4915, June 2007, | |||
2007, <https://www.rfc-editor.org/info/rfc4915>. | <https://www.rfc-editor.org/info/rfc4915>. | |||
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., | [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., | |||
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036, | "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, | |||
October 2007, <https://www.rfc-editor.org/info/rfc5036>. | October 2007, <https://www.rfc-editor.org/info/rfc5036>. | |||
[RFC5120] Przygienda, T., Shen, N., Sheth, N., and RFC Publisher, | [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi | |||
"M-ISIS: Multi Topology (MT) Routing in Intermediate | Topology (MT) Routing in Intermediate System to | |||
System to Intermediate Systems (IS-ISs)", RFC 5120, | Intermediate Systems (IS-ISs)", RFC 5120, | |||
DOI 10.17487/RFC5120, February 2008, | DOI 10.17487/RFC5120, February 2008, | |||
<https://www.rfc-editor.org/info/rfc5120>. | <https://www.rfc-editor.org/info/rfc5120>. | |||
[RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy | [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy | |||
Control Mechanism in IS-IS Using Administrative Tags", | Control Mechanism in IS-IS Using Administrative Tags", | |||
RFC 5130, DOI 10.17487/RFC5130, February 2008, | RFC 5130, DOI 10.17487/RFC5130, February 2008, | |||
<https://www.rfc-editor.org/info/rfc5130>. | <https://www.rfc-editor.org/info/rfc5130>. | |||
[RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange | [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange | |||
Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, | Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, | |||
skipping to change at page 66, line 25 ¶ | skipping to change at page 68, line 25 ¶ | |||
Support for BGP", RFC 8654, DOI 10.17487/RFC8654, October | Support for BGP", RFC 8654, DOI 10.17487/RFC8654, October | |||
2019, <https://www.rfc-editor.org/info/rfc8654>. | 2019, <https://www.rfc-editor.org/info/rfc8654>. | |||
13.2. Informative References | 13.2. Informative References | |||
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. | [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. | |||
J., and E. Lear, "Address Allocation for Private | J., and E. Lear, "Address Allocation for Private | |||
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, | Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, | |||
February 1996, <https://www.rfc-editor.org/info/rfc1918>. | February 1996, <https://www.rfc-editor.org/info/rfc1918>. | |||
[RFC4272] Murphy, S. and RFC Publisher, "BGP Security | [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", | |||
Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, | RFC 4272, DOI 10.17487/RFC4272, January 2006, | |||
January 2006, <https://www.rfc-editor.org/info/rfc4272>. | <https://www.rfc-editor.org/info/rfc4272>. | |||
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private | [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private | |||
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February | Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February | |||
2006, <https://www.rfc-editor.org/info/rfc4364>. | 2006, <https://www.rfc-editor.org/info/rfc4364>. | |||
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path | [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path | |||
Computation Element (PCE)-Based Architecture", RFC 4655, | Computation Element (PCE)-Based Architecture", RFC 4655, | |||
DOI 10.17487/RFC4655, August 2006, | DOI 10.17487/RFC4655, August 2006, | |||
<https://www.rfc-editor.org/info/rfc4655>. | <https://www.rfc-editor.org/info/rfc4655>. | |||
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A | [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A | |||
Per-Domain Path Computation Method for Establishing Inter- | Per-Domain Path Computation Method for Establishing Inter- | |||
Domain Traffic Engineering (TE) Label Switched Paths | Domain Traffic Engineering (TE) Label Switched Paths | |||
(LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, | (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, | |||
<https://www.rfc-editor.org/info/rfc5152>. | <https://www.rfc-editor.org/info/rfc5152>. | |||
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in | ||||
Support of Inter-Autonomous System (AS) MPLS and GMPLS | ||||
Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, | ||||
December 2008, <https://www.rfc-editor.org/info/rfc5316>. | ||||
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in | [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in | |||
Support of Inter-Autonomous System (AS) MPLS and GMPLS | Support of Inter-Autonomous System (AS) MPLS and GMPLS | |||
Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, | Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, | |||
January 2009, <https://www.rfc-editor.org/info/rfc5392>. | January 2009, <https://www.rfc-editor.org/info/rfc5392>. | |||
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic | [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic | |||
Optimization (ALTO) Problem Statement", RFC 5693, | Optimization (ALTO) Problem Statement", RFC 5693, | |||
DOI 10.17487/RFC5693, October 2009, | DOI 10.17487/RFC5693, October 2009, | |||
<https://www.rfc-editor.org/info/rfc5693>. | <https://www.rfc-editor.org/info/rfc5693>. | |||
[RFC5706] Harrington, D. and RFC Publisher, "Guidelines for | [RFC5706] Harrington, D., "Guidelines for Considering Operations and | |||
Considering Operations and Management of New Protocols and | Management of New Protocols and Protocol Extensions", | |||
Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, | RFC 5706, DOI 10.17487/RFC5706, November 2009, | |||
November 2009, <https://www.rfc-editor.org/info/rfc5706>. | <https://www.rfc-editor.org/info/rfc5706>. | |||
[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- | [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- | |||
Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, | Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, | |||
March 2012, <https://www.rfc-editor.org/info/rfc6549>. | March 2012, <https://www.rfc-editor.org/info/rfc6549>. | |||
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of | [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of | |||
BGP, LDP, PCEP, and MSDP Issues According to the Keying | BGP, LDP, PCEP, and MSDP Issues According to the Keying | |||
and Authentication for Routing Protocols (KARP) Design | and Authentication for Routing Protocols (KARP) Design | |||
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, | Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, | |||
<https://www.rfc-editor.org/info/rfc6952>. | <https://www.rfc-editor.org/info/rfc6952>. | |||
skipping to change at page 68, line 5 ¶ | skipping to change at page 69, line 46 ¶ | |||
[RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS | [RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS | |||
Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June | Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June | |||
2017, <https://www.rfc-editor.org/info/rfc8202>. | 2017, <https://www.rfc-editor.org/info/rfc8202>. | |||
[RFC9029] Farrel, A., "Updates to the Allocation Policy for the | [RFC9029] Farrel, A., "Updates to the Allocation Policy for the | |||
Border Gateway Protocol - Link State (BGP-LS) Parameters | Border Gateway Protocol - Link State (BGP-LS) Parameters | |||
Registries", RFC 9029, DOI 10.17487/RFC9029, June 2021, | Registries", RFC 9029, DOI 10.17487/RFC9029, June 2021, | |||
<https://www.rfc-editor.org/info/rfc9029>. | <https://www.rfc-editor.org/info/rfc9029>. | |||
[RFC9346] Chen, M., Ginsberg, L., Previdi, S., and D. Xiaodong, "IS- | ||||
IS Extensions in Support of Inter-Autonomous System (AS) | ||||
MPLS and GMPLS Traffic Engineering", RFC 9346, | ||||
DOI 10.17487/RFC9346, February 2023, | ||||
<https://www.rfc-editor.org/info/rfc9346>. | ||||
Appendix A. Changes from RFC 7752 | Appendix A. Changes from RFC 7752 | |||
This section lists the high-level changes from RFC 7752 and provides | This section lists the high-level changes from RFC 7752 and provides | |||
reference to the document sections wherein those have been | reference to the document sections wherein those have been | |||
introduced. | introduced. | |||
1. Updated the Figure 1 in Section 1 and added Section 3 to | 1. Updated the Figure 1 in Section 1 and added Section 3 to | |||
illustrate the different roles of a BGP implementation in | illustrate the different roles of a BGP implementation in | |||
conveying link-state information. | conveying link-state information. | |||
skipping to change at page 68, line 42 ¶ | skipping to change at page 70, line 42 ¶ | |||
information is explained in Section 5.3 along with mitigation of | information is explained in Section 5.3 along with mitigation of | |||
errors arising out of it. | errors arising out of it. | |||
6. Clarified that the document describes the NLRI descriptor TLVs | 6. Clarified that the document describes the NLRI descriptor TLVs | |||
for the protocols and NLRI types specified in this document and | for the protocols and NLRI types specified in this document and | |||
future BGP-LS extensions must describe the same for other | future BGP-LS extensions must describe the same for other | |||
protocols and NLRI types that they introduce. | protocols and NLRI types that they introduce. | |||
7. Clarification on the use of the Identifier field in the Link- | 7. Clarification on the use of the Identifier field in the Link- | |||
State NLRI in Section 5.2 is provided. It was defined | State NLRI in Section 5.2 is provided. It was defined | |||
ambiguously to refer to only mutli-instance IGP on a single link | ambiguously to refer to only multi-instance IGP on a single link | |||
while it can also be used for multiple IGP protocol instances on | while it can also be used for multiple IGP protocol instances on | |||
a router. The IANA registry is accordingly being removed. | a router. The IANA registry is accordingly being removed. | |||
8. The BGP-LS Identifier TLV in the Node Descriptors has been | 8. The BGP-LS Identifier TLV in the Node Descriptors has been | |||
deprecated. Its use was not well specified by [RFC7752] and | deprecated. Its use was not well specified by [RFC7752] and | |||
there has been some amount of confusion between implementators | there has been some amount of confusion between implementators | |||
on its usage for identification of IGP domains as against the | on its usage for identification of IGP domains as against the | |||
use of the Identifier field carrying the BGP-LS Instance-ID when | use of the Identifier field carrying the BGP-LS Instance-ID when | |||
running multiple instances of IGP routing protocols. | running multiple instances of IGP routing protocols. The | |||
original purpose of the BGP-LS Identifier was that, in | ||||
conjunction with Autonomous System Number (ASN), it would | ||||
uniquely identify the BGP-LS domain and that the combination of | ||||
ASN and BGP-LS ID would be globally unique. However, the BGP-LS | ||||
Instance-ID carried in the Identifier field in the fixed part of | ||||
the NLRI also provides a similar functionality. Hence, the | ||||
inclusion of the BGP-LS Identifier TLV is not necessary. If | ||||
advertised, all BGP-LS speakers within an IGP flooding-set (set | ||||
of IGP nodes within which an LSP/LSA is flooded) had to use the | ||||
same (ASN, BGP-LS ID) tuple and if an IGP domain consists of | ||||
multiple flooding-sets, then all BGP-LS speakers within the IGP | ||||
domain had to use the same (ASN, BGP-LS ID) tuple. | ||||
9. Clarification that the Area-ID TLV is mandatory in the Node | 9. Clarification that the Area-ID TLV is mandatory in the Node | |||
Descriptor for the origination of information from OSPF except | Descriptor for the origination of information from OSPF except | |||
for when sourcing information from AS-scope LSAs where this TLV | for when sourcing information from AS-scope LSAs where this TLV | |||
is not applicable. Also clarified on the IS-IS area and area | is not applicable. Also clarified on the IS-IS area and area | |||
addresses. | addresses. | |||
10. Moved MT-ID TLV from the Node Descriptor section to under the | 10. Moved MT-ID TLV from the Node Descriptor section to under the | |||
Link Descriptor section since it is not a Node Descriptor sub- | Link Descriptor section since it is not a Node Descriptor sub- | |||
TLV. Fixed the ambiguity in the encoding of OSPF MT-ID in this | TLV. Fixed the ambiguity in the encoding of OSPF MT-ID in this | |||
End of changes. 76 change blocks. | ||||
259 lines changed or deleted | 297 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |