draft-ietf-idr-rfc7752bis-00.txt   draft-ietf-idr-rfc7752bis-01.txt 
Inter-Domain Routing K. Talaulikar, Ed. Inter-Domain Routing K. Talaulikar, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track H. Gredler Obsoletes: 7752 (if approved) September 14, 2019
Expires: March 8, 2020 Rtbrick Intended status: Standards Track
J. Medved Expires: March 17, 2020
Cisco Systems, Inc.
S. Previdi
Huawei Technologies
A. Farrel
Old Dog Consulting
S. Ray
Individual Contributor
September 5, 2019
Distribution of Link-State and Traffic Engineering Information Using BGP Distribution of Link-State and Traffic Engineering Information Using BGP
draft-ietf-idr-rfc7752bis-00 draft-ietf-idr-rfc7752bis-01
Abstract Abstract
In a number of environments, a component external to a network is In a number of environments, a component external to a network is
called upon to perform computations based on the network topology and called upon to perform computations based on the network topology and
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 new BGP Network Layer Reachability Information (NLRI) encoding
format. The mechanism is applicable to physical and virtual IGP format. The mechanism is applicable to physical and virtual 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).
Requirements Language This document obsoletes RFC 7752 by completely replacing that
document. It makes a number of small changes and clarifications to
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", the previous specification.
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 8, 2020. This Internet-Draft will expire on March 17, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Motivation and Applicability . . . . . . . . . . . . . . . . 5 2. Motivation and Applicability . . . . . . . . . . . . . . . . 5
2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . 5 2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . 7
4. Carrying Link-State Information in BGP . . . . . . . . . . . 9 4. Carrying Link-State Information in BGP . . . . . . . . . . . 9
4.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 10 4.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 10
4.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 15 4.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 14
4.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . 19 4.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . 18
4.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . 21 4.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . 21
4.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . 23 4.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . 22
4.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 24 4.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 23
4.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 27 4.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 26
4.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 32 4.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 31
4.4. Private Use . . . . . . . . . . . . . . . . . . . . . . . 35 4.4. Private Use . . . . . . . . . . . . . . . . . . . . . . . 34
4.5. BGP Next-Hop Information . . . . . . . . . . . . . . . . 36 4.5. BGP Next-Hop Information . . . . . . . . . . . . . . . . 35
4.6. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 36 4.6. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 35
4.7. Handling of Unreachable IGP Nodes . . . . . . . . . . . . 36 4.7. Handling of Unreachable IGP Nodes . . . . . . . . . . . . 36
4.8. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 38 4.8. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 37
4.9. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 39 4.9. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 38
4.10. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 40 4.10. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 39
5. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 40 5. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 40
5.1. Example: No Link Aggregation . . . . . . . . . . . . . . 41 5.1. Example: No Link Aggregation . . . . . . . . . . . . . . 40
5.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 41 5.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 40
5.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 42 5.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 41
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
6.1. Guidance for Designated Experts . . . . . . . . . . . . . 43 6.1. Guidance for Designated Experts . . . . . . . . . . . . . 42
7. Manageability Considerations . . . . . . . . . . . . . . . . 44 7. Manageability Considerations . . . . . . . . . . . . . . . . 43
7.1. Operational Considerations . . . . . . . . . . . . . . . 44 7.1. Operational Considerations . . . . . . . . . . . . . . . 43
7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 44 7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 43
7.1.2. Installation and Initial Setup . . . . . . . . . . . 44 7.1.2. Installation and Initial Setup . . . . . . . . . . . 43
7.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 44 7.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 43
7.1.4. Requirements on Other Protocols and Functional 7.1.4. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . 44 Components . . . . . . . . . . . . . . . . . . . . . 44
7.1.5. Impact on Network Operation . . . . . . . . . . . . . 45 7.1.5. Impact on Network Operation . . . . . . . . . . . . . 44
7.1.6. Verifying Correct Operation . . . . . . . . . . . . . 45 7.1.6. Verifying Correct Operation . . . . . . . . . . . . . 44
7.2. Management Considerations . . . . . . . . . . . . . . . . 45 7.2. Management Considerations . . . . . . . . . . . . . . . . 44
7.2.1. Management Information . . . . . . . . . . . . . . . 45 7.2.1. Management Information . . . . . . . . . . . . . . . 44
7.2.2. Fault Management . . . . . . . . . . . . . . . . . . 45 7.2.2. Fault Management . . . . . . . . . . . . . . . . . . 44
7.2.3. Configuration Management . . . . . . . . . . . . . . 48 7.2.3. Configuration Management . . . . . . . . . . . . . . 47
7.2.4. Accounting Management . . . . . . . . . . . . . . . . 48 7.2.4. Accounting Management . . . . . . . . . . . . . . . . 47
7.2.5. Performance Management . . . . . . . . . . . . . . . 48 7.2.5. Performance Management . . . . . . . . . . . . . . . 47
7.2.6. Security Management . . . . . . . . . . . . . . . . . 49 7.2.6. Security Management . . . . . . . . . . . . . . . . . 48
8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 49 8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 48
9. Security Considerations . . . . . . . . . . . . . . . . . . . 50 9. Security Considerations . . . . . . . . . . . . . . . . . . . 49
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
12.1. Normative References . . . . . . . . . . . . . . . . . . 52 12.1. Normative References . . . . . . . . . . . . . . . . . . 51
12.2. Informative References . . . . . . . . . . . . . . . . . 54 12.2. Informative References . . . . . . . . . . . . . . . . . 54
Appendix A. Changes from RFC 7752 . . . . . . . . . . . . . . . 56 Appendix A. Changes from RFC 7752 . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 58
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) in order to make better decisions. Autonomous System (AS) in order 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 5, line 41 skipping to change at page 5, line 9
it distributes. Thus, it may distribute the real physical topology it distributes. Thus, it may distribute the real physical topology
from the LSDB or the TED. Alternatively, it may create an abstracted from the LSDB or the TED. Alternatively, it may create an abstracted
topology, where virtual, aggregated nodes are connected by virtual topology, where virtual, aggregated nodes are connected by virtual
paths. Aggregated nodes can be created, for example, out of multiple paths. Aggregated nodes can be created, for example, out of multiple
routers in a Point of Presence (POP). Abstracted topology can also routers in a Point of Presence (POP). Abstracted topology can also
be a mix of physical and virtual nodes and physical and virtual be a mix of physical and virtual nodes and physical and virtual
links. Furthermore, the BGP speaker can apply policy to determine links. Furthermore, the BGP speaker can apply policy to determine
when information is updated to the consumer so that there is a when information is updated to the consumer so that there is a
reduction of information flow from the network to the consumers. reduction of information flow from the network to the consumers.
Mechanisms through which topologies can be aggregated or virtualized Mechanisms through which topologies can be aggregated or virtualized
are outside the scope of this document are outside the scope of this document.
This document obsoletes [RFC7752] by completely replacing that
document. It makes a number of small changes and clarifications to
the previous specification as documented in Appendix A.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Motivation and Applicability 2. Motivation and Applicability
This section describes use cases from which the requirements can be This section describes use cases from which the requirements can be
derived. derived.
2.1. MPLS-TE with PCE 2.1. MPLS-TE with PCE
As described in [RFC4655], a PCE can be used to compute MPLS-TE paths As described in [RFC4655], a PCE can be used to compute MPLS-TE paths
within a "domain" (such as an IGP area) or across multiple domains within a "domain" (such as an IGP area) or across multiple domains
skipping to change at page 10, line 39 skipping to change at page 10, line 15
comparison rules apply. NLRIs having TLVs which do not follow the comparison rules apply. NLRIs having TLVs which do not follow the
above ordering rules MUST be considered as malformed by a BGP-LS above ordering rules MUST be considered as malformed by a BGP-LS
Propagator. This ensures that multiple copies of the same NLRI from Propagator. This ensures that multiple copies of the same NLRI from
multiple BGP-LS Producers and the ambiguity arising there from is multiple BGP-LS Producers and the ambiguity arising there from is
prevented. prevented.
All TLVs within the NLRI that are not specified as mandatory are All TLVs within the NLRI that are not specified as mandatory are
considered optional. All TLVs within the BGP-LS Attribute are considered optional. All TLVs within the BGP-LS Attribute are
considered optional unless specified otherwise. considered optional unless specified otherwise.
The TLVs within the BGP-LS Attribute need not be ordered in any The TLVs within the BGP-LS Attribute MAY be ordered in ascending
specific order. order by TLV type. BGP-LS Attribute with unordered TLVs MUST NOT be
consider malformed.
4.2. The Link-State NLRI 4.2. The Link-State NLRI
The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's containers The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's containers
for carrying opaque information. This specification defines three for carrying opaque information. This specification defines three
Link-State NLRI types that describes either a node, a link, and a Link-State NLRI types that describes either a node, a link, and 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
skipping to change at page 15, line 31 skipping to change at page 14, line 31
followed, a BGP-LS Consumer may see duplicate link-state objects for followed, a BGP-LS Consumer may see duplicate link-state objects for
the same node, link or prefix when there are multiple BGP-LS the same node, link or prefix when there are multiple BGP-LS
Producers deployed. This may also result in the BGP-LS Consumers Producers deployed. This may also result in the BGP-LS Consumers
getting an inaccurate network-wide topology. getting an inaccurate network-wide topology.
When adding, removing or modifying a TLV/sub-TLV from a Link-State When adding, removing or modifying a TLV/sub-TLV from a Link-State
NLRI, the BGP-LS Producer MUST withdraw the old NLRI by including it NLRI, the BGP-LS Producer MUST withdraw the old NLRI by including it
in the MP_UNREACH_NLRI. Not doing so can result in duplicate and in- in the MP_UNREACH_NLRI. Not doing so can result in duplicate and in-
consistent link-state objects hanging around in the BGP-LS table. consistent link-state objects hanging around in the BGP-LS table.
Each Node Descriptor and Link Descriptor consists of one or more Each Node Descriptor, Link Descriptor and Prefix Descriptor consists
TLVs, as described in the following sections. of one or more TLVs, as described in the following sections. These
Descriptor TLVs are applicable for the Node, Link and Prefix NLRI
Types for the protocols listed in Table 2. Documents extending BGP-
LS specifications with new NLRI Types and/or protocols MUST specify
the NLRI Descriptors for them.
4.2.1. Node Descriptors 4.2.1. Node Descriptors
Each link is anchored by a pair of Router-IDs that are used by the Each link is anchored by a pair of Router-IDs that are used by the
underlying IGP, namely, a 48-bit ISO System-ID for IS-IS and a 32-bit underlying IGP, namely, a 48-bit ISO System-ID for IS-IS and a 32-bit
Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more
additional auxiliary Router-IDs, mainly for Traffic Engineering additional auxiliary Router-IDs, mainly for Traffic Engineering
purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE
Router-IDs [RFC5305] [RFC6119]. These auxiliary Router-IDs MUST be Router-IDs [RFC5305] [RFC6119]. These auxiliary Router-IDs MUST be
included in the node attribute described in Section 4.3.1 and MAY be included in the node attribute described in Section 4.3.1 and MAY be
skipping to change at page 18, line 22 skipping to change at page 17, line 22
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. In conjunction with Autonomous System Number (ASN), uniquely TLV. In conjunction with Autonomous System Number (ASN), uniquely
identifies the BGP-LS domain. The combination of ASN and BGP-LS identifies the BGP-LS domain. The combination of ASN and BGP-LS
ID MUST be globally unique. All BGP-LS speakers within an IGP ID MUST be globally unique. All BGP-LS speakers within an IGP
flooding-set (set of IGP nodes within which an LSP/LSA is flooded) flooding-set (set of IGP nodes within which an LSP/LSA is flooded)
MUST use the same ASN, BGP-LS ID tuple. If an IGP domain consists MUST use the same ASN, BGP-LS ID tuple. If an IGP domain consists
of multiple flooding-sets, then all BGP-LS speakers within the IGP of multiple flooding-sets, then all BGP-LS speakers within the IGP
domain SHOULD use the same ASN, BGP-LS ID tuple. domain SHOULD use the same ASN, BGP-LS ID tuple.
Area-ID: Used to identify the 32-bit area to which the NLRI belongs. Area-ID: Used to identify the 32-bit area to which the information
This is a mandatory TLV when originating information from OSPF. advertised in the NLRI belongs. This is a mandatory TLV when
The Area Identifier allows different NLRIs of the same router to originating information from OSPF that is derived from area-scope
be discriminated. LSAs. The Area Identifier allows different NLRIs of the same
router to be discriminated on a per area basis. It is not used
for NLRIs when carrying information that is derived from AS-scope
LSAs as it is not associated with a specific area.
IGP Router-ID: Opaque value. This is a mandatory TLV when IGP Router-ID: Opaque value. This is a mandatory TLV when
originating information from IS-IS, OSPF, direct or static. For originating information from IS-IS, OSPF, direct or static. For
an IS-IS non-pseudonode, this contains a 6-octet ISO Node-ID (ISO an IS-IS non-pseudonode, this contains a 6-octet ISO Node-ID (ISO
system-ID). For an IS-IS pseudonode corresponding to a LAN, this system-ID). For an IS-IS pseudonode corresponding to a LAN, this
contains the 6-octet ISO Node-ID of the Designated Intermediate contains the 6-octet ISO Node-ID of the Designated Intermediate
System (DIS) followed by a 1-octet, nonzero PSN identifier (7 System (DIS) followed by a 1-octet, nonzero PSN identifier (7
octets in total). For an OSPFv2 or OSPFv3 non-pseudonode, this octets in total). For an OSPFv2 or OSPFv3 non-pseudonode, this
contains the 4-octet Router-ID. For an OSPFv2 pseudonode contains the 4-octet Router-ID. For an OSPFv2 pseudonode
representing a LAN, this contains the 4-octet Router-ID of the representing a LAN, this contains the 4-octet Router-ID of the
skipping to change at page 20, line 11 skipping to change at page 19, line 14
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:
+-----------+---------------------+--------------+------------------+ +-----------+---------------------+--------------+------------------+
| TLV Code | Description | IS-IS TLV | Reference | | TLV Code | Description | IS-IS TLV | Reference |
| Point | | /Sub-TLV | (RFC/Section) | | Point | | /Sub-TLV | (RFC/Section) |
+-----------+---------------------+--------------+------------------+ +-----------+---------------------+--------------+------------------+
| 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | | 258 | Link Local/Remote | 22/4 | [RFC5307] / 1.1 |
| | Identifiers | | | | | Identifiers | | |
| 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 | | 259 | IPv4 interface | 22/6 | [RFC5305] / 3.2 |
| | address | | | | | address | | |
| 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | | 260 | IPv4 neighbor | 22/8 | [RFC5305] / 3.3 |
| | address | | | | | address | | |
| 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 | | 261 | IPv6 interface | 22/12 | [RFC6119] / 4.2 |
| | address | | | | | address | | |
| 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | | 262 | IPv6 neighbor | 22/13 | [RFC6119] / 4.3 |
| | address | | | | | address | | |
| 263 | Multi-Topology | --- | Section 4.2.2.1 | | 263 | Multi-Topology | --- | Section 4.2.2.1 |
| | Identifier | | | | | Identifier | | |
+-----------+---------------------+--------------+------------------+ +-----------+---------------------+--------------+------------------+
Table 4: Link Descriptor TLVs Table 4: Link Descriptor TLVs
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 IP address TLVs MUST be included and the Link present, then the IP address TLVs MUST be included and the Link
Local/Remote Identifiers TLV MUST NOT be included in the Link Local/Remote Identifiers TLV MUST NOT be included in the Link
Descriptor. The Link Local/Remote Identifiers TLV MAY be included Descriptor. The Link Local/Remote Identifiers TLV MAY be included
in the link attribute when available. in the link attribute when available. IPv6 link-local addresses
MUST NOT be carried in the IPv6 address TLVs as 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. Identifiers TLV MUST be included in the Link Descriptor. The Link
Local/Remote Identifiers MUST be included in the Link Descriptor
also in the case of links having only IPv6 link-local addressing
on them.
The Multi-Topology Identifier TLV MUST be included in Link The Multi-Topology Identifier TLV MUST be included in Link
Descriptor if the underlying IGP link object is associated with a Descriptor if the underlying IGP link object is associated with a
non-default topology. non-default topology.
4.2.2.1. Multi-Topology ID 4.2.2.1. Multi-Topology ID
The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF
Multi-Topology IDs for a link, node, or prefix. Multi-Topology IDs for a link, node, or prefix.
Semantics of the IS-IS MT-ID are defined in Section 7.2 of RFC 5120 Semantics of the IS-IS MT-ID are defined in Section 7.1 and 7.2 of
[RFC5120]. Semantics of the OSPF MT-ID are defined in Section 3.7 of RFC 5120 [RFC5120]. Semantics of the OSPF MT-ID are defined in
RFC 4915 [RFC4915]. Bits R are reserved and SHOULD be set to 0 when Section 3.7 of RFC 4915 [RFC4915]. If the value in the MT-ID TLV is
originated and ignored on receipt. If the value in the MT-ID TLV is
derived from OSPF, then the upper 5 bits of the MT-ID field MUST be derived from OSPF, then the upper 5 bits of the MT-ID field MUST be
set to 0. set to 0.
The format of the MT-ID TLV is shown in the following figure. The format of the MT-ID TLV is shown in the following figure.
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=2*n | | Type | Length=2*n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 31 skipping to change at page 20, line 39
where Type is 263, Length is 2*n, and n is the number of MT-IDs where Type is 263, Length is 2*n, and n is the number of MT-IDs
carried in the TLV. carried in the TLV.
The MT-ID TLV MAY be present in a Link Descriptor, a Prefix The MT-ID TLV MAY be present in a Link Descriptor, a Prefix
Descriptor, or the BGP-LS attribute of a Node NLRI. In a Link or Descriptor, or the BGP-LS attribute of a Node NLRI. In a Link or
Prefix Descriptor, only a single MT-ID TLV containing the MT-ID of Prefix Descriptor, only a single MT-ID TLV containing the MT-ID of
the topology where the link or the prefix is reachable is allowed. the topology where the link or the prefix is reachable is allowed.
In case one wants to advertise multiple topologies for a given Link In case one wants to advertise multiple topologies for a given Link
Descriptor or Prefix Descriptor, multiple NLRIs MUST be generated Descriptor or Prefix Descriptor, multiple NLRIs MUST be generated
where each NLRI contains a single unique MT-ID. In the BGP-LS where each NLRI contains a single unique MT-ID. When used in the
attribute of a Node NLRI, one MT-ID TLV containing the array of MT- Link or Prefix Descriptor TLV for IS-IS, the Bits R are reserved and
IDs of all topologies where the node is reachable is allowed. MUST be set to 0 (as per Section 7.2 of RFC 5120 [RFC5120]) when
originated and ignored on receipt.
In the BGP-LS attribute of a Node NLRI, one MT-ID TLV containing the
array of MT-IDs of all topologies where the node is reachable is
allowed. When used in the Node Attribute TLV for IS-IS, the Bits R
are set as per Section 7.1 of RFC 5120 [RFC5120].
4.2.3. Prefix Descriptors 4.2.3. Prefix Descriptors
The Prefix Descriptor field is a set of Type/Length/Value (TLV) The Prefix Descriptor field is a set of Type/Length/Value (TLV)
triplets. Prefix Descriptor TLVs uniquely identify an IPv4 or IPv6 triplets. Prefix Descriptor TLVs uniquely identify an IPv4 or IPv6
prefix originated by a node. The following TLVs are defined as prefix originated by a node. The following TLVs are defined as
Prefix Descriptors in the IPv4/IPv6 Prefix NLRI: Prefix Descriptors in the IPv4/IPv6 Prefix NLRI:
+-------------+---------------------+----------+--------------------+ +-------------+---------------------+----------+--------------------+
| TLV Code | Description | Length | Reference | | TLV Code | Description | Length | Reference |
skipping to change at page 24, line 35 skipping to change at page 23, line 43
| Point | | | (RFC/Section) | | Point | | | (RFC/Section) |
+-------------+----------------------+----------+-------------------+ +-------------+----------------------+----------+-------------------+
| 263 | Multi-Topology | variable | Section 4.2.2.1 | | 263 | Multi-Topology | variable | Section 4.2.2.1 |
| | Identifier | | | | | Identifier | | |
| 1024 | Node Flag Bits | 1 | Section 4.3.1.1 | | 1024 | Node Flag Bits | 1 | Section 4.3.1.1 |
| 1025 | Opaque Node | variable | Section 4.3.1.5 | | 1025 | Opaque Node | variable | Section 4.3.1.5 |
| | Attribute | | | | | Attribute | | |
| 1026 | Node Name | variable | Section 4.3.1.3 | | 1026 | Node Name | variable | Section 4.3.1.3 |
| 1027 | IS-IS Area | variable | Section 4.3.1.2 | | 1027 | IS-IS Area | variable | Section 4.3.1.2 |
| | Identifier | | | | | Identifier | | |
| 1028 | IPv4 Router-ID of | 4 | [RFC5305]/4.3 | | 1028 | IPv4 Router-ID of | 4 | [RFC5305] / 4.3 |
| | Local Node | | | | | Local Node | | |
| 1029 | IPv6 Router-ID of | 16 | [RFC6119]/4.1 | | 1029 | IPv6 Router-ID of | 16 | [RFC6119] / 4.1 |
| | Local Node | | | | | Local Node | | |
+-------------+----------------------+----------+-------------------+ +-------------+----------------------+----------+-------------------+
Table 6: Node Attribute TLVs Table 6: Node Attribute TLVs
4.3.1.1. Node Flag Bits TLV 4.3.1.1. Node Flag Bits TLV
The Node Flag Bits TLV carries a bit mask describing node attributes. The Node Flag Bits TLV carries a bit mask describing node attributes.
The value is a variable-length bit array of flags, where each bit The value is a 1 octet length bit array of flags, where each bit
represents a node capability. represents a node operational state or attribute.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|T|E|B|R|V| Rsvd| |O|T|E|B|R|V| Rsvd|
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
Figure 15: Node Flag Bits TLV Format Figure 15: Node Flag Bits TLV Format
skipping to change at page 28, line 9 skipping to change at page 27, line 9
defined for IS-IS, the TLVs can carry data sourced by either IS-IS or defined for IS-IS, the TLVs can carry data sourced by either IS-IS or
OSPF. OSPF.
The following Link Attribute TLVs are defined for the BGP-LS The following Link Attribute TLVs are defined for the BGP-LS
Attribute associated with a Link NLRI: Attribute associated with a Link NLRI:
+-----------+---------------------+--------------+------------------+ +-----------+---------------------+--------------+------------------+
| TLV Code | Description | IS-IS TLV | Reference | | TLV Code | Description | IS-IS TLV | Reference |
| Point | | /Sub-TLV | (RFC/Section) | | Point | | /Sub-TLV | (RFC/Section) |
+-----------+---------------------+--------------+------------------+ +-----------+---------------------+--------------+------------------+
| 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305] / 4.3 |
| | Local Node | | | | | Local Node | | |
| 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119] / 4.1 |
| | Local Node | | | | | Local Node | | |
| 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305] / 4.3 |
| | Remote Node | | | | | Remote Node | | |
| 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119] / 4.1 |
| | Remote Node | | | | | Remote Node | | |
| 1088 | Administrative | 22/3 | [RFC5305]/3.1 | | 1088 | Administrative | 22/3 | [RFC5305] / 3.1 |
| | group (color) | | | | | group (color) | | |
| 1089 | Maximum link | 22/9 | [RFC5305]/3.4 | | 1089 | Maximum link | 22/9 | [RFC5305] / 3.4 |
| | bandwidth | | | | | bandwidth | | |
| 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 | | 1090 | Max. reservable | 22/10 | [RFC5305] / 3.5 |
| | link bandwidth | | | | | link bandwidth | | |
| 1091 | Unreserved | 22/11 | [RFC5305]/3.6 | | 1091 | Unreserved | 22/11 | [RFC5305] / 3.6 |
| | bandwidth | | | | | bandwidth | | |
| 1092 | TE Default Metric | 22/18 | Section 4.3.2.3 | | 1092 | TE Default Metric | 22/18 | Section 4.3.2.3 |
| 1093 | Link Protection | 22/20 | [RFC5307]/1.2 | | 1093 | Link Protection | 22/20 | [RFC5307] / 1.2 |
| | Type | | | | | Type | | |
| 1094 | MPLS Protocol Mask | --- | Section 4.3.2.2 | | 1094 | MPLS Protocol Mask | --- | Section 4.3.2.2 |
| 1095 | IGP Metric | --- | Section 4.3.2.4 | | 1095 | IGP Metric | --- | Section 4.3.2.4 |
| 1096 | Shared Risk Link | --- | Section 4.3.2.5 | | 1096 | Shared Risk Link | --- | Section 4.3.2.5 |
| | Group | | | | | Group | | |
| 1097 | Opaque Link | --- | Section 4.3.2.6 | | 1097 | Opaque Link | --- | Section 4.3.2.6 |
| | Attribute | | | | | Attribute | | |
| 1098 | Link Name | --- | Section 4.3.2.7 | | 1098 | Link Name | --- | Section 4.3.2.7 |
+-----------+---------------------+--------------+------------------+ +-----------+---------------------+--------------+------------------+
skipping to change at page 30, line 9 skipping to change at page 29, line 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Default Link Metric | | TE Default Link Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: TE Default Metric TLV Format Figure 20: TE Default Metric TLV Format
4.3.2.4. IGP Metric TLV 4.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 (the two most protocol. IS-IS small metrics have a length of 1 octet. Since the
significant bits are ignored). OSPF link metrics have a length of 2 ISIS small metrics are of 6 bit size, the two most significant bits
octets. IS-IS wide metrics have a length of 3 octets. MUST be set to 0 and MUST be ignored by receiver. OSPF link metrics
have a length of 2 octets. IS-IS wide 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 36, line 10 skipping to change at page 35, line 10
BGP-LS Attribute, the format as described in Section 4.1 is to be BGP-LS Attribute, the format as described in Section 4.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 4.2 to carry the Enterprise Code. NLRI format as described in Section 4.2 to carry the Enterprise Code.
The Enterprise Codes are listed at <http://www.iana.org/assignments/ The Enterprise Codes are listed at <http://www.iana.org/assignments/
enterprise-numbers>. This enables use vendor specific extensions enterprise-numbers>. This enables use vendor specific extensions
without conflicts. without conflicts.
Multiple instances of private-use TLVs MAY appear in the BGP-LS
Attribute.
4.5. BGP Next-Hop Information 4.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
used, then the next hop in the MP_REACH_NLRI SHOULD be an IPv6 used, then the next hop in the MP_REACH_NLRI SHOULD be an IPv6
address. Usually, the next hop will be set to the local endpoint address. Usually, the next hop will be set to the local endpoint
address of the BGP session. The next-hop address MUST be encoded as address of the BGP session. The next-hop address MUST be encoded as
described in [RFC4760]. The Length field of the next-hop address described in [RFC4760]. The Length field of the next-hop address
skipping to change at page 36, line 43 skipping to change at page 35, line 46
specification doesn't mandate any rule regarding the rewrite of the specification doesn't mandate any rule regarding the rewrite of the
BGP Next Hop attribute. BGP Next Hop attribute.
4.6. Inter-AS Links 4.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] [RFC5316]. 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 provision the inter-AS links is BGP-LS. The exact mechanism used to provision the inter-AS links is
outside the scope of this document outside the scope of this document and are described in
[I-D.ietf-idr-bgpls-inter-as-topology-ext].
4.7. Handling of Unreachable IGP Nodes 4.7. Handling of Unreachable IGP Nodes
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 true view of the topology of the
IGP domain. BGP-LS provides an abstraction of the protocol specifics IGP domain. BGP-LS provides an abstraction of the protocol specifics
and BGP-LS Consumers may be varied types of applications. and BGP-LS Consumers may be varied types of applications. While the
information propagated via BGP-LS from a link-state routing protocol
is sourced from that protocol's LSDB, it does not serve as a true
reflection of the originating router's LSDB since it does not include
the LSA/LSP sequence number information. The sequence numbers are
not included since a single NLRI update may be put together with
information that is coming from multiple LSAs/LSPs.
Consider an OSPF network as shown in Figure 31, where R2 and R3 are Consider an OSPF network as shown in Figure 31, where R2 and R3 are
the BGP-LS Producers and also the OSPF Area Border Routers (ABRs). the BGP-LS Producers and also the OSPF Area Border Routers (ABRs).
The link between R2 and R3 is in area 0 while the other links shown The link between R2 and R3 is in area 0 while the other links shown
are in area 1. are in area 1.
A BGP-LS Consumer talks to a BGP route-reflector (RR) R0 which is A BGP-LS Consumer talks to a BGP route-reflector (RR) R0 which is
aggregating the BGP-LS feed from the BGP-LS Producers R2 and R3. aggregating the BGP-LS feed from the BGP-LS Producers R2 and R3.
Here R2 and R3 provide a redundant topology feed via BGP-LS to R0. Here R2 and R3 provide a redundant topology feed via BGP-LS to R0.
Normally, R0 would receive two identical copies of all the Link-State Normally, R0 would receive two identical copies of all the Link-State
skipping to change at page 43, line 10 skipping to change at page 42, line 10
IANA has created a new "Border Gateway Protocol - Link State (BGP-LS) IANA has created a new "Border Gateway Protocol - Link State (BGP-LS)
Parameters" registry at <http://www.iana.org/assignments/bgp-ls- Parameters" registry at <http://www.iana.org/assignments/bgp-ls-
parameters>. All of the following registries are BGP-LS specific and parameters>. All of the following registries are BGP-LS specific and
are accessible under this registry: are accessible under this registry:
o "BGP-LS NLRI-Types" registry o "BGP-LS NLRI-Types" registry
Value 0 is reserved. The maximum value is 65535. The range Value 0 is reserved. The maximum value is 65535. The range
65000-65535 is for Private Use. The registry has been populated 65000-65535 is for Private Use. The registry has been populated
with the values shown in Table 1. Allocations within the registry with the values shown in Table 1. Allocations within the registry
require documentation of the proposed use of the allocated value under the "Expert Review" policy require documentation of the
(Specification Required) and approval by the Designated Expert proposed use of the allocated value and approval by the Designated
assigned by the IESG (see [RFC8126]). Expert assigned by the IESG (see [RFC8126]).
o "BGP-LS Protocol-IDs" registry o "BGP-LS Protocol-IDs" registry
Value 0 is reserved. The maximum value is 255. The range 200-255 Value 0 is reserved. The maximum value is 255. The range 200-255
is for Private Use. The registry has been populated with the is for Private Use. The registry has been populated with the
values shown in Table 2. Allocations within the registry require values shown in Table 2. Allocations within the registry under
documentation of the proposed use of the allocated value the "Expert Review" policy require documentation of the proposed
(Specification Required) and approval by the Designated Expert use of the allocated value and approval by the Designated Expert
assigned by the IESG (see [RFC8126]). assigned by the IESG (see [RFC8126]).
o "BGP-LS Well-Known Instance-IDs" registry o "BGP-LS Well-Known Instance-IDs" registry
This registry was setup via [RFC7752] and is no longer required. This registry was setup via [RFC7752] and is no longer required.
It may be retained as deprecated. It may be retained as deprecated.
o "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and o "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and
Attribute TLVs" registry Attribute TLVs" registry
Values 0-255 are reserved. Values 256-65535 will be used for code Values 0-255 are reserved. Values 256-65535 will be used for code
points. The range 65000-65535 is for Private Use. The registry points. The range 65000-65535 is for Private Use. The registry
has been populated with the values shown in Table 12. Allocations has been populated with the values shown in Table 12. Allocations
within the registry require documentation of the proposed use of within the registry under the "Expert Review" policy require
the allocated value (Specification Required) and approval by the documentation of the proposed use of the allocated value and
Designated Expert assigned by the IESG (see [RFC8126]). approval by the Designated Expert assigned by the IESG (see
[RFC8126]).
6.1. Guidance for Designated Experts 6.1. Guidance for Designated Experts
In all cases of review by the Designated Expert (DE) described here, In all cases of review by the Designated Expert (DE) described here,
the DE is expected to ascertain the existence of suitable the DE is expected to ascertain the existence of suitable
documentation (a specification) as described in [RFC8126] and to documentation (a specification) as described in [RFC8126]. The DE is
verify that the document is permanently and publicly available. The also expected to check the clarity of purpose and use of the
DE is also expected to check the clarity of purpose and use of the requested code points. Additionally, the DE must verify that any
requested code points. Last, the DE must verify that any request for one of these code points has been made available for
specification produced in the IETF that requests one of these code review and comment within the IETF: the DE will post the request to
points has been made available for review by the IDR working group the IDR Working Group mailing list (or a successor mailing list
and that any specification produced outside the IETF does not designated by the IESG). If the request comes from within the IETF,
conflict with work that is active or already published within the it should be documented in an Internet-Draft. Lastly, the DE must
IETF. ensure that any other request for a code point does not conflict with
work that is active or already published within the IETF.
The IANA also requests (per [RFC8126]) that all registries with
"Expert review" allocation policies have a "Change Controller"
assigned. For these four registries, the assigned "Change
Controllers" are the chairs of the IDR working group or a successor
as designated by the IESG.
7. Manageability Considerations 7. Manageability Considerations
This section is structured as recommended in [RFC5706]. This section is structured as recommended in [RFC5706].
7.1. Operational Considerations 7.1. Operational Considerations
7.1.1. Operations 7.1.1. Operations
Existing BGP operational procedures apply. No new operation Existing BGP operational procedures apply. No new operation
skipping to change at page 49, line 28 skipping to change at page 48, line 31
in this document. in this document.
+-----------+---------------------+--------------+------------------+ +-----------+---------------------+--------------+------------------+
| TLV Code | Description | IS-IS TLV/ | Reference | | TLV Code | Description | IS-IS TLV/ | Reference |
| Point | | Sub-TLV | (RFC/Section) | | Point | | Sub-TLV | (RFC/Section) |
+-----------+---------------------+--------------+------------------+ +-----------+---------------------+--------------+------------------+
| 256 | Local Node | --- | Section 4.2.1.2 | | 256 | Local Node | --- | Section 4.2.1.2 |
| | Descriptors | | | | | Descriptors | | |
| 257 | Remote Node | --- | Section 4.2.1.3 | | 257 | Remote Node | --- | Section 4.2.1.3 |
| | Descriptors | | | | | Descriptors | | |
| 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | | 258 | Link Local/Remote | 22/4 | [RFC5307] / 1.1 |
| | Identifiers | | | | | Identifiers | | |
| 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 | | 259 | IPv4 interface | 22/6 | [RFC5305] / 3.2 |
| | address | | | | | address | | |
| 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | | 260 | IPv4 neighbor | 22/8 | [RFC5305] / 3.3 |
| | address | | | | | address | | |
| 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 | | 261 | IPv6 interface | 22/12 | [RFC6119] / 4.2 |
| | address | | | | | address | | |
| 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | | 262 | IPv6 neighbor | 22/13 | [RFC6119] / 4.3 |
| | address | | | | | address | | |
| 263 | Multi-Topology ID | --- | Section 4.2.2.1 | | 263 | Multi-Topology ID | --- | Section 4.2.2.1 |
| 264 | OSPF Route Type | --- | Section 4.2.3 | | 264 | OSPF Route Type | --- | Section 4.2.3 |
| 265 | IP Reachability | --- | Section 4.2.3 | | 265 | IP Reachability | --- | Section 4.2.3 |
| | Information | | | | | Information | | |
| 512 | Autonomous System | --- | Section 4.2.1.4 | | 512 | Autonomous System | --- | Section 4.2.1.4 |
| 513 | BGP-LS Identifier | --- | Section 4.2.1.4 | | 513 | BGP-LS Identifier | --- | Section 4.2.1.4 |
| | (deprecated) | | | | | (deprecated) | | |
| 514 | OSPF Area-ID | --- | Section 4.2.1.4 | | 514 | OSPF Area-ID | --- | Section 4.2.1.4 |
| 515 | IGP Router-ID | --- | Section 4.2.1.4 | | 515 | IGP Router-ID | --- | Section 4.2.1.4 |
| 1024 | Node Flag Bits | --- | Section 4.3.1.1 | | 1024 | Node Flag Bits | --- | Section 4.3.1.1 |
| 1025 | Opaque Node | --- | Section 4.3.1.5 | | 1025 | Opaque Node | --- | Section 4.3.1.5 |
| | Attribute | | | | | Attribute | | |
| 1026 | Node Name | variable | Section 4.3.1.3 | | 1026 | Node Name | variable | Section 4.3.1.3 |
| 1027 | IS-IS Area | variable | Section 4.3.1.2 | | 1027 | IS-IS Area | variable | Section 4.3.1.2 |
| | Identifier | | | | | Identifier | | |
| 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305] / 4.3 |
| | Local Node | | | | | Local Node | | |
| 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119] / 4.1 |
| | Local Node | | | | | Local Node | | |
| 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305] / 4.3 |
| | Remote Node | | | | | Remote Node | | |
| 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119] / 4.1 |
| | Remote Node | | | | | Remote Node | | |
| 1088 | Administrative | 22/3 | [RFC5305]/3.1 | | 1088 | Administrative | 22/3 | [RFC5305] / 3.1 |
| | group (color) | | | | | group (color) | | |
| 1089 | Maximum link | 22/9 | [RFC5305]/3.4 | | 1089 | Maximum link | 22/9 | [RFC5305] / 3.4 |
| | bandwidth | | | | | bandwidth | | |
| 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 | | 1090 | Max. reservable | 22/10 | [RFC5305] / 3.5 |
| | link bandwidth | | | | | link bandwidth | | |
| 1091 | Unreserved | 22/11 | [RFC5305]/3.6 | | 1091 | Unreserved | 22/11 | [RFC5305] / 3.6 |
| | bandwidth | | | | | bandwidth | | |
| 1092 | TE Default Metric | 22/18 | Section 4.3.2.3 | | 1092 | TE Default Metric | 22/18 | Section 4.3.2.3 |
| 1093 | Link Protection | 22/20 | [RFC5307]/1.2 | | 1093 | Link Protection | 22/20 | [RFC5307] / 1.2 |
| | Type | | | | | Type | | |
| 1094 | MPLS Protocol Mask | --- | Section 4.3.2.2 | | 1094 | MPLS Protocol Mask | --- | Section 4.3.2.2 |
| 1095 | IGP Metric | --- | Section 4.3.2.4 | | 1095 | IGP Metric | --- | Section 4.3.2.4 |
| 1096 | Shared Risk Link | --- | Section 4.3.2.5 | | 1096 | Shared Risk Link | --- | Section 4.3.2.5 |
| | Group | | | | | Group | | |
| 1097 | Opaque Link | --- | Section 4.3.2.6 | | 1097 | Opaque Link | --- | Section 4.3.2.6 |
| | Attribute | | | | | Attribute | | |
| 1098 | Link Name | --- | Section 4.3.2.7 | | 1098 | Link Name | --- | Section 4.3.2.7 |
| 1152 | IGP Flags | --- | Section 4.3.3.1 | | 1152 | IGP Flags | --- | Section 4.3.3.1 |
| 1153 | IGP Route Tag | --- | [RFC5130] | | 1153 | IGP Route Tag | --- | [RFC5130] |
skipping to change at page 51, line 27 skipping to change at page 50, line 32
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 consumers are configured to operator to ensure that only trusted consumers are configured to
receive such information. receive such information.
10. Contributors 10. Contributors
We would like to thank Robert Varga for the significant contribution The following persons contributed significant text to RFC7752 and
he gave to RFC7752. this document. They should be considered as co-authors.
Hannes Gredler
Rtbrick
Email: hannes@rtbrick.com
Jan Medved
Cisco Systems Inc.
USA
Email: jmedved@cisco.com
Stefano Previdi
Huawei Technologies
Italy
Email: stefano@previdi.net
Adrian Farrel
Old Dog Consulting
Email: adrian@olddog.co.uk
Saikat Ray
Individual
USA
Email: raysaikat@gmail.com
11. Acknowledgements 11. Acknowledgements
This document update to the BGP-LS specification [RFC7752] is a This document update to the BGP-LS specification [RFC7752] is a
result of feedback and inputs from the discussions in the IDR working result of feedback and inputs from the discussions in the IDR working
group. It also incorporates certain details and clarifications based group. It also incorporates certain details and clarifications based
on implementation and deployment experience with BGP-LS. on implementation and deployment experience with BGP-LS.
Cengiz Alaettinoglu and Parag Amritkar brought forward the need to Cengiz Alaettinoglu and Parag Amritkar brought forward the need to
clarify the advertisement of LAN subnet for OSPF. clarify the advertisement of LAN subnet for OSPF.
We would like to thank Balaji Rajagopalan, Srihari Sangli and We would like to thank Balaji Rajagopalan, Srihari Sangli, Shraddha
Shraddha Hegde for their review and feedback on this document. Hegde, Andrew Stone, Jeff Tantsura, Acee Lindem, Jie Dong, Aijun Wang
and Nandan Saha for their review and feedback on this document.
We would like to thank Robert Varga for the significant contribution
he gave to RFC7752.
We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek
Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les
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.
12. References 12. References
skipping to change at page 54, line 49 skipping to change at page 54, line 31
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-idr-bgpls-inter-as-topology-ext]
Wang, A., Chen, H., Talaulikar, K., and S. Ma, "BGP-LS
Extension for Inter-AS Topology Retrieval", draft-ietf-
idr-bgpls-inter-as-topology-ext-05 (work in progress),
September 2019.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006, RFC 4272, DOI 10.17487/RFC4272, 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
skipping to change at page 56, line 38 skipping to change at page 56, line 26
1. Update the Figure 1 in Section 1 and added Section 3 to 1. Update 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.
2. In Section 4.1, clarification about the TLV handling aspects 2. In Section 4.1, clarification about the TLV handling aspects
that are applicable to both the NLRI and BGP-LS Attribute parts that are applicable to both the NLRI and BGP-LS Attribute parts
and those that are applicable only for the NLRI portion. An and those that are applicable only for the NLRI portion. An
implementation may have missed the part about handling of implementation may have missed the part about handling of
unrecognized TLV and so, based on [RFC7606] guidelines, might unrecognized TLV and so, based on [RFC7606] guidelines, might
discard the unknown NLRI types. This aspect is now discard the unknown NLRI types. This aspect is now
unambiguously clarified in Section 4.2. Also, the ascending unambiguously clarified in Section 4.2. Also, the TLVs in the
order of TLVs in the BGP-LS Attribute is not necessary. BGP-LS Attribute that are not ordered are not to be considered
as malformed.
3. Clarification of mandatory and optional TLVs in both NLRI and 3. Clarification of mandatory and optional TLVs in both NLRI and
BGP-LS Attribute portions all through the document. BGP-LS Attribute portions all through the document.
4. Handling of the growth of the BGP-LS Attribute is covered in 4. Handling of the growth of the BGP-LS Attribute is covered in
Section 4.3. Section 4.3.
5. Clarification on the use of Identifier field in the Link-State 5. Clarified that the document describes the NLRI descriptor TLVs
for the protocols and NLRI types specified in this document and
future BGP-LS extensions must describe the same for other
protocols and NLRI types that they introduce.
6. Clarification on the use of Identifier field in the Link-State
NLRI in Section 4.2 is provided. It was defined ambiguously to NLRI in Section 4.2 is provided. It was defined ambiguously to
refer to only mutli-instance IGP on a single link while it can refer to only mutli-instance IGP on a single link while it can
also be used for multiple IGP protocol instances on a router. also be used for multiple IGP protocol instances on a router.
The IANA registry is accordingly being removed. The IANA registry is accordingly being removed.
6. The BGP-LS Identifier TLV in the Node Descriptors has been 7. 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 doing the same functionality as the use of the Identifier doing the same functionality as the
Instance-ID when running multiple instances of IGP routing Instance-ID when running multiple instances of IGP routing
protocols. protocols.
7. Moved MT-ID TLV from the Node Descriptor section to under the 8. Clarification that the Area-ID TLV is mandatory in the Node
Descriptor for origination of information from OSPF except for
when sourcing information from AS-scope LSAs where this TLV is
not applicable.
9. 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. Also fixed the ambiguity in the encoding of OSPF MT-ID in TLV. Fixed the ambiguity in the encoding of OSPF MT-ID in this
this TLV. MT-ID TLV use is now elevated to SHOULD when it is TLV. Updated the IS-IS specification reference section and
enabled in the underlying IGP. describe the differences in the applicability of the R flags
when MT-ID TLV is used as link descriptor TLV and Prefix
Attribute TLV. MT-ID TLV use is now elevated to SHOULD when it
is enabled in the underlying IGP.
8. Update the usage of OSPF Route Type TLV to mandate its use for 10. Clarified that IPv6 Link-Local Addresses are not advertised in
the Link Descriptor TLVs and the local/remote identifiers are to
be used instead for links with IPv6 link-local addresses only.
11. Update the usage of OSPF Route Type TLV to mandate its use for
OSPF prefixes in Section 4.2.3.1 since this is required for OSPF prefixes in Section 4.2.3.1 since this is required for
segregation of intra-area prefixes that are used to reach a node segregation of intra-area prefixes that are used to reach a node
(e.g. a loopback) from other types of inter-area and external (e.g. a loopback) from other types of inter-area and external
prefixes. prefixes.
9. Updated the Node Name TLV in Section 4.3.1.3 with the OSPF 12. Clarification on the length of the Node Flag Bits TLV to be one
octet.
13. Updated the Node Name TLV in Section 4.3.1.3 with the OSPF
specification. specification.
10. Clarified the advertisement of the prefix corresponding to the 14. Clarification on the size of the IS-IS Narrow Metric
advertisement via the IGP Metric TLV and the handling of the
unused bits.
15. Clarified the advertisement of the prefix corresponding to the
LAN segment in an OSPF network in Section 4.9. LAN segment in an OSPF network in Section 4.9.
11. Introduced Private Use TLV code point space and specified their 16. Introduced Private Use TLV code point space and specified their
encoding in Section 4.4. encoding in Section 4.4.
12. Introduced Section 4.7 where issues related to consistency of 17. Introduced Section 4.7 where issues related to consistency of
reporting IGP link-state along with their solutions are covered. reporting IGP link-state along with their solutions are covered.
13. Handling of large size of BGP-LS Attribute with growth in BGP-LS 18. Handling of large size of BGP-LS Attribute with growth in BGP-LS
information is explained in Section 4.3 along with mitigation of information is explained in Section 4.3 along with mitigation of
errors arising out of it. errors arising out of it.
14. Added recommendation for isolation of BGP-LS sessions from other 19. Added recommendation for isolation of BGP-LS sessions from other
BGP route exchange to avoid errors and faults in BGP-LS BGP route exchange to avoid errors and faults in BGP-LS
affecting the normal BGP routing. affecting the normal BGP routing.
15. Updated the Fault Management section with detailed rules based 20. Updated the Fault Management section with detailed rules based
on the role in the BGP-LS information propagation flow. on the role in the BGP-LS information propagation flow.
Authors' Addresses 21. Change to the management of BGP-LS IANA registries from
"Specification Required" to "Expert Review" along with updated
guidelines for Designated Experts.
Author's Address
Ketan Talaulikar (editor) Ketan Talaulikar (editor)
Cisco Systems Cisco Systems
India India
Email: ketant@cisco.com Email: ketant@cisco.com
Hannes Gredler
Rtbrick
Email: hannes@rtbrick.com
Jan Medved
Cisco Systems, Inc.
170, West Tasman Drive
San Jose, CA 95134
US
Email: jmedved@cisco.com
Stefano Previdi
Huawei Technologies
Rome
Italy
Email: stefano@previdi.net
Adrian Farrel
Old Dog Consulting
Email: adrian@olddog.co.uk
Saikat Ray
Individual Contributor
Email: raysaikat@gmail.com
 End of changes. 78 change blocks. 
152 lines changed or deleted 253 lines changed or added

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