idnits 2.17.1 draft-ketant-idr-bgp-ls-bgp-only-fabric-00.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 3, 2018) is 2236 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-04 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-msd-01 == Outdated reference: A later version (-27) exists of draft-ietf-idr-bgp-prefix-sid-17 == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-14 == Outdated reference: A later version (-19) exists of draft-ietf-idr-te-lsp-distribution-08 == Outdated reference: A later version (-18) exists of draft-ietf-idr-te-pm-bgp-09 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-06) exists of draft-filsfils-spring-segment-routing-policy-05 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-02 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-11 == Outdated reference: A later version (-11) exists of draft-ietf-spring-segment-routing-msdc-08 Summary: 1 error (**), 0 flaws (~~), 11 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 4, 2018 Cisco Systems 6 S. Zandi 7 G. Dawra 8 LinkedIn 9 March 3, 2018 11 BGP Link-State Extensions for BGP-only Fabric 12 draft-ketant-idr-bgp-ls-bgp-only-fabric-00 14 Abstract 16 BGP is used as the only routing protocol in some networks today. In 17 such networks, it is useful to get a detailed view of the nodes and 18 underlying links in the topology along with their attributes similar 19 to one available when using link state routing protocols. Such a 20 view of a BGP-only fabric enables use cases like traffic engineering 21 and forwarding of services along paths other than the BGP best path 22 selection. 24 This document defines extensions to the BGP Link-state address-family 25 (BGP-LS) and the procedures for advertisement of the topology in a 26 BGP-only network. It also describes a specific use-case for traffic 27 engineering based on Segment Routing. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on September 4, 2018. 51 Copyright Notice 53 Copyright (c) 2018 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Topology Collection Mechanism . . . . . . . . . . . . . . . . 3 70 3. Advertising BGP-only Network Topology . . . . . . . . . . . . 5 71 3.1. Node Advertisements . . . . . . . . . . . . . . . . . . . 5 72 3.2. Link Advertisements . . . . . . . . . . . . . . . . . . . 6 73 3.3. Prefix Advertisements . . . . . . . . . . . . . . . . . . 8 74 3.4. TE Policy Advertisements . . . . . . . . . . . . . . . . 9 75 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.1. Advertisement of Router's Node Attributes . . . . . . . . 10 77 4.2. Advertisement of Router's Local Links Attributes . . . . 11 78 4.3. Advertisement of Router's Prefix Attributes . . . . . . . 13 79 4.4. Advertisement of Router's TE Policy Attributes . . . . . 14 80 5. Usage of BGP Topology . . . . . . . . . . . . . . . . . . . . 14 81 5.1. Topology View for Monitoring . . . . . . . . . . . . . . 15 82 5.2. SR-TE in BGP Networks . . . . . . . . . . . . . . . . . . 15 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 7. Manageability Considerations . . . . . . . . . . . . . . . . 17 85 7.1. Operational Considerations . . . . . . . . . . . . . . . 17 86 7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 17 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 91 10.2. Informative References . . . . . . . . . . . . . . . . . 19 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 94 1. Introduction 96 Network operators are going for a BGP-only routing protocol for 97 certain networks like Massively Scaled Data Centers (MSDCs). BGP 98 MSDC [RFC7938] describes the requirement, design and operational 99 aspects for use of BGP as the only routing protocol in MSDCs. The 100 underlying link and topology information between BGP routers is 101 hidden or abstracted in this design from the underlay routing for 102 improving scalability and stability in a large scale network. On the 103 flip side, there is no detailed topology view similar to one 104 available in form of the Traffic Engineering (TE) Database (TED) when 105 running link state routing protocols like OSPF [RFC2328] with 106 extensions specified in OSPF-TE [RFC3630]. 108 BGP-LS [RFC7752] enables advertisement of a link state topology via 109 BGP that can be consumed by a controller or in general any software 110 component to get a complete topology view of the network. BGP-LS 111 extensions for advertisement of a BGP topology for the Egress Peer 112 Engineering (EPE) use-case SR Central EPE 113 [I-D.ietf-spring-segment-routing-central-epe] are specified in BGP-LS 114 EPE [I-D.ietf-idr-bgpls-segment-routing-epe]. This document 115 leverages the BGP-LS TLVs defined for BGP-LS EPE and other BGP-LS 116 documents and specifies the procedures for advertising the underlying 117 topology in a more generic BGP-only fabric use-case. 119 This document specifies the operations and procedures when using the 120 design involving EBGP single-hop sessions over direct point-to-point 121 links connecting the network nodes (refer BGP MSDC [RFC7938] for 122 details). Certain modifications and other considerations are 123 required when using a different design using IBGP or EGBP multihop 124 and these would be specified in a future version of this document. 125 While a data-center design is used as a reference, the procedures for 126 topology advertisement may also apply to other networks with BGP-only 127 fabric or to BGP-only portions of a larger network topology. 129 2. Topology Collection Mechanism 131 BGP-LS [RFC7752] has been defined to allow BGP to convey topology 132 information in the form of Link-State objects - node, link and 133 prefix. The properties of each of these objects are encoded as BGP- 134 LS attributes. Applications need a topological view and visibility 135 even for networks where BGP is the only routing protocol. In such 136 networks, each BGP router advertises its local information which 137 includes its node, links and prefix attributes via BGP-LS. 139 Figure 1 describes a typical deployment scenario. Every BGP router 140 in the network is enabled for BGP-LS and forms BGP-LS sessions with 141 one or more centralized BGP speakers over which it conveys its local 142 topology information. Each BGP router MAY receive the topology 143 information from all other BGP routers via the centralized BGP 144 speakers. This way, any BGP router (as also the centralized BGP 145 speakers) MAY obtain aggregated Link-State information for the entire 146 BGP network. An external component (e.g. a controller) can obtain 147 this information from the centralized BGP speakers or directly by 148 doing BGP-LS peering to the BGP routers. An internal software 149 component on any of the BGP routers (e.g. TE module) can also 150 receive the entire BGP network topology information from its local 151 BGP process. 153 +------------+ 154 | Consumer | 155 +------------+ 156 ^ 157 | 158 v 159 +-------------------+ 160 | BGP Speaker | +-----------+ 161 | (Centralized) | | Consumer | 162 +-------------------+ +-----------+ 163 ^ ^ ^ ^ 164 | | | | 165 +-----------+ | +---------------+ | 166 | | | | 167 v v v v 168 +-----------+ +-----------+ +-----------+ +-----------+ 169 | BGP | | BGP | | BGP | <-->| Local | 170 | Router | | Router | . . . | Router | | Consumer | 171 +-----------+ +-----------+ +-----------+ +-----------+ 172 ^ ^ ^ 173 | | | 174 Local Info Local Info Local Info 175 (node & links) (node & links) (node & links) 177 Figure 1: Link State info collection 179 The design described above relies on the base BGP IPv4 or IPv6 180 routing underlay or any other mechanism for reachability for the BGP- 181 LS session establishment with the centralized BGP speakers. Another 182 alternate design would be to enable BGP-LS as well on the hop by hop 183 EBGP sessions in the underlay. This approach results in the topology 184 information being flooded via BGP-LS hop-by-hop along the BGP routers 185 in the network. Other peering designs for BGP-LS sessions may also 186 be possible and they are not precluded by this document and may be 187 specified in a future version of this document. 189 3. Advertising BGP-only Network Topology 191 This sections specifies the BGP-LS TLVs and sub-TLVs and their use 192 for advertising the topology of a BGP-only network in the form of 193 BGP-LS Node, Link and Prefix NLRIs. 195 BGP-LS [RFC7752] defines the BGP-LS NLRI that can be a Node NLRI, a 196 Link NLRI or a Prefix NLRI. BGP-LS EPE 197 [I-D.ietf-idr-bgpls-segment-routing-epe] specifies the BGP Protocol 198 ID to be used for signaling EPE information and the same is used for 199 advertising of BGP topology as well. 201 BGP-LS TE [I-D.ietf-idr-te-lsp-distribution] defines the BGP-LS NLRI 202 that can be used to advertise the RSVP-TE or Segment Routing (SR) 203 policies instantiated on a BGP Router head-end along with their 204 properties and state. 206 The corresponding BGP-LS attribute is a Node Attribute, a Link 207 Attribute or a Prefix Attribute. BGP-LS [RFC7752] defines the TLVs 208 that map link-state information to BGP-LS NLRI and the BGP-LS 209 attribute. 211 3.1. Node Advertisements 213 BGP-LS [RFC7752] defines Node NLRI Type as follows and also defines 214 the Node Descriptor TLVs: 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+ 219 | Protocol-ID | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Identifier | 222 | (64 bits) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 // Local Node Descriptors (variable) // 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 BGP-LS EPE [I-D.ietf-idr-bgpls-segment-routing-epe] introduces 228 additional Node Descriptor TLVs for BGP protocol for EPE use-case and 229 the same are used by this document. 231 The following Node Descriptors TLVs MUST appear in the Node NLRI as 232 Local Node Descriptors: 234 o BGP Router-ID, which contains the BGP Identifier of the 235 originating BGP router 237 o Autonomous System Number, which contains the advertising router 238 ASN. 240 The following Node Attribute TLVs are defined in respective documents 241 to signal the router properties and capabilities ( Section 4.1 242 defines the procedures for their advertisements): 244 +--------+--------------+-------------------------------------------+ 245 | TLV | Description | Reference Document | 246 | Code | | | 247 | Point | | | 248 +--------+--------------+-------------------------------------------+ 249 | 1026 | Node Name | [RFC7752] | 250 | 1161 | SID/Label | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 251 | 1034 | SRGB & | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 252 | | Capabilities | | 253 | 1036 | SR Local | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 254 | | Block | | 255 | 266 | Node MSD | [I-D.ietf-idr-bgp-ls-segment-routing-msd] | 256 +--------+--------------+-------------------------------------------+ 258 Table 1: Node Attribute TLVs 260 3.2. Link Advertisements 262 BGP-LS [RFC7752] defines Link NLRI Type as follows and also defines 263 the Node and Link Descriptor TLVs used: 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+ 268 | Protocol-ID | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Identifier | 271 | (64 bits) | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 // Local Node Descriptors (variable) // 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 // Remote Node Descriptors (variable) // 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 // Link Descriptors (variable) // 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 The following Node Descriptors TLVs MUST appear in the Link NLRI as 281 Local Node Descriptors: 283 o BGP Router-ID, which contains the BGP Identifier of the 284 originating BGP router 286 o Autonomous System Number, which contains the advertising router 287 ASN. 289 The following Node Descriptors TLVs MUST appear in the Link NLRI as 290 Remote Node Descriptors: 292 o BGP Router-ID, which contains the BGP Identifier of the peer BGP 293 router 295 o Autonomous System Number, which contains the peer ASN. 297 The following Link Descriptors TLVs MUST appear in the Link NLRI as 298 Link Descriptors: 300 o Link Local/Remote Identifiers containing the 4-octet Link Local 301 Identifier followed by the 4-octet value 0 indicating the Link 302 Remote Identifier is unknown 304 In addition, the following Link Descriptors TLVs SHOULD appear in the 305 Link NLRI as Link Descriptors based on the address family used for 306 setting up the BGP Peering: 308 o IPv4 Interface Address contains the address of the local interface 309 through which the BGP session is established using IPv4 address. 311 o IPv6 Interface Address contains the address of the local interface 312 through which the BGP session is established using IPv6 address. 314 o IPv4 Neighbor Address contains the IPv4 address of the peer 315 interface used by the BGP session establishment using IPv4 316 address. 318 o IPv6 Neighbor Address contains the IPv6 address of the peer 319 interface used by the BGP session establishment using IPv6 320 address. 322 The following Node Attribute TLVs are defined in respective documents 323 which are used to signal the router's local links' properties and 324 capabilities ( Section 4.2 defines the procedures for their 325 advertisements) : 327 +------+----------------+-------------------------------------------+ 328 | TLV | Description | Reference Document | 329 | Code | | | 330 | Poin | | | 331 | t | | | 332 +------+----------------+-------------------------------------------+ 333 | 1088 | Administrative | [RFC7752] | 334 | | group (color) | | 335 | 1089 | Maximum link | [RFC7752] | 336 | | bandwidth | | 337 | 1092 | TE Default | [RFC7752] | 338 | | Metric | | 339 | 1096 | SRLG | [RFC7752] | 340 | 1098 | Link Name | [RFC7752] | 341 | 267 | Link MSD | [I-D.ietf-idr-bgp-ls-segment-routing-msd] | 342 | 1172 | L2 Bundle | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 343 | | Member | | 344 | 1104 | Unidirectional | [I-D.ietf-idr-te-pm-bgp] | 345 | | link delay | | 346 | 1105 | Min/Max | [I-D.ietf-idr-te-pm-bgp] | 347 | | Unidirectional | | 348 | | link delay | | 349 | 1106 | Min/Max | [I-D.ietf-idr-te-pm-bgp] | 350 | | Unidirectional | | 351 | | link delay | | 352 | 1107 | Unidirectional | [I-D.ietf-idr-te-pm-bgp] | 353 | | packet loss | | 354 | 1101 | EPE Peer Node | [I-D.ietf-idr-bgpls-segment-routing-epe] | 355 | | SID | | 356 | 1102 | EPE Peer Adj | [I-D.ietf-idr-bgpls-segment-routing-epe] | 357 | | SID | | 358 | 1103 | EPE Peer Set | [I-D.ietf-idr-bgpls-segment-routing-epe] | 359 | | SID | | 360 +------+----------------+-------------------------------------------+ 362 Table 2: Link Attribute TLVs 364 3.3. Prefix Advertisements 366 BGP-LS [RFC7752] defines Prefix NLRI Type as follows and also defines 367 the Node and Prefix Descriptor TLVs used: 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+ 372 | Protocol-ID | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Identifier | 375 | (64 bits) | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 // Local Node Descriptors (variable) // 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 // Prefix Descriptors (variable) // 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 The following Node Descriptors TLVs MUST appear in the Node NLRI as 383 Local Node Descriptors: 385 o BGP Router-ID, which contains the BGP Identifier of the 386 originating BGP router 388 o Autonomous System Number, which contains the advertising router 389 ASN. 391 The Prefix Descriptor MUST contain the IP Reachability information 392 TLV to identify the prefix. 394 The following Prefix Attribute TLVs are defined in respective 395 documents which are used to signal the router's own prefix properties 396 and capabilities ( Section 4.3 defines the procedures for their 397 advertisements): 399 +---------+-------------+-------------------------------------------+ 400 | TLV | Description | Reference Document | 401 | Code | | | 402 | Point | | | 403 +---------+-------------+-------------------------------------------+ 404 | 1158 | Prefix SID | [I-D.ietf-idr-bgp-ls-segment-routing-ext] | 405 +---------+-------------+-------------------------------------------+ 407 Table 3: Prefix Attribute TLVs 409 3.4. TE Policy Advertisements 411 BGP-LS TE [I-D.ietf-idr-te-lsp-distribution] defines TE Policy NLRI 412 Type as follows and also defines the Headend Node and TE Policy 413 Descriptor TLVs used: 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+ 418 | Protocol-ID | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Identifier | 421 | (64 bits) | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 // Headend (Node Descriptors) // 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 // TE Policy Descriptors (variable) // 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 The Node Descriptors TLVs are the same as specified in Section 3.1. 429 The semantics for the TE Policy Descriptor TLVs and the its Attribute 430 TLVs are used as specified in BGP-LS TE 431 [I-D.ietf-idr-te-lsp-distribution]. 433 4. Procedures 435 In a network where BGP is the only routing protocol, the BGP-LS 436 session is used to advertise the necessary information about the 437 local node properties, its local links' properties and where 438 necessary the prefix's owned by the node. TE Policies, that are 439 instantiated on the local node (i.e. when it is the head-end for the 440 policy), along with their properties are also advertised via the BGP- 441 LS session. This information, once collected across all BGP routers 442 in the network, provides a complete topology view of the network. 443 Many of these attributes are not part of the base BGP protocol 444 operations and are either configured or provided by other components 445 on the router. BGP-LS performs the role of collecting this 446 information and propagating it across the BGP network. 448 The following sections describe the procedures for the propagation of 449 the BGP-LS NLRIs on a BGP router into the BGP-LS session. These 450 procedures for propagation of BGP topology information via BGP-LS 451 SHOULD be applied only in deployments and use-cases where necessary 452 and SHOULD NOT be applied in every BGP deployment when BGP-LS is 453 enabled. Implementations MAY provide a configuration option to 454 enable these procedures in required deployments. 456 4.1. Advertisement of Router's Node Attributes 458 Advertisement of the Node NLRI via BGP-LS by each BGP router in a 459 BGP-only network enables the discovery of all the router nodes in the 460 topology. The Node NLRI MUST be generated by a BGP router only for 461 itself and even when there are no attributes to be advertised along 462 with it. 464 The Node attributes defined currently related to SEGMENT ROUTING 465 [I-D.ietf-spring-segment-routing] have been described in Table 1 and 466 are to be advertised when SR is enabled. This includes: 468 o The Segment Routing Global Block (SRGB) provisioned on the router 469 which is used by BGP for BGP SR [I-D.ietf-idr-bgp-prefix-sid] and 470 other SR control plane protocols on the router MUST be advertised. 471 The value for Flags field in the TLV is not defined for BGP 472 protocol and MUST be set to 0 by the originator and ignored by 473 receivers. 475 o The Segment Routing Local Block (SRLB) provisioned on the router 476 which may be used by BGP for BGP-LS EPE 477 [I-D.ietf-idr-bgpls-segment-routing-epe] for BGP Peering SIDs 478 SHOULD be advertised. The value for Flags field in the TLV is not 479 defined for BGP protocol and MUST be set to 0 by the originator 480 and ignored by receivers. 482 o The Node level MSD provides the Node's capabilities for SR SID 483 operations and SHOULD be advertised. 485 The Node Name Attribute SHOULD be advertised when available. 487 This document introduces some of the TE concepts into BGP-only 488 networks. However, the advertisement and need for provisioning of a 489 TE Router-ID is not required. The BGP Router-ID along with the ASN 490 provides similar capability for uniquely identifying a BGP router in 491 the network. 493 Other Node Attributes applicable to a BGP Router may also be included 494 and this document does not describe the exhaustive list. 496 4.2. Advertisement of Router's Local Links Attributes 498 Each BGP router in a BGP-only network also advertises its local links 499 using the Link NLRIs thru BGP-LS. The Link NLRI for a given link 500 between two BGP routers is advertised as uni-directional logical 501 "half-link" and its link descriptors allow the correlation between 502 the two NLRIs "half-links" originated by the peering routers to 503 describe the bi-directional logical link and its attributes on both 504 routers. 506 A Link NLRI MUST be generated by a BGP router for each of its local 507 link over which it is establishing a BGP session to its neighbors. 508 The Link NLRI MUST be generated even when there are no link 509 attributes to be advertised for it. The Link NLRI represents a 510 peering adjacency between BGP routers and its association with the 511 underlying Layer 3 link. When the underlying Layer 3 link or the BGP 512 session on top of it goes down, the Link NLRI MUST be withdrawn by 513 the BGP router. Advertisement of the Link NLRIs via BGP-LS by each 514 BGP router in a BGP-only network enables the discovery of all the 515 active links in the topology. 517 The monitoring of links, detecting of their failures and notification 518 to BGP may be performed using mechanisms like BFD. When failures are 519 detected and the BGP session over it goes down, then the 520 corresponding Link NLRI is also withdrawn. This enables faster 521 detection of failures and verification of the underlying links. 523 The discovery of all the links in the BGP-only network relies on the 524 design that uses EBGP sessions over each interconnecting link using 525 the link IP addresses (refer BGP MSDC [RFC7938]). When doing EBGP 526 multi-hop sessions between directly connected BGP routers, the 527 underlying link information would need to learn by some discovery 528 protocol or provisioning entity. The mechanisms to learn the 529 underlying link information for BGP-LS advertisements are outside the 530 scope of this document. However, to provide a true link topology 531 picture, the advertisement of underlying links is RECOMMENDED for 532 most use-cases instead of a single EBGP peering representation of a 533 link between the routers. 535 TE attributes for links have been traditionally associated with Link 536 State Routing protocols. However, with the ability to discover the 537 link topology via BGP-LS as specified in this document, the TE 538 attributes and their principles can also be applied to a network 539 running BGP alone. The TE attributes for a link have been described 540 in Table 2 and are to be advertised when TE use-cases are enabled. 541 This includes: 543 o The maximum bandwidth of a link is its protocol independent 544 attribute and SHOULD be advertised. 546 o TE concepts of Administrative Groups (also known as affinities) 547 and Shared Risk Link Groups (SRLGs) MAY be provisioned locally on 548 links and then MUST be advertised. 550 o The BGP base protocol does not operate with link metrics, however, 551 a TE metric concept can be introduced in a BGP only network as 552 well for TE use-cases. Implementations MAY provide the ability to 553 provision TE metric value for a link for BGP use including a 554 different default value for it. The TE metric attribute SHOULD be 555 advertised for each link when configured and its default value is 556 taken as 1. When not advertised for a link, implementations who 557 intend to use the TE metric MUST assume the value to be 1. 559 o The delay and loss TE metrics for links are measured via MPLS 560 PerfMon [RFC6374] and their measurement mechanism over a link are 561 independent of the routing protocol. The same mechanism MAY be 562 enabled in BGP-only networks and their values advertised via BGP- 563 LS. 565 The Link attributes defined currently related to the Segment Routing 566 feature BGP-LS EPE [I-D.ietf-idr-bgpls-segment-routing-epe] have been 567 described in Table 2 and are to be advertised when SR use-cases are 568 enabled. This includes: 570 o The BGP Peering SIDs provide a functionality similar to Adjacency- 571 SID (refer SEGMENT ROUTING [I-D.ietf-spring-segment-routing] ) in 572 BGP-only networks. Implementations SHOULD allocate the BGP Peer- 573 Adjacency SID for all its links and the BGP Peer-Node SID for all 574 its peer routers. Implementations MAY allocate the BGP Peer-Set 575 SID based on local configuration. 577 o The Link level MSD provides the per link capabilities for SR SID 578 operations and SHOULD be advertised when the router links have 579 differing capabilities. 581 The use of Layer 3 bundle links which comprise of multiple layer 2 582 member links are often used in BGP networks. When BGP session is 583 configured over such a layer 3 link, the link attributes of the 584 underlying layer 2 links MAY be advertised individually using the L2 585 Bundle Member TLV. The applicable attributes for the L2 links are 586 described in BGP-LS SR [I-D.ietf-idr-bgp-ls-segment-routing-ext] . 588 The Link Name Attribute MAY be advertised when available. 590 Other Link Attributes applicable to a BGP Router may also be included 591 and this document does not describe the exhaustive list. 593 4.3. Advertisement of Router's Prefix Attributes 595 Advertisement of the Prefix NLRI via BGP-LS is required only in 596 specific use-cases. Since the base BGP protocol along with its 597 extensions already signals Prefix reachability via different NLRIs, 598 there is no necessity to always duplicate the information via BGP-LS 599 session. However, for specific use-cases related to SR Traffic 600 Engineering (SR-TE), it is required for each router to advertise it's 601 Prefix SID(s) (refer SEGMENT ROUTING 602 [I-D.ietf-spring-segment-routing]) that can be used to direct traffic 603 via specific BGP routers. Advertising such BGP Prefix SID for every 604 BGP router provides this key attribute via BGP-LS and avoids the 605 requirement for the consumer of the topology information (e.g. a 606 controller or local TE process) to tap into other BGP NLRI 607 information. 609 Advertisement of the Prefix NLRI via BGP-LS MUST be done only for its 610 locally configured prefixes (e.g. its loopback interface address) and 611 when BGP is advertising the BGP Prefix SID (BGP SR 612 [I-D.ietf-idr-bgp-prefix-sid]) for it. 614 The Prefix attributes defined currently related to SEGMENT ROUTING 615 [I-D.ietf-spring-segment-routing] have been described in Table 3 and 616 are to be advertised when SR is enabled. This includes: 618 o The BGP Prefix SID provisioned on the router for the prefix MUST 619 be advertised. The SID MUST be advertised as the index to be 620 consistent with the Label-Index TLV of BGP Prefix SID attribute. 621 The algorithm is not defined for BGP and MUST be set to 0 by the 622 originator and ignored by the receiver. The flags are defined as 623 the most significant 8 bits of the 16 bit field defined for Label- 624 Index TLV in BGP SR [I-D.ietf-idr-bgp-prefix-sid]. 626 Other Prefix Attributes applicable may also be included and this 627 document does not describe the exhaustive list. 629 4.4. Advertisement of Router's TE Policy Attributes 631 TE Policies that are setup using RSVP-TE or SR-TE mechanisms MAY be 632 instantiated on a BGP router. One use-case that results in such SR 633 Policy instantiation on a BGP router is described later in this 634 document in Section 5.2. Advertising such TE Policies instantiated 635 for every BGP router as head-end via BGP-LS provides the consumer of 636 the topology information (e.g. a controller or local TE process) a 637 policy view of the BGP fabric as well. 639 The procedures for advertisement of the TE Policy NLRI via BGP-LS 640 MUST be done only for its locally instantiated TE Policies and as 641 specified in BGP-LS TE [I-D.ietf-idr-te-lsp-distribution]). 642 Implementation MAY provide configuration options to control the 643 specific set of TE Policies that are to be advertised from the local 644 node. 646 5. Usage of BGP Topology 648 This section describes some of the use-cases for the building of the 649 BGP topology information as specified in this document and leveraging 650 it for enabling new functionality. 652 5.1. Topology View for Monitoring 654 The BGP-LS advertisement of the BGP topology as specified in this 655 document provides a live topology view of the BGP network for an 656 application or controller that is monitoring the network. The 657 topology view is from the BGP protocol perspective and includes the 658 underlying links as well that aids in network monitoring as well as 659 diagnostics use-cases. BGP-LS is the de-facto protocol for 660 northbound propagation of network topology related information for 661 most IGP networks and extending this capability for BGP-only networks 662 allows existing controllers and applications to consume the 663 information with some incremental BGP protocol awareness. 665 5.2. SR-TE in BGP Networks 667 The SR-TE use-case for BGP builds on top of the BGP SR 668 [I-D.ietf-idr-bgp-prefix-sid] functionality and also described in BGP 669 SR MSDC [I-D.ietf-spring-segment-routing-msdc].The BGP SR Prefix SID 670 signaled provides the basic connectivity between all BGP routers 671 using their loopback addresses. This provides the basic best-effort 672 paths in the network using the base BGP decision process that is 673 unchanged. BGP and other overlay routes and services recurse on top 674 of these loopback addresses of the egress nodes and the forwarding is 675 done via the BGP SR Prefix SID labels in the underlay. While this 676 version of the document focuses on the examples with MPLS dataplane 677 instantiation for SR, the same is applicable for the IPv6 dataplane 678 instantiation (SRv6) as well. 680 SR-TE for BGP provides underlay paths through the network for the 681 overlay routes and services with specific SLA requirements and use- 682 cases like path disjointness, low latency paths, inclusion or 683 exclusion and other TE considerations. 685 SR-TE [I-D.filsfils-spring-segment-routing-policy] specifies the SR- 686 TE architecture and the SR Policy construct. The BGP SR-TE 687 [I-D.ietf-idr-segment-routing-te-policy] describes the extensions to 688 BGP for signaling of SR Policies from a controller to the SR-TE 689 headend BGP router. BGP-LS has been extended to allow signaling of 690 the SR Policies from SR-TE head-end to controllers via BGP-LS SR-TE 691 [I-D.ietf-idr-te-lsp-distribution] which allows the controllers to 692 learn the state of SR Policies instantiated on routers in the 693 network. This document completes the missing piece that is related 694 to getting the BGP topology information from all the routers to a 695 controller as well the local SRTE process on each router for their 696 path computation requirements. 698 The signaling of SR Polices from controller to SR-TE headend and 699 reporting of the state back to the controller can also be done using 700 PCEP (PCEP SR [I-D.ietf-pce-segment-routing], PCE Initiated 701 [RFC8281], PCEP Stateful [RFC8231]). However, the BGP topology 702 learning via BGP-LS which is specified in this document is also 703 required for the deployments that uses PCEP in the BGP-only network. 705 The topology collected via BGP-LS in a BGP-only fabric in a Segment 706 Routing deployment comprise of: 708 o The properties of every BGP router node and the Prefix SID to 709 reach that node. 711 o The properties of all the links between the BGP routers and the 712 Peer-Adjacency-SIDs (and other EPE SIDs) corresponding to them 713 that allow directing traffic over specific links and/or to 714 specific neighbors. 716 o The properties and state of the SR Policies instantiatied on each 717 of the BGP routers along with their end points, their properties 718 and most importantly the Binding SID to steer traffic into the SR 719 Policies. 721 This topology information allows a computation node to build SR 722 Policies for services over the BGP fabric for a given traffic 723 engineering objective at any given node. 725 The topology of the BGP fabric is distributed to a centralized 726 controller or application for use-cases that need a centralized 727 computation of SR Policy which can then be signaled to the SR-TE 728 head-end node via PCEP or BGP-SRTE. The topology is also available 729 at any node in the BGP fabric to be used by its local SR-TE process 730 to perform path computation for its own SR Policies for use-cases 731 that are addressed by local computation. 733 A high level summary of the key topology information advertised via 734 BGP-LS by BGP routers can be used for TE computations as follows 736 o The BGP SR Prefix SIDs and the BGP EPE Peering Adjacency SIDs 737 provide the equivalent of the IGP Prefix and Adjacency SIDs and 738 can be used to direct traffic to a specific BGP router and over a 739 specific BGP peer session or link respectively. Traffic for the 740 BGP SR Prefix SIDs follow the path computed by the BGP decision 741 process. 743 o The TE administrative group (also known as affinities) and SRLG 744 attributes can be configured over links to enable computation of 745 paths with inclusion and exclusion of specific links or paths that 746 are mutually disjoint. 748 o The enabling of link delay and loss measurements and their 749 advertisements can help monitoring the link quality and carve out 750 paths based on latency and other SLA requirements. 752 o The signaling of the Node and Link MSD allows controllers to 753 instantiate SR Policies based on the capability of the routers. 755 This section attempts to highlight and describe at a high level some 756 of the possible SR-TE solutions and use-cases in a BGP-only network. 757 Further details on these use-cases can be found in SR-TE 758 [I-D.filsfils-spring-segment-routing-policy]. 760 6. IANA Considerations 762 None 764 7. Manageability Considerations 766 This section is structured as recommended in [RFC5706]. 768 7.1. Operational Considerations 770 7.1.1. Operations 772 Existing BGP and BGP-LS operational procedures apply. No additional 773 operation procedures are defined in this document. 775 8. Security Considerations 777 Procedures and protocol extensions defined in this document do not 778 affect the BGP security model. See the 'Security Considerations' 779 section of [RFC4271] for a discussion of BGP security. Also refer to 780 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 782 9. Acknowledgements 784 10. References 786 10.1. Normative References 788 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 789 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 790 and M. Chen, "BGP Link-State extensions for Segment 791 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-04 792 (work in progress), January 2018. 794 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 795 Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, 796 "Signaling Maximum SID Depth using Border Gateway Protocol 797 Link-State", draft-ietf-idr-bgp-ls-segment-routing-msd-01 798 (work in progress), October 2017. 800 [I-D.ietf-idr-bgp-prefix-sid] 801 Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A., 802 and H. Gredler, "Segment Routing Prefix SID extensions for 803 BGP", draft-ietf-idr-bgp-prefix-sid-17 (work in progress), 804 February 2018. 806 [I-D.ietf-idr-bgpls-segment-routing-epe] 807 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 808 Dong, "BGP-LS extensions for Segment Routing BGP Egress 809 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 810 epe-14 (work in progress), December 2017. 812 [I-D.ietf-idr-te-lsp-distribution] 813 Previdi, S., Dong, J., Chen, M., Gredler, H., and J. 814 Tantsura, "Distribution of Traffic Engineering (TE) 815 Policies and State using BGP-LS", draft-ietf-idr-te-lsp- 816 distribution-08 (work in progress), December 2017. 818 [I-D.ietf-idr-te-pm-bgp] 819 Ginsberg, L., Previdi, S., Wu, Q., Gredler, H., Ray, S., 820 Tantsura, J., and C. Filsfils, "BGP-LS Advertisement of 821 IGP Traffic Engineering Performance Metric Extensions", 822 draft-ietf-idr-te-pm-bgp-09 (work in progress), February 823 2018. 825 [I-D.ietf-spring-segment-routing] 826 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 827 Litkowski, S., and R. Shakir, "Segment Routing 828 Architecture", draft-ietf-spring-segment-routing-15 (work 829 in progress), January 2018. 831 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 832 Requirement Levels", BCP 14, RFC 2119, 833 DOI 10.17487/RFC2119, March 1997, 834 . 836 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 837 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 838 DOI 10.17487/RFC4271, January 2006, 839 . 841 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 842 S. Ray, "North-Bound Distribution of Link-State and 843 Traffic Engineering (TE) Information Using BGP", RFC 7752, 844 DOI 10.17487/RFC7752, March 2016, 845 . 847 10.2. Informative References 849 [I-D.filsfils-spring-segment-routing-policy] 850 Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, 851 F., Talaulikar, K., Ali, Z., Hegde, S., 852 daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, 853 b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., 854 Litkowski, S., and P. Mattes, "Segment Routing Policy for 855 Traffic Engineering", draft-filsfils-spring-segment- 856 routing-policy-05 (work in progress), February 2018. 858 [I-D.ietf-idr-segment-routing-te-policy] 859 Previdi, S., Filsfils, C., Jain, D., Mattes, P., Rosen, 860 E., and S. Lin, "Advertising Segment Routing Policies in 861 BGP", draft-ietf-idr-segment-routing-te-policy-02 (work in 862 progress), March 2018. 864 [I-D.ietf-pce-segment-routing] 865 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 866 and J. Hardwick, "PCEP Extensions for Segment Routing", 867 draft-ietf-pce-segment-routing-11 (work in progress), 868 November 2017. 870 [I-D.ietf-spring-segment-routing-central-epe] 871 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 872 Afanasiev, "Segment Routing Centralized BGP Egress Peer 873 Engineering", draft-ietf-spring-segment-routing-central- 874 epe-10 (work in progress), December 2017. 876 [I-D.ietf-spring-segment-routing-msdc] 877 Filsfils, C., Previdi, S., Mitchell, J., Aries, E., and P. 878 Lapukhov, "BGP-Prefix Segment in large-scale data 879 centers", draft-ietf-spring-segment-routing-msdc-08 (work 880 in progress), December 2017. 882 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 883 DOI 10.17487/RFC2328, April 1998, 884 . 886 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 887 (TE) Extensions to OSPF Version 2", RFC 3630, 888 DOI 10.17487/RFC3630, September 2003, 889 . 891 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 892 RFC 4272, DOI 10.17487/RFC4272, January 2006, 893 . 895 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 896 Management of New Protocols and Protocol Extensions", 897 RFC 5706, DOI 10.17487/RFC5706, November 2009, 898 . 900 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 901 Measurement for MPLS Networks", RFC 6374, 902 DOI 10.17487/RFC6374, September 2011, 903 . 905 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 906 BGP, LDP, PCEP, and MSDP Issues According to the Keying 907 and Authentication for Routing Protocols (KARP) Design 908 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 909 . 911 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 912 BGP for Routing in Large-Scale Data Centers", RFC 7938, 913 DOI 10.17487/RFC7938, August 2016, 914 . 916 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 917 Computation Element Communication Protocol (PCEP) 918 Extensions for Stateful PCE", RFC 8231, 919 DOI 10.17487/RFC8231, September 2017, 920 . 922 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 923 Computation Element Communication Protocol (PCEP) 924 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 925 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 926 . 928 Authors' Addresses 929 Ketan Talaulikar 930 Cisco Systems 931 Pune 411057 932 India 934 Email: ketant@cisco.com 936 Clarence Filsfils 937 Cisco Systems 938 Brussels 939 Belgium 941 Email: cfilsfil@cisco.com 943 Krishna Swamy 944 Cisco Systems 945 San Jose 946 USA 948 Email: kriswamy@cisco.com 950 Shawn Zandi 951 LinkedIn 952 USA 954 Email: szandi@linkedin.com 956 Gaurav Dawra 957 LinkedIn 958 USA 960 Email: szandi@linkedin.com