idnits 2.17.1 draft-ietf-idr-bgp-ls-bgp-only-fabric-01.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 (September 13, 2021) is 955 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-07 == Outdated reference: A later version (-19) exists of draft-ietf-idr-te-lsp-distribution-15 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-17 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-13 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-13 Summary: 1 error (**), 0 flaws (~~), 6 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: March 17, 2022 Cisco Systems 6 S. Zandi 7 G. Dawra 8 LinkedIn 9 M. Durrani 10 Equinix 11 September 13, 2021 13 BGP Link-State Extensions for BGP-only Fabric 14 draft-ietf-idr-bgp-ls-bgp-only-fabric-01 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 March 17, 2022. 48 Copyright Notice 50 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . 11 75 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 5.1. Advertisement of Router's Node Attributes . . . . . . . . 12 77 5.2. Advertisement of Router's Local Links Attributes . . . . 13 78 5.3. Advertisement of Router's Prefix Attributes . . . . . . . 15 79 5.4. Advertisement of Router's TE Policy Attributes . . . . . 16 80 6. Usage of BGP Topology . . . . . . . . . . . . . . . . . . . . 17 81 6.1. Topology View for Monitoring . . . . . . . . . . . . . . 17 82 6.2. SR-TE in BGP Networks . . . . . . . . . . . . . . . . . . 17 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 8. Manageability Considerations . . . . . . . . . . . . . . . . 19 85 8.1. Operational Considerations . . . . . . . . . . . . . . . 19 86 8.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 20 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 91 11.2. Informative References . . . . . . . . . . . . . . . . . 22 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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 [RFC9087] are specified in 113 [RFC9086]. This document leverages the BGP-LS TLVs defined for BGP- 114 LS EPE and other BGP-LS documents and specifies the procedures for 115 advertising the underlying topology in a more generic BGP-only fabric 116 use-case. 118 This document specifies the operations and procedures when using the 119 design involving BGP use for hop-by-hop routing between directly 120 connected network nodes (refer [RFC7938] for details). 122 1.1. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 2. BGP Routing in the Fabric 132 This document does not change base BGP routing protocol operations in 133 the fabric that provides routing using the BGP best path selection 134 process [RFC4271] . 136 The applicability of this specification is limited to those 137 deployments where BGP is used as hop-by-hop routing protocol between 138 directly connected nodes in the fabric. While a data-center design 139 [RFC7938] is used as a reference, the topology advertisement and its 140 use for computation may also apply to other networks with BGP-only 141 fabric or to BGP-only portions of a larger network topology. 143 BGP hop-by-hop routing can be setup using EBGP single-hop sessions 144 over individual links between directly connected routers using their 145 link addresses for peering as described in [RFC7938]. In such a 146 design, the neighbors' link addresses may be provisioned for peering 147 and the EBGP session operating directly over the link performs the 148 monitoring of the neighbor on that link. A variation of this design 149 would be that the EBGP session is setup between directly connected 150 routers using their loopback sessions. The mechanisms for discovery 151 of the neighbor's link addresses and their monitoring on a per link 152 basis are outside the scope of this document. 153 [I-D.xu-idr-neighbor-autodiscovery] describes one such mechanism and 154 the same may be also realized by other means. 156 Though this document uses the EBGP based design as a reference, it 157 does not preclude other alternate designs using IBGP. 159 3. Topology Collection Mechanism 161 BGP-LS [RFC7752] has been defined to allow BGP to convey topology 162 information in the form of Link-State objects - node, link and 163 prefix. The properties of each of these objects are encoded using 164 BGP-LS Attribute TLVs. Applications need a topological view and 165 visibility even for networks where BGP is the only routing protocol. 166 In such networks, each BGP router advertises its local information 167 which includes its node, links and prefix attributes via BGP-LS. 169 Figure 1 describes a typical deployment scenario. Every BGP router 170 in the network is enabled for BGP-LS and forms BGP-LS sessions with 171 one or more centralized BGP-LS speakers over which it sends its local 172 topology information. Each BGP router MAY also receive the topology 173 information from all other BGP routers via these centralized BGP-LS 174 speakers. This way, any BGP router (as also the centralized BGP-LS 175 speakers) MAY obtain aggregated Link-State information for the entire 176 BGP network. An external component (e.g. a controller) can obtain 177 this information from the centralized BGP-LS speakers or directly by 178 doing BGP-LS peering to the BGP routers. An internal software 179 component on any of the BGP routers (e.g. TE module) can also 180 receive the entire BGP network topology information from its local 181 BGP process. 183 +------------+ 184 | Controller | 185 +------------+ 186 ^ 187 | 188 v 189 +-------------------+ 190 | BGP-LS Speaker | +------------+ 191 | (Centralized) | | Controller | 192 +-------------------+ +------------+ 193 ^ ^ ^ ^ 194 | | | | 195 +-----------+ | +---------------+ | 196 | | | | 197 v v v v 198 +-----------+ +-----------+ +-----------+ +----------+ 199 | BGP | | BGP | | BGP |<-->| Local | 200 | Router | | Router | . . . | Router | | Consumer | 201 +-----------+ +-----------+ +-----------+ +----------+ 202 ^ ^ ^ 203 | | | 204 Local Info Local Info Local Info 205 (node & links) (node & links) (node & links) 207 Figure 1: Link State info collection 209 3.1. Peering Models 211 The peering model described above relies on the base BGP IPv4 or IPv6 212 routing underlay (e.g. as described in [RFC7938]) or any other 213 mechanism for reachability for the BGP-LS session establishment with 214 the centralized BGP speakers. A variation of this model would be to 215 setup reachability to the centralized BGP speakers (or controller) 216 over the out of band management network, where available, and for 217 each BGP router in the fabric use the same for the BGP-LS session 218 establishment with the centralized BGP speakers. This variation 219 removes the dependency between the topology learning via BGP-LS from 220 the base best effort reachability over the BGP routing in the fabric. 222 Another alternate design would be to enable BGP-LS as well on the hop 223 by hop EBGP sessions in the underlay as described in [RFC7938]. This 224 approach results in the topology information being flooded via BGP-LS 225 hop-by-hop along the BGP routers in the network. Other peering 226 designs for BGP-LS sessions may also be possible and they are not 227 precluded by this document. 229 4. Advertising BGP-only Network Topology 231 This section specifies the BGP-LS TLVs and sub-TLVs and their use for 232 advertising the topology of a BGP-only network in the form of BGP-LS 233 Node, Link and Prefix NLRIs. 235 BGP-LS [RFC7752] defines the BGP-LS NLRI types (i.e. Node NLRI, Link 236 NLRI and Prefix NLRI) along with their corresponding BGP-LS Attribute 237 (i.e. Node Attribute, Link Attribute or Prefix Attribute) and the 238 TLVs that map to the respective NLRI and Attribute for each type. 240 [RFC9086] specifies the BGP Protocol ID to be used for signaling BGP 241 EPE information and the same is used for advertising of BGP topology. 243 [I-D.ietf-idr-te-lsp-distribution] defines the BGP-LS NLRI that can 244 be used to advertise the RSVP-TE or Segment Routing (SR) policies 245 instantiated on a BGP Router head-end along with their corresponding 246 BGP-LS Attribute TLVs to advertise their properties and state. 248 The following sub-sections specify the use of these encodings by a 249 router running BGP protocol. 251 4.1. Node Advertisements 253 [RFC7752] defines Node NLRI Type and the Node Descriptor TLVs as 254 follows: 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+ 259 | Protocol-ID | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Identifier | 262 | (64 bits) | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 // Local Node Descriptors (variable) // 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 [RFC9086] introduces additional Node Descriptor TLVs for BGP protocol 268 that are required to be used. 270 The following Node Descriptors TLVs MUST appear in the Node NLRI as 271 Local Node Descriptors: 273 o BGP Router-ID, which contains the BGP Identifier of the 274 originating BGP router 276 o Autonomous System Number, which contains the advertising router 277 ASN. 279 The BGP-LS Attribute associated with the Node NLRI MAY include the 280 following TLVs that are defined in respective documents to signal the 281 router properties and capabilities (Section 5.1 defines the 282 procedures for their advertisements): 284 +------------+--------------------+---------------------------------+ 285 | TLV Code | Description | Reference Document | 286 | Point | | | 287 +------------+--------------------+---------------------------------+ 288 | 1026 | Node Name | [RFC7752] | 289 | 1028 | IPv4 TE Router-ID | [RFC7752] | 290 | 1029 | IPv6 TE Router-ID | [RFC7752] | 291 | 1161 | SID/Label | [RFC9085] | 292 | 1034 | SRGB & | [RFC9085] | 293 | | Capabilities | | 294 | 1035 | SR Algorithm | [RFC9085] | 295 | 1036 | SR Local Block | [RFC9085] | 296 | 266 | Node MSD | [RFC8814] | 297 | TBD | Flex Algorithm | [I-D.ietf-idr-bgp-ls-flex-algo] | 298 | | Definition | | 299 +------------+--------------------+---------------------------------+ 301 Table 1: Node Attribute TLVs 303 The above list of TLVs is not exhaustive but indicative as of the 304 time of writing of this document. 306 4.2. Link Advertisements 308 [RFC7752] defines Link NLRI Type and its Node and Link Descriptor 309 TLVs as follows: 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+ 314 | Protocol-ID | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Identifier | 317 | (64 bits) | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 // Local Node Descriptors (variable) // 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 // Remote Node Descriptors (variable) // 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 // Link Descriptors (variable) // 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 The following Node Descriptors TLVs MUST appear in the Link NLRI as 327 Local Node Descriptors: 329 o BGP Router-ID, which contains the BGP Identifier of the 330 originating BGP router 332 o Autonomous System Number, which contains the advertising router 333 ASN. 335 The following Node Descriptors TLVs MUST appear in the Link NLRI as 336 Remote Node Descriptors: 338 o BGP Router-ID, which contains the BGP Identifier of the peer BGP 339 router 341 o Autonomous System Number, which contains the peer ASN. 343 The following Link Descriptors TLVs MUST appear in the Link NLRI as 344 Link Descriptors: 346 o Link Local/Remote Identifiers containing the 4-octet Link Local 347 Identifier followed by the 4-octet Link Remote Identifier. The 348 value 0 MUST be used for the Link Remote Identifier when the value 349 is unknown. 351 In addition, the following Link Descriptors TLVs SHOULD appear in the 352 Link NLRI as Link Descriptors based on the address family used for 353 setting up the BGP Peering or the addresses configured on the links: 355 o IPv4 Interface Address contains the address of the local interface 356 through which the BGP session is established using IPv4 address. 358 o IPv6 Interface Address contains the address of the local interface 359 through which the BGP session is established using IPv6 address. 361 o IPv4 Neighbor Address contains the IPv4 address of the peer 362 interface used by the BGP session establishment using IPv4 363 address. 365 o IPv6 Neighbor Address contains the IPv6 address of the peer 366 interface used by the BGP session establishment using IPv6 367 address. 369 The BGP-LS Attribute associated with the Link NLRI MAY include the 370 following TLVs that are defined in respective documents to signal the 371 router's local links' properties and capabilities (Section 5.2 372 defines the procedures for their advertisements) : 374 +--------------+---------------------------------+------------------+ 375 | TLV Code | Description | Reference | 376 | Point | | Document | 377 +--------------+---------------------------------+------------------+ 378 | 1088 | Administrative group (color) | [RFC7752] | 379 | 1173 | Extended Administrative group | [RFC9104] | 380 | | (color) | | 381 | 1089 | Maximum link bandwidth | [RFC7752] | 382 | 1092 | TE Default Metric | [RFC7752] | 383 | 1096 | SRLG | [RFC7752] | 384 | 1098 | Link Name | [RFC7752] | 385 | 267 | Link MSD | [RFC8814] | 386 | 1172 | L2 Bundle Member | [RFC9085] | 387 | 1104 | Unidirectional link delay | [RFC8571] | 388 | 1105 | Min/Max Unidirectional link | [RFC8571] | 389 | | delay | | 390 | 1106 | Min/Max Unidirectional link | [RFC8571] | 391 | | delay | | 392 | 1107 | Unidirectional packet loss | [RFC8571] | 393 | 1101 | EPE Peer Node SID | [RFC9086] | 394 | 1102 | EPE Peer Adj SID | [RFC9086] | 395 | 1103 | EPE Peer Set SID | [RFC9086] | 396 +--------------+---------------------------------+------------------+ 398 Table 2: Link Attribute TLVs 400 The above list of TLVs is not exhaustive but indicative as of the 401 time of writing of this document. 403 4.3. Prefix Advertisements 405 [RFC7752] defines Prefix NLRI Type and its Node and Prefix Descriptor 406 TLVs as follows: 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+ 411 | Protocol-ID | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Identifier | 414 | (64 bits) | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 // Local Node Descriptors (variable) // 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 // Prefix Descriptors (variable) // 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 The following Node Descriptors TLVs MUST appear in the Prefix NLRI as 422 Local Node Descriptors: 424 o BGP Router-ID, which contains the BGP Identifier of the 425 originating BGP router 427 o Autonomous System Number, which contains the advertising router 428 ASN. 430 The Prefix Descriptor MUST contain the IP Reachability information 431 TLV to identify the prefix. 433 This document defines a new BGP Route Type TLV that MUST be included 434 in the Prefix Descriptor when the BGP node advertises the Prefix 435 NLRI. The format of this TLV is as follows: 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Type | Length | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Route Type | 443 +-+-+-+-+-+-+-+-+ 445 Where: 447 Type: 2 octet field with value TBD, see Section 7. 449 Length: 2 octet field with value set to 1. 451 Route Type: one octet with the following values defined: 453 +-----+---------------+------------------------------------------+ 454 |Value| Type | Description | 455 +-----+---------------+------------------------------------------+ 456 | 1 | Local | Local interface prefix e.g. Loopback | 457 | 2 | Attached | Directly attached node's prefix e.g host | 458 | 3 | External BGP | Prefix learnt via EBGP | 459 | 4 | Internal BGP | Prefix learnt via IBGP | 460 | 5 | Redistributed | Prefix redistributed into BGP | 461 +-------+-------------+------------------------------------------+ 463 Figure 2: BGP Route Types 465 The BGP-LS Attribute associated with the Prefix NLRI MAY include the 466 following TLVs that are defined in respective documents to signal the 467 router's own prefix properties and capabilities (Section 5.3 defines 468 the procedures for their advertisements): 470 +----------------+---------------+--------------------+ 471 | TLV Code Point | Description | Reference Document | 472 +----------------+---------------+--------------------+ 473 | 1155 | Prefix Metric | [RFC7752] | 474 | 1158 | Prefix SID | [RFC9085] | 475 +----------------+---------------+--------------------+ 477 Table 3: Prefix Attribute TLVs 479 The above list of TLVs is not exhaustive but indicative as of the 480 time of writing of this document. 482 4.4. TE Policy Advertisements 484 [I-D.ietf-idr-te-lsp-distribution] defines TE Policy NLRI Type and 485 its Headend Node and TE Policy Descriptor TLVs as follows: 487 0 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+ 490 | Protocol-ID | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Identifier | 493 | (64 bits) | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 // Headend (Node Descriptors) // 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 // TE Policy Descriptors (variable) // 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 The Node Descriptors TLVs are the same as specified in Section 4.1. 501 The semantics for the TE Policy Descriptor TLVs and the TLVs 502 associated with the BGP-LS Attribute are used as specified in 503 [I-D.ietf-idr-te-lsp-distribution]. 505 5. Procedures 507 In a network where BGP is the only routing protocol, the BGP-LS 508 session is used to advertise the necessary information about the 509 local node properties, its local links' properties and where 510 necessary the prefix's owned by the node. TE Policies, that are 511 instantiated on the local node (i.e. when it is the head-end for the 512 policy), along with their properties are also advertised via the BGP- 513 LS session. This information, once collected across all BGP routers 514 in the network, provides a complete topology view of the network. 515 Many of these attributes are not part of the base BGP protocol 516 operations and are either configured or provided by other components 517 on the router. BGP-LS performs the role of collecting this 518 information and propagating it across the BGP network. 520 The following sections describe the procedures for the propagation of 521 the BGP-LS NLRIs on a BGP router into the BGP-LS session. These 522 procedures for propagation of BGP topology information via BGP-LS 523 SHOULD be applied only in deployments and use-cases where necessary 524 and SHOULD NOT be applied in every BGP deployment when BGP-LS is 525 enabled. Implementations MAY provide a configuration option to 526 enable these procedures in required deployments. 528 5.1. Advertisement of Router's Node Attributes 530 Advertisement of the Node NLRI via BGP-LS by each BGP router in a 531 BGP-only network enables the discovery of all the router nodes in the 532 topology. The Node NLRI MUST be generated by a BGP router only for 533 itself and even when there are no attributes to be advertised along 534 with it. 536 The Node attributes defined currently related to Segment Routing (SR) 537 [RFC8402] have been described in Table 1 and are to be advertised 538 when SR is enabled. This includes: 540 o All SR enabled routers support the default SR algorithm 0 and MUST 541 advertise it in the SR Algorithm TLV. Other algorithms (including 542 Flexible Algorithm [I-D.ietf-lsr-flex-algo]) SHOULD be advertised 543 when supported. 545 o The Segment Routing Global Block (SRGB) provisioned on the router 546 which is used by BGP Prefix SIDs [RFC8669] and other SR control 547 plane protocols on the router MUST be advertised. The value for 548 Flags field in the TLV is not defined for BGP protocol and MUST be 549 set to 0 by the originator and ignored by receivers. 551 o The Segment Routing Local Block (SRLB) provisioned on the router 552 which MAY be used by BGP EPE SIDs [RFC9086] SHOULD be advertised. 553 The value for Flags field in the TLV is not defined for BGP 554 protocol and MUST be set to 0 by the originator and ignored by 555 receivers. 557 o The Node level MSD provides the Node's capabilities for SR SID 558 operations and SHOULD be advertised. 560 o When the router supports SR Flexible Algorithms and is provisioned 561 with the Flexible Algorithm Definition (FAD), then it MUST 562 advertise the same. 564 The Node Name Attribute SHOULD be advertised when available. 566 This document introduces some of the TE concepts into BGP-only 567 networks. Provisioning of TE Router-ID with a unique address 568 normally associated with a loopback interface on the router enables 569 TE use-cases for both IPv4 and IPv6 SHOULD be supported. The BGP 570 Router-ID along with the ASN also provides the capability for 571 uniquely identifying a BGP router in the network. 573 Other Node Attributes applicable to a BGP Router may also be included 574 and this document does not describe the exhaustive list. 576 5.2. Advertisement of Router's Local Links Attributes 578 Each BGP router in a BGP-only network also advertises its local links 579 using the Link NLRIs thru BGP-LS. The Link NLRI for a given link 580 between two BGP routers is advertised as uni-directional logical 581 "half-link" and its link descriptors allow the correlation between 582 the two NLRIs "half-links" originated by the peering routers to 583 describe the bi-directional logical link and its attributes on both 584 routers. 586 The discovery of all the links and their local and remote identifiers 587 in a BGP-only network relies on the design that uses EBGP sessions 588 over each interconnecting link using the link IP addresses (refer 589 [RFC7938]). In this case, a Link NLRI MUST be generated by a BGP 590 router for each of its local link regardless of whether it has any 591 link attributes to be advertised for it. 593 When doing EBGP multi-hop sessions between directly connected BGP 594 routers, the underlying link information would need to learn by some 595 discovery protocol or provisioning entity. The mechanisms to learn 596 the underlying link information for BGP-LS advertisements are outside 597 the scope of this document. However, to provide a true link topology 598 picture, the advertisement of underlying links is RECOMMENDED for 599 most use-cases instead of a single EBGP peering representation of a 600 link between the routers using their loopback addresses. 602 The Link NLRI represents an adjacency between BGP routers and its 603 association with the underlying Layer 3 link. When the underlying 604 Layer 3 link or the BGP session on top of it goes down, the Link NLRI 605 MUST be withdrawn by the BGP router. The monitoring of links, 606 detecting of their failures and notification to BGP may be performed 607 using mechanisms like BFD. This enables faster detection of failures 608 and verification of the underlying links. 610 Advertisement of the Link NLRIs via BGP-LS by each BGP router in a 611 BGP-only network enables the discovery of all the active links in the 612 topology. 614 TE attributes for links have been traditionally associated with Link 615 State Routing protocols. However, with the ability to discover the 616 link topology via BGP-LS as specified in this document, the TE 617 attributes and their principles can also be applied to a network 618 running BGP alone. The TE attributes for a link have been described 619 in Table 2 and MAY be advertised when TE use-cases are enabled. This 620 includes: 622 o The maximum bandwidth of a link is its protocol independent 623 attribute and SHOULD be advertised. 625 o TE concepts of Administrative Groups (also known as affinities) 626 and Shared Risk Link Groups (SRLGs) MAY be provisioned locally on 627 links and then MUST be advertised. 629 o The BGP base protocol does not operate with link metrics, however, 630 a TE metric concept can be introduced in a BGP only network as 631 well for TE use-cases. Implementations MAY provide the ability to 632 provision TE metric value for a link for BGP use including a 633 different default value for it. The TE metric attribute SHOULD be 634 advertised for each link when configured and its default value is 635 taken as 100. When not advertised for a link, implementations who 636 intend to use the TE metric MUST assume the value to be 100. 638 o The delay and loss TE metrics for links are measured via MPLS 639 Performance Monitoring [RFC6374] and their measurement mechanism 640 over a link are independent of the routing protocol. The same 641 mechanism MAY be enabled in BGP-only networks and their values 642 advertised via BGP-LS. 644 The Link attributes defined currently related to the Segment Routing 645 feature BGP EPE [RFC9086] have been described in Table 2 and are to 646 be advertised when SR use-cases are enabled. This includes: 648 o The BGP Peering SIDs provide a functionality similar to Adjacency- 649 SID (refer [RFC8402]) in BGP-only networks. Implementations 650 SHOULD allocate the BGP Peer-Adjacency SID for all its links and 651 the BGP Peer-Node SID for all its peer routers. Implementations 652 MAY allocate the BGP Peer-Set SID based on local configuration. 654 o The Link level MSD provides the per link capabilities for SR SID 655 operations and SHOULD be advertised when the router links have 656 differing capabilities. 658 The use of Layer 3 bundle links which comprise of multiple layer 2 659 member links are often used in BGP networks. When BGP session is 660 configured over such a layer 3 link, the link attributes of the 661 underlying layer 2 links MAY be advertised individually using the L2 662 Bundle Member TLV. The applicable attributes for the L2 links are 663 described in [RFC9085]. 665 The Link Name Attribute MAY be advertised when available. 667 Other Link Attributes applicable to a BGP Router may also be included 668 and this document does not describe the exhaustive list. 670 5.3. Advertisement of Router's Prefix Attributes 672 Advertisement of the Prefix NLRI via BGP-LS may be required only in 673 specific use-cases. Since the base BGP protocol along with its 674 extensions already signals Prefix reachability via different NLRIs, 675 there is no necessity to duplicate the information via BGP-LS 676 session. However, for specific use-cases related to SR Traffic 677 Engineering (SR-TE), it is required for each router to advertise it's 678 Prefix SID(s) (refer [RFC8402]) that can be used to direct traffic 679 via specific BGP routers. Advertising such BGP Prefix SID for every 680 BGP router provides this key attribute via BGP-LS and avoids the 681 requirement for the consumer of the topology information (e.g. a 682 controller or local TE process) to tap into other BGP NLRI 683 information. 685 Advertisement of the Prefix NLRI via BGP-LS MUST be done for its 686 locally configured prefixes (e.g. its loopback interface address) and 687 when BGP is advertising the BGP Prefix SID ([RFC8669]) for it. The 688 advertisement of the Prefix NLRI via BGP-LS for other prefixes learnt 689 by the router MAY be done based on the specific use-case requirement 690 and the BGP Route Type as described in Figure 2 indicates the type of 691 route being advertised. 693 The Prefix attributes defined currently related to SR [RFC8402] have 694 been described in Table 3 and MAY be advertised when SR is enabled. 695 This includes: 697 o The Prefix SID TLV is included with the SID advertised as the 698 index to be consistent with the Label-Index TLV of BGP Prefix SID 699 attribute. The default algorithm is MUST be set to 0 by the 700 originator except in the case where a local prefix is associated 701 with a specific SR Algorithm. The flags are defined as the most 702 significant 8 bits of the 16 bit field defined for Label-Index TLV 703 in [RFC8669]. 705 o For certain SR-TE uses, the Prefix Metric value MAY be included 706 and it is set based on the SR-TE computation based on the link- 707 state topology learnt via BGP-LS. 709 Other Prefix Attributes applicable may also be included and this 710 document does not describe the exhaustive list. 712 5.4. Advertisement of Router's TE Policy Attributes 714 TE Policies that are setup using RSVP-TE or SR-TE mechanisms MAY be 715 instantiated on a BGP router. One use-case that results in such SR 716 Policy instantiation on a BGP router is described later in this 717 document in Section 6.2. Advertising such TE Policies instantiated 718 for every BGP router as head-end via BGP-LS provides the consumer of 719 the topology information (e.g. a controller or local TE process) a 720 policy view of the BGP fabric as well. 722 The procedures for advertisement of the TE Policy NLRI via BGP-LS 723 MUST be done only for its locally instantiated TE Policies and as 724 specified in [I-D.ietf-idr-te-lsp-distribution]). Implementation MAY 725 provide configuration options to control the specific set of TE 726 Policies that are to be advertised from the local node. 728 6. Usage of BGP Topology 730 This section describes some of the use-cases for the building of the 731 BGP topology information as specified in this document and leveraging 732 it for enabling new functionality. 734 6.1. Topology View for Monitoring 736 The BGP-LS advertisement of the BGP topology as specified in this 737 document provides a live topology view of the BGP network for an 738 application or controller that is monitoring the network. The 739 topology view is from the BGP protocol perspective and includes the 740 underlying links as well that aids in network monitoring as well as 741 diagnostics use-cases. BGP-LS is the de-facto protocol for 742 northbound propagation of network topology related information for 743 most IGP networks and extending this capability for BGP-only networks 744 allows existing controllers and applications to consume the 745 information with some incremental BGP protocol awareness. 747 6.2. SR-TE in BGP Networks 749 The SR-TE use-case for BGP builds on top of functionality specified 750 in [RFC8669] and also described in [RFC8670].The BGP SR Prefix SID 751 signaled, provides the basic connectivity between all BGP routers 752 using their loopback addresses. This provides the basic best-effort 753 paths in the network using the base BGP decision process that is 754 unchanged. BGP and other overlay routes and services recurse on top 755 of these loopback addresses of the egress nodes and the forwarding is 756 done via the BGP SR Prefix SID labels in the underlay. While this 757 version of the document focuses on the examples with MPLS dataplane 758 instantiation for SR, the same is applicable for the IPv6 dataplane 759 instantiation (SRv6) as well. 761 SR-TE for BGP provides underlay paths through the network for the 762 overlay routes and services with specific SLA requirements and use- 763 cases like path disjointness, low latency paths, inclusion or 764 exclusion and other TE considerations. 766 [I-D.ietf-spring-segment-routing-policy] specifies the SR-TE 767 architecture and the SR Policy construct. 768 [I-D.ietf-idr-segment-routing-te-policy] describes the extensions to 769 BGP for signaling of SR Policies from a controller to the SR-TE 770 headend BGP router. BGP-LS has been extended to allow signaling of 771 the SR Policies from SR-TE head-end to controllers via 772 [I-D.ietf-idr-te-lsp-distribution] which allows the controllers to 773 learn the state of SR Policies instantiated on routers in the 774 network. This document completes the missing piece that is related 775 to getting the BGP topology information from all the routers to a 776 controller as well the local SRTE process on each router for their 777 path computation requirements. 779 The signaling of SR Polices from controller to SR-TE headend and 780 reporting of the state back to the controller can also be done using 781 PCEP ([RFC8664], [RFC8281], [RFC8231]). However, the BGP topology 782 learning via BGP-LS which is specified in this document is also 783 required for the deployments that uses PCEP in the BGP-only network. 785 The topology collected via BGP-LS in a BGP-only fabric in a Segment 786 Routing deployment comprise of: 788 o The properties of every BGP router node and the Prefix SIDs to 789 reach that node. 791 o The properties of all the links between the BGP routers and the 792 Peer-Adjacency-SIDs (and other EPE SIDs) corresponding to them 793 that allow directing traffic over specific links and/or to 794 specific neighbors. 796 o The properties and state of the SR Policies instantiatied on each 797 of the BGP routers along with their end points, their properties 798 and most importantly the Binding SID to steer traffic into the SR 799 Policies. 801 This topology information allows a computation node to build SR 802 Policies for services over the BGP fabric for a given traffic 803 engineering objective at any given node. 805 The topology of the BGP fabric is advertised to a centralized 806 controller or application for use-cases that need a centralized 807 computation of SR Policy which can then be signaled to the SR-TE 808 head-end node via PCEP or BGP-SRTE. The topology may also be 809 distributed to any node in the BGP fabric to be used by its local SR- 810 TE process to perform path computation for its own SR Policies for 811 use-cases that are addressed by local computation. 813 A high level summary of the key topology information advertised via 814 BGP-LS by BGP routers can be used for TE computations as follows 816 o The BGP SR Prefix SIDs and the BGP EPE Peering Adjacency SIDs 817 provide the equivalent of the IGP Prefix and Adjacency SIDs and 818 can be used to direct traffic to a specific BGP router and over a 819 specific BGP peer session or link respectively. Traffic for the 820 BGP SR Prefix SIDs follow the path computed by the BGP decision 821 process. 823 o The TE metric can be used to tailor the choice of specific paths 824 in the network for SR-TE. 826 o The TE administrative group (also known as affinities) and SRLG 827 attributes can be configured over links to enable computation of 828 paths with inclusion and exclusion of specific links or paths that 829 are mutually disjoint. 831 o The enabling of link delay and loss measurements and their 832 advertisements can help monitoring the link quality and carve out 833 paths based on latency and other SLA requirements. 835 o The signaling of the Node and Link MSD allows controllers to 836 instantiate SR Policies based on the capability of the routers. 838 This section attempts to highlight and describe at a high level some 839 of the possible SR-TE solutions and use-cases in a BGP-only network. 840 The actual SR-TE computation and algorithms are outside the scope of 841 this document. 843 7. IANA Considerations 845 IANA maintains a registry called "Border Gateway Protocol - Link 846 State (BGP-LS) Parameters" with a sub-registry called "Node Anchor, 847 Link Descriptor and Link Attribute TLVs". 849 The following TLV codepoints are suggested (to be assigned by IANA): 851 +----------+----------------------------------------+---------------+ 852 | TLV Code | Description | Value defined | 853 | Point | | in | 854 +----------+----------------------------------------+---------------+ 855 | TBD | BGP Route Type TLV | this document | 856 +----------+----------------------------------------+---------------+ 858 8. Manageability Considerations 860 This section is structured as recommended in [RFC5706]. 862 8.1. Operational Considerations 863 8.1.1. Operations 865 Existing BGP and BGP-LS operational procedures apply. No additional 866 operation procedures are defined in this document. 868 9. Security Considerations 870 Procedures and protocol extensions defined in this document do not 871 affect the BGP security model. See the 'Security Considerations' 872 section of [RFC4271] for a discussion of BGP security. Also refer to 873 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 875 10. Acknowledgements 877 The authors would like to thank Bruno Decraene for his review and 878 comments on this document. 880 11. References 882 11.1. Normative References 884 [I-D.ietf-idr-bgp-ls-flex-algo] 885 Talaulikar, K., Psenak, P., Zandi, S., and G. Dawra, 886 "Flexible Algorithm Definition Advertisement with BGP 887 Link-State", draft-ietf-idr-bgp-ls-flex-algo-07 (work in 888 progress), June 2021. 890 [I-D.ietf-idr-te-lsp-distribution] 891 Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler, 892 H., and J. Tantsura, "Distribution of Traffic Engineering 893 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 894 lsp-distribution-15 (work in progress), May 2021. 896 [I-D.ietf-lsr-flex-algo] 897 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 898 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 899 algo-17 (work in progress), July 2021. 901 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 902 Requirement Levels", BCP 14, RFC 2119, 903 DOI 10.17487/RFC2119, March 1997, 904 . 906 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 907 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 908 DOI 10.17487/RFC4271, January 2006, 909 . 911 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 912 S. Ray, "North-Bound Distribution of Link-State and 913 Traffic Engineering (TE) Information Using BGP", RFC 7752, 914 DOI 10.17487/RFC7752, March 2016, 915 . 917 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 918 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 919 May 2017, . 921 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 922 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 923 IGP Traffic Engineering Performance Metric Extensions", 924 RFC 8571, DOI 10.17487/RFC8571, March 2019, 925 . 927 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 928 A., and H. Gredler, "Segment Routing Prefix Segment 929 Identifier Extensions for BGP", RFC 8669, 930 DOI 10.17487/RFC8669, December 2019, 931 . 933 [RFC8814] Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., 934 and N. Triantafillis, "Signaling Maximum SID Depth (MSD) 935 Using the Border Gateway Protocol - Link State", RFC 8814, 936 DOI 10.17487/RFC8814, August 2020, 937 . 939 [RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, 940 H., and M. Chen, "Border Gateway Protocol - Link State 941 (BGP-LS) Extensions for Segment Routing", RFC 9085, 942 DOI 10.17487/RFC9085, August 2021, 943 . 945 [RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K., 946 Ray, S., and J. Dong, "Border Gateway Protocol - Link 947 State (BGP-LS) Extensions for Segment Routing BGP Egress 948 Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August 949 2021, . 951 [RFC9104] Tantsura, J., Wang, Z., Wu, Q., and K. Talaulikar, 952 "Distribution of Traffic Engineering Extended 953 Administrative Groups Using the Border Gateway Protocol - 954 Link State (BGP-LS)", RFC 9104, DOI 10.17487/RFC9104, 955 August 2021, . 957 11.2. Informative References 959 [I-D.ietf-idr-segment-routing-te-policy] 960 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 961 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 962 Routing Policies in BGP", draft-ietf-idr-segment-routing- 963 te-policy-13 (work in progress), June 2021. 965 [I-D.ietf-spring-segment-routing-policy] 966 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 967 P. Mattes, "Segment Routing Policy Architecture", draft- 968 ietf-spring-segment-routing-policy-13 (work in progress), 969 May 2021. 971 [I-D.xu-idr-neighbor-autodiscovery] 972 Xu, X., Talaulikar, K., Bi, K., Tantsura, J., and N. 973 Triantafillis, "BGP Neighbor Discovery", draft-xu-idr- 974 neighbor-autodiscovery-12 (work in progress), November 975 2019. 977 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 978 DOI 10.17487/RFC2328, April 1998, 979 . 981 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 982 (TE) Extensions to OSPF Version 2", RFC 3630, 983 DOI 10.17487/RFC3630, September 2003, 984 . 986 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 987 RFC 4272, DOI 10.17487/RFC4272, January 2006, 988 . 990 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 991 Management of New Protocols and Protocol Extensions", 992 RFC 5706, DOI 10.17487/RFC5706, November 2009, 993 . 995 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 996 Measurement for MPLS Networks", RFC 6374, 997 DOI 10.17487/RFC6374, September 2011, 998 . 1000 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1001 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1002 and Authentication for Routing Protocols (KARP) Design 1003 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1004 . 1006 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 1007 BGP for Routing in Large-Scale Data Centers", RFC 7938, 1008 DOI 10.17487/RFC7938, August 2016, 1009 . 1011 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1012 Computation Element Communication Protocol (PCEP) 1013 Extensions for Stateful PCE", RFC 8231, 1014 DOI 10.17487/RFC8231, September 2017, 1015 . 1017 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1018 Computation Element Communication Protocol (PCEP) 1019 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1020 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1021 . 1023 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1024 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1025 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1026 July 2018, . 1028 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1029 and J. Hardwick, "Path Computation Element Communication 1030 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1031 DOI 10.17487/RFC8664, December 2019, 1032 . 1034 [RFC8670] Filsfils, C., Ed., Previdi, S., Dawra, G., Aries, E., and 1035 P. Lapukhov, "BGP Prefix Segment in Large-Scale Data 1036 Centers", RFC 8670, DOI 10.17487/RFC8670, December 2019, 1037 . 1039 [RFC9087] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., Aries, E., 1040 and D. Afanasiev, "Segment Routing Centralized BGP Egress 1041 Peer Engineering", RFC 9087, DOI 10.17487/RFC9087, August 1042 2021, . 1044 Authors' Addresses 1046 Ketan Talaulikar 1047 Cisco Systems 1048 Pune 411057 1049 India 1051 Email: ketant@cisco.com 1052 Clarence Filsfils 1053 Cisco Systems 1054 Brussels 1055 Belgium 1057 Email: cfilsfil@cisco.com 1059 Krishna Swamy 1060 Cisco Systems 1061 San Jose 1062 USA 1064 Email: kriswamy@cisco.com 1066 Shawn Zandi 1067 LinkedIn 1068 USA 1070 Email: szandi@linkedin.com 1072 Gaurav Dawra 1073 LinkedIn 1074 USA 1076 Email: gdawra.ietf@gmail.com 1078 Muhammad Durrani 1079 Equinix 1080 USA 1082 Email: mdurrani@equinix.com