draft-ietf-idr-rfc7752bis-04.txt   draft-ietf-idr-rfc7752bis-05.txt 
Inter-Domain Routing K. Talaulikar, Ed. Inter-Domain Routing K. Talaulikar, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Obsoletes: 7752 (if approved) September 4, 2020 Obsoletes: 7752 (if approved) November 2, 2020
Intended status: Standards Track Intended status: Standards Track
Expires: March 8, 2021 Expires: May 6, 2021
Distribution of Link-State and Traffic Engineering Information Using BGP Distribution of Link-State and Traffic Engineering Information Using BGP
draft-ietf-idr-rfc7752bis-04 draft-ietf-idr-rfc7752bis-05
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
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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, 2021. This Internet-Draft will expire on May 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Motivation and Applicability . . . . . . . . . . . . . . . . 5 2. Motivation and Applicability . . . . . . . . . . . . . . . . 6
2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . 7 3. BGP Speaker Roles for BGP-LS . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 10 4.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 11
4.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 14 4.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 15
4.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . 18 4.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . 18
4.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . 21 4.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . 22
4.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . 23 4.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . 23
4.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 23 4.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 24
4.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 27 4.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 27
4.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 32 4.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 32
4.4. Private Use . . . . . . . . . . . . . . . . . . . . . . . 35 4.4. Private Use . . . . . . . . . . . . . . . . . . . . . . . 36
4.5. BGP Next-Hop Information . . . . . . . . . . . . . . . . 36 4.5. BGP Next-Hop Information . . . . . . . . . . . . . . . . 36
4.6. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 36 4.6. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 36
4.7. Handling of Unreachable IGP Nodes . . . . . . . . . . . . 37 4.7. OSPF Virtual Links and Sham Links . . . . . . . . . . . . 37
4.8. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 38 4.8. OSPFv2 Type 4 Summary LSA & OSPFv3 Inter-Area Router LSA 37
4.9. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 39 4.9. Handling of Unreachable IGP Nodes . . . . . . . . . . . . 37
4.10. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 40 4.10. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 39
5. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 41 4.11. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 40
5.1. Example: No Link Aggregation . . . . . . . . . . . . . . 41 4.12. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 41
5. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 42
5.1. Example: No Link Aggregation . . . . . . . . . . . . . . 42
5.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 42 5.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 42
5.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 42 5.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 43
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
6.1. Guidance for Designated Experts . . . . . . . . . . . . . 44 6.1. BGP-LS Registries . . . . . . . . . . . . . . . . . . . . 44
7. Manageability Considerations . . . . . . . . . . . . . . . . 44 6.1.1. BGP-LS NLRI Types Registry . . . . . . . . . . . . . 44
7.1. Operational Considerations . . . . . . . . . . . . . . . 44 6.1.2. BGP-LS Protocol-IDs Registry . . . . . . . . . . . . 44
7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 44 6.1.3. BGP-LS Well-Known Instance-IDs Registry . . . . . . . 45
7.1.2. Installation and Initial Setup . . . . . . . . . . . 45 6.1.4. BGP-LS Node Flags Registry . . . . . . . . . . . . . 45
7.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 45 6.1.5. BGP-LS MPLS Protocol Mask Registry . . . . . . . . . 45
6.1.6. BGP-LS IGP Prefix Flags Registry . . . . . . . . . . 45
6.1.7. BGP-LS TLVs Registry . . . . . . . . . . . . . . . . 46
6.2. Guidance for Designated Experts . . . . . . . . . . . . . 46
7. Manageability Considerations . . . . . . . . . . . . . . . . 46
7.1. Operational Considerations . . . . . . . . . . . . . . . 46
7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 47
7.1.2. Installation and Initial Setup . . . . . . . . . . . 47
7.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 47
7.1.4. Requirements on Other Protocols and Functional 7.1.4. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . 45 Components . . . . . . . . . . . . . . . . . . . . . 47
7.1.5. Impact on Network Operation . . . . . . . . . . . . . 45 7.1.5. Impact on Network Operation . . . . . . . . . . . . . 47
7.1.6. Verifying Correct Operation . . . . . . . . . . . . . 45 7.1.6. Verifying Correct Operation . . . . . . . . . . . . . 48
7.2. Management Considerations . . . . . . . . . . . . . . . . 46 7.2. Management Considerations . . . . . . . . . . . . . . . . 48
7.2.1. Management Information . . . . . . . . . . . . . . . 46 7.2.1. Management Information . . . . . . . . . . . . . . . 48
7.2.2. Fault Management . . . . . . . . . . . . . . . . . . 46 7.2.2. Fault Management . . . . . . . . . . . . . . . . . . 48
7.2.3. Configuration Management . . . . . . . . . . . . . . 48 7.2.3. Configuration Management . . . . . . . . . . . . . . 50
7.2.4. Accounting Management . . . . . . . . . . . . . . . . 49 7.2.4. Accounting Management . . . . . . . . . . . . . . . . 51
7.2.5. Performance Management . . . . . . . . . . . . . . . 49 7.2.5. Performance Management . . . . . . . . . . . . . . . 51
7.2.6. Security Management . . . . . . . . . . . . . . . . . 49 7.2.6. Security Management . . . . . . . . . . . . . . . . . 51
8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 49 8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 52
9. Security Considerations . . . . . . . . . . . . . . . . . . . 51 9. Security Considerations . . . . . . . . . . . . . . . . . . . 53
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
12.1. Normative References . . . . . . . . . . . . . . . . . . 53 12.1. Normative References . . . . . . . . . . . . . . . . . . 55
12.2. Informative References . . . . . . . . . . . . . . . . . 56 12.2. Informative References . . . . . . . . . . . . . . . . . 58
Appendix A. Changes from RFC 7752 . . . . . . . . . . . . . . . 57 Appendix A. Changes from RFC 7752 . . . . . . . . . . . . . . . 60
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 62
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 11, line 38 skipping to change at page 12, line 26
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Link-State VPN AFI 16388 / SAFI 72 NLRI Format Figure 6: Link-State VPN AFI 16388 / SAFI 72 NLRI Format
The Total NLRI Length field contains the cumulative length, in The Total NLRI Length field contains the cumulative length, in
octets, of the rest of the NLRI, not including the NLRI Type field or octets, of the rest of the NLRI, not including the NLRI Type field or
itself. For VPN applications, it also includes the length of the itself. For VPN applications, it also includes the length of the
Route Distinguisher. Route Distinguisher.
+-------------+---------------------------+ +------+---------------------------+
| Type | NLRI Type | | Type | NLRI Type |
+-------------+---------------------------+ +------+---------------------------+
| 1 | Node NLRI | | 1 | Node NLRI |
| 2 | Link NLRI | | 2 | Link NLRI |
| 3 | IPv4 Topology Prefix NLRI | | 3 | IPv4 Topology Prefix NLRI |
| 4 | IPv6 Topology Prefix NLRI | | 4 | IPv6 Topology Prefix NLRI |
| 65000-65535 | Private Use | +------+---------------------------+
+-------------+---------------------------+
Table 1: NLRI Types Table 1: NLRI Types
Route Distinguishers are defined and discussed in [RFC4364]. Route Distinguishers are defined and discussed in [RFC4364].
The Node NLRI (NLRI Type = 1) is shown in the following figure. The Node NLRI (NLRI Type = 1) 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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 13, line 31 skipping to change at page 14, line 14
+-------------+----------------------------------+ +-------------+----------------------------------+
| Protocol-ID | NLRI information source protocol | | Protocol-ID | NLRI information source protocol |
+-------------+----------------------------------+ +-------------+----------------------------------+
| 1 | IS-IS Level 1 | | 1 | IS-IS Level 1 |
| 2 | IS-IS Level 2 | | 2 | IS-IS Level 2 |
| 3 | OSPFv2 | | 3 | OSPFv2 |
| 4 | Direct | | 4 | Direct |
| 5 | Static configuration | | 5 | Static configuration |
| 6 | OSPFv3 | | 6 | OSPFv3 |
| 200-255 | Private Use |
+-------------+----------------------------------+ +-------------+----------------------------------+
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 5, used. For modeling virtual links, such as described in Section 5,
skipping to change at page 24, line 36 skipping to change at page 25, line 16
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 1 octet 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 operational state or attribute. 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| |
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 15: Node Flag Bits TLV Format Figure 15: Node Flag Bits TLV Format
The bits are defined as follows: The bits are defined as follows:
+-----------------+-------------------------+------------+ +-----+--------------+------------+
| Bit | Description | Reference | | Bit | Description | Reference |
+-----------------+-------------------------+------------+ +-----+--------------+------------+
| 'O' | Overload Bit | [ISO10589] | | 'O' | Overload Bit | [ISO10589] |
| 'T' | Attached Bit | [ISO10589] | | 'T' | Attached Bit | [ISO10589] |
| 'E' | External Bit | [RFC2328] | | 'E' | External Bit | [RFC2328] |
| 'B' | ABR Bit | [RFC2328] | | 'B' | ABR Bit | [RFC2328] |
| 'R' | Router Bit | [RFC5340] | | 'R' | Router Bit | [RFC5340] |
| 'V' | V6 Bit | [RFC5340] | | 'V' | V6 Bit | [RFC5340] |
| Reserved (Rsvd) | Reserved for future use | | +-----+--------------+------------+
+-----------------+-------------------------+------------+
Table 7: Node Flag Bits Definitions Table 7: Node Flag Bits Definitions
4.3.1.2. IS-IS Area Identifier TLV 4.3.1.2. IS-IS Area Identifier TLV
An IS-IS node can be part of one or more IS-IS areas. Each of these An IS-IS node can be part of one or more IS-IS areas. Each of these
area addresses is carried in the IS-IS Area Identifier TLV. If area addresses is carried in the IS-IS Area Identifier TLV. If
multiple area addresses are present, multiple TLVs are used to encode multiple area addresses are present, multiple TLVs are used to encode
them. The IS-IS Area Identifier TLV may be present in the BGP-LS them. The IS-IS Area Identifier TLV may be present in the BGP-LS
attribute only when advertised in the Link-State Node NLRI. attribute only when advertised in the Link-State Node NLRI.
skipping to change at page 26, line 38 skipping to change at page 27, line 5
The Opaque Node Attribute TLV is an envelope that transparently The Opaque Node Attribute TLV is an envelope that transparently
carries optional Node Attribute TLVs advertised by a router. An carries optional Node Attribute TLVs advertised by a router. An
originating router shall use this TLV for encoding information originating router shall use this TLV for encoding information
specific to the protocol advertised in the NLRI header Protocol-ID specific to the protocol advertised in the NLRI header Protocol-ID
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, Opaque Node Attribute TLV is to bridge the document lag between,
e.g., a new IGP link-state attribute being defined and the protocol- e.g., a new IGP link-state attribute being defined and the protocol-
neutral BGP-LS extensions being published. A router, for example, neutral BGP-LS extensions being published.
could use this extension in order to advertise the native protocol's
Node Attribute TLVs, such as the OSPF Router Informational In the case of OSPF, this TLV MAY be used to advertise information
Capabilities TLV defined in [RFC7770] or the IGP TE Node Capability carried using the TLVs in the "OSPF Router Information (RI) TLVs"
Descriptor TLV described in [RFC5073]. registry [RFC7770] under the IANA OSPF Parameters registry.
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 29, line 25 skipping to change at page 29, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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: The following bits are defined:
+------------+------------------------------------------+-----------+ +-----+---------------------------------------------+-----------+
| 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 | [RFC3209] | | 'R' | Extension to RSVP for LSP Tunnels (RSVP-TE) | [RFC3209] |
| | (RSVP-TE) | | +-----+---------------------------------------------+-----------+
| 'Reserved' | Reserved for future use | |
+------------+------------------------------------------+-----------+
Table 9: MPLS Protocol Mask TLV Codes Table 9: MPLS Protocol Mask TLV Codes
4.3.2.3. TE Default Metric TLV 4.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 less than 32 bits, then the high- protocol uses a metric width of less 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.
skipping to change at page 31, line 18 skipping to change at page 31, line 18
carries optional Link Attribute TLVs advertised by a router. An carries optional Link Attribute TLVs advertised by a router. An
originating router shall use this TLV for encoding information originating router shall use this TLV for encoding information
specific to the protocol advertised in the NLRI header Protocol-ID specific to the protocol advertised in the NLRI header Protocol-ID
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, Opaque Link Attribute TLV is to bridge the document lag between,
e.g., a new IGP link-state attribute being defined and the 'protocol- e.g., a new IGP link-state attribute being defined and the 'protocol-
neutral' BGP-LS extensions being published. neutral' BGP-LS extensions being published.
In the case of OSPFv2, this TLV MAY be used to advertise information
carried using the TLVs in the "OSPFv2 Extended Link Opaque LSA TLVs"
registry [RFC7684] under the IANA OSPFv2 Parameters registry. In the
case of OSPFv3, this TLV MAY be used to advertise information carried
using the TLVs in the "OSPFv3 Extended-LSA Sub-TLVs" registry
[RFC8362] under the IANA OSPFv3 Parameters registry.
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
skipping to change at page 32, line 44 skipping to change at page 32, line 44
| 1156 | OSPF Forwarding | 4 | [RFC2328] | | 1156 | OSPF Forwarding | 4 | [RFC2328] |
| | Address | | | | | Address | | |
| 1157 | Opaque Prefix | variable | Section 4.3.3. | | 1157 | Opaque Prefix | variable | Section 4.3.3. |
| | Attribute | | 6 | | | Attribute | | 6 |
+---------------+-----------------------+----------+----------------+ +---------------+-----------------------+----------+----------------+
Table 10: Prefix Attribute TLVs Table 10: Prefix Attribute TLVs
4.3.3.1. IGP Flags TLV 4.3.3.1. IGP Flags TLV
The IGP Flags TLV contains IS-IS and OSPF flags and bits originally The IGP Flags TLV contains one octet of IS-IS and OSPF flags and bits
assigned to the prefix. The IGP Flags TLV is encoded as follows: originally assigned to the prefix. The IGP Flags TLV 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|N|L|P| Resvd.| |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:
+----------+---------------------------+-----------+ +-----+---------------------------+-----------+
| 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] |
| Reserved | Reserved for future use. | | +-----+---------------------------+-----------+
+----------+---------------------------+-----------+
Table 11: IGP Flag Bits Definitions Table 11: IGP Flag Bits Definitions
4.3.3.2. IGP Route Tag TLV 4.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
skipping to change at page 35, line 31 skipping to change at page 35, line 31
carries optional Prefix Attribute TLVs advertised by a router. An carries optional Prefix Attribute TLVs advertised by a router. An
originating router shall use this TLV for encoding information originating router shall use this TLV for encoding information
specific to the protocol advertised in the NLRI header Protocol-ID specific to the protocol advertised in the NLRI header Protocol-ID
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, Opaque Prefix Attribute TLV is to bridge the document lag between,
e.g., a new IGP link-state attribute being defined and the protocol- e.g., a new IGP link-state attribute being defined and the protocol-
neutral BGP-LS extensions being published. neutral BGP-LS extensions being published.
In the case of OSPFv2, this TLV MAY be used to advertise information
carried using the TLVs in the "OSPFv2 Extended Prefix Opaque LSA
TLVs" registry [RFC7684] under the IANA OSPFv2 Parameters registry.
In the case of OSPFv3, this TLV MAY be used to advertise information
carried using the TLVs in the "OSPFv3 Extended-LSA Sub-TLVs" registry
[RFC8362] under the IANA OSPFv3 Parameters registry.
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 36, line 45 skipping to change at page 37, line 5
tiebreak as per the standard BGP path decision process. This tiebreak as per the standard BGP path decision process. This
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 advertise the inter-AS links is
outside the scope of this document and are described in outside the scope of this document.
[I-D.ietf-idr-bgpls-inter-as-topology-ext].
4.7. Handling of Unreachable IGP Nodes 4.7. OSPF Virtual Links and Sham Links
In an OSPF [RFC2328] [RFC5340] network, virtual links serve to
connect physically separate components of the backbone to establish/
maintain continuity of the backbone area. While virtual links are
modeled as point-to-point unnumbered links in the OSPF topology,
their characteristics and purpose are different from other types of
links in the OSPF topology. They are advertised using a distinct
"virtual link" type in OSPF LSAs. The mechanism for advertisement of
OSPF virtual links via BGP-LS is outside the scope of this document.
In an OSPF network, sham links [RFC4577] [RFC6565] are used to
provide an intra-area connectivity between VRFs on PE routers over
the VPN provider's network. These links are advertised in OSPF as a
point-to-point unnumbered links and represent connectivity over a
service provider network using encapsulation mechanisms like MPLS.
As such, the mechanism for advertisement of OSPF sham links follow
the same procedures as other point-to-point unnumbered links as
described previously in this document.
4.8. OSPFv2 Type 4 Summary LSA & OSPFv3 Inter-Area Router LSA
OSPFv2 [RFC2328] defines the Type 4 Summary LSA and OSPFv3 [RFC5340]
the Inter-area-router-LSA for an Area Border Router (ABR) to
advertise reachability to an AS Border Router (ASBR) that is external
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
node or a link or a prefix as discussed in this document. Therefore,
the mechanism for advertisement of the information carried by these
LSAs is outside the scope of this document.
4.9. 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. While the and BGP-LS Consumers may be varied types of applications. While the
information propagated via BGP-LS from a link-state routing protocol 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 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 reflection of the originating router's LSDB since it does not include
the LSA/LSP sequence number information. The sequence numbers are the LSA/LSP sequence number information. The sequence numbers are
not included since a single NLRI update may be put together with not included since a single NLRI update may be put together with
skipping to change at page 38, line 44 skipping to change at page 39, line 32
LS Consumer via appropriate handling of such a topology feed in LS Consumer via appropriate handling of such a topology feed in
addition to the use of either a direct BGP peering with the producer addition to the use of either a direct BGP peering with the producer
nodes or mechanisms such as [RFC7911] when using RR. Details of nodes or mechanisms such as [RFC7911] when using RR. Details of
these mechanisms are outside the scope of this draft. these mechanisms are outside the scope of this draft.
If the BGP-LS Producer does withdraw link-state objects associated If the BGP-LS Producer does withdraw link-state objects associated
with an IGP node based on failure of reachability check for that with an IGP node based on failure of reachability check for that
node, then it MUST re-advertise those link-state objects after that node, then it MUST re-advertise those link-state objects after that
node becomes reachable again in the IGP domain. node becomes reachable again in the IGP domain.
4.8. Router-ID Anchoring Example: ISO Pseudonode 4.10. Router-ID Anchoring Example: ISO Pseudonode
Encoding of a broadcast LAN in IS-IS provides a good example of how Encoding of a broadcast LAN in IS-IS provides a good example of how
Router-IDs are encoded. Consider Figure 32. This represents a Router-IDs are encoded. Consider Figure 32. This represents a
Broadcast LAN between a pair of routers. The "real" (non-pseudonode) Broadcast LAN between a pair of routers. The "real" (non-pseudonode)
routers have both an IPv4 Router-ID and IS-IS Node-ID. The routers have both an IPv4 Router-ID and IS-IS Node-ID. The
pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for the pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for the
LAN. Two unidirectional links (Node1, Pseudonode1) and (Pseudonode1, LAN. Two unidirectional links (Node1, Pseudonode1) and (Pseudonode1,
Node2) are being generated. Node2) are being generated.
The Link NLRI of (Node1, Pseudonode1) is encoded as follows. The IGP The Link NLRI of (Node1, Pseudonode1) is encoded as follows. The IGP
skipping to change at page 39, line 31 skipping to change at page 40, line 17
containing 192.0.2.2, the IPv4 Router-ID of Node2. containing 192.0.2.2, the IPv4 Router-ID of Node2.
+-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+
| Node1 | | Pseudonode1 | | Node2 | | Node1 | | Pseudonode1 | | Node2 |
|1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00| |1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00|
| 192.0.2.1 | | | | 192.0.2.2 | | 192.0.2.1 | | | | 192.0.2.2 |
+-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+
Figure 32: IS-IS Pseudonodes Figure 32: IS-IS Pseudonodes
4.9. Router-ID Anchoring Example: OSPF Pseudonode 4.11. Router-ID Anchoring Example: OSPF Pseudonode
Encoding of a broadcast LAN in OSPF provides a good example of how Encoding of a broadcast LAN in OSPF provides a good example of how
Router-IDs and local Interface IPs are encoded. Consider Figure 33. Router-IDs and local Interface IPs are encoded. Consider Figure 33.
This represents a Broadcast LAN between a pair of routers. The This represents a Broadcast LAN between a pair of routers. The
"real" (non-pseudonode) routers have both an IPv4 Router-ID and an "real" (non-pseudonode) routers have both an IPv4 Router-ID and an
Area Identifier. The pseudonode does have an IPv4 Router-ID, an IPv4 Area Identifier. The pseudonode does have an IPv4 Router-ID, an IPv4
Interface Address (for disambiguation), and an OSPF Area. Node1 is Interface Address (for disambiguation), and an OSPF Area. Node1 is
the DR for the LAN; hence, its local IP address 10.1.1.1 is used as the DR for the LAN; hence, its local IP address 10.1.1.1 is used as
both the Router-ID and Interface IP for the pseudonode keys. Two both the Router-ID and Interface IP for the pseudonode keys. Two
unidirectional links, (Node1, Pseudonode1) and (Pseudonode1, Node2), unidirectional links, (Node1, Pseudonode1) and (Pseudonode1, Node2),
skipping to change at page 40, line 42 skipping to change at page 41, line 28
Figure 33: OSPF Pseudonodes Figure 33: OSPF Pseudonodes
The LAN subnet 10.1.1.0/24 is not included in the Router LSA of Node1 The LAN subnet 10.1.1.0/24 is not included in the Router LSA of Node1
or Node2. The Network LSA for this LAN advertised by the DR Node1 or Node2. The Network LSA for this LAN advertised by the DR Node1
contains the subnet mask for the LAN along with the DR address. A contains the subnet mask for the LAN along with the DR address. A
Prefix NLRI corresponding to the LAN subnet is advertised with the Prefix NLRI corresponding to the LAN subnet is advertised with the
Pseudonode1 used as the Local node using the DR address and the Pseudonode1 used as the Local node using the DR address and the
subnet mask from the Network LSA. subnet mask from the Network LSA.
4.10. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration 4.12. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration
Graceful migration from one IGP to another requires coordinated Graceful migration from one IGP to another requires coordinated
operation of both protocols during the migration period. Such a operation of both protocols during the migration period. Such a
coordination requires identifying a given physical link in both IGPs. coordination requires identifying a given physical link in both IGPs.
The IPv4 Router-ID provides that "glue", which is present in the Node The IPv4 Router-ID provides that "glue", which is present in the Node
Descriptors of the OSPF Link NLRI and in the link attribute of the Descriptors of the OSPF Link NLRI and in the link attribute of the
IS-IS Link NLRI. IS-IS Link NLRI.
Consider a point-to-point link between two routers, A and B, that Consider a point-to-point link between two routers, A and B, that
initially were OSPFv2-only routers and then IS-IS is enabled on them. initially were OSPFv2-only routers and then IS-IS is enabled on them.
skipping to change at page 43, line 24 skipping to change at page 43, line 43
Figure 36: Multi-AS Aggregation Figure 36: Multi-AS Aggregation
6. IANA Considerations 6. IANA Considerations
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 with [RFC7752] as a reference. "Address Family Numbers" registry with [RFC7752] as a reference.
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" sub-registry under the "Subsequent Address Family
Identifiers (SAFI) Parameters" registry. Identifiers (SAFI) Parameters" registry with [RFC7752] as a
reference.
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" sub-registry under the "Border Gateway Protocol (BGP)
Parameters" registry. Parameters" registry with [RFC7752] as a reference.
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 <https://www.iana.org/assignments/bgp-ls-
parameters>. All of the following registries are BGP-LS specific and parameters>.
are accessible under this registry:
o "BGP-LS NLRI-Types" registry 6.1. BGP-LS Registries
Value 0 is reserved. The maximum value is 65535. The range All of the registries listed in the following sub-sections are BGP-LS
65000-65535 is for Private Use. The registry has been populated specific and are accessible under this registry.
with the values shown in Table 1. Allocations within the registry
under the "Expert Review" policy require documentation of the
proposed use of the allocated value and approval by the Designated
Expert assigned by the IESG (see [RFC8126]).
o "BGP-LS Protocol-IDs" registry 6.1.1. BGP-LS NLRI Types Registry
Value 0 is reserved. The maximum value is 255. The range 200-255 The "BGP-LS NLRI Types" registry has been setup for assignment for
is for Private Use. The registry has been populated with the the two octet sized code-points for BGP-LS NLRI types and populated
values shown in Table 2. Allocations within the registry under with the values shown below:
the "Expert Review" policy require documentation of the proposed
use of the allocated value and approval by the Designated Expert
assigned by the IESG (see [RFC8126]).
o "BGP-LS Well-Known Instance-IDs" registry Type NLRI Type Reference
-----------------------------------------------------------------
0 Reserved [RFC7752][This document]
1 Node NLRI [RFC7752][This document]
2 Link NLRI [RFC7752][This document]
3 IPv4 Topology Prefix NLRI [RFC7752][This document]
4 IPv6 Topology Prefix NLRI [RFC7752][This document]
65000-65535 Private Use [This document]
This registry was setup via [RFC7752] and is no longer required. Allocations within the registry under the "Expert Review" policy
It may be retained as deprecated. require documentation of the proposed use of the allocated value and
approval by the Designated Expert assigned by the IESG (see
[RFC8126]).
o "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 6.1.2. BGP-LS Protocol-IDs Registry
Attribute TLVs" registry
Values 0-255 are reserved. Values 256-65535 will be used for code The "BGP-LS Protocol-IDs" registry has been setup for assignment for
points. The range 65000-65535 is for Private Use. The registry the one octet sized code-points for BGP-LS Protocol-IDs and populated
has been populated with the values shown in Table 12. Allocations with the values shown below:
within the registry under the "Expert Review" policy require
documentation of the proposed use of the allocated value and
approval by the Designated Expert assigned by the IESG (see
[RFC8126]).
6.1. Guidance for Designated Experts Protocol-ID NLRI information source protocol Reference
-----------------------------------------------------------------------
0 Reserved [RFC7752][This document]
1 IS-IS Level 1 [RFC7752][This document]
2 IS-IS Level 2 [RFC7752][This document]
3 OSPFv2 [RFC7752][This document]
4 Direct [RFC7752][This document]
5 Static configuration [RFC7752][This document]
6 OSPFv3 [RFC7752][This document]
200-255 Private Use [This document]
Allocations within the registry under the "Expert Review" policy
require documentation of the proposed use of the allocated value and
approval by the Designated Expert assigned by the IESG (see
[RFC8126]).
6.1.3. BGP-LS Well-Known Instance-IDs Registry
The "BGP-LS Well-Known Instance-IDs" registry that was setup via
[RFC7752] is no longer required. It may be retained as deprecated
and no further assignments be made from it.
6.1.4. BGP-LS Node Flags Registry
The "BGP-LS Node Flags" registry is requested to be created for the 1
octet sized flags field of the Node Flag Bits TLV (1024) and
populated with the initial values shown below:
Bit Description Reference
-----------------------------------------------------------------------
0 Overload Bit (O-bit) [RFC7752][This document]
1 Attached Bit (A-bit) [RFC7752][This document]
2 External Bit (E-bit) [RFC7752][This document]
3 ABR Bit (B-bit) [RFC7752][This document]
4 Router Bit (R-bit) [RFC7752][This document]
5 V6 Bit (V-bit) [RFC7752][This document]
6-7 Unassigned
Allocations within the registry under the "Specification Required"
policy (see [RFC8126]).
6.1.5. BGP-LS MPLS Protocol Mask Registry
The "BGP-LS MPLS Protocol Mask" registry is requested to be created
for the 1 octet sized flags field of the MPLS Protocol Mask TLV
(1094) and populated with the initial values shown below:
Bit Description Reference
-----------------------------------------------------------------------
0 Label Distribution Protocol (L-bit) [RFC7752][This document]
1 Extension to RSVP for LSP Tunnels (R-bit) [RFC7752][This document]
2-7 Unassigned
Allocations within the registry under the "Specification Required"
policy (see [RFC8126]).
6.1.6. BGP-LS IGP Prefix Flags Registry
The "BGP-LS IGP Prefix Flags" registry is requested to be created for
the 1 octet sized flags field of the IGP Flags TLV (1152) and
populated with the initial values shown below:
Bit Description Reference
-----------------------------------------------------------------
0 IS-IS Up/Down Bit (D-bit) [RFC7752][This document]
1 OSPF "no unicast" Bit (N-bit) [RFC7752][This document]
2 OSPF "local address" Bit (L-bit) [RFC7752][This document]
3 OSPF "propagate NSSA" Bit (P-bit) [RFC7752][This document]
4-7 Unassigned
Allocations within the registry under the "Specification Required"
policy (see [RFC8126]).
6.1.7. BGP-LS TLVs Registry
The "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and
Attribute TLVs" registry was setup via [RFC7752]. Values 0-255 are
reserved. Values 256-65535 will be used for code points. The range
65000-65535 is for Private Use. The registry has been populated with
the values shown in Table 12. Allocations within the registry under
the "Expert Review" policy require documentation of the proposed use
of the allocated value and approval by the Designated Expert assigned
by the IESG (see [RFC8126]).
6.2. 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]. The DE is documentation (a specification) as described in [RFC8126]. The DE is
also expected to check the clarity of purpose and use of the 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. Additionally, the DE must verify that any
request for one of these code points has been made available for request for one of these code points has been made available for
review and comment within the IETF: the DE will post the request to review and comment within the IETF: the DE will post the request to
the IDR Working Group mailing list (or a successor mailing list the IDR Working Group mailing list (or a successor mailing list
designated by the IESG). If the request comes from within the IETF, designated by the IESG). If the request comes from within the IETF,
skipping to change at page 54, line 10 skipping to change at page 56, line 20
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<https://www.rfc-editor.org/info/rfc4203>. <https://www.rfc-editor.org/info/rfc4203>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the
Provider/Customer Edge Protocol for BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4577, DOI 10.17487/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., and P. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007, RFC 4915, DOI 10.17487/RFC4915, June 2007,
<https://www.rfc-editor.org/info/rfc4915>. <https://www.rfc-editor.org/info/rfc4915>.
skipping to change at page 55, line 23 skipping to change at page 57, line 36
<https://www.rfc-editor.org/info/rfc5890>. <https://www.rfc-editor.org/info/rfc5890>.
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
February 2011, <https://www.rfc-editor.org/info/rfc6119>. February 2011, <https://www.rfc-editor.org/info/rfc6119>.
[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>.
[RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and
M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge
(PE-CE) Routing Protocol", RFC 6565, DOI 10.17487/RFC6565,
June 2012, <https://www.rfc-editor.org/info/rfc6565>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages", Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>. <https://www.rfc-editor.org/info/rfc7606>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <https://www.rfc-editor.org/info/rfc7684>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
F. Baker, "OSPFv3 Link State Advertisement (LSA)
Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
2018, <https://www.rfc-editor.org/info/rfc8362>.
[RFC8654] Bush, R., Patel, K., and D. Ward, "Extended Message [RFC8654] Bush, R., Patel, K., and D. Ward, "Extended Message
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>.
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. Zhuang, "BGP-LS
Extension for Inter-AS Topology Retrieval", draft-ietf-
idr-bgpls-inter-as-topology-ext-08 (work in progress),
April 2020.
[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
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., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, 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>.
[RFC5073] Vasseur, J., Ed. and J. Le Roux, Ed., "IGP Routing
Protocol Extensions for Discovery of Traffic Engineering
Node Capabilities", RFC 5073, DOI 10.17487/RFC5073,
December 2007, <https://www.rfc-editor.org/info/rfc5073>.
[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 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
December 2008, <https://www.rfc-editor.org/info/rfc5316>. December 2008, <https://www.rfc-editor.org/info/rfc5316>.
skipping to change at page 58, line 11 skipping to change at page 60, line 28
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 TLVs in the unambiguously clarified in Section 4.2. Also, the TLVs in the
BGP-LS Attribute that are not ordered are not to be considered BGP-LS Attribute that are not ordered are not to be considered
as malformed. 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 large size of BGP-LS Attribute with growth in BGP-LS
Section 4.3. information is explained in Section 4.3 along with mitigation of
errors arising out of it.
5. Clarified that the document describes the NLRI descriptor TLVs 5. 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.
6. Clarification on the use of Identifier field in the Link-State 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.
skipping to change at page 59, line 11 skipping to change at page 61, line 26
10. Clarified that IPv6 Link-Local Addresses are not advertised in 10. Clarified that IPv6 Link-Local Addresses are not advertised in
the Link Descriptor TLVs and the local/remote identifiers are to the Link Descriptor TLVs and the local/remote identifiers are to
be used instead for links with IPv6 link-local addresses only. 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 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.
12. Clarification on the length of the Node Flag Bits TLV to be one 12. Clarification on the specific OSPFv2 and OSPFv3 protocol TLV
octet. space to be used in the node, link and prefix opaque attribute
TLVs.
13. Updated the Node Name TLV in Section 4.3.1.3 with the OSPF 13. Clarification on the length of the Node Flag Bits and IGP Flags
TLVs to be one octet.
14. Updated the Node Name TLV in Section 4.3.1.3 with the OSPF
specification. specification.
14. Clarification on the size of the IS-IS Narrow Metric 15. Clarification on the size of the IS-IS Narrow Metric
advertisement via the IGP Metric TLV and the handling of the advertisement via the IGP Metric TLV and the handling of the
unused bits. unused bits.
15. Clarified the advertisement of the prefix corresponding to the 16. 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.11.
16. Introduced Private Use TLV code point space and specified their 17. Clarified the advertisement and support for OSPF specific
concepts like Virtual links, Sham links and Type 4 LSAs in
Section 4.7 and Section 4.8.
18. Introduced Private Use TLV code point space and specified their
encoding in Section 4.4. encoding in Section 4.4.
17. Introduced Section 4.7 where issues related to consistency of 19. Introduced Section 4.9 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.
18. Handling of large size of BGP-LS Attribute with growth in BGP-LS 20. Added recommendation for isolation of BGP-LS sessions from other
information is explained in Section 4.3 along with mitigation of
errors arising out of it.
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.
20. Updated the Fault Management section with detailed rules based 21. 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.
21. Change to the management of BGP-LS IANA registries from 22. Change to the management of BGP-LS IANA registries from
"Specification Required" to "Expert Review" along with updated "Specification Required" to "Expert Review" along with updated
guidelines for Designated Experts. guidelines for Designated Experts.
23. Added BGP-LS IANA registries with "Specification Required"
policy for the flag fields of various TLVs that was missed out.
Author's Address Author's Address
Ketan Talaulikar (editor) Ketan Talaulikar (editor)
Cisco Systems Cisco Systems
India India
Email: ketant@cisco.com Email: ketant@cisco.com
 End of changes. 59 change blocks. 
160 lines changed or deleted 307 lines changed or added

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