idnits 2.17.1 draft-ketant-idr-bgp-ls-bgp-only-fabric-02.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 9, 2019) is 1875 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 (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-12 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-msd-04 == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-17 == Outdated reference: A later version (-19) exists of draft-ietf-idr-eag-distribution-08 == Outdated reference: A later version (-19) exists of draft-ietf-idr-te-lsp-distribution-10 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-01 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-05 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-02 == Outdated reference: A later version (-12) exists of draft-xu-idr-neighbor-autodiscovery-10 Summary: 1 error (**), 0 flaws (~~), 10 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 10, 2019 Cisco Systems 6 S. Zandi 7 G. Dawra 8 LinkedIn 9 M. Durrani 10 Equinix 11 March 9, 2019 13 BGP Link-State Extensions for BGP-only Fabric 14 draft-ketant-idr-bgp-ls-bgp-only-fabric-02 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 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 10, 2019. 54 Copyright Notice 56 Copyright (c) 2019 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. BGP Routing in the Fabric . . . . . . . . . . . . . . . . . . 3 73 3. Topology Collection Mechanism . . . . . . . . . . . . . . . . 4 74 3.1. Peering Models . . . . . . . . . . . . . . . . . . . . . 5 75 4. Advertising BGP-only Network Topology . . . . . . . . . . . . 6 76 4.1. Node Advertisements . . . . . . . . . . . . . . . . . . . 6 77 4.2. Link Advertisements . . . . . . . . . . . . . . . . . . . 7 78 4.3. Prefix Advertisements . . . . . . . . . . . . . . . . . . 10 79 4.4. TE Policy Advertisements . . . . . . . . . . . . . . . . 12 80 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 5.1. Advertisement of Router's Node Attributes . . . . . . . . 13 82 5.2. Advertisement of Router's Local Links Attributes . . . . 15 83 5.3. Advertisement of Router's Prefix Attributes . . . . . . . 17 84 5.4. Advertisement of Router's TE Policy Attributes . . . . . 17 85 6. Usage of BGP Topology . . . . . . . . . . . . . . . . . . . . 18 86 6.1. Topology View for Monitoring . . . . . . . . . . . . . . 18 87 6.2. SR-TE in BGP Networks . . . . . . . . . . . . . . . . . . 18 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 89 8. Manageability Considerations . . . . . . . . . . . . . . . . 21 90 8.1. Operational Considerations . . . . . . . . . . . . . . . 21 91 8.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 21 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 96 11.2. Informative References . . . . . . . . . . . . . . . . . 23 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 100 1. Introduction 102 Network operators are going for a BGP-only routing protocol for 103 certain networks like Massively Scaled Data Centers (MSDCs). 104 [RFC7938] describes the requirement, design and operational aspects 105 for use of BGP as the only routing protocol in MSDCs. The underlying 106 link and topology information between BGP routers is hidden or 107 abstracted in this design from the underlay routing for improving 108 scalability and stability in a large scale network. On the flip 109 side, there is no detailed topology view similar to one available in 110 form of the Traffic Engineering (TE) Database (TED) when running link 111 state routing protocols like OSPF [RFC2328] with extensions specified 112 in [RFC3630]. 114 BGP Link-State (BGP-LS)[RFC7752] enables advertisement of a link 115 state topology via BGP that can be consumed by a controller or in 116 general any software component to get a complete topology view of the 117 network. BGP-LS extensions for advertisement of a BGP topology for 118 the Egress Peer Engineering (EPE) use-case 119 [I-D.ietf-spring-segment-routing-central-epe] are specified in 120 [I-D.ietf-idr-bgpls-segment-routing-epe]. This document leverages 121 the BGP-LS TLVs defined for BGP-LS EPE and other BGP-LS documents and 122 specifies the procedures for advertising the underlying topology in a 123 more generic BGP-only fabric use-case. 125 This document specifies the operations and procedures when using the 126 design involving BGP use for hop-by-hop routing between directly 127 connected network nodes (refer [RFC7938] for details). 129 2. BGP Routing in the Fabric 131 This document does not change base BGP routing protocol operations in 132 the fabric that provides routing using the BGP best path selection 133 process [RFC4271] . 135 The applicability of this specification is limited to those 136 deployments where BGP is used as hop-by-hop routing protocol between 137 directly connected nodes in the fabric. While a data-center design 138 [RFC7938] is used as a reference, the topology advertisement and its 139 use for computation may also apply to other networks with BGP-only 140 fabric or to BGP-only portions of a larger network topology. 142 BGP hop-by-hop routing can be setup using EBGP single-hop sessions 143 over individual links between directly connected routers using their 144 link addresses for peering as described in [RFC7938]. In such a 145 design, the neighbors' link addresses may be provisioned for peering 146 and the EBGP session operating directly over the link performs the 147 monitoring of the neighbor on that link. A variation of this design 148 would be that the EBGP session is setup between directly connected 149 routers using their loopback sessions. The mechanisms for discovery 150 of the neighbor's link addresses and their monitoring on a per link 151 basis are outside the scope of this document. 152 [I-D.xu-idr-neighbor-autodiscovery] describes one such mechanism and 153 the same may be also realized by other means. 155 Though this document uses the EBGP based design as a reference, it 156 does not preclude other alternate designs using IBGP. 158 3. Topology Collection Mechanism 160 BGP-LS [RFC7752] has been defined to allow BGP to convey topology 161 information in the form of Link-State objects - node, link and 162 prefix. The properties of each of these objects are encoded using 163 BGP-LS Attribute TLVs. Applications need a topological view and 164 visibility even for networks where BGP is the only routing protocol. 165 In such networks, each BGP router advertises its local information 166 which includes its node, links and prefix attributes via BGP-LS. 168 Figure 1 describes a typical deployment scenario. Every BGP router 169 in the network is enabled for BGP-LS and forms BGP-LS sessions with 170 one or more centralized BGP-LS speakers over which it sends its local 171 topology information. Each BGP router MAY also receive the topology 172 information from all other BGP routers via these centralized BGP-LS 173 speakers. This way, any BGP router (as also the centralized BGP-LS 174 speakers) MAY obtain aggregated Link-State information for the entire 175 BGP network. An external component (e.g. a controller) can obtain 176 this information from the centralized BGP-LS speakers or directly by 177 doing BGP-LS peering to the BGP routers. An internal software 178 component on any of the BGP routers (e.g. TE module) can also 179 receive the entire BGP network topology information from its local 180 BGP process. 182 +------------+ 183 | Controller | 184 +------------+ 185 ^ 186 | 187 v 188 +-------------------+ 189 | BGP-LS Speaker | +------------+ 190 | (Centralized) | | Controller | 191 +-------------------+ +------------+ 192 ^ ^ ^ ^ 193 | | | | 194 +-----------+ | +---------------+ | 195 | | | | 196 v v v v 197 +-----------+ +-----------+ +-----------+ +----------+ 198 | BGP | | BGP | | BGP |<-->| Local | 199 | Router | | Router | . . . | Router | | Consumer | 200 +-----------+ +-----------+ +-----------+ +----------+ 201 ^ ^ ^ 202 | | | 203 Local Info Local Info Local Info 204 (node & links) (node & links) (node & links) 206 Figure 1: Link State info collection 208 3.1. Peering Models 210 The peering model described above relies on the base BGP IPv4 or IPv6 211 routing underlay (e.g. as described in [RFC7938]) or any other 212 mechanism for reachability for the BGP-LS session establishment with 213 the centralized BGP speakers. A variation of this model would be to 214 setup reachability to the centralized BGP speakers (or controller) 215 over the out of band management network, where available, and for 216 each BGP router in the fabric use the same for the BGP-LS session 217 establishment with the centralized BGP speakers. This variation 218 removes the dependency between the topology learning via BGP-LS from 219 the base best effort reachability over the BGP routing in the fabric. 221 Another alternate design would be to enable BGP-LS as well on the hop 222 by hop EBGP sessions in the underlay as described in [RFC7938]. This 223 approach results in the topology information being flooded via BGP-LS 224 hop-by-hop along the BGP routers in the network. Other peering 225 designs for BGP-LS sessions may also be possible and they are not 226 precluded by this document. 228 4. Advertising BGP-only Network Topology 230 This section specifies the BGP-LS TLVs and sub-TLVs and their use for 231 advertising the topology of a BGP-only network in the form of BGP-LS 232 Node, Link and Prefix NLRIs. 234 BGP-LS [RFC7752] defines the BGP-LS NLRI types (i.e. Node NLRI, Link 235 NLRI and Prefix NLRI) along with their corresponding BGP-LS Attribute 236 (i.e. Node Attribute, Link Attribute or Prefix Attribute) and the 237 TLVs that map to the respective NLRI and Attribute for each type. 239 [I-D.ietf-idr-bgpls-segment-routing-epe] specifies the BGP Protocol 240 ID to be used for signaling BGP EPE information and the same is used 241 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 [I-D.ietf-idr-bgpls-segment-routing-epe] introduces additional Node 268 Descriptor TLVs for BGP protocol 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 | Description | Reference Document | 286 | Code | | | 287 | Point | | | 288 +--------+--------------+-------------------------------------------+ 289 | 1026 | Node Name | [RFC7752] | 290 | 1028 | IPv4 TE | [RFC7752] | 291 | | Router-ID | | 292 | 1029 | IPv6 TE | [RFC7752] | 293 | | Router-ID | | 294 | 1161 | SID/Label | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 295 | 1034 | SRGB & | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 296 | | Capabilities | | 297 | 1035 | SR Algorithm | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 298 | 1036 | SR Local | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 299 | | Block | | 300 | 266 | Node MSD | [I-D.ietf-idr-bgp-ls-segment-routing-msd] | 301 | TBD | Flex | [I-D.ketant-idr-bgp-ls-flex-algo] | 302 | | Algorithm | | 303 | | Definition | | 304 +--------+--------------+-------------------------------------------+ 306 Table 1: Node Attribute TLVs 308 The above list of TLVs is not exhaustive but indicative as of the 309 time of writing of this document. 311 4.2. Link Advertisements 313 [RFC7752] defines Link NLRI Type and its Node and Link Descriptor 314 TLVs as follows: 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+ 319 | Protocol-ID | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Identifier | 322 | (64 bits) | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 // Local Node Descriptors (variable) // 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 // Remote Node Descriptors (variable) // 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 // Link Descriptors (variable) // 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 The following Node Descriptors TLVs MUST appear in the Link NLRI as 332 Local Node Descriptors: 334 o BGP Router-ID, which contains the BGP Identifier of the 335 originating BGP router 337 o Autonomous System Number, which contains the advertising router 338 ASN. 340 The following Node Descriptors TLVs MUST appear in the Link NLRI as 341 Remote Node Descriptors: 343 o BGP Router-ID, which contains the BGP Identifier of the peer BGP 344 router 346 o Autonomous System Number, which contains the peer ASN. 348 The following Link Descriptors TLVs MUST appear in the Link NLRI as 349 Link Descriptors: 351 o Link Local/Remote Identifiers containing the 4-octet Link Local 352 Identifier followed by the 4-octet Link Remote Identifier. The 353 value 0 MUST be used for the Link Remote Identifier when the value 354 is unknown. 356 In addition, the following Link Descriptors TLVs SHOULD appear in the 357 Link NLRI as Link Descriptors based on the address family used for 358 setting up the BGP Peering or the addresses configured on the links: 360 o IPv4 Interface Address contains the address of the local interface 361 through which the BGP session is established using IPv4 address. 363 o IPv6 Interface Address contains the address of the local interface 364 through which the BGP session is established using IPv6 address. 366 o IPv4 Neighbor Address contains the IPv4 address of the peer 367 interface used by the BGP session establishment using IPv4 368 address. 370 o IPv6 Neighbor Address contains the IPv6 address of the peer 371 interface used by the BGP session establishment using IPv6 372 address. 374 The BGP-LS Attribute associated with the Link NLRI MAY include the 375 following TLVs that are defined in respective documents to signal the 376 router's local links' properties and capabilities (Section 5.2 377 defines the procedures for their advertisements) : 379 +------+----------------+-------------------------------------------+ 380 | TLV | Description | Reference Document | 381 | Code | | | 382 | Poin | | | 383 | t | | | 384 +------+----------------+-------------------------------------------+ 385 | 1088 | Administrative | [RFC7752] | 386 | | group (color) | | 387 | 1173 | Extended | [I-D.ietf-idr-eag-distribution] | 388 | | Administrative | | 389 | | group (color) | | 390 | 1089 | Maximum link | [RFC7752] | 391 | | bandwidth | | 392 | 1092 | TE Default | [RFC7752] | 393 | | Metric | | 394 | 1096 | SRLG | [RFC7752] | 395 | 1098 | Link Name | [RFC7752] | 396 | 267 | Link MSD | [I-D.ietf-idr-bgp-ls-segment-routing-msd] | 397 | 1172 | L2 Bundle | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 398 | | Member | | 399 | 1104 | Unidirectional | [I-D.ietf-idr-te-pm-bgp] | 400 | | link delay | | 401 | 1105 | Min/Max | [I-D.ietf-idr-te-pm-bgp] | 402 | | Unidirectional | | 403 | | link delay | | 404 | 1106 | Min/Max | [I-D.ietf-idr-te-pm-bgp] | 405 | | Unidirectional | | 406 | | link delay | | 407 | 1107 | Unidirectional | [I-D.ietf-idr-te-pm-bgp] | 408 | | packet loss | | 409 | 1101 | EPE Peer Node | [I-D.ietf-idr-bgpls-segment-routing-epe] | 410 | | SID | | 411 | 1102 | EPE Peer Adj | [I-D.ietf-idr-bgpls-segment-routing-epe] | 412 | | SID | | 413 | 1103 | EPE Peer Set | [I-D.ietf-idr-bgpls-segment-routing-epe] | 414 | | SID | | 415 +------+----------------+-------------------------------------------+ 417 Table 2: Link Attribute TLVs 419 The above list of TLVs is not exhaustive but indicative as of the 420 time of writing of this document. 422 4.3. Prefix Advertisements 424 [RFC7752] defines Prefix NLRI Type and its Node and Prefix Descriptor 425 TLVs as follows: 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+ 430 | Protocol-ID | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Identifier | 433 | (64 bits) | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 // Local Node Descriptors (variable) // 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 // Prefix Descriptors (variable) // 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 The following Node Descriptors TLVs MUST appear in the Prefix NLRI as 441 Local Node Descriptors: 443 o BGP Router-ID, which contains the BGP Identifier of the 444 originating BGP router 446 o Autonomous System Number, which contains the advertising router 447 ASN. 449 The Prefix Descriptor MUST contain the IP Reachability information 450 TLV to identify the prefix. 452 This document defines a new BGP Route Type TLV that MUST be included 453 in the Prefix Descriptor when the BGP node advertises the Prefix 454 NLRI. The format of this TLV is as follows: 456 0 1 2 3 457 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 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Type | Length | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Route Type | 462 +-+-+-+-+-+-+-+-+ 464 Where: 466 Type: 2 octet field with value TBD, see Section 7. 468 Length: 2 octet field with value set to 1. 470 Route Type: one octet with the following values defined: 472 +-----+---------------+------------------------------------------+ 473 |Value| Type | Description | 474 +-----+---------------+------------------------------------------+ 475 | 1 | Local | Local interface prefix e.g. Loopback | 476 | 2 | Attached | Directly attached node's prefix e.g host | 477 | 3 | External BGP | Prefix learnt via EBGP | 478 | 4 | Internal BGP | Prefix learnt via IBGP | 479 | 5 | Redistributed | Prefix redistributed into BGP | 480 +-------+-------------+------------------------------------------+ 482 Figure 2: BGP Route Types 484 The BGP-LS Attribute associated with the Prefix NLRI MAY include the 485 following TLVs that are defined in respective documents to signal the 486 router's own prefix properties and capabilities (Section 5.3 defines 487 the procedures for their advertisements): 489 +---------+-------------+-------------------------------------------+ 490 | TLV | Description | Reference Document | 491 | Code | | | 492 | Point | | | 493 +---------+-------------+-------------------------------------------+ 494 | 1155 | Prefix | [RFC7752] | 495 | | Metric | | 496 | 1158 | Prefix SID | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 497 +---------+-------------+-------------------------------------------+ 499 Table 3: Prefix Attribute TLVs 501 The above list of TLVs is not exhaustive but indicative as of the 502 time of writing of this document. 504 4.4. TE Policy Advertisements 506 [I-D.ietf-idr-te-lsp-distribution] defines TE Policy NLRI Type and 507 its Headend Node and TE Policy Descriptor TLVs as follows: 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+ 512 | Protocol-ID | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Identifier | 515 | (64 bits) | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 // Headend (Node Descriptors) // 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 // TE Policy Descriptors (variable) // 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 The Node Descriptors TLVs are the same as specified in Section 4.1. 523 The semantics for the TE Policy Descriptor TLVs and the TLVs 524 associated with the BGP-LS Attribute are used as specified in 525 [I-D.ietf-idr-te-lsp-distribution]. 527 5. Procedures 529 In a network where BGP is the only routing protocol, the BGP-LS 530 session is used to advertise the necessary information about the 531 local node properties, its local links' properties and where 532 necessary the prefix's owned by the node. TE Policies, that are 533 instantiated on the local node (i.e. when it is the head-end for the 534 policy), along with their properties are also advertised via the BGP- 535 LS session. This information, once collected across all BGP routers 536 in the network, provides a complete topology view of the network. 537 Many of these attributes are not part of the base BGP protocol 538 operations and are either configured or provided by other components 539 on the router. BGP-LS performs the role of collecting this 540 information and propagating it across the BGP network. 542 The following sections describe the procedures for the propagation of 543 the BGP-LS NLRIs on a BGP router into the BGP-LS session. These 544 procedures for propagation of BGP topology information via BGP-LS 545 SHOULD be applied only in deployments and use-cases where necessary 546 and SHOULD NOT be applied in every BGP deployment when BGP-LS is 547 enabled. Implementations MAY provide a configuration option to 548 enable these procedures in required deployments. 550 5.1. Advertisement of Router's Node Attributes 552 Advertisement of the Node NLRI via BGP-LS by each BGP router in a 553 BGP-only network enables the discovery of all the router nodes in the 554 topology. The Node NLRI MUST be generated by a BGP router only for 555 itself and even when there are no attributes to be advertised along 556 with it. 558 The Node attributes defined currently related to Segment Routing (SR) 559 [RFC8402] have been described in Table 1 and are to be advertised 560 when SR is enabled. This includes: 562 o All SR enabled routers support the default SR algorithm 0 and MUST 563 advertise it in the SR Algorithm TLV. Other algorithms (including 564 Flexible Algorithm [I-D.ietf-lsr-flex-algo]) SHOULD be advertised 565 when supported. 567 o The Segment Routing Global Block (SRGB) provisioned on the router 568 which is used by BGP Prefix SIDs [I-D.ietf-idr-bgp-prefix-sid] and 569 other SR control plane protocols on the router MUST be advertised. 570 The value for Flags field in the TLV is not defined for BGP 571 protocol and MUST be set to 0 by the originator and ignored by 572 receivers. 574 o The Segment Routing Local Block (SRLB) provisioned on the router 575 which MAY be used by BGP EPE SIDs 576 [I-D.ietf-idr-bgpls-segment-routing-epe] SHOULD be advertised. 577 The value for Flags field in the TLV is not defined for BGP 578 protocol and MUST be set to 0 by the originator and ignored by 579 receivers. 581 o The Node level MSD provides the Node's capabilities for SR SID 582 operations and SHOULD be advertised. 584 o When the router supports SR Flexible Algorithms and is provisioned 585 with the Flexible Algorithm Definition (FAD), then it MUST 586 advertise the same. 588 The Node Name Attribute SHOULD be advertised when available. 590 This document introduces some of the TE concepts into BGP-only 591 networks. Provisioning of TE Router-ID with a unique address 592 normally associated with a loopback interface on the router enables 593 TE use-cases for both IPv4 and IPv6 SHOULD be supported. The BGP 594 Router-ID along with the ASN also provides the capability for 595 uniquely identifying a BGP router in the network. 597 Other Node Attributes applicable to a BGP Router may also be included 598 and this document does not describe the exhaustive list. 600 5.2. Advertisement of Router's Local Links Attributes 602 Each BGP router in a BGP-only network also advertises its local links 603 using the Link NLRIs thru BGP-LS. The Link NLRI for a given link 604 between two BGP routers is advertised as uni-directional logical 605 "half-link" and its link descriptors allow the correlation between 606 the two NLRIs "half-links" originated by the peering routers to 607 describe the bi-directional logical link and its attributes on both 608 routers. 610 The discovery of all the links and their local and remote identifiers 611 in a BGP-only network relies on the design that uses EBGP sessions 612 over each interconnecting link using the link IP addresses (refer 613 [RFC7938]). In this case, a Link NLRI MUST be generated by a BGP 614 router for each of its local link regardless of whether it has any 615 link attributes to be advertised for it. 617 When doing EBGP multi-hop sessions between directly connected BGP 618 routers, the underlying link information would need to learn by some 619 discovery protocol or provisioning entity. The mechanisms to learn 620 the underlying link information for BGP-LS advertisements are outside 621 the scope of this document. However, to provide a true link topology 622 picture, the advertisement of underlying links is RECOMMENDED for 623 most use-cases instead of a single EBGP peering representation of a 624 link between the routers using their loopback addresses. 626 The Link NLRI represents an adjacency between BGP routers and its 627 association with the underlying Layer 3 link. When the underlying 628 Layer 3 link or the BGP session on top of it goes down, the Link NLRI 629 MUST be withdrawn by the BGP router. The monitoring of links, 630 detecting of their failures and notification to BGP may be performed 631 using mechanisms like BFD. This enables faster detection of failures 632 and verification of the underlying links. 634 Advertisement of the Link NLRIs via BGP-LS by each BGP router in a 635 BGP-only network enables the discovery of all the active links in the 636 topology. 638 TE attributes for links have been traditionally associated with Link 639 State Routing protocols. However, with the ability to discover the 640 link topology via BGP-LS as specified in this document, the TE 641 attributes and their principles can also be applied to a network 642 running BGP alone. The TE attributes for a link have been described 643 in Table 2 and MAY be advertised when TE use-cases are enabled. This 644 includes: 646 o The maximum bandwidth of a link is its protocol independent 647 attribute and SHOULD be advertised. 649 o TE concepts of Administrative Groups (also known as affinities) 650 and Shared Risk Link Groups (SRLGs) MAY be provisioned locally on 651 links and then MUST be advertised. 653 o The BGP base protocol does not operate with link metrics, however, 654 a TE metric concept can be introduced in a BGP only network as 655 well for TE use-cases. Implementations MAY provide the ability to 656 provision TE metric value for a link for BGP use including a 657 different default value for it. The TE metric attribute SHOULD be 658 advertised for each link when configured and its default value is 659 taken as 100. When not advertised for a link, implementations who 660 intend to use the TE metric MUST assume the value to be 100. 662 o The delay and loss TE metrics for links are measured via MPLS 663 Performance Monitoring [RFC6374] and their measurement mechanism 664 over a link are independent of the routing protocol. The same 665 mechanism MAY be enabled in BGP-only networks and their values 666 advertised via BGP-LS. 668 The Link attributes defined currently related to the Segment Routing 669 feature BGP EPE [I-D.ietf-idr-bgpls-segment-routing-epe] have been 670 described in Table 2 and are to be advertised when SR use-cases are 671 enabled. This includes: 673 o The BGP Peering SIDs provide a functionality similar to Adjacency- 674 SID (refer [RFC8402]) in BGP-only networks. Implementations 675 SHOULD allocate the BGP Peer-Adjacency SID for all its links and 676 the BGP Peer-Node SID for all its peer routers. Implementations 677 MAY allocate the BGP Peer-Set SID based on local configuration. 679 o The Link level MSD provides the per link capabilities for SR SID 680 operations and SHOULD be advertised when the router links have 681 differing capabilities. 683 The use of Layer 3 bundle links which comprise of multiple layer 2 684 member links are often used in BGP networks. When BGP session is 685 configured over such a layer 3 link, the link attributes of the 686 underlying layer 2 links MAY be advertised individually using the L2 687 Bundle Member TLV. The applicable attributes for the L2 links are 688 described in [I-D.ietf-idr-bgp-ls-segment-routing-ext]. 690 The Link Name Attribute MAY be advertised when available. 692 Other Link Attributes applicable to a BGP Router may also be included 693 and this document does not describe the exhaustive list. 695 5.3. Advertisement of Router's Prefix Attributes 697 Advertisement of the Prefix NLRI via BGP-LS may be required only in 698 specific use-cases. Since the base BGP protocol along with its 699 extensions already signals Prefix reachability via different NLRIs, 700 there is no necessity to duplicate the information via BGP-LS 701 session. However, for specific use-cases related to SR Traffic 702 Engineering (SR-TE), it is required for each router to advertise it's 703 Prefix SID(s) (refer [RFC8402]) that can be used to direct traffic 704 via specific BGP routers. Advertising such BGP Prefix SID for every 705 BGP router provides this key attribute via BGP-LS and avoids the 706 requirement for the consumer of the topology information (e.g. a 707 controller or local TE process) to tap into other BGP NLRI 708 information. 710 Advertisement of the Prefix NLRI via BGP-LS MUST be done for its 711 locally configured prefixes (e.g. its loopback interface address) and 712 when BGP is advertising the BGP Prefix SID 713 ([I-D.ietf-idr-bgp-prefix-sid]) for it. The advertisement of the 714 Prefix NLRI via BGP-LS for other prefixes learnt by the router MAY be 715 done based on the specific use-case requirement and the BGP Route 716 Type as described in Figure 2 indicates the type of route being 717 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 [I-D.ietf-idr-bgp-prefix-sid]. 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 [I-D.ietf-idr-bgp-prefix-sid] and also described in 777 [I-D.ietf-spring-segment-routing-msdc].The BGP SR Prefix SID 778 signaled, provides the basic connectivity between all BGP routers 779 using their loopback addresses. This provides the basic best-effort 780 paths in the network using the base BGP decision process that is 781 unchanged. BGP and other overlay routes and services recurse on top 782 of these loopback addresses of the egress nodes and the forwarding is 783 done via the BGP SR Prefix SID labels in the underlay. While this 784 version of the document focuses on the examples with MPLS dataplane 785 instantiation for SR, the same is applicable for the IPv6 dataplane 786 instantiation (SRv6) as well. 788 SR-TE for BGP provides underlay paths through the network for the 789 overlay routes and services with specific SLA requirements and use- 790 cases like path disjointness, low latency paths, inclusion or 791 exclusion and other TE considerations. 793 [I-D.ietf-spring-segment-routing-policy] specifies the SR-TE 794 architecture and the SR Policy construct. 795 [I-D.ietf-idr-segment-routing-te-policy] describes the extensions to 796 BGP for signaling of SR Policies from a controller to the SR-TE 797 headend BGP router. BGP-LS has been extended to allow signaling of 798 the SR Policies from SR-TE head-end to controllers via 799 [I-D.ietf-idr-te-lsp-distribution] which allows the controllers to 800 learn the state of SR Policies instantiated on routers in the 801 network. This document completes the missing piece that is related 802 to getting the BGP topology information from all the routers to a 803 controller as well the local SRTE process on each router for their 804 path computation requirements. 806 The signaling of SR Polices from controller to SR-TE headend and 807 reporting of the state back to the controller can also be done using 808 PCEP ([I-D.ietf-pce-segment-routing], [RFC8281], [RFC8231]). 809 However, the BGP topology learning via BGP-LS which is specified in 810 this document is also required for the deployments that uses PCEP in 811 the BGP-only network. 813 The topology collected via BGP-LS in a BGP-only fabric in a Segment 814 Routing deployment comprise of: 816 o The properties of every BGP router node and the Prefix SIDs to 817 reach that node. 819 o The properties of all the links between the BGP routers and the 820 Peer-Adjacency-SIDs (and other EPE SIDs) corresponding to them 821 that allow directing traffic over specific links and/or to 822 specific neighbors. 824 o The properties and state of the SR Policies instantiatied on each 825 of the BGP routers along with their end points, their properties 826 and most importantly the Binding SID to steer traffic into the SR 827 Policies. 829 This topology information allows a computation node to build SR 830 Policies for services over the BGP fabric for a given traffic 831 engineering objective at any given node. 833 The topology of the BGP fabric is advertised to a centralized 834 controller or application for use-cases that need a centralized 835 computation of SR Policy which can then be signaled to the SR-TE 836 head-end node via PCEP or BGP-SRTE. The topology may also be 837 distributed to any node in the BGP fabric to be used by its local SR- 838 TE process to perform path computation for its own SR Policies for 839 use-cases that are addressed by local computation. 841 A high level summary of the key topology information advertised via 842 BGP-LS by BGP routers can be used for TE computations as follows 844 o The BGP SR Prefix SIDs and the BGP EPE Peering Adjacency SIDs 845 provide the equivalent of the IGP Prefix and Adjacency SIDs and 846 can be used to direct traffic to a specific BGP router and over a 847 specific BGP peer session or link respectively. Traffic for the 848 BGP SR Prefix SIDs follow the path computed by the BGP decision 849 process. 851 o The TE metric can be used to tailor the choice of specific paths 852 in the network for SR-TE. 854 o The TE administrative group (also known as affinities) and SRLG 855 attributes can be configured over links to enable computation of 856 paths with inclusion and exclusion of specific links or paths that 857 are mutually disjoint. 859 o The enabling of link delay and loss measurements and their 860 advertisements can help monitoring the link quality and carve out 861 paths based on latency and other SLA requirements. 863 o The signaling of the Node and Link MSD allows controllers to 864 instantiate SR Policies based on the capability of the routers. 866 This section attempts to highlight and describe at a high level some 867 of the possible SR-TE solutions and use-cases in a BGP-only network. 868 The actual SR-TE computation and algorithms are outside the scope of 869 this document. 871 7. IANA Considerations 873 IANA maintains a registry called "Border Gateway Protocol - Link 874 State (BGP-LS) Parameters" with a sub-registry called "Node Anchor, 875 Link Descriptor and Link Attribute TLVs". 877 The following TLV codepoints are suggested (to be assigned by IANA): 879 +----------+----------------------------------------+---------------+ 880 | TLV Code | Description | Value defined | 881 | Point | | in | 882 +----------+----------------------------------------+---------------+ 883 | TBD | BGP Route Type TLV | this document | 884 +----------+----------------------------------------+---------------+ 886 8. Manageability Considerations 888 This section is structured as recommended in [RFC5706]. 890 8.1. Operational Considerations 892 8.1.1. Operations 894 Existing BGP and BGP-LS operational procedures apply. No additional 895 operation procedures are defined in this document. 897 9. Security Considerations 899 Procedures and protocol extensions defined in this document do not 900 affect the BGP security model. See the 'Security Considerations' 901 section of [RFC4271] for a discussion of BGP security. Also refer to 902 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 904 10. Acknowledgements 906 The authors would like to thank Bruno Decraene for his review and 907 comments on this document. 909 11. References 911 11.1. Normative References 913 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 914 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 915 and M. Chen, "BGP Link-State extensions for Segment 916 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-12 917 (work in progress), March 2019. 919 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 920 Tantsura, J., Chunduri, U., Mirsky, G., Sivabalan, S., and 921 N. Triantafillis, "Signaling MSD (Maximum SID Depth) using 922 Border Gateway Protocol Link-State", draft-ietf-idr-bgp- 923 ls-segment-routing-msd-04 (work in progress), February 924 2019. 926 [I-D.ietf-idr-bgp-prefix-sid] 927 Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A., 928 and H. Gredler, "Segment Routing Prefix SID extensions for 929 BGP", draft-ietf-idr-bgp-prefix-sid-27 (work in progress), 930 June 2018. 932 [I-D.ietf-idr-bgpls-segment-routing-epe] 933 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 934 S., and J. Dong, "BGP-LS extensions for Segment Routing 935 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 936 segment-routing-epe-17 (work in progress), October 2018. 938 [I-D.ietf-idr-eag-distribution] 939 Wang, Z., Wu, Q., and J. Tantsura, "Distribution of MPLS- 940 TE Extended admin Group Using BGP", draft-ietf-idr-eag- 941 distribution-08 (work in progress), October 2018. 943 [I-D.ietf-idr-te-lsp-distribution] 944 Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler, 945 H., and J. Tantsura, "Distribution of Traffic Engineering 946 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 947 lsp-distribution-10 (work in progress), February 2019. 949 [I-D.ietf-idr-te-pm-bgp] 950 Ginsberg, L., Previdi, S., Wu, Q., Tantsura, J., and C. 951 Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering 952 Performance Metric Extensions", draft-ietf-idr-te-pm- 953 bgp-18 (work in progress), December 2018. 955 [I-D.ietf-lsr-flex-algo] 956 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 957 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 958 algo-01 (work in progress), November 2018. 960 [I-D.ketant-idr-bgp-ls-flex-algo] 961 Talaulikar, K., Psenak, P., Zandi, S., and G. Dawra, 962 "Flexible Algorithm Definition Advertisement with BGP 963 Link-State", draft-ketant-idr-bgp-ls-flex-algo-01 (work in 964 progress), February 2019. 966 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 967 Requirement Levels", BCP 14, RFC 2119, 968 DOI 10.17487/RFC2119, March 1997, 969 . 971 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 972 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 973 DOI 10.17487/RFC4271, January 2006, 974 . 976 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 977 S. Ray, "North-Bound Distribution of Link-State and 978 Traffic Engineering (TE) Information Using BGP", RFC 7752, 979 DOI 10.17487/RFC7752, March 2016, 980 . 982 11.2. Informative References 984 [I-D.ietf-idr-segment-routing-te-policy] 985 Previdi, S., Filsfils, C., Jain, D., Mattes, P., Rosen, 986 E., and S. Lin, "Advertising Segment Routing Policies in 987 BGP", draft-ietf-idr-segment-routing-te-policy-05 (work in 988 progress), November 2018. 990 [I-D.ietf-pce-segment-routing] 991 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 992 and J. Hardwick, "PCEP Extensions for Segment Routing", 993 draft-ietf-pce-segment-routing-16 (work in progress), 994 March 2019. 996 [I-D.ietf-spring-segment-routing-central-epe] 997 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 998 Afanasiev, "Segment Routing Centralized BGP Egress Peer 999 Engineering", draft-ietf-spring-segment-routing-central- 1000 epe-10 (work in progress), December 2017. 1002 [I-D.ietf-spring-segment-routing-msdc] 1003 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and P. 1004 Lapukhov, "BGP-Prefix Segment in large-scale data 1005 centers", draft-ietf-spring-segment-routing-msdc-11 (work 1006 in progress), November 2018. 1008 [I-D.ietf-spring-segment-routing-policy] 1009 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 1010 bogdanov@google.com, b., and P. Mattes, "Segment Routing 1011 Policy Architecture", draft-ietf-spring-segment-routing- 1012 policy-02 (work in progress), October 2018. 1014 [I-D.xu-idr-neighbor-autodiscovery] 1015 Xu, X., Talaulikar, K., Bi, K., Tantsura, J., and N. 1016 Triantafillis, "BGP Neighbor Discovery", draft-xu-idr- 1017 neighbor-autodiscovery-10 (work in progress), October 1018 2018. 1020 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1021 DOI 10.17487/RFC2328, April 1998, 1022 . 1024 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1025 (TE) Extensions to OSPF Version 2", RFC 3630, 1026 DOI 10.17487/RFC3630, September 2003, 1027 . 1029 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1030 RFC 4272, DOI 10.17487/RFC4272, January 2006, 1031 . 1033 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 1034 Management of New Protocols and Protocol Extensions", 1035 RFC 5706, DOI 10.17487/RFC5706, November 2009, 1036 . 1038 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1039 Measurement for MPLS Networks", RFC 6374, 1040 DOI 10.17487/RFC6374, September 2011, 1041 . 1043 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1044 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1045 and Authentication for Routing Protocols (KARP) Design 1046 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1047 . 1049 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 1050 BGP for Routing in Large-Scale Data Centers", RFC 7938, 1051 DOI 10.17487/RFC7938, August 2016, 1052 . 1054 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1055 Computation Element Communication Protocol (PCEP) 1056 Extensions for Stateful PCE", RFC 8231, 1057 DOI 10.17487/RFC8231, September 2017, 1058 . 1060 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1061 Computation Element Communication Protocol (PCEP) 1062 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1063 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1064 . 1066 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1067 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1068 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1069 July 2018, . 1071 Authors' Addresses 1073 Ketan Talaulikar 1074 Cisco Systems 1075 Pune 411057 1076 India 1078 Email: ketant@cisco.com 1080 Clarence Filsfils 1081 Cisco Systems 1082 Brussels 1083 Belgium 1085 Email: cfilsfil@cisco.com 1087 Krishna Swamy 1088 Cisco Systems 1089 San Jose 1090 USA 1092 Email: kriswamy@cisco.com 1094 Shawn Zandi 1095 LinkedIn 1096 USA 1098 Email: szandi@linkedin.com 1100 Gaurav Dawra 1101 LinkedIn 1102 USA 1104 Email: gdawra.ietf@gmail.com 1106 Muhammad Durrani 1107 Equinix 1108 USA 1110 Email: mdurrani@equinix.com