idnits 2.17.1 draft-ketant-idr-bgp-ls-bgp-only-fabric-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2020) is 1503 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-idr-bgp-ls-flex-algo-02 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-16 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-msd-15 == Outdated reference: A later version (-19) exists of draft-ietf-idr-eag-distribution-11 == Outdated reference: A later version (-19) exists of draft-ietf-idr-te-lsp-distribution-12 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-06 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-06 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing K. Talaulikar 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track K. Swamy 5 Expires: September 13, 2020 Cisco Systems 6 S. Zandi 7 G. Dawra 8 LinkedIn 9 M. Durrani 10 Equinix 11 March 12, 2020 13 BGP Link-State Extensions for BGP-only Fabric 14 draft-ketant-idr-bgp-ls-bgp-only-fabric-04 16 Abstract 18 BGP is used as the only routing protocol in some networks today. In 19 such networks, it is useful to get a detailed view of the nodes and 20 underlying links in the topology along with their attributes similar 21 to one available when using link state routing protocols. Such a 22 view of a BGP-only fabric enables use cases like traffic engineering 23 and forwarding of services along paths other than the BGP best path 24 selection. 26 This document defines extensions to the BGP Link-state address-family 27 (BGP-LS) and the procedures for advertisement of the topology in a 28 BGP-only network. It also describes a specific use-case for traffic 29 engineering based on Segment Routing. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 13, 2020. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 67 2. BGP Routing in the Fabric . . . . . . . . . . . . . . . . . . 3 68 3. Topology Collection Mechanism . . . . . . . . . . . . . . . . 4 69 3.1. Peering Models . . . . . . . . . . . . . . . . . . . . . 5 70 4. Advertising BGP-only Network Topology . . . . . . . . . . . . 6 71 4.1. Node Advertisements . . . . . . . . . . . . . . . . . . . 6 72 4.2. Link Advertisements . . . . . . . . . . . . . . . . . . . 7 73 4.3. Prefix Advertisements . . . . . . . . . . . . . . . . . . 10 74 4.4. TE Policy Advertisements . . . . . . . . . . . . . . . . 12 75 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 5.1. Advertisement of Router's Node Attributes . . . . . . . . 13 77 5.2. Advertisement of Router's Local Links Attributes . . . . 15 78 5.3. Advertisement of Router's Prefix Attributes . . . . . . . 17 79 5.4. Advertisement of Router's TE Policy Attributes . . . . . 17 80 6. Usage of BGP Topology . . . . . . . . . . . . . . . . . . . . 18 81 6.1. Topology View for Monitoring . . . . . . . . . . . . . . 18 82 6.2. SR-TE in BGP Networks . . . . . . . . . . . . . . . . . . 18 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 84 8. Manageability Considerations . . . . . . . . . . . . . . . . 21 85 8.1. Operational Considerations . . . . . . . . . . . . . . . 21 86 8.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 21 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 91 11.2. Informative References . . . . . . . . . . . . . . . . . 23 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 94 1. Introduction 96 Network operators are going for a BGP-only routing protocol for 97 certain networks like Massively Scaled Data Centers (MSDCs). 98 [RFC7938] describes the requirement, design and operational aspects 99 for use of BGP as the only routing protocol in MSDCs. The underlying 100 link and topology information between BGP routers is hidden or 101 abstracted in this design from the underlay routing for improving 102 scalability and stability in a large scale network. On the flip 103 side, there is no detailed topology view similar to one available in 104 form of the Traffic Engineering (TE) Database (TED) when running link 105 state routing protocols like OSPF [RFC2328] with extensions specified 106 in [RFC3630]. 108 BGP Link-State (BGP-LS)[RFC7752] enables advertisement of a link 109 state topology via BGP that can be consumed by a controller or in 110 general any software component to get a complete topology view of the 111 network. BGP-LS extensions for advertisement of a BGP topology for 112 the Egress Peer Engineering (EPE) use-case 113 [I-D.ietf-spring-segment-routing-central-epe] are specified in 114 [I-D.ietf-idr-bgpls-segment-routing-epe]. This document leverages 115 the BGP-LS TLVs defined for BGP-LS EPE and other BGP-LS documents and 116 specifies the procedures for advertising the underlying topology in a 117 more generic BGP-only fabric use-case. 119 This document specifies the operations and procedures when using the 120 design involving BGP use for hop-by-hop routing between directly 121 connected network nodes (refer [RFC7938] for details). 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in BCP 128 14 [RFC2119] [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 2. BGP Routing in the Fabric 133 This document does not change base BGP routing protocol operations in 134 the fabric that provides routing using the BGP best path selection 135 process [RFC4271] . 137 The applicability of this specification is limited to those 138 deployments where BGP is used as hop-by-hop routing protocol between 139 directly connected nodes in the fabric. While a data-center design 140 [RFC7938] is used as a reference, the topology advertisement and its 141 use for computation may also apply to other networks with BGP-only 142 fabric or to BGP-only portions of a larger network topology. 144 BGP hop-by-hop routing can be setup using EBGP single-hop sessions 145 over individual links between directly connected routers using their 146 link addresses for peering as described in [RFC7938]. In such a 147 design, the neighbors' link addresses may be provisioned for peering 148 and the EBGP session operating directly over the link performs the 149 monitoring of the neighbor on that link. A variation of this design 150 would be that the EBGP session is setup between directly connected 151 routers using their loopback sessions. The mechanisms for discovery 152 of the neighbor's link addresses and their monitoring on a per link 153 basis are outside the scope of this document. 154 [I-D.xu-idr-neighbor-autodiscovery] describes one such mechanism and 155 the same may be also realized by other means. 157 Though this document uses the EBGP based design as a reference, it 158 does not preclude other alternate designs using IBGP. 160 3. Topology Collection Mechanism 162 BGP-LS [RFC7752] has been defined to allow BGP to convey topology 163 information in the form of Link-State objects - node, link and 164 prefix. The properties of each of these objects are encoded using 165 BGP-LS Attribute TLVs. Applications need a topological view and 166 visibility even for networks where BGP is the only routing protocol. 167 In such networks, each BGP router advertises its local information 168 which includes its node, links and prefix attributes via BGP-LS. 170 Figure 1 describes a typical deployment scenario. Every BGP router 171 in the network is enabled for BGP-LS and forms BGP-LS sessions with 172 one or more centralized BGP-LS speakers over which it sends its local 173 topology information. Each BGP router MAY also receive the topology 174 information from all other BGP routers via these centralized BGP-LS 175 speakers. This way, any BGP router (as also the centralized BGP-LS 176 speakers) MAY obtain aggregated Link-State information for the entire 177 BGP network. An external component (e.g. a controller) can obtain 178 this information from the centralized BGP-LS speakers or directly by 179 doing BGP-LS peering to the BGP routers. An internal software 180 component on any of the BGP routers (e.g. TE module) can also 181 receive the entire BGP network topology information from its local 182 BGP process. 184 +------------+ 185 | Controller | 186 +------------+ 187 ^ 188 | 189 v 190 +-------------------+ 191 | BGP-LS Speaker | +------------+ 192 | (Centralized) | | Controller | 193 +-------------------+ +------------+ 194 ^ ^ ^ ^ 195 | | | | 196 +-----------+ | +---------------+ | 197 | | | | 198 v v v v 199 +-----------+ +-----------+ +-----------+ +----------+ 200 | BGP | | BGP | | BGP |<-->| Local | 201 | Router | | Router | . . . | Router | | Consumer | 202 +-----------+ +-----------+ +-----------+ +----------+ 203 ^ ^ ^ 204 | | | 205 Local Info Local Info Local Info 206 (node & links) (node & links) (node & links) 208 Figure 1: Link State info collection 210 3.1. Peering Models 212 The peering model described above relies on the base BGP IPv4 or IPv6 213 routing underlay (e.g. as described in [RFC7938]) or any other 214 mechanism for reachability for the BGP-LS session establishment with 215 the centralized BGP speakers. A variation of this model would be to 216 setup reachability to the centralized BGP speakers (or controller) 217 over the out of band management network, where available, and for 218 each BGP router in the fabric use the same for the BGP-LS session 219 establishment with the centralized BGP speakers. This variation 220 removes the dependency between the topology learning via BGP-LS from 221 the base best effort reachability over the BGP routing in the fabric. 223 Another alternate design would be to enable BGP-LS as well on the hop 224 by hop EBGP sessions in the underlay as described in [RFC7938]. This 225 approach results in the topology information being flooded via BGP-LS 226 hop-by-hop along the BGP routers in the network. Other peering 227 designs for BGP-LS sessions may also be possible and they are not 228 precluded by this document. 230 4. Advertising BGP-only Network Topology 232 This section specifies the BGP-LS TLVs and sub-TLVs and their use for 233 advertising the topology of a BGP-only network in the form of BGP-LS 234 Node, Link and Prefix NLRIs. 236 BGP-LS [RFC7752] defines the BGP-LS NLRI types (i.e. Node NLRI, Link 237 NLRI and Prefix NLRI) along with their corresponding BGP-LS Attribute 238 (i.e. Node Attribute, Link Attribute or Prefix Attribute) and the 239 TLVs that map to the respective NLRI and Attribute for each type. 241 [I-D.ietf-idr-bgpls-segment-routing-epe] specifies the BGP Protocol 242 ID to be used for signaling BGP EPE information and the same is used 243 for advertising of BGP topology. 245 [I-D.ietf-idr-te-lsp-distribution] defines the BGP-LS NLRI that can 246 be used to advertise the RSVP-TE or Segment Routing (SR) policies 247 instantiated on a BGP Router head-end along with their corresponding 248 BGP-LS Attribute TLVs to advertise their properties and state. 250 The following sub-sections specify the use of these encodings by a 251 router running BGP protocol. 253 4.1. Node Advertisements 255 [RFC7752] defines Node NLRI Type and the Node Descriptor TLVs as 256 follows: 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+ 261 | Protocol-ID | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Identifier | 264 | (64 bits) | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 // Local Node Descriptors (variable) // 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 [I-D.ietf-idr-bgpls-segment-routing-epe] introduces additional Node 270 Descriptor TLVs for BGP protocol that are required to be used. 272 The following Node Descriptors TLVs MUST appear in the Node NLRI as 273 Local Node Descriptors: 275 o BGP Router-ID, which contains the BGP Identifier of the 276 originating BGP router 278 o Autonomous System Number, which contains the advertising router 279 ASN. 281 The BGP-LS Attribute associated with the Node NLRI MAY include the 282 following TLVs that are defined in respective documents to signal the 283 router properties and capabilities (Section 5.1 defines the 284 procedures for their advertisements): 286 +--------+--------------+-------------------------------------------+ 287 | TLV | Description | Reference Document | 288 | Code | | | 289 | Point | | | 290 +--------+--------------+-------------------------------------------+ 291 | 1026 | Node Name | [RFC7752] | 292 | 1028 | IPv4 TE | [RFC7752] | 293 | | Router-ID | | 294 | 1029 | IPv6 TE | [RFC7752] | 295 | | Router-ID | | 296 | 1161 | SID/Label | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 297 | 1034 | SRGB & | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 298 | | Capabilities | | 299 | 1035 | SR Algorithm | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 300 | 1036 | SR Local | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 301 | | Block | | 302 | 266 | Node MSD | [I-D.ietf-idr-bgp-ls-segment-routing-msd] | 303 | TBD | Flex | [I-D.ietf-idr-bgp-ls-flex-algo] | 304 | | Algorithm | | 305 | | Definition | | 306 +--------+--------------+-------------------------------------------+ 308 Table 1: Node Attribute TLVs 310 The above list of TLVs is not exhaustive but indicative as of the 311 time of writing of this document. 313 4.2. Link Advertisements 315 [RFC7752] defines Link NLRI Type and its Node and Link Descriptor 316 TLVs as follows: 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+ 321 | Protocol-ID | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Identifier | 324 | (64 bits) | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 // Local Node Descriptors (variable) // 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 // Remote Node Descriptors (variable) // 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 // Link Descriptors (variable) // 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 The following Node Descriptors TLVs MUST appear in the Link NLRI as 334 Local Node Descriptors: 336 o BGP Router-ID, which contains the BGP Identifier of the 337 originating BGP router 339 o Autonomous System Number, which contains the advertising router 340 ASN. 342 The following Node Descriptors TLVs MUST appear in the Link NLRI as 343 Remote Node Descriptors: 345 o BGP Router-ID, which contains the BGP Identifier of the peer BGP 346 router 348 o Autonomous System Number, which contains the peer ASN. 350 The following Link Descriptors TLVs MUST appear in the Link NLRI as 351 Link Descriptors: 353 o Link Local/Remote Identifiers containing the 4-octet Link Local 354 Identifier followed by the 4-octet Link Remote Identifier. The 355 value 0 MUST be used for the Link Remote Identifier when the value 356 is unknown. 358 In addition, the following Link Descriptors TLVs SHOULD appear in the 359 Link NLRI as Link Descriptors based on the address family used for 360 setting up the BGP Peering or the addresses configured on the links: 362 o IPv4 Interface Address contains the address of the local interface 363 through which the BGP session is established using IPv4 address. 365 o IPv6 Interface Address contains the address of the local interface 366 through which the BGP session is established using IPv6 address. 368 o IPv4 Neighbor Address contains the IPv4 address of the peer 369 interface used by the BGP session establishment using IPv4 370 address. 372 o IPv6 Neighbor Address contains the IPv6 address of the peer 373 interface used by the BGP session establishment using IPv6 374 address. 376 The BGP-LS Attribute associated with the Link NLRI MAY include the 377 following TLVs that are defined in respective documents to signal the 378 router's local links' properties and capabilities (Section 5.2 379 defines the procedures for their advertisements) : 381 +------+----------------+-------------------------------------------+ 382 | TLV | Description | Reference Document | 383 | Code | | | 384 | Poin | | | 385 | t | | | 386 +------+----------------+-------------------------------------------+ 387 | 1088 | Administrative | [RFC7752] | 388 | | group (color) | | 389 | 1173 | Extended | [I-D.ietf-idr-eag-distribution] | 390 | | Administrative | | 391 | | group (color) | | 392 | 1089 | Maximum link | [RFC7752] | 393 | | bandwidth | | 394 | 1092 | TE Default | [RFC7752] | 395 | | Metric | | 396 | 1096 | SRLG | [RFC7752] | 397 | 1098 | Link Name | [RFC7752] | 398 | 267 | Link MSD | [I-D.ietf-idr-bgp-ls-segment-routing-msd] | 399 | 1172 | L2 Bundle | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 400 | | Member | | 401 | 1104 | Unidirectional | [RFC8571] | 402 | | link delay | | 403 | 1105 | Min/Max | [RFC8571] | 404 | | Unidirectional | | 405 | | link delay | | 406 | 1106 | Min/Max | [RFC8571] | 407 | | Unidirectional | | 408 | | link delay | | 409 | 1107 | Unidirectional | [RFC8571] | 410 | | packet loss | | 411 | 1101 | EPE Peer Node | [I-D.ietf-idr-bgpls-segment-routing-epe] | 412 | | SID | | 413 | 1102 | EPE Peer Adj | [I-D.ietf-idr-bgpls-segment-routing-epe] | 414 | | SID | | 415 | 1103 | EPE Peer Set | [I-D.ietf-idr-bgpls-segment-routing-epe] | 416 | | SID | | 417 +------+----------------+-------------------------------------------+ 419 Table 2: Link Attribute TLVs 421 The above list of TLVs is not exhaustive but indicative as of the 422 time of writing of this document. 424 4.3. Prefix Advertisements 426 [RFC7752] defines Prefix NLRI Type and its Node and Prefix Descriptor 427 TLVs as follows: 429 0 1 2 3 430 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 431 +-+-+-+-+-+-+-+-+ 432 | Protocol-ID | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Identifier | 435 | (64 bits) | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 // Local Node Descriptors (variable) // 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 // Prefix Descriptors (variable) // 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 The following Node Descriptors TLVs MUST appear in the Prefix NLRI as 443 Local Node Descriptors: 445 o BGP Router-ID, which contains the BGP Identifier of the 446 originating BGP router 448 o Autonomous System Number, which contains the advertising router 449 ASN. 451 The Prefix Descriptor MUST contain the IP Reachability information 452 TLV to identify the prefix. 454 This document defines a new BGP Route Type TLV that MUST be included 455 in the Prefix Descriptor when the BGP node advertises the Prefix 456 NLRI. The format of this TLV is as follows: 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Type | Length | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Route Type | 464 +-+-+-+-+-+-+-+-+ 466 Where: 468 Type: 2 octet field with value TBD, see Section 7. 470 Length: 2 octet field with value set to 1. 472 Route Type: one octet with the following values defined: 474 +-----+---------------+------------------------------------------+ 475 |Value| Type | Description | 476 +-----+---------------+------------------------------------------+ 477 | 1 | Local | Local interface prefix e.g. Loopback | 478 | 2 | Attached | Directly attached node's prefix e.g host | 479 | 3 | External BGP | Prefix learnt via EBGP | 480 | 4 | Internal BGP | Prefix learnt via IBGP | 481 | 5 | Redistributed | Prefix redistributed into BGP | 482 +-------+-------------+------------------------------------------+ 484 Figure 2: BGP Route Types 486 The BGP-LS Attribute associated with the Prefix NLRI MAY include the 487 following TLVs that are defined in respective documents to signal the 488 router's own prefix properties and capabilities (Section 5.3 defines 489 the procedures for their advertisements): 491 +---------+-------------+-------------------------------------------+ 492 | TLV | Description | Reference Document | 493 | Code | | | 494 | Point | | | 495 +---------+-------------+-------------------------------------------+ 496 | 1155 | Prefix | [RFC7752] | 497 | | Metric | | 498 | 1158 | Prefix SID | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 499 +---------+-------------+-------------------------------------------+ 501 Table 3: Prefix Attribute TLVs 503 The above list of TLVs is not exhaustive but indicative as of the 504 time of writing of this document. 506 4.4. TE Policy Advertisements 508 [I-D.ietf-idr-te-lsp-distribution] defines TE Policy NLRI Type and 509 its Headend Node and TE Policy Descriptor TLVs as follows: 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+ 514 | Protocol-ID | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Identifier | 517 | (64 bits) | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 // Headend (Node Descriptors) // 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 // TE Policy Descriptors (variable) // 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 The Node Descriptors TLVs are the same as specified in Section 4.1. 525 The semantics for the TE Policy Descriptor TLVs and the TLVs 526 associated with the BGP-LS Attribute are used as specified in 527 [I-D.ietf-idr-te-lsp-distribution]. 529 5. Procedures 531 In a network where BGP is the only routing protocol, the BGP-LS 532 session is used to advertise the necessary information about the 533 local node properties, its local links' properties and where 534 necessary the prefix's owned by the node. TE Policies, that are 535 instantiated on the local node (i.e. when it is the head-end for the 536 policy), along with their properties are also advertised via the BGP- 537 LS session. This information, once collected across all BGP routers 538 in the network, provides a complete topology view of the network. 539 Many of these attributes are not part of the base BGP protocol 540 operations and are either configured or provided by other components 541 on the router. BGP-LS performs the role of collecting this 542 information and propagating it across the BGP network. 544 The following sections describe the procedures for the propagation of 545 the BGP-LS NLRIs on a BGP router into the BGP-LS session. These 546 procedures for propagation of BGP topology information via BGP-LS 547 SHOULD be applied only in deployments and use-cases where necessary 548 and SHOULD NOT be applied in every BGP deployment when BGP-LS is 549 enabled. Implementations MAY provide a configuration option to 550 enable these procedures in required deployments. 552 5.1. Advertisement of Router's Node Attributes 554 Advertisement of the Node NLRI via BGP-LS by each BGP router in a 555 BGP-only network enables the discovery of all the router nodes in the 556 topology. The Node NLRI MUST be generated by a BGP router only for 557 itself and even when there are no attributes to be advertised along 558 with it. 560 The Node attributes defined currently related to Segment Routing (SR) 561 [RFC8402] have been described in Table 1 and are to be advertised 562 when SR is enabled. This includes: 564 o All SR enabled routers support the default SR algorithm 0 and MUST 565 advertise it in the SR Algorithm TLV. Other algorithms (including 566 Flexible Algorithm [I-D.ietf-lsr-flex-algo]) SHOULD be advertised 567 when supported. 569 o The Segment Routing Global Block (SRGB) provisioned on the router 570 which is used by BGP Prefix SIDs [RFC8669] and other SR control 571 plane protocols on the router MUST be advertised. The value for 572 Flags field in the TLV is not defined for BGP protocol and MUST be 573 set to 0 by the originator and ignored by receivers. 575 o The Segment Routing Local Block (SRLB) provisioned on the router 576 which MAY be used by BGP EPE SIDs 577 [I-D.ietf-idr-bgpls-segment-routing-epe] SHOULD be advertised. 578 The value for Flags field in the TLV is not defined for BGP 579 protocol and MUST be set to 0 by the originator and ignored by 580 receivers. 582 o The Node level MSD provides the Node's capabilities for SR SID 583 operations and SHOULD be advertised. 585 o When the router supports SR Flexible Algorithms and is provisioned 586 with the Flexible Algorithm Definition (FAD), then it MUST 587 advertise the same. 589 The Node Name Attribute SHOULD be advertised when available. 591 This document introduces some of the TE concepts into BGP-only 592 networks. Provisioning of TE Router-ID with a unique address 593 normally associated with a loopback interface on the router enables 594 TE use-cases for both IPv4 and IPv6 SHOULD be supported. The BGP 595 Router-ID along with the ASN also provides the capability for 596 uniquely identifying a BGP router in the network. 598 Other Node Attributes applicable to a BGP Router may also be included 599 and this document does not describe the exhaustive list. 601 5.2. Advertisement of Router's Local Links Attributes 603 Each BGP router in a BGP-only network also advertises its local links 604 using the Link NLRIs thru BGP-LS. The Link NLRI for a given link 605 between two BGP routers is advertised as uni-directional logical 606 "half-link" and its link descriptors allow the correlation between 607 the two NLRIs "half-links" originated by the peering routers to 608 describe the bi-directional logical link and its attributes on both 609 routers. 611 The discovery of all the links and their local and remote identifiers 612 in a BGP-only network relies on the design that uses EBGP sessions 613 over each interconnecting link using the link IP addresses (refer 614 [RFC7938]). In this case, a Link NLRI MUST be generated by a BGP 615 router for each of its local link regardless of whether it has any 616 link attributes to be advertised for it. 618 When doing EBGP multi-hop sessions between directly connected BGP 619 routers, the underlying link information would need to learn by some 620 discovery protocol or provisioning entity. The mechanisms to learn 621 the underlying link information for BGP-LS advertisements are outside 622 the scope of this document. However, to provide a true link topology 623 picture, the advertisement of underlying links is RECOMMENDED for 624 most use-cases instead of a single EBGP peering representation of a 625 link between the routers using their loopback addresses. 627 The Link NLRI represents an adjacency between BGP routers and its 628 association with the underlying Layer 3 link. When the underlying 629 Layer 3 link or the BGP session on top of it goes down, the Link NLRI 630 MUST be withdrawn by the BGP router. The monitoring of links, 631 detecting of their failures and notification to BGP may be performed 632 using mechanisms like BFD. This enables faster detection of failures 633 and verification of the underlying links. 635 Advertisement of the Link NLRIs via BGP-LS by each BGP router in a 636 BGP-only network enables the discovery of all the active links in the 637 topology. 639 TE attributes for links have been traditionally associated with Link 640 State Routing protocols. However, with the ability to discover the 641 link topology via BGP-LS as specified in this document, the TE 642 attributes and their principles can also be applied to a network 643 running BGP alone. The TE attributes for a link have been described 644 in Table 2 and MAY be advertised when TE use-cases are enabled. This 645 includes: 647 o The maximum bandwidth of a link is its protocol independent 648 attribute and SHOULD be advertised. 650 o TE concepts of Administrative Groups (also known as affinities) 651 and Shared Risk Link Groups (SRLGs) MAY be provisioned locally on 652 links and then MUST be advertised. 654 o The BGP base protocol does not operate with link metrics, however, 655 a TE metric concept can be introduced in a BGP only network as 656 well for TE use-cases. Implementations MAY provide the ability to 657 provision TE metric value for a link for BGP use including a 658 different default value for it. The TE metric attribute SHOULD be 659 advertised for each link when configured and its default value is 660 taken as 100. When not advertised for a link, implementations who 661 intend to use the TE metric MUST assume the value to be 100. 663 o The delay and loss TE metrics for links are measured via MPLS 664 Performance Monitoring [RFC6374] and their measurement mechanism 665 over a link are independent of the routing protocol. The same 666 mechanism MAY be enabled in BGP-only networks and their values 667 advertised via BGP-LS. 669 The Link attributes defined currently related to the Segment Routing 670 feature BGP EPE [I-D.ietf-idr-bgpls-segment-routing-epe] have been 671 described in Table 2 and are to be advertised when SR use-cases are 672 enabled. This includes: 674 o The BGP Peering SIDs provide a functionality similar to Adjacency- 675 SID (refer [RFC8402]) in BGP-only networks. Implementations 676 SHOULD allocate the BGP Peer-Adjacency SID for all its links and 677 the BGP Peer-Node SID for all its peer routers. Implementations 678 MAY allocate the BGP Peer-Set SID based on local configuration. 680 o The Link level MSD provides the per link capabilities for SR SID 681 operations and SHOULD be advertised when the router links have 682 differing capabilities. 684 The use of Layer 3 bundle links which comprise of multiple layer 2 685 member links are often used in BGP networks. When BGP session is 686 configured over such a layer 3 link, the link attributes of the 687 underlying layer 2 links MAY be advertised individually using the L2 688 Bundle Member TLV. The applicable attributes for the L2 links are 689 described in [I-D.ietf-idr-bgp-ls-segment-routing-ext]. 691 The Link Name Attribute MAY be advertised when available. 693 Other Link Attributes applicable to a BGP Router may also be included 694 and this document does not describe the exhaustive list. 696 5.3. Advertisement of Router's Prefix Attributes 698 Advertisement of the Prefix NLRI via BGP-LS may be required only in 699 specific use-cases. Since the base BGP protocol along with its 700 extensions already signals Prefix reachability via different NLRIs, 701 there is no necessity to duplicate the information via BGP-LS 702 session. However, for specific use-cases related to SR Traffic 703 Engineering (SR-TE), it is required for each router to advertise it's 704 Prefix SID(s) (refer [RFC8402]) that can be used to direct traffic 705 via specific BGP routers. Advertising such BGP Prefix SID for every 706 BGP router provides this key attribute via BGP-LS and avoids the 707 requirement for the consumer of the topology information (e.g. a 708 controller or local TE process) to tap into other BGP NLRI 709 information. 711 Advertisement of the Prefix NLRI via BGP-LS MUST be done for its 712 locally configured prefixes (e.g. its loopback interface address) and 713 when BGP is advertising the BGP Prefix SID ([RFC8669]) for it. The 714 advertisement of the Prefix NLRI via BGP-LS for other prefixes learnt 715 by the router MAY be done based on the specific use-case requirement 716 and the BGP Route Type as described in Figure 2 indicates the type of 717 route being advertised. 719 The Prefix attributes defined currently related to SR [RFC8402] have 720 been described in Table 3 and MAY be advertised when SR is enabled. 721 This includes: 723 o The Prefix SID TLV is included with the SID advertised as the 724 index to be consistent with the Label-Index TLV of BGP Prefix SID 725 attribute. The default algorithm is MUST be set to 0 by the 726 originator except in the case where a local prefix is associated 727 with a specific SR Algorithm. The flags are defined as the most 728 significant 8 bits of the 16 bit field defined for Label-Index TLV 729 in [RFC8669]. 731 o For certain SR-TE uses, the Prefix Metric value MAY be included 732 and it is set based on the SR-TE computation based on the link- 733 state topology learnt via BGP-LS. 735 Other Prefix Attributes applicable may also be included and this 736 document does not describe the exhaustive list. 738 5.4. Advertisement of Router's TE Policy Attributes 740 TE Policies that are setup using RSVP-TE or SR-TE mechanisms MAY be 741 instantiated on a BGP router. One use-case that results in such SR 742 Policy instantiation on a BGP router is described later in this 743 document in Section 6.2. Advertising such TE Policies instantiated 744 for every BGP router as head-end via BGP-LS provides the consumer of 745 the topology information (e.g. a controller or local TE process) a 746 policy view of the BGP fabric as well. 748 The procedures for advertisement of the TE Policy NLRI via BGP-LS 749 MUST be done only for its locally instantiated TE Policies and as 750 specified in [I-D.ietf-idr-te-lsp-distribution]). Implementation MAY 751 provide configuration options to control the specific set of TE 752 Policies that are to be advertised from the local node. 754 6. Usage of BGP Topology 756 This section describes some of the use-cases for the building of the 757 BGP topology information as specified in this document and leveraging 758 it for enabling new functionality. 760 6.1. Topology View for Monitoring 762 The BGP-LS advertisement of the BGP topology as specified in this 763 document provides a live topology view of the BGP network for an 764 application or controller that is monitoring the network. The 765 topology view is from the BGP protocol perspective and includes the 766 underlying links as well that aids in network monitoring as well as 767 diagnostics use-cases. BGP-LS is the de-facto protocol for 768 northbound propagation of network topology related information for 769 most IGP networks and extending this capability for BGP-only networks 770 allows existing controllers and applications to consume the 771 information with some incremental BGP protocol awareness. 773 6.2. SR-TE in BGP Networks 775 The SR-TE use-case for BGP builds on top of functionality specified 776 in [RFC8669] and also described in [RFC8670].The BGP SR Prefix SID 777 signaled, provides the basic connectivity between all BGP routers 778 using their loopback addresses. This provides the basic best-effort 779 paths in the network using the base BGP decision process that is 780 unchanged. BGP and other overlay routes and services recurse on top 781 of these loopback addresses of the egress nodes and the forwarding is 782 done via the BGP SR Prefix SID labels in the underlay. While this 783 version of the document focuses on the examples with MPLS dataplane 784 instantiation for SR, the same is applicable for the IPv6 dataplane 785 instantiation (SRv6) as well. 787 SR-TE for BGP provides underlay paths through the network for the 788 overlay routes and services with specific SLA requirements and use- 789 cases like path disjointness, low latency paths, inclusion or 790 exclusion and other TE considerations. 792 [I-D.ietf-spring-segment-routing-policy] specifies the SR-TE 793 architecture and the SR Policy construct. 794 [I-D.ietf-idr-segment-routing-te-policy] describes the extensions to 795 BGP for signaling of SR Policies from a controller to the SR-TE 796 headend BGP router. BGP-LS has been extended to allow signaling of 797 the SR Policies from SR-TE head-end to controllers via 798 [I-D.ietf-idr-te-lsp-distribution] which allows the controllers to 799 learn the state of SR Policies instantiated on routers in the 800 network. This document completes the missing piece that is related 801 to getting the BGP topology information from all the routers to a 802 controller as well the local SRTE process on each router for their 803 path computation requirements. 805 The signaling of SR Polices from controller to SR-TE headend and 806 reporting of the state back to the controller can also be done using 807 PCEP ([RFC8664], [RFC8281], [RFC8231]). However, the BGP topology 808 learning via BGP-LS which is specified in this document is also 809 required for the deployments that uses PCEP in the BGP-only network. 811 The topology collected via BGP-LS in a BGP-only fabric in a Segment 812 Routing deployment comprise of: 814 o The properties of every BGP router node and the Prefix SIDs to 815 reach that node. 817 o The properties of all the links between the BGP routers and the 818 Peer-Adjacency-SIDs (and other EPE SIDs) corresponding to them 819 that allow directing traffic over specific links and/or to 820 specific neighbors. 822 o The properties and state of the SR Policies instantiatied on each 823 of the BGP routers along with their end points, their properties 824 and most importantly the Binding SID to steer traffic into the SR 825 Policies. 827 This topology information allows a computation node to build SR 828 Policies for services over the BGP fabric for a given traffic 829 engineering objective at any given node. 831 The topology of the BGP fabric is advertised to a centralized 832 controller or application for use-cases that need a centralized 833 computation of SR Policy which can then be signaled to the SR-TE 834 head-end node via PCEP or BGP-SRTE. The topology may also be 835 distributed to any node in the BGP fabric to be used by its local SR- 836 TE process to perform path computation for its own SR Policies for 837 use-cases that are addressed by local computation. 839 A high level summary of the key topology information advertised via 840 BGP-LS by BGP routers can be used for TE computations as follows 842 o The BGP SR Prefix SIDs and the BGP EPE Peering Adjacency SIDs 843 provide the equivalent of the IGP Prefix and Adjacency SIDs and 844 can be used to direct traffic to a specific BGP router and over a 845 specific BGP peer session or link respectively. Traffic for the 846 BGP SR Prefix SIDs follow the path computed by the BGP decision 847 process. 849 o The TE metric can be used to tailor the choice of specific paths 850 in the network for SR-TE. 852 o The TE administrative group (also known as affinities) and SRLG 853 attributes can be configured over links to enable computation of 854 paths with inclusion and exclusion of specific links or paths that 855 are mutually disjoint. 857 o The enabling of link delay and loss measurements and their 858 advertisements can help monitoring the link quality and carve out 859 paths based on latency and other SLA requirements. 861 o The signaling of the Node and Link MSD allows controllers to 862 instantiate SR Policies based on the capability of the routers. 864 This section attempts to highlight and describe at a high level some 865 of the possible SR-TE solutions and use-cases in a BGP-only network. 866 The actual SR-TE computation and algorithms are outside the scope of 867 this document. 869 7. IANA Considerations 871 IANA maintains a registry called "Border Gateway Protocol - Link 872 State (BGP-LS) Parameters" with a sub-registry called "Node Anchor, 873 Link Descriptor and Link Attribute TLVs". 875 The following TLV codepoints are suggested (to be assigned by IANA): 877 +----------+----------------------------------------+---------------+ 878 | TLV Code | Description | Value defined | 879 | Point | | in | 880 +----------+----------------------------------------+---------------+ 881 | TBD | BGP Route Type TLV | this document | 882 +----------+----------------------------------------+---------------+ 884 8. Manageability Considerations 886 This section is structured as recommended in [RFC5706]. 888 8.1. Operational Considerations 890 8.1.1. Operations 892 Existing BGP and BGP-LS operational procedures apply. No additional 893 operation procedures are defined in this document. 895 9. Security Considerations 897 Procedures and protocol extensions defined in this document do not 898 affect the BGP security model. See the 'Security Considerations' 899 section of [RFC4271] for a discussion of BGP security. Also refer to 900 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 902 10. Acknowledgements 904 The authors would like to thank Bruno Decraene for his review and 905 comments on this document. 907 11. References 909 11.1. Normative References 911 [I-D.ietf-idr-bgp-ls-flex-algo] 912 Talaulikar, K., Psenak, P., Zandi, S., and G. Dawra, 913 "Flexible Algorithm Definition Advertisement with BGP 914 Link-State", draft-ietf-idr-bgp-ls-flex-algo-02 (work in 915 progress), January 2020. 917 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 918 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 919 and M. Chen, "BGP Link-State extensions for Segment 920 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 921 (work in progress), June 2019. 923 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 924 Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., 925 and N. Triantafillis, "Signaling MSD (Maximum SID Depth) 926 using Border Gateway Protocol - Link State", draft-ietf- 927 idr-bgp-ls-segment-routing-msd-15 (work in progress), 928 March 2020. 930 [I-D.ietf-idr-bgpls-segment-routing-epe] 931 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 932 S., and J. Dong, "BGP-LS extensions for Segment Routing 933 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 934 segment-routing-epe-19 (work in progress), May 2019. 936 [I-D.ietf-idr-eag-distribution] 937 Wang, Z., WU, Q., Tantsura, J., and K. Talaulikar, 938 "Distribution of Traffic Engineering Extended Admin Groups 939 using BGP-LS", draft-ietf-idr-eag-distribution-11 (work in 940 progress), November 2019. 942 [I-D.ietf-idr-te-lsp-distribution] 943 Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler, 944 H., and J. Tantsura, "Distribution of Traffic Engineering 945 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 946 lsp-distribution-12 (work in progress), October 2019. 948 [I-D.ietf-lsr-flex-algo] 949 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 950 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 951 algo-06 (work in progress), February 2020. 953 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 954 Requirement Levels", BCP 14, RFC 2119, 955 DOI 10.17487/RFC2119, March 1997, 956 . 958 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 959 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 960 DOI 10.17487/RFC4271, January 2006, 961 . 963 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 964 S. Ray, "North-Bound Distribution of Link-State and 965 Traffic Engineering (TE) Information Using BGP", RFC 7752, 966 DOI 10.17487/RFC7752, March 2016, 967 . 969 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 970 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 971 May 2017, . 973 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 974 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 975 IGP Traffic Engineering Performance Metric Extensions", 976 RFC 8571, DOI 10.17487/RFC8571, March 2019, 977 . 979 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 980 A., and H. Gredler, "Segment Routing Prefix Segment 981 Identifier Extensions for BGP", RFC 8669, 982 DOI 10.17487/RFC8669, December 2019, 983 . 985 11.2. Informative References 987 [I-D.ietf-idr-segment-routing-te-policy] 988 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 989 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 990 Routing Policies in BGP", draft-ietf-idr-segment-routing- 991 te-policy-08 (work in progress), November 2019. 993 [I-D.ietf-spring-segment-routing-central-epe] 994 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 995 Afanasiev, "Segment Routing Centralized BGP Egress Peer 996 Engineering", draft-ietf-spring-segment-routing-central- 997 epe-10 (work in progress), December 2017. 999 [I-D.ietf-spring-segment-routing-policy] 1000 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 1001 P. Mattes, "Segment Routing Policy Architecture", draft- 1002 ietf-spring-segment-routing-policy-06 (work in progress), 1003 December 2019. 1005 [I-D.xu-idr-neighbor-autodiscovery] 1006 Xu, X., Talaulikar, K., Bi, K., Tantsura, J., and N. 1007 Triantafillis, "BGP Neighbor Discovery", draft-xu-idr- 1008 neighbor-autodiscovery-12 (work in progress), November 1009 2019. 1011 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1012 DOI 10.17487/RFC2328, April 1998, 1013 . 1015 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1016 (TE) Extensions to OSPF Version 2", RFC 3630, 1017 DOI 10.17487/RFC3630, September 2003, 1018 . 1020 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1021 RFC 4272, DOI 10.17487/RFC4272, January 2006, 1022 . 1024 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 1025 Management of New Protocols and Protocol Extensions", 1026 RFC 5706, DOI 10.17487/RFC5706, November 2009, 1027 . 1029 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1030 Measurement for MPLS Networks", RFC 6374, 1031 DOI 10.17487/RFC6374, September 2011, 1032 . 1034 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1035 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1036 and Authentication for Routing Protocols (KARP) Design 1037 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1038 . 1040 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 1041 BGP for Routing in Large-Scale Data Centers", RFC 7938, 1042 DOI 10.17487/RFC7938, August 2016, 1043 . 1045 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1046 Computation Element Communication Protocol (PCEP) 1047 Extensions for Stateful PCE", RFC 8231, 1048 DOI 10.17487/RFC8231, September 2017, 1049 . 1051 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1052 Computation Element Communication Protocol (PCEP) 1053 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1054 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1055 . 1057 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1058 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1059 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1060 July 2018, . 1062 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1063 and J. Hardwick, "Path Computation Element Communication 1064 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1065 DOI 10.17487/RFC8664, December 2019, 1066 . 1068 [RFC8670] Filsfils, C., Ed., Previdi, S., Dawra, G., Aries, E., and 1069 P. Lapukhov, "BGP Prefix Segment in Large-Scale Data 1070 Centers", RFC 8670, DOI 10.17487/RFC8670, December 2019, 1071 . 1073 Authors' Addresses 1075 Ketan Talaulikar 1076 Cisco Systems 1077 Pune 411057 1078 India 1080 Email: ketant@cisco.com 1082 Clarence Filsfils 1083 Cisco Systems 1084 Brussels 1085 Belgium 1087 Email: cfilsfil@cisco.com 1089 Krishna Swamy 1090 Cisco Systems 1091 San Jose 1092 USA 1094 Email: kriswamy@cisco.com 1096 Shawn Zandi 1097 LinkedIn 1098 USA 1100 Email: szandi@linkedin.com 1102 Gaurav Dawra 1103 LinkedIn 1104 USA 1106 Email: gdawra.ietf@gmail.com 1108 Muhammad Durrani 1109 Equinix 1110 USA 1112 Email: mdurrani@equinix.com