idnits 2.17.1 draft-ketant-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 3, 2018) is 2055 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-08 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-msd-02 == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-15 == Outdated reference: A later version (-19) exists of draft-ietf-idr-te-lsp-distribution-09 == Outdated reference: A later version (-18) exists of draft-ietf-idr-te-pm-bgp-10 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-04 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-12 == Outdated reference: A later version (-11) exists of draft-ietf-spring-segment-routing-msdc-09 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-01 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: March 7, 2019 Cisco Systems 6 S. Zandi 7 G. Dawra 8 LinkedIn 9 M. Durrani 10 Equinix 11 September 3, 2018 13 BGP Link-State Extensions for BGP-only Fabric 14 draft-ketant-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 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 March 7, 2019. 54 Copyright Notice 56 Copyright (c) 2018 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. Topology Collection Mechanism . . . . . . . . . . . . . . . . 3 73 3. Advertising BGP-only Network Topology . . . . . . . . . . . . 5 74 3.1. Node Advertisements . . . . . . . . . . . . . . . . . . . 5 75 3.2. Link Advertisements . . . . . . . . . . . . . . . . . . . 6 76 3.3. Prefix Advertisements . . . . . . . . . . . . . . . . . . 8 77 3.4. TE Policy Advertisements . . . . . . . . . . . . . . . . 9 78 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 4.1. Advertisement of Router's Node Attributes . . . . . . . . 10 80 4.2. Advertisement of Router's Local Links Attributes . . . . 11 81 4.3. Advertisement of Router's Prefix Attributes . . . . . . . 13 82 4.4. Advertisement of Router's TE Policy Attributes . . . . . 14 83 5. Usage of BGP Topology . . . . . . . . . . . . . . . . . . . . 14 84 5.1. Topology View for Monitoring . . . . . . . . . . . . . . 15 85 5.2. SR-TE in BGP Networks . . . . . . . . . . . . . . . . . . 15 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 87 7. Manageability Considerations . . . . . . . . . . . . . . . . 17 88 7.1. Operational Considerations . . . . . . . . . . . . . . . 17 89 7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 17 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 94 10.2. Informative References . . . . . . . . . . . . . . . . . 19 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 97 1. Introduction 99 Network operators are going for a BGP-only routing protocol for 100 certain networks like Massively Scaled Data Centers (MSDCs). BGP 101 MSDC [RFC7938] describes the requirement, design and operational 102 aspects for use of BGP as the only routing protocol in MSDCs. The 103 underlying link and topology information between BGP routers is 104 hidden or abstracted in this design from the underlay routing for 105 improving scalability and stability in a large scale network. On the 106 flip side, there is no detailed topology view similar to one 107 available in form of the Traffic Engineering (TE) Database (TED) when 108 running link state routing protocols like OSPF [RFC2328] with 109 extensions specified in OSPF-TE [RFC3630]. 111 BGP-LS [RFC7752] enables advertisement of a link state topology via 112 BGP that can be consumed by a controller or in general any software 113 component to get a complete topology view of the network. BGP-LS 114 extensions for advertisement of a BGP topology for the Egress Peer 115 Engineering (EPE) use-case SR Central EPE 116 [I-D.ietf-spring-segment-routing-central-epe] are specified in BGP-LS 117 EPE [I-D.ietf-idr-bgpls-segment-routing-epe]. This document 118 leverages the BGP-LS TLVs defined for BGP-LS EPE and other BGP-LS 119 documents and specifies the procedures for advertising the underlying 120 topology in a more generic BGP-only fabric use-case. 122 This document specifies the operations and procedures when using the 123 design involving EBGP single-hop sessions over direct point-to-point 124 links connecting the network nodes (refer BGP MSDC [RFC7938] for 125 details). Certain modifications and other considerations are 126 required when using a different design using IBGP or EGBP multihop 127 and these would be specified in a future version of this document. 128 While a data-center design is used as a reference, the procedures for 129 topology advertisement may also apply to other networks with BGP-only 130 fabric or to BGP-only portions of a larger network topology. 132 2. Topology Collection Mechanism 134 BGP-LS [RFC7752] has been defined to allow BGP to convey topology 135 information in the form of Link-State objects - node, link and 136 prefix. The properties of each of these objects are encoded as BGP- 137 LS attributes. Applications need a topological view and visibility 138 even for networks where BGP is the only routing protocol. In such 139 networks, each BGP router advertises its local information which 140 includes its node, links and prefix attributes via BGP-LS. 142 Figure 1 describes a typical deployment scenario. Every BGP router 143 in the network is enabled for BGP-LS and forms BGP-LS sessions with 144 one or more centralized BGP speakers over which it conveys its local 145 topology information. Each BGP router MAY receive the topology 146 information from all other BGP routers via the centralized BGP 147 speakers. This way, any BGP router (as also the centralized BGP 148 speakers) MAY obtain aggregated Link-State information for the entire 149 BGP network. An external component (e.g. a controller) can obtain 150 this information from the centralized BGP speakers or directly by 151 doing BGP-LS peering to the BGP routers. An internal software 152 component on any of the BGP routers (e.g. TE module) can also 153 receive the entire BGP network topology information from its local 154 BGP process. 156 +------------+ 157 | Controller | 158 +------------+ 159 ^ 160 | 161 v 162 +-------------------+ 163 | BGP Speaker | +------------+ 164 | (Centralized) | | Controller | 165 +-------------------+ +------------+ 166 ^ ^ ^ ^ 167 | | | | 168 +-----------+ | +---------------+ | 169 | | | | 170 v v v v 171 +-----------+ +-----------+ +-----------+ +-----------+ 172 | BGP | | BGP | | BGP | <-->| Local | 173 | Router | | Router | . . . | Router | | Consumer | 174 +-----------+ +-----------+ +-----------+ +-----------+ 175 ^ ^ ^ 176 | | | 177 Local Info Local Info Local Info 178 (node & links) (node & links) (node & links) 180 Figure 1: Link State info collection 182 The design described above relies on the base BGP IPv4 or IPv6 183 routing underlay or any other mechanism for reachability for the BGP- 184 LS session establishment with the centralized BGP speakers. Another 185 alternate design would be to enable BGP-LS as well on the hop by hop 186 EBGP sessions in the underlay. This approach results in the topology 187 information being flooded via BGP-LS hop-by-hop along the BGP routers 188 in the network. Other peering designs for BGP-LS sessions may also 189 be possible and they are not precluded by this document and may be 190 specified in a future version of this document. 192 3. Advertising BGP-only Network Topology 194 This sections specifies the BGP-LS TLVs and sub-TLVs and their use 195 for advertising the topology of a BGP-only network in the form of 196 BGP-LS Node, Link and Prefix NLRIs. 198 BGP-LS [RFC7752] defines the BGP-LS NLRI that can be a Node NLRI, a 199 Link NLRI or a Prefix NLRI. BGP-LS EPE 200 [I-D.ietf-idr-bgpls-segment-routing-epe] specifies the BGP Protocol 201 ID to be used for signaling EPE information and the same is used for 202 advertising of BGP topology as well. 204 BGP-LS TE [I-D.ietf-idr-te-lsp-distribution] defines the BGP-LS NLRI 205 that can be used to advertise the RSVP-TE or Segment Routing (SR) 206 policies instantiated on a BGP Router head-end along with their 207 properties and state. 209 The corresponding BGP-LS attribute is a Node Attribute, a Link 210 Attribute or a Prefix Attribute. BGP-LS [RFC7752] defines the TLVs 211 that map link-state information to BGP-LS NLRI and the BGP-LS 212 attribute. 214 3.1. Node Advertisements 216 BGP-LS [RFC7752] defines Node NLRI Type as follows and also defines 217 the Node Descriptor TLVs: 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+ 222 | Protocol-ID | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Identifier | 225 | (64 bits) | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 // Local Node Descriptors (variable) // 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 BGP-LS EPE [I-D.ietf-idr-bgpls-segment-routing-epe] introduces 231 additional Node Descriptor TLVs for BGP protocol for EPE use-case and 232 the same are used by this document. 234 The following Node Descriptors TLVs MUST appear in the Node NLRI as 235 Local Node Descriptors: 237 o BGP Router-ID, which contains the BGP Identifier of the 238 originating BGP router 240 o Autonomous System Number, which contains the advertising router 241 ASN. 243 The following Node Attribute TLVs are defined in respective documents 244 to signal the router properties and capabilities ( Section 4.1 245 defines the procedures for their advertisements): 247 +--------+--------------+-------------------------------------------+ 248 | TLV | Description | Reference Document | 249 | Code | | | 250 | Point | | | 251 +--------+--------------+-------------------------------------------+ 252 | 1026 | Node Name | [RFC7752] | 253 | 1161 | SID/Label | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 254 | 1034 | SRGB & | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 255 | | Capabilities | | 256 | 1036 | SR Local | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 257 | | Block | | 258 | 266 | Node MSD | [I-D.ietf-idr-bgp-ls-segment-routing-msd] | 259 +--------+--------------+-------------------------------------------+ 261 Table 1: Node Attribute TLVs 263 3.2. Link Advertisements 265 BGP-LS [RFC7752] defines Link NLRI Type as follows and also defines 266 the Node and Link Descriptor TLVs used: 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+ 271 | Protocol-ID | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Identifier | 274 | (64 bits) | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 // Local Node Descriptors (variable) // 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 // Remote Node Descriptors (variable) // 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 // Link Descriptors (variable) // 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 The following Node Descriptors TLVs MUST appear in the Link NLRI as 284 Local Node Descriptors: 286 o BGP Router-ID, which contains the BGP Identifier of the 287 originating BGP router 289 o Autonomous System Number, which contains the advertising router 290 ASN. 292 The following Node Descriptors TLVs MUST appear in the Link NLRI as 293 Remote Node Descriptors: 295 o BGP Router-ID, which contains the BGP Identifier of the peer BGP 296 router 298 o Autonomous System Number, which contains the peer ASN. 300 The following Link Descriptors TLVs MUST appear in the Link NLRI as 301 Link Descriptors: 303 o Link Local/Remote Identifiers containing the 4-octet Link Local 304 Identifier followed by the 4-octet value 0 indicating the Link 305 Remote Identifier is unknown 307 In addition, the following Link Descriptors TLVs SHOULD appear in the 308 Link NLRI as Link Descriptors based on the address family used for 309 setting up the BGP Peering: 311 o IPv4 Interface Address contains the address of the local interface 312 through which the BGP session is established using IPv4 address. 314 o IPv6 Interface Address contains the address of the local interface 315 through which the BGP session is established using IPv6 address. 317 o IPv4 Neighbor Address contains the IPv4 address of the peer 318 interface used by the BGP session establishment using IPv4 319 address. 321 o IPv6 Neighbor Address contains the IPv6 address of the peer 322 interface used by the BGP session establishment using IPv6 323 address. 325 The following Node Attribute TLVs are defined in respective documents 326 which are used to signal the router's local links' properties and 327 capabilities ( Section 4.2 defines the procedures for their 328 advertisements) : 330 +------+----------------+-------------------------------------------+ 331 | TLV | Description | Reference Document | 332 | Code | | | 333 | Poin | | | 334 | t | | | 335 +------+----------------+-------------------------------------------+ 336 | 1088 | Administrative | [RFC7752] | 337 | | group (color) | | 338 | 1089 | Maximum link | [RFC7752] | 339 | | bandwidth | | 340 | 1092 | TE Default | [RFC7752] | 341 | | Metric | | 342 | 1096 | SRLG | [RFC7752] | 343 | 1098 | Link Name | [RFC7752] | 344 | 267 | Link MSD | [I-D.ietf-idr-bgp-ls-segment-routing-msd] | 345 | 1172 | L2 Bundle | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 346 | | Member | | 347 | 1104 | Unidirectional | [I-D.ietf-idr-te-pm-bgp] | 348 | | link delay | | 349 | 1105 | Min/Max | [I-D.ietf-idr-te-pm-bgp] | 350 | | Unidirectional | | 351 | | link delay | | 352 | 1106 | Min/Max | [I-D.ietf-idr-te-pm-bgp] | 353 | | Unidirectional | | 354 | | link delay | | 355 | 1107 | Unidirectional | [I-D.ietf-idr-te-pm-bgp] | 356 | | packet loss | | 357 | 1101 | EPE Peer Node | [I-D.ietf-idr-bgpls-segment-routing-epe] | 358 | | SID | | 359 | 1102 | EPE Peer Adj | [I-D.ietf-idr-bgpls-segment-routing-epe] | 360 | | SID | | 361 | 1103 | EPE Peer Set | [I-D.ietf-idr-bgpls-segment-routing-epe] | 362 | | SID | | 363 +------+----------------+-------------------------------------------+ 365 Table 2: Link Attribute TLVs 367 3.3. Prefix Advertisements 369 BGP-LS [RFC7752] defines Prefix NLRI Type as follows and also defines 370 the Node and Prefix Descriptor TLVs used: 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+ 375 | Protocol-ID | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Identifier | 378 | (64 bits) | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 // Local Node Descriptors (variable) // 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 // Prefix Descriptors (variable) // 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 The following Node Descriptors TLVs MUST appear in the Node NLRI as 386 Local Node Descriptors: 388 o BGP Router-ID, which contains the BGP Identifier of the 389 originating BGP router 391 o Autonomous System Number, which contains the advertising router 392 ASN. 394 The Prefix Descriptor MUST contain the IP Reachability information 395 TLV to identify the prefix. 397 The following Prefix Attribute TLVs are defined in respective 398 documents which are used to signal the router's own prefix properties 399 and capabilities ( Section 4.3 defines the procedures for their 400 advertisements): 402 +---------+-------------+-------------------------------------------+ 403 | TLV | Description | Reference Document | 404 | Code | | | 405 | Point | | | 406 +---------+-------------+-------------------------------------------+ 407 | 1158 | Prefix SID | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 408 +---------+-------------+-------------------------------------------+ 410 Table 3: Prefix Attribute TLVs 412 3.4. TE Policy Advertisements 414 BGP-LS TE [I-D.ietf-idr-te-lsp-distribution] defines TE Policy NLRI 415 Type as follows and also defines the Headend Node and TE Policy 416 Descriptor TLVs used: 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+ 421 | Protocol-ID | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Identifier | 424 | (64 bits) | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 // Headend (Node Descriptors) // 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 // TE Policy Descriptors (variable) // 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 The Node Descriptors TLVs are the same as specified in Section 3.1. 432 The semantics for the TE Policy Descriptor TLVs and the its Attribute 433 TLVs are used as specified in BGP-LS TE 434 [I-D.ietf-idr-te-lsp-distribution]. 436 4. Procedures 438 In a network where BGP is the only routing protocol, the BGP-LS 439 session is used to advertise the necessary information about the 440 local node properties, its local links' properties and where 441 necessary the prefix's owned by the node. TE Policies, that are 442 instantiated on the local node (i.e. when it is the head-end for the 443 policy), along with their properties are also advertised via the BGP- 444 LS session. This information, once collected across all BGP routers 445 in the network, provides a complete topology view of the network. 446 Many of these attributes are not part of the base BGP protocol 447 operations and are either configured or provided by other components 448 on the router. BGP-LS performs the role of collecting this 449 information and propagating it across the BGP network. 451 The following sections describe the procedures for the propagation of 452 the BGP-LS NLRIs on a BGP router into the BGP-LS session. These 453 procedures for propagation of BGP topology information via BGP-LS 454 SHOULD be applied only in deployments and use-cases where necessary 455 and SHOULD NOT be applied in every BGP deployment when BGP-LS is 456 enabled. Implementations MAY provide a configuration option to 457 enable these procedures in required deployments. 459 4.1. Advertisement of Router's Node Attributes 461 Advertisement of the Node NLRI via BGP-LS by each BGP router in a 462 BGP-only network enables the discovery of all the router nodes in the 463 topology. The Node NLRI MUST be generated by a BGP router only for 464 itself and even when there are no attributes to be advertised along 465 with it. 467 The Node attributes defined currently related to SEGMENT ROUTING 468 [I-D.ietf-spring-segment-routing] have been described in Table 1 and 469 are to be advertised when SR is enabled. This includes: 471 o The Segment Routing Global Block (SRGB) provisioned on the router 472 which is used by BGP for BGP SR [I-D.ietf-idr-bgp-prefix-sid] and 473 other SR control plane protocols on the router MUST be advertised. 474 The value for Flags field in the TLV is not defined for BGP 475 protocol and MUST be set to 0 by the originator and ignored by 476 receivers. 478 o The Segment Routing Local Block (SRLB) provisioned on the router 479 which may be used by BGP for BGP-LS EPE 480 [I-D.ietf-idr-bgpls-segment-routing-epe] for BGP Peering SIDs 481 SHOULD be advertised. The value for Flags field in the TLV is not 482 defined for BGP protocol and MUST be set to 0 by the originator 483 and ignored by receivers. 485 o The Node level MSD provides the Node's capabilities for SR SID 486 operations and SHOULD be advertised. 488 The Node Name Attribute SHOULD be advertised when available. 490 This document introduces some of the TE concepts into BGP-only 491 networks. However, the advertisement and need for provisioning of a 492 TE Router-ID is not required. The BGP Router-ID along with the ASN 493 provides similar capability for uniquely identifying a BGP router in 494 the network. 496 Other Node Attributes applicable to a BGP Router may also be included 497 and this document does not describe the exhaustive list. 499 4.2. Advertisement of Router's Local Links Attributes 501 Each BGP router in a BGP-only network also advertises its local links 502 using the Link NLRIs thru BGP-LS. The Link NLRI for a given link 503 between two BGP routers is advertised as uni-directional logical 504 "half-link" and its link descriptors allow the correlation between 505 the two NLRIs "half-links" originated by the peering routers to 506 describe the bi-directional logical link and its attributes on both 507 routers. 509 A Link NLRI MUST be generated by a BGP router for each of its local 510 link over which it is establishing a BGP session to its neighbors. 511 The Link NLRI MUST be generated even when there are no link 512 attributes to be advertised for it. The Link NLRI represents a 513 peering adjacency between BGP routers and its association with the 514 underlying Layer 3 link. When the underlying Layer 3 link or the BGP 515 session on top of it goes down, the Link NLRI MUST be withdrawn by 516 the BGP router. Advertisement of the Link NLRIs via BGP-LS by each 517 BGP router in a BGP-only network enables the discovery of all the 518 active links in the topology. 520 The monitoring of links, detecting of their failures and notification 521 to BGP may be performed using mechanisms like BFD. When failures are 522 detected and the BGP session over it goes down, then the 523 corresponding Link NLRI is also withdrawn. This enables faster 524 detection of failures and verification of the underlying links. 526 The discovery of all the links in the BGP-only network relies on the 527 design that uses EBGP sessions over each interconnecting link using 528 the link IP addresses (refer BGP MSDC [RFC7938]). When doing EBGP 529 multi-hop sessions between directly connected BGP routers, the 530 underlying link information would need to learn by some discovery 531 protocol or provisioning entity. The mechanisms to learn the 532 underlying link information for BGP-LS advertisements are outside the 533 scope of this document. However, to provide a true link topology 534 picture, the advertisement of underlying links is RECOMMENDED for 535 most use-cases instead of a single EBGP peering representation of a 536 link between the routers. 538 TE attributes for links have been traditionally associated with Link 539 State Routing protocols. However, with the ability to discover the 540 link topology via BGP-LS as specified in this document, the TE 541 attributes and their principles can also be applied to a network 542 running BGP alone. The TE attributes for a link have been described 543 in Table 2 and are to be advertised when TE use-cases are enabled. 544 This includes: 546 o The maximum bandwidth of a link is its protocol independent 547 attribute and SHOULD be advertised. 549 o TE concepts of Administrative Groups (also known as affinities) 550 and Shared Risk Link Groups (SRLGs) MAY be provisioned locally on 551 links and then MUST be advertised. 553 o The BGP base protocol does not operate with link metrics, however, 554 a TE metric concept can be introduced in a BGP only network as 555 well for TE use-cases. Implementations MAY provide the ability to 556 provision TE metric value for a link for BGP use including a 557 different default value for it. The TE metric attribute SHOULD be 558 advertised for each link when configured and its default value is 559 taken as 1. When not advertised for a link, implementations who 560 intend to use the TE metric MUST assume the value to be 1. 562 o The delay and loss TE metrics for links are measured via MPLS 563 PerfMon [RFC6374] and their measurement mechanism over a link are 564 independent of the routing protocol. The same mechanism MAY be 565 enabled in BGP-only networks and their values advertised via BGP- 566 LS. 568 The Link attributes defined currently related to the Segment Routing 569 feature BGP-LS EPE [I-D.ietf-idr-bgpls-segment-routing-epe] have been 570 described in Table 2 and are to be advertised when SR use-cases are 571 enabled. This includes: 573 o The BGP Peering SIDs provide a functionality similar to Adjacency- 574 SID (refer SEGMENT ROUTING [I-D.ietf-spring-segment-routing] ) in 575 BGP-only networks. Implementations SHOULD allocate the BGP Peer- 576 Adjacency SID for all its links and the BGP Peer-Node SID for all 577 its peer routers. Implementations MAY allocate the BGP Peer-Set 578 SID based on local configuration. 580 o The Link level MSD provides the per link capabilities for SR SID 581 operations and SHOULD be advertised when the router links have 582 differing capabilities. 584 The use of Layer 3 bundle links which comprise of multiple layer 2 585 member links are often used in BGP networks. When BGP session is 586 configured over such a layer 3 link, the link attributes of the 587 underlying layer 2 links MAY be advertised individually using the L2 588 Bundle Member TLV. The applicable attributes for the L2 links are 589 described in BGP-LS SR [I-D.ietf-idr-bgp-ls-segment-routing-ext] . 591 The Link Name Attribute MAY be advertised when available. 593 Other Link Attributes applicable to a BGP Router may also be included 594 and this document does not describe the exhaustive list. 596 4.3. Advertisement of Router's Prefix Attributes 598 Advertisement of the Prefix NLRI via BGP-LS is required only in 599 specific use-cases. Since the base BGP protocol along with its 600 extensions already signals Prefix reachability via different NLRIs, 601 there is no necessity to always duplicate the information via BGP-LS 602 session. However, for specific use-cases related to SR Traffic 603 Engineering (SR-TE), it is required for each router to advertise it's 604 Prefix SID(s) (refer SEGMENT ROUTING 605 [I-D.ietf-spring-segment-routing]) that can be used to direct traffic 606 via specific BGP routers. Advertising such BGP Prefix SID for every 607 BGP router provides this key attribute via BGP-LS and avoids the 608 requirement for the consumer of the topology information (e.g. a 609 controller or local TE process) to tap into other BGP NLRI 610 information. 612 Advertisement of the Prefix NLRI via BGP-LS MUST be done only for its 613 locally configured prefixes (e.g. its loopback interface address) and 614 when BGP is advertising the BGP Prefix SID (BGP SR 615 [I-D.ietf-idr-bgp-prefix-sid]) for it. 617 The Prefix attributes defined currently related to SEGMENT ROUTING 618 [I-D.ietf-spring-segment-routing] have been described in Table 3 and 619 are to be advertised when SR is enabled. This includes: 621 o The BGP Prefix SID provisioned on the router for the prefix MUST 622 be advertised. The SID MUST be advertised as the index to be 623 consistent with the Label-Index TLV of BGP Prefix SID attribute. 624 The algorithm is not defined for BGP and MUST be set to 0 by the 625 originator and ignored by the receiver. The flags are defined as 626 the most significant 8 bits of the 16 bit field defined for Label- 627 Index TLV in BGP SR [I-D.ietf-idr-bgp-prefix-sid]. 629 Other Prefix Attributes applicable may also be included and this 630 document does not describe the exhaustive list. 632 4.4. Advertisement of Router's TE Policy Attributes 634 TE Policies that are setup using RSVP-TE or SR-TE mechanisms MAY be 635 instantiated on a BGP router. One use-case that results in such SR 636 Policy instantiation on a BGP router is described later in this 637 document in Section 5.2. Advertising such TE Policies instantiated 638 for every BGP router as head-end via BGP-LS provides the consumer of 639 the topology information (e.g. a controller or local TE process) a 640 policy view of the BGP fabric as well. 642 The procedures for advertisement of the TE Policy NLRI via BGP-LS 643 MUST be done only for its locally instantiated TE Policies and as 644 specified in BGP-LS TE [I-D.ietf-idr-te-lsp-distribution]). 645 Implementation MAY provide configuration options to control the 646 specific set of TE Policies that are to be advertised from the local 647 node. 649 5. Usage of BGP Topology 651 This section describes some of the use-cases for the building of the 652 BGP topology information as specified in this document and leveraging 653 it for enabling new functionality. 655 5.1. Topology View for Monitoring 657 The BGP-LS advertisement of the BGP topology as specified in this 658 document provides a live topology view of the BGP network for an 659 application or controller that is monitoring the network. The 660 topology view is from the BGP protocol perspective and includes the 661 underlying links as well that aids in network monitoring as well as 662 diagnostics use-cases. BGP-LS is the de-facto protocol for 663 northbound propagation of network topology related information for 664 most IGP networks and extending this capability for BGP-only networks 665 allows existing controllers and applications to consume the 666 information with some incremental BGP protocol awareness. 668 5.2. SR-TE in BGP Networks 670 The SR-TE use-case for BGP builds on top of the BGP SR 671 [I-D.ietf-idr-bgp-prefix-sid] functionality and also described in BGP 672 SR MSDC [I-D.ietf-spring-segment-routing-msdc].The BGP SR Prefix SID 673 signaled provides the basic connectivity between all BGP routers 674 using their loopback addresses. This provides the basic best-effort 675 paths in the network using the base BGP decision process that is 676 unchanged. BGP and other overlay routes and services recurse on top 677 of these loopback addresses of the egress nodes and the forwarding is 678 done via the BGP SR Prefix SID labels in the underlay. While this 679 version of the document focuses on the examples with MPLS dataplane 680 instantiation for SR, the same is applicable for the IPv6 dataplane 681 instantiation (SRv6) as well. 683 SR-TE for BGP provides underlay paths through the network for the 684 overlay routes and services with specific SLA requirements and use- 685 cases like path disjointness, low latency paths, inclusion or 686 exclusion and other TE considerations. 688 SR-TE [I-D.ietf-spring-segment-routing-policy] specifies the SR-TE 689 architecture and the SR Policy construct. The BGP SR-TE 690 [I-D.ietf-idr-segment-routing-te-policy] describes the extensions to 691 BGP for signaling of SR Policies from a controller to the SR-TE 692 headend BGP router. BGP-LS has been extended to allow signaling of 693 the SR Policies from SR-TE head-end to controllers via BGP-LS SR-TE 694 [I-D.ietf-idr-te-lsp-distribution] which allows the controllers to 695 learn the state of SR Policies instantiated on routers in the 696 network. This document completes the missing piece that is related 697 to getting the BGP topology information from all the routers to a 698 controller as well the local SRTE process on each router for their 699 path computation requirements. 701 The signaling of SR Polices from controller to SR-TE headend and 702 reporting of the state back to the controller can also be done using 703 PCEP (PCEP SR [I-D.ietf-pce-segment-routing], PCE Initiated 704 [RFC8281], PCEP Stateful [RFC8231]). However, the BGP topology 705 learning via BGP-LS which is specified in this document is also 706 required for the deployments that uses PCEP in the BGP-only network. 708 The topology collected via BGP-LS in a BGP-only fabric in a Segment 709 Routing deployment comprise of: 711 o The properties of every BGP router node and the Prefix SID to 712 reach that node. 714 o The properties of all the links between the BGP routers and the 715 Peer-Adjacency-SIDs (and other EPE SIDs) corresponding to them 716 that allow directing traffic over specific links and/or to 717 specific neighbors. 719 o The properties and state of the SR Policies instantiatied on each 720 of the BGP routers along with their end points, their properties 721 and most importantly the Binding SID to steer traffic into the SR 722 Policies. 724 This topology information allows a computation node to build SR 725 Policies for services over the BGP fabric for a given traffic 726 engineering objective at any given node. 728 The topology of the BGP fabric is distributed to a centralized 729 controller or application for use-cases that need a centralized 730 computation of SR Policy which can then be signaled to the SR-TE 731 head-end node via PCEP or BGP-SRTE. The topology is also available 732 at any node in the BGP fabric to be used by its local SR-TE process 733 to perform path computation for its own SR Policies for use-cases 734 that are addressed by local computation. 736 A high level summary of the key topology information advertised via 737 BGP-LS by BGP routers can be used for TE computations as follows 739 o The BGP SR Prefix SIDs and the BGP EPE Peering Adjacency SIDs 740 provide the equivalent of the IGP Prefix and Adjacency SIDs and 741 can be used to direct traffic to a specific BGP router and over a 742 specific BGP peer session or link respectively. Traffic for the 743 BGP SR Prefix SIDs follow the path computed by the BGP decision 744 process. 746 o The TE administrative group (also known as affinities) and SRLG 747 attributes can be configured over links to enable computation of 748 paths with inclusion and exclusion of specific links or paths that 749 are mutually disjoint. 751 o The enabling of link delay and loss measurements and their 752 advertisements can help monitoring the link quality and carve out 753 paths based on latency and other SLA requirements. 755 o The signaling of the Node and Link MSD allows controllers to 756 instantiate SR Policies based on the capability of the routers. 758 This section attempts to highlight and describe at a high level some 759 of the possible SR-TE solutions and use-cases in a BGP-only network. 760 Further details on these use-cases can be found in SR-TE 761 [I-D.ietf-spring-segment-routing-policy]. 763 6. IANA Considerations 765 None 767 7. Manageability Considerations 769 This section is structured as recommended in [RFC5706]. 771 7.1. Operational Considerations 773 7.1.1. Operations 775 Existing BGP and BGP-LS operational procedures apply. No additional 776 operation procedures are defined in this document. 778 8. Security Considerations 780 Procedures and protocol extensions defined in this document do not 781 affect the BGP security model. See the 'Security Considerations' 782 section of [RFC4271] for a discussion of BGP security. Also refer to 783 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 785 9. Acknowledgements 787 10. References 789 10.1. Normative References 791 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 792 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 793 and M. Chen, "BGP Link-State extensions for Segment 794 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-08 795 (work in progress), May 2018. 797 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 798 Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, 799 "Signaling MSD (Maximum SID Depth) using Border Gateway 800 Protocol Link-State", draft-ietf-idr-bgp-ls-segment- 801 routing-msd-02 (work in progress), August 2018. 803 [I-D.ietf-idr-bgp-prefix-sid] 804 Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A., 805 and H. Gredler, "Segment Routing Prefix SID extensions for 806 BGP", draft-ietf-idr-bgp-prefix-sid-27 (work in progress), 807 June 2018. 809 [I-D.ietf-idr-bgpls-segment-routing-epe] 810 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 811 Dong, "BGP-LS extensions for Segment Routing BGP Egress 812 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 813 epe-15 (work in progress), March 2018. 815 [I-D.ietf-idr-te-lsp-distribution] 816 Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler, 817 H., and J. Tantsura, "Distribution of Traffic Engineering 818 (TE) Policies and State using BGP-LS", draft-ietf-idr-te- 819 lsp-distribution-09 (work in progress), June 2018. 821 [I-D.ietf-idr-te-pm-bgp] 822 Ginsberg, L., Previdi, S., Wu, Q., Tantsura, J., and C. 823 Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering 824 Performance Metric Extensions", draft-ietf-idr-te-pm- 825 bgp-10 (work in progress), March 2018. 827 [I-D.ietf-spring-segment-routing] 828 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 829 Litkowski, S., and R. Shakir, "Segment Routing 830 Architecture", draft-ietf-spring-segment-routing-15 (work 831 in progress), January 2018. 833 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 834 Requirement Levels", BCP 14, RFC 2119, 835 DOI 10.17487/RFC2119, March 1997, 836 . 838 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 839 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 840 DOI 10.17487/RFC4271, January 2006, 841 . 843 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 844 S. Ray, "North-Bound Distribution of Link-State and 845 Traffic Engineering (TE) Information Using BGP", RFC 7752, 846 DOI 10.17487/RFC7752, March 2016, 847 . 849 10.2. Informative References 851 [I-D.ietf-idr-segment-routing-te-policy] 852 Previdi, S., Filsfils, C., Jain, D., Mattes, P., Rosen, 853 E., and S. Lin, "Advertising Segment Routing Policies in 854 BGP", draft-ietf-idr-segment-routing-te-policy-04 (work in 855 progress), July 2018. 857 [I-D.ietf-pce-segment-routing] 858 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 859 and J. Hardwick, "PCEP Extensions for Segment Routing", 860 draft-ietf-pce-segment-routing-12 (work in progress), June 861 2018. 863 [I-D.ietf-spring-segment-routing-central-epe] 864 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 865 Afanasiev, "Segment Routing Centralized BGP Egress Peer 866 Engineering", draft-ietf-spring-segment-routing-central- 867 epe-10 (work in progress), December 2017. 869 [I-D.ietf-spring-segment-routing-msdc] 870 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and P. 871 Lapukhov, "BGP-Prefix Segment in large-scale data 872 centers", draft-ietf-spring-segment-routing-msdc-09 (work 873 in progress), May 2018. 875 [I-D.ietf-spring-segment-routing-policy] 876 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 877 bogdanov@google.com, b., and P. Mattes, "Segment Routing 878 Policy Architecture", draft-ietf-spring-segment-routing- 879 policy-01 (work in progress), June 2018. 881 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 882 DOI 10.17487/RFC2328, April 1998, 883 . 885 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 886 (TE) Extensions to OSPF Version 2", RFC 3630, 887 DOI 10.17487/RFC3630, September 2003, 888 . 890 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 891 RFC 4272, DOI 10.17487/RFC4272, January 2006, 892 . 894 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 895 Management of New Protocols and Protocol Extensions", 896 RFC 5706, DOI 10.17487/RFC5706, November 2009, 897 . 899 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 900 Measurement for MPLS Networks", RFC 6374, 901 DOI 10.17487/RFC6374, September 2011, 902 . 904 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 905 BGP, LDP, PCEP, and MSDP Issues According to the Keying 906 and Authentication for Routing Protocols (KARP) Design 907 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 908 . 910 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 911 BGP for Routing in Large-Scale Data Centers", RFC 7938, 912 DOI 10.17487/RFC7938, August 2016, 913 . 915 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 916 Computation Element Communication Protocol (PCEP) 917 Extensions for Stateful PCE", RFC 8231, 918 DOI 10.17487/RFC8231, September 2017, 919 . 921 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 922 Computation Element Communication Protocol (PCEP) 923 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 924 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 925 . 927 Authors' Addresses 929 Ketan Talaulikar 930 Cisco Systems 931 Pune 411057 932 India 934 Email: ketant@cisco.com 935 Clarence Filsfils 936 Cisco Systems 937 Brussels 938 Belgium 940 Email: cfilsfil@cisco.com 942 Krishna Swamy 943 Cisco Systems 944 San Jose 945 USA 947 Email: kriswamy@cisco.com 949 Shawn Zandi 950 LinkedIn 951 USA 953 Email: szandi@linkedin.com 955 Gaurav Dawra 956 LinkedIn 957 USA 959 Email: gdawra.ietf@gmail.com 961 Muhammad Durrani 962 Equinix 963 USA 965 Email: mdurrani@equinix.com