--- 1/draft-ietf-idr-rfc7752bis-04.txt 2020-11-02 03:13:09.183826382 -0800 +++ 2/draft-ietf-idr-rfc7752bis-05.txt 2020-11-02 03:13:09.255827359 -0800 @@ -1,19 +1,19 @@ Inter-Domain Routing K. Talaulikar, Ed. Internet-Draft Cisco Systems -Obsoletes: 7752 (if approved) September 4, 2020 +Obsoletes: 7752 (if approved) November 2, 2020 Intended status: Standards Track -Expires: March 8, 2021 +Expires: May 6, 2021 Distribution of Link-State and Traffic Engineering Information Using BGP - draft-ietf-idr-rfc7752bis-04 + draft-ietf-idr-rfc7752bis-05 Abstract In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE @@ -38,93 +38,103 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 8, 2021. + This Internet-Draft will expire on May 6, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 - 2. Motivation and Applicability . . . . . . . . . . . . . . . . 5 - 2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . 5 + 2. Motivation and Applicability . . . . . . . . . . . . . . . . 6 + 2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . 6 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.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 10 - 4.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 14 + 4.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 10 + 4.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 11 + 4.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 15 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.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 23 + 4.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 24 4.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 27 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.6. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 36 - 4.7. Handling of Unreachable IGP Nodes . . . . . . . . . . . . 37 - 4.8. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 38 - 4.9. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 39 - 4.10. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 40 - 5. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 41 - 5.1. Example: No Link Aggregation . . . . . . . . . . . . . . 41 + 4.7. OSPF Virtual Links and Sham Links . . . . . . . . . . . . 37 + 4.8. OSPFv2 Type 4 Summary LSA & OSPFv3 Inter-Area Router LSA 37 + 4.9. Handling of Unreachable IGP Nodes . . . . . . . . . . . . 37 + 4.10. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 39 + 4.11. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 40 + 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.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 42 + 5.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 43 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 - 6.1. Guidance for Designated Experts . . . . . . . . . . . . . 44 - 7. Manageability Considerations . . . . . . . . . . . . . . . . 44 - 7.1. Operational Considerations . . . . . . . . . . . . . . . 44 - 7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 44 - 7.1.2. Installation and Initial Setup . . . . . . . . . . . 45 - 7.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 45 + 6.1. BGP-LS Registries . . . . . . . . . . . . . . . . . . . . 44 + 6.1.1. BGP-LS NLRI Types Registry . . . . . . . . . . . . . 44 + 6.1.2. BGP-LS Protocol-IDs Registry . . . . . . . . . . . . 44 + 6.1.3. BGP-LS Well-Known Instance-IDs Registry . . . . . . . 45 + 6.1.4. BGP-LS Node Flags Registry . . . . . . . . . . . . . 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 - Components . . . . . . . . . . . . . . . . . . . . . 45 - 7.1.5. Impact on Network Operation . . . . . . . . . . . . . 45 - 7.1.6. Verifying Correct Operation . . . . . . . . . . . . . 45 - 7.2. Management Considerations . . . . . . . . . . . . . . . . 46 - 7.2.1. Management Information . . . . . . . . . . . . . . . 46 - 7.2.2. Fault Management . . . . . . . . . . . . . . . . . . 46 - 7.2.3. Configuration Management . . . . . . . . . . . . . . 48 - 7.2.4. Accounting Management . . . . . . . . . . . . . . . . 49 - 7.2.5. Performance Management . . . . . . . . . . . . . . . 49 - 7.2.6. Security Management . . . . . . . . . . . . . . . . . 49 - 8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 49 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 51 - 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 53 - 12.2. Informative References . . . . . . . . . . . . . . . . . 56 - Appendix A. Changes from RFC 7752 . . . . . . . . . . . . . . . 57 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 59 + Components . . . . . . . . . . . . . . . . . . . . . 47 + 7.1.5. Impact on Network Operation . . . . . . . . . . . . . 47 + 7.1.6. Verifying Correct Operation . . . . . . . . . . . . . 48 + 7.2. Management Considerations . . . . . . . . . . . . . . . . 48 + 7.2.1. Management Information . . . . . . . . . . . . . . . 48 + 7.2.2. Fault Management . . . . . . . . . . . . . . . . . . 48 + 7.2.3. Configuration Management . . . . . . . . . . . . . . 50 + 7.2.4. Accounting Management . . . . . . . . . . . . . . . . 51 + 7.2.5. Performance Management . . . . . . . . . . . . . . . 51 + 7.2.6. Security Management . . . . . . . . . . . . . . . . . 51 + 8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 52 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 53 + 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 55 + 12.2. Informative References . . . . . . . . . . . . . . . . . 58 + Appendix A. Changes from RFC 7752 . . . . . . . . . . . . . . . 60 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 62 1. Introduction The contents of a Link-State Database (LSDB) or of an IGP's Traffic Engineering Database (TED) describe only the links and nodes within an IGP area. Some applications, such as end-to-end Traffic Engineering (TE), would benefit from visibility outside one area or Autonomous System (AS) in order to make better decisions. The IETF has defined the Path Computation Element (PCE) [RFC4655] as @@ -497,29 +507,28 @@ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Link-State VPN AFI 16388 / SAFI 72 NLRI Format The Total NLRI Length field contains the cumulative length, in 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 Route Distinguisher. - +-------------+---------------------------+ + +------+---------------------------+ | Type | NLRI Type | - +-------------+---------------------------+ + +------+---------------------------+ | 1 | Node NLRI | | 2 | Link NLRI | | 3 | IPv4 Topology Prefix NLRI | | 4 | IPv6 Topology Prefix NLRI | - | 65000-65535 | Private Use | - +-------------+---------------------------+ + +------+---------------------------+ Table 1: NLRI Types Route Distinguishers are defined and discussed in [RFC4364]. The Node NLRI (NLRI Type = 1) is shown in the following figure. 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 +-+-+-+-+-+-+-+-+ @@ -574,21 +583,20 @@ +-------------+----------------------------------+ | Protocol-ID | NLRI information source protocol | +-------------+----------------------------------+ | 1 | IS-IS Level 1 | | 2 | IS-IS Level 2 | | 3 | OSPFv2 | | 4 | Direct | | 5 | Static configuration | | 6 | OSPFv3 | - | 200-255 | Private Use | +-------------+----------------------------------+ Table 2: Protocol Identifiers The 'Direct' and 'Static configuration' protocol types SHOULD be used when BGP-LS is sourcing local information. For all information derived from other protocols, the corresponding Protocol-ID MUST be used. If BGP-LS has direct access to interface information and wants to advertise a local link, then the Protocol-ID 'Direct' SHOULD be used. For modeling virtual links, such as described in Section 5, @@ -1083,38 +1089,37 @@ 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 represents a node operational state or attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |O|T|E|B|R|V| Rsvd| - +-+-+-+-+-+-+-+-+-+ + |O|T|E|B|R|V| | + +-+-+-+-+-+-+-+-+ Figure 15: Node Flag Bits TLV Format The bits are defined as follows: - +-----------------+-------------------------+------------+ + +-----+--------------+------------+ | Bit | Description | Reference | - +-----------------+-------------------------+------------+ + +-----+--------------+------------+ | 'O' | Overload Bit | [ISO10589] | | 'T' | Attached Bit | [ISO10589] | | 'E' | External Bit | [RFC2328] | | 'B' | ABR Bit | [RFC2328] | | 'R' | Router Bit | [RFC5340] | | 'V' | V6 Bit | [RFC5340] | - | Reserved (Rsvd) | Reserved for future use | | - +-----------------+-------------------------+------------+ + +-----+--------------+------------+ Table 7: Node Flag Bits Definitions 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 area addresses is carried in the IS-IS Area Identifier TLV. If 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 attribute only when advertised in the Link-State Node NLRI. @@ -1171,25 +1176,25 @@ The Opaque Node Attribute TLV is an envelope that transparently carries optional Node Attribute TLVs advertised by a router. An originating router shall use this TLV for encoding information specific to the protocol advertised in the NLRI header Protocol-ID field or new protocol extensions to the protocol as advertised in the NLRI header Protocol-ID field for which there is no protocol-neutral representation in the BGP Link-State NLRI. The primary use of the Opaque Node Attribute TLV is to bridge the document lag between, e.g., a new IGP link-state attribute being defined and the protocol- - neutral BGP-LS extensions being published. A router, for example, - could use this extension in order to advertise the native protocol's - Node Attribute TLVs, such as the OSPF Router Informational - Capabilities TLV defined in [RFC7770] or the IGP TE Node Capability - Descriptor TLV described in [RFC5073]. + neutral BGP-LS extensions being published. + + In the case of OSPF, this TLV MAY be used to advertise information + carried using the TLVs in the "OSPF Router Information (RI) TLVs" + registry [RFC7770] under the IANA OSPF Parameters registry. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Opaque node attributes (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18: Opaque Node Attribute Format @@ -1271,28 +1276,26 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L|R| Reserved | +-+-+-+-+-+-+-+-+ Figure 19: MPLS Protocol Mask TLV The following bits are defined: - +------------+------------------------------------------+-----------+ + +-----+---------------------------------------------+-----------+ | Bit | Description | Reference | - +------------+------------------------------------------+-----------+ + +-----+---------------------------------------------+-----------+ | 'L' | Label Distribution Protocol (LDP) | [RFC5036] | - | 'R' | Extension to RSVP for LSP Tunnels | [RFC3209] | - | | (RSVP-TE) | | - | 'Reserved' | Reserved for future use | | - +------------+------------------------------------------+-----------+ + | 'R' | Extension to RSVP for LSP Tunnels (RSVP-TE) | [RFC3209] | + +-----+---------------------------------------------+-----------+ Table 9: MPLS Protocol Mask TLV Codes 4.3.2.3. TE Default Metric TLV 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 protocol uses a metric width of less than 32 bits, then the high- order bits of this field MUST be padded with zero. @@ -1361,20 +1364,27 @@ carries optional Link Attribute TLVs advertised by a router. An originating router shall use this TLV for encoding information specific to the protocol advertised in the NLRI header Protocol-ID field or new protocol extensions to the protocol as advertised in the NLRI header Protocol-ID field for which there is no protocol-neutral representation in the BGP Link-State NLRI. The primary use of the Opaque Link Attribute TLV is to bridge the document lag between, e.g., a new IGP link-state attribute being defined and the 'protocol- 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 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Opaque link attributes (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 23: Opaque Link Attribute TLV Format @@ -1428,44 +1438,44 @@ | 1156 | OSPF Forwarding | 4 | [RFC2328] | | | Address | | | | 1157 | Opaque Prefix | variable | Section 4.3.3. | | | Attribute | | 6 | +---------------+-----------------------+----------+----------------+ Table 10: Prefix Attribute TLVs 4.3.3.1. IGP Flags TLV - The IGP Flags TLV contains IS-IS and OSPF flags and bits originally - assigned to the prefix. The IGP Flags TLV is encoded as follows: + The IGP Flags TLV contains one octet of IS-IS and OSPF flags and bits + originally assigned to the prefix. The IGP Flags TLV is encoded as + follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |D|N|L|P| Resvd.| + |D|N|L|P| | +-+-+-+-+-+-+-+-+ Figure 25: IGP Flag TLV Format The Value field contains bits defined according to the table below: - +----------+---------------------------+-----------+ + +-----+---------------------------+-----------+ | Bit | Description | Reference | - +----------+---------------------------+-----------+ + +-----+---------------------------+-----------+ | 'D' | IS-IS Up/Down Bit | [RFC5305] | | 'N' | OSPF "no unicast" Bit | [RFC5340] | | 'L' | OSPF "local address" Bit | [RFC5340] | | 'P' | OSPF "propagate NSSA" Bit | [RFC5340] | - | Reserved | Reserved for future use. | | - +----------+---------------------------+-----------+ + +-----+---------------------------+-----------+ Table 11: IGP Flag Bits Definitions 4.3.3.2. IGP Route Tag TLV The IGP Route Tag TLV carries original IGP Tags (IS-IS [RFC5130] or OSPF) of the prefix and is encoded as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 @@ -1548,20 +1558,27 @@ carries optional Prefix Attribute TLVs advertised by a router. An originating router shall use this TLV for encoding information specific to the protocol advertised in the NLRI header Protocol-ID field or new protocol extensions to the protocol as advertised in the NLRI header Protocol-ID field for which there is no protocol-neutral representation in the BGP Link-State NLRI. The primary use of the Opaque Prefix Attribute TLV is to bridge the document lag between, e.g., a new IGP link-state attribute being defined and the protocol- 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: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Opaque Prefix Attributes (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -1611,25 +1628,55 @@ tiebreak as per the standard BGP path decision process. This specification doesn't mandate any rule regarding the rewrite of the BGP Next Hop attribute. 4.6. Inter-AS Links 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 [RFC5392] [RFC5316]. In other cases, an implementation SHOULD provide a means to inject inter-AS links into - BGP-LS. The exact mechanism used to provision the inter-AS links is - outside the scope of this document and are described in - [I-D.ietf-idr-bgpls-inter-as-topology-ext]. + BGP-LS. The exact mechanism used to advertise the inter-AS links is + outside the scope of this document. -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 needs to provide a consistent and true view of the topology of the IGP domain. BGP-LS provides an abstraction of the protocol specifics 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 @@ -1702,21 +1750,21 @@ LS Consumer via appropriate handling of such a topology feed in addition to the use of either a direct BGP peering with the producer nodes or mechanisms such as [RFC7911] when using RR. Details of these mechanisms are outside the scope of this draft. If the BGP-LS Producer does withdraw link-state objects associated 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 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 Router-IDs are encoded. Consider Figure 32. This represents a Broadcast LAN between a pair of routers. The "real" (non-pseudonode) 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 LAN. Two unidirectional links (Node1, Pseudonode1) and (Pseudonode1, Node2) are being generated. The Link NLRI of (Node1, Pseudonode1) is encoded as follows. The IGP @@ -1736,21 +1784,21 @@ containing 192.0.2.2, the IPv4 Router-ID of Node2. +-----------------+ +-----------------+ +-----------------+ | Node1 | | Pseudonode1 | | Node2 | |1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00| | 192.0.2.1 | | | | 192.0.2.2 | +-----------------+ +-----------------+ +-----------------+ 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 Router-IDs and local Interface IPs are encoded. Consider Figure 33. This represents a Broadcast LAN between a pair of routers. The "real" (non-pseudonode) routers have both an IPv4 Router-ID and an Area Identifier. The pseudonode does have an IPv4 Router-ID, an IPv4 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 both the Router-ID and Interface IP for the pseudonode keys. Two unidirectional links, (Node1, Pseudonode1) and (Pseudonode1, Node2), @@ -1794,21 +1842,21 @@ Figure 33: OSPF Pseudonodes 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 contains the subnet mask for the LAN along with the DR address. A Prefix NLRI corresponding to the LAN subnet is advertised with the Pseudonode1 used as the Local node using the DR address and the 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 operation of both protocols during the migration period. Such a coordination requires identifying a given physical link in both IGPs. 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 IS-IS Link NLRI. 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. @@ -1905,66 +1952,147 @@ Figure 36: Multi-AS Aggregation 6. IANA Considerations IANA has assigned address family number 16388 (BGP-LS) in the "Address Family Numbers" registry with [RFC7752] as a reference. IANA has assigned SAFI values 71 (BGP-LS) and 72 (BGP-LS-VPN) in the "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 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) - Parameters" registry at . All of the following registries are BGP-LS specific and - are accessible under this registry: + Parameters" registry at . - o "BGP-LS NLRI-Types" registry +6.1. BGP-LS Registries - Value 0 is reserved. The maximum value is 65535. The range - 65000-65535 is for Private Use. The registry has been populated - 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]). + All of the registries listed in the following sub-sections are BGP-LS + specific and are accessible under this registry. - 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 - is for Private Use. The registry has been populated with the - values shown in Table 2. 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]). + The "BGP-LS NLRI Types" registry has been setup for assignment for + the two octet sized code-points for BGP-LS NLRI types and populated + with the values shown below: - 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. - It may be retained as deprecated. + 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 Node Descriptor, Link Descriptor, Prefix Descriptor, and - Attribute TLVs" registry +6.1.2. BGP-LS Protocol-IDs Registry - 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 + The "BGP-LS Protocol-IDs" registry has been setup for assignment for + the one octet sized code-points for BGP-LS Protocol-IDs and populated + with the values shown below: + + 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. Guidance for Designated Experts +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, the DE is expected to ascertain the existence of suitable documentation (a specification) as described in [RFC8126]. 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 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 the IDR Working Group mailing list (or a successor mailing list designated by the IESG). If the request comes from within the IETF, @@ -2417,20 +2544,25 @@ [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . + [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, . + [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, . @@ -2477,79 +2609,83 @@ . [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, February 2011, . [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, March 2012, . + [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, . + [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . + [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, . + [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June 2017, . + [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, . + [RFC8654] Bush, R., Patel, K., and D. Ward, "Extended Message Support for BGP", RFC 8654, DOI 10.17487/RFC8654, October 2019, . 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., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . - [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, . - [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter- Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, . [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, December 2008, . @@ -2607,22 +2743,23 @@ implementation may have missed the part about handling of unrecognized TLV and so, based on [RFC7606] guidelines, might discard the unknown NLRI types. This aspect is now unambiguously clarified in Section 4.2. Also, the TLVs in the 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 BGP-LS Attribute portions all through the document. - 4. Handling of the growth of the BGP-LS Attribute is covered in - Section 4.3. + 4. Handling of large size of BGP-LS Attribute with growth in BGP-LS + 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 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 refer to only mutli-instance IGP on a single link while it can also be used for multiple IGP protocol instances on a router. @@ -2653,51 +2790,58 @@ 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 segregation of intra-area prefixes that are used to reach a node (e.g. a loopback) from other types of inter-area and external prefixes. - 12. Clarification on the length of the Node Flag Bits TLV to be one - octet. + 12. Clarification on the specific OSPFv2 and OSPFv3 protocol TLV + 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. - 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 unused bits. - 15. Clarified the advertisement of the prefix corresponding to the - LAN segment in an OSPF network in Section 4.9. + 16. Clarified the advertisement of the prefix corresponding to the + 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. - 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. - 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 - errors arising out of it. - - 19. Added recommendation for isolation of BGP-LS sessions from other + 20. Added recommendation for isolation of BGP-LS sessions from other BGP route exchange to avoid errors and faults in BGP-LS 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. - 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 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 Ketan Talaulikar (editor) Cisco Systems India Email: ketant@cisco.com