idnits 2.17.1 draft-ietf-idr-bgpls-segment-routing-epe-16.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 (October 15, 2018) is 2012 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 (-06) exists of draft-dawra-idr-bgpls-srv6-ext-04 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-09 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-01 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing S. Previdi, Ed. 3 Internet-Draft Individual 4 Intended status: Standards Track K. Talaulikar 5 Expires: April 18, 2019 C. Filsfils 6 Cisco Systems, Inc. 7 K. Patel 8 Arrcus, Inc. 9 S. Ray 10 Individual Contributor 11 J. Dong 12 Huawei Technologies 13 October 15, 2018 15 BGP-LS extensions for Segment Routing BGP Egress Peer Engineering 16 draft-ietf-idr-bgpls-segment-routing-epe-16 18 Abstract 20 Segment Routing (SR) leverages source routing. A node steers a 21 packet through a controlled set of instructions, called segments, by 22 prepending the packet with an SR header. A segment can represent any 23 instruction, topological or service-based. SR segments allow 24 steering a flow through any topological path and service chain while 25 maintaining per-flow state only at the ingress node of the SR domain. 27 This document describes an extension to BGP Link State (BGP-LS) for 28 advertisement of BGP Peering Segments along with their BGP peering 29 node information so that efficient BGP Egress Peer Engineering (EPE) 30 policies and strategies can be computed based on Segment Routing. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on April 18, 2019. 55 Copyright Notice 57 Copyright (c) 2018 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Segment Routing Documents . . . . . . . . . . . . . . . . . . 4 74 3. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 4 75 4. BGP-LS NLRI for BGP . . . . . . . . . . . . . . . . . . . . . 5 76 4.1. BGP Router ID and Member ASN . . . . . . . . . . . . . . 6 77 4.2. Mandatory BGP Node Descriptors . . . . . . . . . . . . . 6 78 4.3. Optional BGP Node Descriptors . . . . . . . . . . . . . . 7 79 5. BGP-LS Attributes for BGP Peering Segments . . . . . . . . . 7 80 5.1. Peer-Node-SID . . . . . . . . . . . . . . . . . . . . . . 10 81 5.2. Peer-Adj-SID . . . . . . . . . . . . . . . . . . . . . . 11 82 5.3. Peer-Set-SID . . . . . . . . . . . . . . . . . . . . . . 12 83 6. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 12 84 6.1. Reference Diagram . . . . . . . . . . . . . . . . . . . . 12 85 6.2. Peer-Node-SID for Node D . . . . . . . . . . . . . . . . 14 86 6.3. Peer-Node-SID for Node F . . . . . . . . . . . . . . . . 15 87 6.4. Peer-Node-SID for Node E . . . . . . . . . . . . . . . . 15 88 6.5. Peer-Adj-SID for Node E, Link 1 . . . . . . . . . . . . . 16 89 6.6. Peer-Adj-SID for Node E, Link 2 . . . . . . . . . . . . . 16 90 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 92 8.1. New BGP-LS Protocol-ID . . . . . . . . . . . . . . . . . 18 93 8.2. Node Descriptors and Link Attribute TLVs . . . . . . . . 18 94 9. Manageability Considerations . . . . . . . . . . . . . . . . 18 95 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 96 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 97 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 98 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 100 13.2. Informative References . . . . . . . . . . . . . . . . . 21 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 103 1. Introduction 105 Segment Routing (SR) leverages source routing. A node steers a 106 packet through a controlled set of instructions, called segments, by 107 prepending the packet with an SR header with segment identifiers 108 (SID). A SID can represent any instruction, topological or service- 109 based. SR segments allows to enforce a flow through any topological 110 path or service function while maintaining per-flow state only at the 111 ingress node of the SR domain. 113 The SR architecture [RFC8402] defines three types of BGP Peering 114 Segments that may be instantiated at a BGP node: 116 o Peer Node Segment (Peer-Node-SID) : instruction to steer to a 117 specific peer node 119 o Peer Adjacency Segment (Peer-Adj-SID) : instruction to steer over 120 a specific local interface towards a specific peer node 122 o Peer Set Segment (Peer-Set-SID) : instruction to load-balance to a 123 set of specific peer nodes 125 SR can be directly applied to either an MPLS dataplane (SR/MPLS) with 126 no change on the forwarding plane or to a modified IPv6 forwarding 127 plane (SRv6). 129 This document describes extensions to the Link State NLRI and the 130 BGP-LS Attribute defined for BGP-LS [RFC7752] for advertising BGP 131 peering segments from a BGP node along with its peering topology 132 information (i.e. its peers, interfaces, and peering ASs) to enable 133 computation of efficient BGP Egress Peer Engineering (BGP-EPE) 134 policies and strategies using the SR/MPLS dataplane. The 135 corresponding extensions for SRv6 are specified in 136 [I-D.dawra-idr-bgpls-srv6-ext]. 138 One use-case for these BGP Peering Segments is to enable computation 139 of SR paths that enable Central BGP-EPE as described in 140 [I-D.ietf-spring-segment-routing-central-epe]. This use-case 141 comprises of a centralized controller that learns the BGP Peering 142 SIDs via BGP-LS and then uses this information to program a SR policy 143 [I-D.ietf-spring-segment-routing-policy] at any node in the domain to 144 perform traffic steering via a specific BGP egress node to a specific 145 EBGP peer(s) optionally also over a specific interface. 147 This document introduces a new BGP protocol type for BGP-LS NLRI and 148 defines new BGP-LS Node and Link description TLVs to facilitate 149 advertising BGP-LS Link NLRI that represent the BGP peering topology. 150 Further, it specifies the BGP-LS Attribute TLVs for advertisement of 151 the BGP Peering Segments (i.e. Peer Node SID, Peer Adjacency SID, 152 and Peer Set SID) to be advertised in the same BGP-LS Link NLRI. 154 2. Segment Routing Documents 156 The main reference is the SR architecture defined in [RFC8402]. 158 The SR BGP-EPE architecture and use-case is described in 159 [I-D.ietf-spring-segment-routing-central-epe]. 161 3. BGP Peering Segments 163 As described in [I-D.ietf-spring-segment-routing-central-epe], a BGP- 164 EPE enabled Egress PE node MAY advertise SIDs corresponding to its 165 attached peers. These SIDs are called BGP peering segments or BGP 166 Peering SIDs. In case of EBGP, they enable the expression of source- 167 routed inter-domain paths. 169 An ingress border router of an AS may compose a list of SIDs to steer 170 a flow along a selected path within the AS, towards a selected egress 171 border router C of the AS, and to a specific EBGP peer. At minimum, 172 a BGP-EPE policy applied at an ingress PE involves two SIDs: the Node 173 SID of the chosen egress PE and then the BGP Peering SID for the 174 chosen egress PE peer or peering interface. 176 Each BGP session MUST be described by a Peer Node SID. The 177 description of the BGP session MAY be augmented by additional Peer 178 Adjacency SIDs. Finally, multiple Peer Node SIDs or Peer Adjacency 179 SIDs MAY be part of the same group/set in order to group EPE 180 resources under a common Peer-Set SID. 182 When the extensions defined in this document are applied to the EPE 183 use-case defined in [I-D.ietf-spring-segment-routing-central-epe], 184 then the following BGP Peering SIDs need to be instantiated on a BGP 185 router for each of its BGP peer sessions that are enabled for EPE: 187 o One Peer-Node-SID MUST be instantiated to describe the BGP peer 188 session. 190 o One or more Peer-Adj-SID MAY be instantiated corresponding to the 191 underlying link(s) to the directly connected BGP peer session. 193 o A Peer-Set-SID MAY be instantiated and additionally associated and 194 shared between one or more Peer-Node-SIDs or Peer-Adj-SIDs. 196 While an egress point in a topology usually refers to EBGP sessions 197 between external peers, there's nothing in the extensions defined in 198 this document that would prevent the use of these extensions in the 199 context of IBGP sessions. However, unlike EBGP sessions which are 200 generally between directly connected BGP routers which are also along 201 the traffic forwarding path, IBGP peer sessions may be setup to BGP 202 routers which are not in the forwarding path. As such, when the IBGP 203 design includes sessions with route-reflectors, a BGP router SHOULD 204 NOT instantiate a BGP Peering SID for those sessions to peer nodes 205 which are not in the forwarding path since the purpose of BGP Peering 206 SID is to steer traffic to that specific peers. Thus, the 207 applicability for IBGP peering may be limited to only those 208 deployments where the IBGP peer is also along with forwarding data 209 path. Further details and the use-cases of BGP Peering SIDs and 210 their BGP-LS extensions to IBGP deployments are beyond the scope of 211 this document. 213 The BGP Peering SIDs instantiated as described above are then 214 advertised via BGP-LS Link NLRI as described in the sections below. 216 4. BGP-LS NLRI for BGP 218 This section describes the BGP-LS NLRI encodings that describe the 219 BGP peering and link connectivity between BGP routers. 221 This document specifies the advertisement of BGP peering topology 222 information via BGP-LS NLRI which requires use of a new BGP protocol 223 identifier. 225 Protocol-ID : BGP (codepoint 7 assigned by IANA Section 8 from the 226 registry "BGP-LS Protocol-IDs") 228 The use of a new Protocol-ID allows separation and differentiation 229 between the BGP-LS NLRI carrying BGP information from the NLRI 230 carrying IGP link-state information as defined in [RFC7752]. 232 The BGP Peering information along with their Peering Segments are 233 advertised using BGP-LS Link NLRI with the protocol ID set to BGP. 234 The BGP-LS Link NLRI uses the descriptor TLVs and BGP-LS Attribute 235 TLVs as defined in [RFC7752]. In order to correctly describe BGP 236 nodes, new TLVs are defined in this section. 238 [RFC7752] defines Link NLRI Type is as follows: 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+ 243 | Protocol-ID | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Identifier | 246 | (64 bits) | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 // Local Node Descriptors // 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 // Remote Node Descriptors // 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 // Link Descriptors // 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Node Descriptors and Link Descriptors are defined in [RFC7752]. 257 4.1. BGP Router ID and Member ASN 259 Two new Node Descriptors TLVs are defined in this document: 261 o BGP Router Identifier (BGP Router-ID): 263 Type: 516 (assigned by IANA Section 8 from the registry "BGP-LS 264 Node Descriptor, Link Descriptor, Prefix Descriptor, and 265 Attribute TLVs"). 267 Length: 4 octets 269 Value: 4 octet unsigned non-zero integer representing the BGP 270 Identifier as defined in [RFC4271] and [RFC6286]. 272 o Confederation Member ASN (Member-ASN) 274 Type: 517 (assigned by IANA Section 8 from the registry "BGP-LS 275 Node Descriptor, Link Descriptor, Prefix Descriptor, and 276 Attribute TLVs"). 278 Length: 4 octets 280 Value: 4 octet unsigned non-zero integer representing the 281 Member ASN inside the Confederation [RFC5065]. 283 4.2. Mandatory BGP Node Descriptors 285 The following Node Descriptors TLVs MUST be included in BGP-LS NLRI 286 as Local Node Descriptors when distributing BGP information: 288 o BGP Router-ID, which contains a valid BGP Identifier of the local 289 BGP node. 291 o Autonomous System Number, which contains the ASN or confederation 292 identifier (ASN), if confederations are used, of the local BGP 293 node. 295 Note that [RFC6286] (section 2.1) requires the BGP identifier 296 (router-id) to be unique within an Autonomous System and non-zero. 297 Therefore, the tuple is globally unique. 299 The following Node Descriptors TLVs MUST be included in BGP-LS Link 300 NLRI as Remote Node Descriptors when distributing BGP information: 302 o BGP Router-ID, which contains the valid BGP Identifier of the peer 303 BGP node. 305 o Autonomous System Number, which contains the ASN or the 306 confederation identifier (ASN), if confederations are used, of the 307 peer BGP node. 309 4.3. Optional BGP Node Descriptors 311 The following Node Descriptors TLVs MAY be included in BGP-LS NLRI as 312 Local Node Descriptors when distributing BGP information: 314 o Member-ASN, which contains the ASN of the confederation member, if 315 BGP confederations are used, of the local BGP node. 317 o Node Descriptors as defined in [RFC7752]. 319 The following Node Descriptors TLVs MAY be included in BGP-LS Link 320 NLRI as Remote Node Descriptors when distributing BGP information: 322 o Member-ASN, which contains the ASN of the confederation member, if 323 BGP confederations are used, of the peer BGP node. 325 o Node Descriptors as defined in defined in [RFC7752]. 327 5. BGP-LS Attributes for BGP Peering Segments 329 This section defines the BGP-LS Attributes corresponding to the 330 following BGP Peer Segment SIDs: 332 Peer Node Segment Identifier (Peer-Node-SID) 334 Peer Adjacency Segment Identifier (Peer-Adj-SID) 335 Peer Set Segment Identifier (Peer-Set-SID) 337 The following new BGP-LS Link attributes TLVs are defined for use 338 with BGP-LS Link NLRI for advertising BGP Peering SIDs: 340 +----------+---------------------------+----------+ 341 | TLV Code | Description | Length | 342 | Point | | | 343 +----------+---------------------------+----------+ 344 | 1101 | Peer Node Segment | variable | 345 | | Identifier (Peer-Node-SID)| | 346 | 1102 | Peer Adjacency Segment | variable | 347 | | Identifier (Peer-Adj-SID) | | 348 | 1103 | Peer Set Segment | variable | 349 | | Identifier (Peer-Set-SID) | | 350 +----------+---------------------------+----------+ 352 Figure 1: BGP-LS TLV code points for BGP-EPE 354 Peer-Node-SID, Peer-Adj-SID, and Peer-Set-SID have all the same 355 format defined here below: 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Type | Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Flags | Weight | Reserved | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | SID/Label/Index (variable) | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 where: 369 Figure 2 371 o Type: 1101, 1102 or 1103 (assigned by IANA (Section 8) from the 372 registry "BGP-LS Node Descriptor, Link Descriptor, Prefix 373 Descriptor, and Attribute TLVs"). 375 o Length: variable. 377 o Flags: one octet of flags with the following definition: 379 0 1 2 3 4 5 6 7 380 +-+-+-+-+-+-+-+-+ 381 |V|L|B|P| | 382 +-+-+-+-+-+-+-+-+ 384 where: 386 * V-Flag: Value flag. If set, then the SID carries a label 387 value. By default the flag is SET. 389 * L-Flag: Local Flag. If set, then the value/index carried by 390 the SID has local significance. By default the flag is SET. 392 * B-Flag: Backup Flag. If set, the SID refers to a path that is 393 eligible for protection. 395 * P-Flag: Persistent Flag: If set, the SID is persistently 396 allocated, i.e., the SID value remains consistent across router 397 restart and session/interface flap. 399 * Other bits: MUST be zero when originated and ignored when 400 received. 402 o Weight: 1 octet. The value represents the weight of the SID for 403 the purpose of load balancing. An example use of the weight is 404 described in [RFC8402]. 406 o SID/Index/Label. According to the TLV length and to the V and L 407 flags settings, it contains either: 409 * A 3 octet local label where the 20 rightmost bits are used for 410 encoding the label value. In this case, the V and L flags MUST 411 be SET. 413 * A 4 octet index defining the offset in the SRGB (Segment 414 Routing Global Block as defined in [RFC8402] advertised by this 415 router. In this case, the SRGB MUST be advertised using the 416 extensions defined in 417 [I-D.ietf-idr-bgp-ls-segment-routing-ext]. 419 The values of the Peer-Node-SID, Peer-Adj-SID, and Peer-Set-SID Sub- 420 TLVs SHOULD be persistent across router restart. 422 The Peer-Node-SID TLV MUST be included in the BGP-LS Attribute for 423 the BGP-LS Link NLRI when advertising BGP peering information for the 424 use case described in [I-D.ietf-spring-segment-routing-central-epe] 425 and MAY be omitted for other use cases. 427 The Peer-Adj-SID and Peer-Set-SID TLVs MAY be included in the BGP-LS 428 Attribute for the BGP-LS Link NLRI when advertising BGP peering 429 information for the use case described in 430 [I-D.ietf-spring-segment-routing-central-epe] and MAY be omitted for 431 other use cases. 433 Additional BGP-LS Link Attribute TLVs, as defined in [RFC7752] MAY be 434 included with the BGP-LS Link NLRI in order to advertise the 435 characteristics of the peering link. 437 5.1. Peer-Node-SID 439 The Peer-Node-SID TLV includes a SID associated with the BGP peer 440 node that is described by a BGP-LS Link NLRI as specified in 441 Section 4. 443 The Peer-Node-SID, at the BGP node advertising it, has the following 444 semantics: 446 o SR header operation: NEXT (as defined in [RFC8402]). 448 o Next-Hop: the connected peering node to which the segment is 449 associated. 451 The Peer-Node-SID is advertised with a BGP-LS Link NLRI, where: 453 o Local Node Descriptors include: 455 * Local BGP Router-ID (TLV 516) of the BGP-EPE enabled egress PE. 457 * Local ASN (TLV 512). 459 o Remote Node Descriptors include: 461 * Peer BGP Router-ID (TLV 516) (i.e.: the peer BGP ID used in the 462 BGP session) 464 * Peer ASN (TLV 512). 466 o Link Descriptors include the addresses used by the BGP session 467 encoded using TLVs as defined in [RFC7752]: 469 * IPv4 Interface Address (TLV 259) contains the BGP session IPv4 470 local address. 472 * IPv4 Neighbor Address (TLV 260) contains the BGP session IPv4 473 peer address. 475 * IPv6 Interface Address (TLV 261) contains the BGP session IPv6 476 local address. 478 * IPv6 Neighbor Address (TLV 262) contains the BGP session IPv6 479 peer address. 481 o Link Attribute TLVs include the Peer-Node-SID TLV as defined in 482 Figure 2. 484 5.2. Peer-Adj-SID 486 The Peer-Adj-SID TLV includes a SID associated with the underlying 487 link to the BGP peer node that is described by a BGP-LS Link NLRI as 488 specified in Section 4. 490 The Peer-Adj-SID, at the BGP node advertising it, has the following 491 semantics: 493 o SR header operation: NEXT (as defined in [RFC8402]). 495 o Next-Hop: the interface peer address. 497 The Peer-Adj-SID is advertised with a BGP-LS Link NLRI, where: 499 o Local Node Descriptors include: 501 * Local BGP Router-ID (TLV 516) of the BGP-EPE enabled egress PE. 503 * Local ASN (TLV 512). 505 o Remote Node Descriptors include: 507 * Peer BGP Router-ID (TLV 516) (i.e. the peer BGP ID used in the 508 BGP session). 510 * Peer ASN (TLV 512). 512 o Link Descriptors MUST include the following TLV, as defined in 513 [RFC7752]: 515 * Link Local/Remote Identifiers (TLV 258) contains the 4-octet 516 Link Local Identifier followed by the 4-octet Link Remote 517 Identifier [RFC5307]. The value 0 is used by default when the 518 link remote identifier is unknown. 520 o Additional Link Descriptors TLVs, as defined in [RFC7752], MAY 521 also be included to describe the addresses corresponding to the 522 link between the BGP routers: 524 * IPv4 Interface Address (Sub-TLV 259) contains the address of 525 the local interface through which the BGP session is 526 established. 528 * IPv6 Interface Address (Sub-TLV 261) contains the address of 529 the local interface through which the BGP session is 530 established. 532 * IPv4 Neighbor Address (Sub-TLV 260) contains the IPv4 address 533 of the peer interface used by the BGP session. 535 * IPv6 Neighbor Address (Sub-TLV 262) contains the IPv6 address 536 of the peer interface used by the BGP session. 538 o Link Attribute TLVs include the Peer-Adj-SID TLV as defined in 539 Figure 2. 541 5.3. Peer-Set-SID 543 The Peer-Set-SID TLV includes a SID that is shared amongst BGP peer 544 nodes or the underlying links that are described by BGP-LS Link NLRI 545 as specified in Section 4. 547 The Peer-Set-SID, at the BGP node advertising it, has the following 548 semantics: 550 o SR header operation: NEXT (as defined in [RFC8402]). 552 o Next-Hop: load balance across any connected interface to any peer 553 in the associated peer set. 555 The Peer-Set-SID TLV containing the same SID value (encoded as 556 defined in Figure 2) is included in the BGP-LS Attribute for all of 557 the BGP-LS Link NLRI corresponding to the Peer Node or Peer Adjacency 558 segments associated with the peer set. 560 6. Illustration 562 6.1. Reference Diagram 564 The following reference diagram is used throughout this section. The 565 solution is illustrated for IPv6 with MPLS-based SIDs and the BGP-EPE 566 topology is based on EBGP sessions between external peers. 568 This illustration is non-normative text provided as an example for 569 implementers and describes the BGP-LS advertisements for the Central 570 EPE use-case. 572 As stated in Section 3, the solution illustrated hereafter is equally 573 applicable to an IBGP session topology. In other words, the solution 574 also applies to the case where C, D, F, and E are in the same AS and 575 run IBGP sessions between each other. 577 +------+ 578 | | 579 +---D H 580 +---------+ / | AS 2 |\ +------+ 581 | X |/ +------+ \ | Z |---L/8 582 A C---+ \| | 583 | |\\ \ +------+ /| AS 4 |---M/8 584 | AS1 | \\ +-F |/ +------+ 585 | | \\ | G 586 +----P----+ +===E AS 3 | 587 | +--Q---+ 588 | | 589 +----------------+ 591 Figure 3: Reference Diagram 593 IP addressing: 595 o C's IP address of interface to D: 2001:db8:cd::c/64, D's 596 interface: 2001:db8:cd::d/64 598 o C's IP address of interface to F: 2001:db8:cf::c/64, F's 599 interface: 2001:db8:cf::f/64 601 o C's IP address of upper interface to E: 2001:db8:ce1::c/64, E's 602 interface: 2001:db8:ce1::e 604 o C's local identifier of upper interface to E: 0.0.0.1.0.0.0.0 606 o C's IP address of lower interface to E: 2001:db8:ce2::c, E's 607 interface: 2001:db8:ce2::e 609 o C's local identifier of lower interface to E: 0.0.0.2.0.0.0.0 611 o Loopback of E used for EBGP multi-hop peering to C: 612 2001:db8:e::e/128 614 o C's loopback is 2001:db8:c::c/128 with SID 64 616 BGP Router-IDs are C, D, F and E. 618 o C's BGP Router-ID: 192.0.2.3 619 o D's BGP Router-ID: 192.0.2.4 621 o E's BGP Router-ID: 192.0.2.5 623 o F's BGP Router-ID: 192.0.2.6 625 C's BGP peering: 627 o Single-hop EBGP peering with neighbor 2001:db8:cd::d (D) 629 o Single-hop EBGP peering with neighbor 2001:db8:cf::f (F) 631 o Multi-hop EBGP peering with E on ip address 2001:db8:e::e (E) 633 C's resolution of the multi-hop EBGP session to E: 635 o Static route 2001:db8:e::e/128 via 2001:db8:ce1::e 637 o Static route 2001:db8:e::e/128 via 2001:db8:ce2::e 639 Node C configuration is such that: 641 o A Peer-Node-SID is allocated to each peer (D, F and E). 643 o An Peer-Adj-SID is defined for each recursing interface to a 644 multi-hop peer (CE upper and lower interfaces). 646 o A Peer-Set-SID is defined to include all peers in AS3 (peers F and 647 E). 649 A BGP-LS Link NLRI is used in order to encode C's connectivity. The 650 Link NLRI uses the Protocol-ID for BGP (value 7) as assigned by IANA. 652 Once the BGP-LS update is originated by C, it may be advertised to 653 internal (IBGP) as well as external (EBGP) neighbors supporting the 654 BGP-LS EPE extensions defined in this document. Note that the BGP-LS 655 sessions may be completely separate and different from the normal BGP 656 routing sessions described above - e.g. to a central EPE controller. 658 6.2. Peer-Node-SID for Node D 660 Descriptor TLVs used in the BGP-LS Link NLRI: 662 o Local Node Descriptors (BGP Router-ID, local ASN): 192.0.2.3, AS1 664 o Remote Node Descriptors (BGP Router-ID, peer ASN): 192.0.2.4, AS2 665 o Link Descriptors (BGP session IPv6 local address, BGP session IPv6 666 neighbor address): 2001:db8:cd::c, 2001:db8:cd::d 668 Link Attribute TLVs used in the BGP-LS Attribute associated with the 669 BGP-LS Link NLRI above: 671 o Peer-Node-SID: 1012 673 o Other Link Attributes: see section 3.3.2 of [RFC7752] 675 6.3. Peer-Node-SID for Node F 677 Descriptor TLVs used in the BGP-LS Link NLRI: 679 o Local Node Descriptors (BGP Router-ID, ASN): 192.0.2.3, AS1 681 o Remote Node Descriptors (BGP Router-ID ASN): 192.0.2.6, AS3 683 o Link Descriptors (BGP session IPv6 local address, BGP session IPv6 684 peer address): 2001:db8:cf::c, 2001:db8:cf::f 686 Link Attribute TLVs used in the BGP-LS Attribute associated with the 687 BGP-LS Link NLRI above: 689 o Peer-Node-SID: 1022 691 o Peer-Set-SID: 1060 693 o Other Link Attributes: see section 3.3.2 of [RFC7752] 695 6.4. Peer-Node-SID for Node E 697 Descriptor TLVs used in the BGP-LS Link NLRI: 699 o Local Node Descriptors (BGP Router-ID, ASN): 192.0.2.3, AS1 701 o Remote Node Descriptors (BGP Router-ID, ASN): 192.0.2.5, AS3 703 o Link Descriptors (BGP session IPv6 local address, BGP session IPv6 704 peer address): 2001:db8:c::c, 2001:db8:e::e 706 Link Attribute TLVs used in the BGP-LS Attribute associated with the 707 BGP-LS Link NLRI above: 709 o Peer-Node-SID: 1052 711 o Peer-Set-SID: 1060 713 6.5. Peer-Adj-SID for Node E, Link 1 715 Descriptor TLVs used in the BGP-LS Link NLRI: 717 o Local Node Descriptors (BGP Router-ID, ASN): 192.0.2.3, AS1 719 o Remote Node Descriptors (BGP Router-ID, ASN): 192.0.2.5, AS3 721 o Link Descriptors (local interface identifier, IPv6 peer interface 722 address): 0.0.0.1.0.0.0.0 , 2001:db8:ce1::e 724 Link Attribute TLVs used in the BGP-LS Attribute associated with the 725 BGP-LS Link NLRI above: 727 o Peer-Adj-SID: 1032 729 o Other Link Attributes: see section 3.3.2 of [RFC7752] 731 6.6. Peer-Adj-SID for Node E, Link 2 733 Descriptor TLVs used in the BGP-LS Link NLRI: 735 o Local Node Descriptors (BGP Router-ID, ASN): 192.0.2.3, AS1 737 o Remote Node Descriptors (BGP Router-ID, ASN): 192.0.2.5, AS3 739 o Link Descriptors (local interface identifier, IPv6 peer interface 740 address): 0.0.0.2.0.0.0.0 , 2001:db8:ce2::e 742 Link Attribute TLVs used in the BGP-LS Attribute associated with the 743 BGP-LS Link NLRI above: 745 o Peer-Adj-SID: 1042 747 o Other Link Attributes: see section 3.3.2 of [RFC7752] 749 7. Implementation Status 751 Note to RFC Editor: Please remove this section prior to publication, 752 as well as the reference to RFC 7942. 754 This section records the status of known implementations of the 755 protocol defined by this specification at the time of posting of this 756 Internet-Draft, and is based on a proposal described in [RFC7942]. 757 The description of implementations in this section is intended to 758 assist the IETF in its decision processes in progressing drafts to 759 RFCs. Please note that the listing of any individual implementation 760 here does not imply endorsement by the IETF. Furthermore, no effort 761 has been spent to verify the information presented here that was 762 supplied by IETF contributors. This is not intended as, and must not 763 be construed to be, a catalog of available implementations or their 764 features. Readers are advised to note that other implementations may 765 exist. 767 According to [RFC7942], "this will allow reviewers and working groups 768 to assign due consideration to documents that have the benefit of 769 running code, which may serve as evidence of valuable experimentation 770 and feedback that have made the implemented protocols more mature. 771 It is up to the individual working groups to use this information as 772 they see fit". 774 Several early implementations exist and will be reported in detail in 775 a forthcoming version of this document. For purposes of early 776 interoperability testing, when no FCFS code point was available, 777 implementations have made use of the following values: 779 +---------------------------------------+ 780 | Codepoint | Description | 781 +---------------------------------------+ 782 | 7 | Protocol-ID BGP | 783 | 516 | BGP Router-ID | 784 | 517 | BGP Confederation Member | 785 | 1101 | Peer-Node-SID | 786 | 1102 | Peer-Adj-SID | 787 | 1103 | Peer-Set-SID | 788 +------------+--------------------------+ 790 IANA has now confirmed the assignment of the above codepoints. See 791 Section 8. 793 8. IANA Considerations 795 This document defines: 797 A new Protocol-ID: BGP. The codepoint is from the "BGP-LS 798 Protocol-IDs" registry. 800 Two new TLVs: BGP-Router-ID and BGP Confederation Member. The 801 codepoints are in the "BGP-LS Node Descriptor, Link Descriptor, 802 Prefix Descriptor, and Attribute TLVs" registry. 804 Three new BGP-LS Attribute TLVs: Peer-Node-SID, Peer-Adj-SID and 805 Peer-Set-SID. The codepoints are in the "BGP-LS Node Descriptor, 806 Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry. 808 8.1. New BGP-LS Protocol-ID 810 This document defines a new value in the registry "BGP-LS Protocol- 811 IDs": 813 +----------------------------------------------+ 814 | Codepoint | Description | Status | 815 +----------------------------------------------+ 816 | 7 | BGP | Assigned by IANA | 817 +----------------------------------------------+ 819 8.2. Node Descriptors and Link Attribute TLVs 821 This document defines 5 new TLVs in the registry "BGP-LS Node 822 Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs": 824 o Two new node descriptor TLVs 826 o Three new link attribute TLVs 828 All the new 5 codepoints are in the same registry: "BGP-LS Node 829 Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs". 831 The following new Node Descriptors TLVs are defined: 833 +-----------------------------------------------------------+ 834 | Codepoint | Description | Status | 835 +-----------------------------------------------------------+ 836 | 516 | BGP Router-ID | Assigned by IANA | 837 | 517 | BGP Confederation Member | Assigned by IANA | 838 +------------+----------------------------------------------+ 840 The following new Link Attribute TLVs are defined: 842 +-----------------------------------------------------------+ 843 | Codepoint | Description | Status | 844 +-----------------------------------------------------------+ 845 | 1101 | Peer-Node-SID | Assigned by IANA | 846 | 1102 | Peer-Adj-SID | Assigned by IANA | 847 | 1103 | Peer-Set-SID | Assigned by IANA | 848 +------------+----------------------------------------------+ 850 9. Manageability Considerations 852 The new protocol extensions introduced herein augment the existing 853 IGP topology information BGP-LS distribution [RFC7752] by adding 854 support for distribution of BGP peering topology information. As 855 such, the Manageability Considerations section of [RFC7752] applies 856 to these new extensions as well. 858 Specifically, the malformed NLRI attribute tests for syntactic checks 859 in the Fault Management section of [RFC7752] now apply to the TLVs 860 for the BGP-LS NLRI TLVs defined in this document. The semantic or 861 content checking for the TLVs specified in this document and their 862 association with the BGP-LS NLRI types or their associated BGP-LS 863 Attributes is left to the consumer of the BGP-LS information (e.g. an 864 application or a controller) and not the BGP protocol. 866 The operator MUST be provided with the options of configuring, 867 enabling, and disabling the advertisement of each of the Peer-Node- 868 SID, Peer-Adj-SID, and Peer-Set-SID as well as control of which 869 information is advertised to which internal or external peer. This 870 is not different from what is required by a BGP speaker in terms of 871 information origination and advertisement. 873 BGP Peering Segments are associated with the normal BGP routing 874 peering sessions. However, the BGP peering information along with 875 these Peering Segments themselves are advertised via a distinct BGP- 876 LS peering session. It is expected that this isolation as described 877 in [RFC7752] is followed when advertising BGP peering topology 878 information via BGP-LS. 880 BGP-EPE functionality enables the capability for instantiation of an 881 SR path for traffic engineering a flow via an egress BGP router to a 882 specific peer, bypassing the normal BGP best path routing for that 883 flow and any routing policies implemented in BGP on that egress BGP 884 router. As with any traffic engineering solution, the controller or 885 application implementing the policy needs to ensure that there is no 886 looping or mis-routing of traffic. 888 10. Security Considerations 890 [RFC7752] defines BGP-LS NLRI to which the extensions defined in this 891 document apply. The Security Considerations section of [RFC7752] 892 also applies to these extensions. 894 BGP-EPE enables engineering of traffic when leaving the 895 administrative domain via an egress BGP router. Therefore precaution 896 is necessary to ensure that the BGP peering information collected via 897 BGP-LS is limited to specific controllers or applications in a secure 898 manner. By default, Segment Routing operates within a trusted domain 899 (refer Security Considerations section in [RFC8402] for more detail) 900 and its security considerations also apply to BGP Peering Segments. 901 The BGP-EPE policies are expected to be used entirely within this 902 trusted SR domain (e.g. between multiple AS/domains within a single 903 provider network). 905 The isolation of BGP-LS peering sessions is also required to ensure 906 that BGP-LS topology information (including the newly added BGP 907 peering topology) is not advertised to an external BGP peering 908 session outside an administrative domain. 910 11. Contributors 912 Mach (Guoyi) Chen 913 Huawei Technologies 914 China 916 Email: mach.chen@huawei.com 918 Acee Lindem 919 Cisco Systems Inc. 920 US 922 Email: acee@cisco.com 924 12. Acknowledgements 926 The authors would like to thank Jakob Heitz, Howard Yang, Hannes 927 Gredler, Peter Psenak, Arjun Sreekantiah and Bruno Decraene for their 928 feedback and comments. The authors would also like to thank Susan 929 Hares for her substantial contributions in improving the clarity of 930 the document during her shepherd's review. 932 13. References 934 13.1. Normative References 936 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 937 Requirement Levels", BCP 14, RFC 2119, 938 DOI 10.17487/RFC2119, March 1997, 939 . 941 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 942 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 943 DOI 10.17487/RFC4271, January 2006, 944 . 946 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 947 System Confederations for BGP", RFC 5065, 948 DOI 10.17487/RFC5065, August 2007, 949 . 951 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 952 in Support of Generalized Multi-Protocol Label Switching 953 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 954 . 956 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 957 Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, 958 June 2011, . 960 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 961 Decraene, B., Litkowski, S., and R. Shakir, "Segment 962 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 963 July 2018, . 965 13.2. Informative References 967 [I-D.dawra-idr-bgpls-srv6-ext] 968 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 969 daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., and 970 H. Elmalky, "BGP Link State extensions for IPv6 Segment 971 Routing(SRv6)", draft-dawra-idr-bgpls-srv6-ext-04 (work in 972 progress), September 2018. 974 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 975 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 976 and M. Chen, "BGP Link-State extensions for Segment 977 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-09 978 (work in progress), October 2018. 980 [I-D.ietf-spring-segment-routing-central-epe] 981 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 982 Afanasiev, "Segment Routing Centralized BGP Egress Peer 983 Engineering", draft-ietf-spring-segment-routing-central- 984 epe-10 (work in progress), December 2017. 986 [I-D.ietf-spring-segment-routing-policy] 987 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 988 bogdanov@google.com, b., and P. Mattes, "Segment Routing 989 Policy Architecture", draft-ietf-spring-segment-routing- 990 policy-01 (work in progress), June 2018. 992 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 993 S. Ray, "North-Bound Distribution of Link-State and 994 Traffic Engineering (TE) Information Using BGP", RFC 7752, 995 DOI 10.17487/RFC7752, March 2016, 996 . 998 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 999 Code: The Implementation Status Section", BCP 205, 1000 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1001 . 1003 Authors' Addresses 1005 Stefano Previdi (editor) 1006 Individual 1008 Email: stefano@previdi.net 1010 Ketan Talaulikar 1011 Cisco Systems, Inc. 1013 Email: ketant@cisco.com 1015 Clarence Filsfils 1016 Cisco Systems, Inc. 1017 Brussels 1018 Belgium 1020 Email: cfilsfil@cisco.com 1022 Keyur Patel 1023 Arrcus, Inc. 1025 Email: Keyur@arrcus.com 1027 Saikat Ray 1028 Individual Contributor 1030 Email: raysaikat@gmail.com 1032 Jie Dong 1033 Huawei Technologies 1034 Huawei Campus, No. 156 Beiqing Rd. 1035 Beijing 100095 1036 China 1038 Email: jie.dong@huawei.com