idnits 2.17.1 draft-ietf-idr-bgpls-segment-routing-epe-19.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 (May 16, 2019) is 1807 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-14 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing S. Previdi 3 Internet-Draft Individual 4 Intended status: Standards Track K. Talaulikar, Ed. 5 Expires: November 17, 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 May 16, 2019 15 BGP-LS extensions for Segment Routing BGP Egress Peer Engineering 16 draft-ietf-idr-bgpls-segment-routing-epe-19 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", "NOT RECOMMENDED", "MAY", and 36 "OPTIONAL" in this document are to be interpreted as described in BCP 37 14 [RFC2119] [RFC8174] when, and only when, they appear in all 38 capitals, as shown here. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on November 17, 2019. 57 Copyright Notice 59 Copyright (c) 2019 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 4 76 3. BGP-LS NLRI Advertisement for BGP Protocol . . . . . . . . . 5 77 3.1. BGP Router-ID and Member AS Number . . . . . . . . . . . 6 78 3.2. Mandatory BGP Node Descriptors . . . . . . . . . . . . . 6 79 3.3. Optional BGP Node Descriptors . . . . . . . . . . . . . . 7 80 4. BGP-LS Attributes for BGP Peering Segments . . . . . . . . . 7 81 4.1. Advertisement of the PeerNode SID . . . . . . . . . . . . 10 82 4.2. Advertisement of the PeerAdj SID . . . . . . . . . . . . 11 83 4.3. Advertisement of the PeerSet SID . . . . . . . . . . . . 12 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 5.1. New BGP-LS Protocol-ID . . . . . . . . . . . . . . . . . 13 86 5.2. Node Descriptors and Link Attribute TLVs . . . . . . . . 13 87 6. Manageability Considerations . . . . . . . . . . . . . . . . 14 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 89 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 93 10.2. Informative References . . . . . . . . . . . . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 96 1. Introduction 98 Segment Routing (SR) leverages source routing. A node steers a 99 packet through a controlled set of instructions, called segments, by 100 prepending the packet with an SR header with segment identifiers 101 (SID). A SID can represent any instruction, topological or service- 102 based. SR segments allows to enforce a flow through any topological 103 path or service function while maintaining per-flow state only at the 104 ingress node of the SR domain. 106 The SR architecture [RFC8402] defines three types of BGP Peering 107 Segments that may be instantiated at a BGP node: 109 o Peer Node Segment (PeerNode SID) : instruction to steer to a 110 specific peer node 112 o Peer Adjacency Segment (PeerAdj SID) : instruction to steer over a 113 specific local interface towards a specific peer node 115 o Peer Set Segment (PeerSet SID) : instruction to load-balance to a 116 set of specific peer nodes 118 SR can be directly applied to either to an MPLS dataplane (SR/MPLS) 119 with no change on the forwarding plane or to a modified IPv6 120 forwarding plane (SRv6). 122 This document describes extensions to the BGP Link-State NLRI (BGP-LS 123 NLRI) and the BGP-LS Attribute defined for BGP-LS [RFC7752] for 124 advertising BGP peering segments from a BGP node along with its 125 peering topology information (i.e., its peers, interfaces, and 126 peering ASs) to enable computation of efficient BGP Egress Peer 127 Engineering (BGP-EPE) policies and strategies using the SR/MPLS 128 dataplane. The corresponding extensions for SRv6 are specified in 129 [I-D.dawra-idr-bgpls-srv6-ext]. 131 [I-D.ietf-spring-segment-routing-central-epe] illustrates a 132 centralized controller-based BGP Egress Peer Engineering solution 133 involving SR path computation using the BGP Peering Segments. This 134 use case comprises a centralized controller that learns the BGP 135 Peering SIDs via BGP-LS and then uses this information to program a 136 BGP-EPE policy at any node in the domain to perform traffic steering 137 via a specific BGP egress node to a specific EBGP peer(s) optionally 138 also over a specific interface. The BGP-EPE policy can be realized 139 using the SR Policy framework 140 [I-D.ietf-spring-segment-routing-policy]. 142 This document introduces a new BGP-LS Protocol-ID for BGP and defines 143 new BGP-LS Node and Link Descriptor TLVs to facilitate advertising 144 BGP-LS Link NLRI to represent the BGP peering topology. Further, it 145 specifies the BGP-LS Attribute TLVs for advertisement of the BGP 146 Peering Segments (i.e., PeerNode SID, PeerAdj SID, and PeerSet SID) 147 to be advertised in the same BGP-LS Link NLRI. 149 2. BGP Peering Segments 151 As described in [RFC8402], a BGP-EPE enabled Egress PE node 152 instantiates SR Segments corresponding to its attached peers. These 153 segments are called BGP Peering Segments or BGP Peering SIDs. In 154 case of EBGP, they enable the expression of source-routed inter- 155 domain paths. 157 An ingress border router of an AS may compose a list of SIDs to steer 158 a flow along a selected path within the AS, towards a selected egress 159 border router C of the AS, and to a specific EBGP peer. At minimum, 160 a BGP-EPE policy applied at an ingress PE involves two SIDs: the Node 161 SID of the chosen egress PE and then the BGP Peering SID for the 162 chosen egress PE peer or peering interface. 164 Each BGP session MUST be described by a PeerNode SID. The 165 description of the BGP session MAY be augmented by additional PeerAdj 166 SIDs. Finally, multiple PeerNode SIDs or PeerAdj SIDs MAY be part of 167 the same group/set in order to group EPE resources under a common 168 PeerSet SID. These BGP Peering SIDs and their encoding are described 169 in detail in Section 4. 171 The following BGP Peering SIDs need to be instantiated on a BGP 172 router for each of its BGP peer sessions that are enabled for Egress 173 Peer Engineering: 175 o One PeerNode SID MUST be instantiated to describe the BGP peer 176 session. 178 o One or more PeerAdj SID MAY be instantiated corresponding to the 179 underlying link(s) to the directly connected BGP peer session. 181 o A PeerSet SID MAY be instantiated and additionally associated and 182 shared between one or more PeerNode SIDs or PeerAdj SIDs. 184 While an egress point in a topology usually refers to EBGP sessions 185 between external peers, there's nothing in the extensions defined in 186 this document that would prevent the use of these extensions in the 187 context of IBGP sessions. However, unlike EBGP sessions which are 188 generally between directly connected BGP routers which are also along 189 the traffic forwarding path, IBGP peer sessions may be setup to BGP 190 routers which are not in the forwarding path. As such, when the IBGP 191 design includes sessions with route-reflectors, a BGP router SHOULD 192 NOT instantiate a BGP Peering SID for those sessions to peer nodes 193 which are not in the forwarding path since the purpose of BGP Peering 194 SID is to steer traffic to that specific peers. Thus, the 195 applicability for IBGP peering may be limited to only those 196 deployments where the IBGP peer is also along the forwarding data 197 path. 199 Any BGP Peering SIDs instantiated on the node are advertised via BGP- 200 LS Link NLRI type as described in the sections below. An 201 illustration of the BGP Peering SIDs' allocations in a reference BGP 202 peering topology along with the information carried in the BGP-LS 203 Link NLRI and its corresponding BGP-LS Attribute are described in 204 [I-D.ietf-spring-segment-routing-central-epe]. 206 3. BGP-LS NLRI Advertisement for BGP Protocol 208 This section describes the BGP-LS NLRI encodings that describe the 209 BGP peering and link connectivity between BGP routers. 211 This document specifies the advertisement of BGP peering topology 212 information via BGP-LS Link NLRI type which requires use of a new 213 BGP-LS Protocol-ID. 215 +-------------+----------------------------------+ 216 | Protocol-ID | NLRI information source protocol | 217 +-------------+----------------------------------+ 218 | 7 | BGP | 219 +-------------+----------------------------------+ 221 Table 1: BGP-LS Protocol Identifier for BGP 223 The use of a new Protocol-ID allows separation and differentiation 224 between the BGP-LS NLRIs carrying BGP information from the BGP-LS 225 NLRIs carrying IGP link-state information defined in [RFC7752]. 227 The BGP Peering information along with their Peering Segments are 228 advertised using BGP-LS Link NLRI type with the Protocol-ID set to 229 BGP. The BGP-LS Link NLRI type uses the Descriptor TLVs and BGP-LS 230 Attribute TLVs as defined in [RFC7752]. In order to correctly 231 describe BGP nodes, new TLVs are defined in this section. 233 [RFC7752] defines Link NLRI Type is as follows: 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+ 238 | Protocol-ID | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Identifier | 241 | (64 bits) | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 // Local Node Descriptors // 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 // Remote Node Descriptors // 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 // Link Descriptors // 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Figure 1: BGP-LS Link NLRI 252 Node Descriptors and Link Descriptors are defined in [RFC7752]. 254 3.1. BGP Router-ID and Member AS Number 256 Two new Node Descriptors TLVs are defined in this document: 258 o BGP Router Identifier (BGP Router-ID): 260 Type: 516 262 Length: 4 octets 264 Value: 4 octet unsigned non-zero integer representing the BGP 265 Identifier as defined in [RFC6286]. 267 o Member-AS Number (Member-ASN) 269 Type: 517 271 Length: 4 octets 273 Value: 4 octet unsigned non-zero integer representing the 274 Member-AS Number [RFC5065]. 276 3.2. Mandatory BGP Node Descriptors 278 The following Node Descriptors TLVs MUST be included in BGP-LS NLRI 279 as Local Node Descriptors when distributing BGP information: 281 o BGP Router-ID (TLV 516), which contains a valid BGP Identifier of 282 the local BGP node. 284 o Autonomous System Number (TLV 512) [RFC7752], which contains the 285 ASN or AS Confederation Identifier (ASN) [RFC5065], if 286 confederations are used, of the local BGP node. 288 Note that [RFC6286] (section 2.1) requires the BGP identifier 289 (Router-ID) to be unique within an Autonomous System and non-zero. 290 Therefore, the tuple is globally unique. Their 291 use in the Node Descriptor helps map Link-State NLRIs with BGP 292 protocol-ID to a unique BGP router in the administrative domain where 293 BGP-LS is enabled. 295 The following Node Descriptors TLVs MUST be included in BGP-LS Link 296 NLRI as Remote Node Descriptors when distributing BGP information: 298 o BGP Router-ID (TLV 516), which contains the valid BGP Identifier 299 of the peer BGP node. 301 o Autonomous System Number (TLV 512) [RFC7752], which contains the 302 ASN or the AS Confederation Identifier (ASN) [RFC5065], if 303 confederations are used, of the peer BGP node. 305 3.3. Optional BGP Node Descriptors 307 The following Node Descriptors TLVs MAY be included in BGP-LS NLRI as 308 Local Node Descriptors when distributing BGP information: 310 o Member-ASN (TLV 517), which contains the ASN of the confederation 311 member (i.e., Member-AS Number), if BGP confederations are used, 312 of the local BGP node. 314 o Node Descriptors as defined in [RFC7752]. 316 The following Node Descriptors TLVs MAY be included in BGP-LS Link 317 NLRI as Remote Node Descriptors when distributing BGP information: 319 o Member-ASN (TLV 517), which contains the ASN of the confederation 320 member (i.e., Member-AS Number), if BGP confederations are used, 321 of the peer BGP node. 323 o Node Descriptors as defined in [RFC7752]. 325 4. BGP-LS Attributes for BGP Peering Segments 327 This section defines the BGP-LS Attributes corresponding to the 328 following BGP Peer Segment SIDs: 330 Peer Node Segment Identifier (PeerNode SID) 331 Peer Adjacency Segment Identifier (PeerAdj SID) 333 Peer Set Segment Identifier (PeerSet SID) 335 The following new BGP-LS Link attributes TLVs are defined for use 336 with BGP-LS Link NLRI for advertising BGP Peering SIDs: 338 +----------+---------------------------+ 339 | TLV Code | Description | 340 | Point | | 341 +----------+---------------------------+ 342 | 1101 | PeerNode SID | 343 | 1102 | PeerAdj SID | 344 | 1103 | PeerSet SID | 345 +----------+---------------------------+ 347 Figure 2: BGP-LS TLV code points for BGP-EPE 349 PeerNode SID, PeerAdj SID, and PeerSet SID have all the same format 350 defined here below: 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Type | Length | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Flags | Weight | Reserved | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | SID/Label/Index (variable) | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 3: BGP Peering SIDs TLV Format 364 o Type: 1101, 1102 or 1103 as listed in Figure 2. 366 o Length: variable. Valid values are either 7 or 8 based on the 367 whether the encoding is done as a SID Index or a label. 369 o Flags: one octet of flags with the following definition: 371 0 1 2 3 4 5 6 7 372 +-+-+-+-+-+-+-+-+ 373 |V|L|B|P| Rsvd | 374 +-+-+-+-+-+-+-+-+ 376 Figure 4: Peering SID TLV Flags Format 378 * V-Flag: Value flag. If set, then the SID carries a label 379 value. By default the flag is SET. 381 * L-Flag: Local Flag. If set, then the value/index carried by 382 the SID has local significance. By default the flag is SET. 384 * B-Flag: Backup Flag. If set, the SID refers to a path that is 385 eligible for protection using fast re-route (FRR). The 386 computation of the backup forwarding path and its association 387 with the BGP Peering SID forwarding entry is implementation 388 specific. [I-D.ietf-spring-segment-routing-central-epe] 389 section 3.6 discusses some of the possible ways of identifying 390 backup paths for BGP Peering SIDs. 392 * P-Flag: Persistent Flag: If set, the SID is persistently 393 allocated, i.e., the SID value remains consistent across router 394 restart and session/interface flap. 396 * Rsvd bits: Reserved for future use and MUST be zero when 397 originated and ignored when received. 399 o Weight: 1 octet. The value represents the weight of the SID for 400 the purpose of load balancing. An example use of the weight is 401 described in [RFC8402]. 403 o SID/Index/Label. According to the TLV length and to the V and L 404 flags settings, it contains either: 406 * A 3 octet local label where the 20 rightmost bits are used for 407 encoding the label value. In this case, the V and L flags MUST 408 be SET. 410 * A 4 octet index defining the offset in the Segment Routing 411 Global Block (SRGB) [RFC8402] advertised by this router. In 412 this case, the SRGB MUST be advertised using the extensions 413 defined in [I-D.ietf-idr-bgp-ls-segment-routing-ext]. 415 The values of the PeerNode SID, PeerAdj SID, and PeerSet SID Sub-TLVs 416 SHOULD be persistent across router restart. 418 When enabled for Egress Peer Engineering, the BGP router MUST include 419 the PeerNode SID TLV in the BGP-LS Attribute for the BGP-LS Link NLRI 420 corresponding to its BGP peering sessions. The PeerAdj SID and 421 PeerSet SID TLVs MAY be included in the BGP-LS Attribute for the BGP- 422 LS Link NLRI. 424 Additional BGP-LS Link Attribute TLVs, as defined in [RFC7752] MAY be 425 included with the BGP-LS Link NLRI in order to advertise the 426 characteristics of the peering link. E.g., one or more interface 427 addresses (TLV 259 or TLV 261) of the underlying link(s) over which a 428 multi-hop BGP peering session is setup may be included in the BGP-LS 429 Attribute along with the PeerNode SID TLV. 431 4.1. Advertisement of the PeerNode SID 433 The PeerNode SID TLV includes a SID associated with the BGP peer node 434 that is described by a BGP-LS Link NLRI as specified in Section 3. 436 The PeerNode SID, at the BGP node advertising it, has the following 437 semantics (as defined in [RFC8402]): 439 o SR operation: NEXT. 441 o Next-Hop: the connected peering node to which the segment is 442 associated. 444 The PeerNode SID is advertised with a BGP-LS Link NLRI, where: 446 o Local Node Descriptors include: 448 * Local BGP Router-ID (TLV 516) of the BGP-EPE enabled egress PE. 450 * Local ASN (TLV 512). 452 o Remote Node Descriptors include: 454 * Peer BGP Router-ID (TLV 516) (i.e., the peer BGP ID used in the 455 BGP session) 457 * Peer ASN (TLV 512). 459 o Link Descriptors include the addresses used by the BGP session 460 encoded using TLVs as defined in [RFC7752]: 462 * IPv4 Interface Address (TLV 259) contains the BGP session IPv4 463 local address. 465 * IPv4 Neighbor Address (TLV 260) contains the BGP session IPv4 466 peer address. 468 * IPv6 Interface Address (TLV 261) contains the BGP session IPv6 469 local address. 471 * IPv6 Neighbor Address (TLV 262) contains the BGP session IPv6 472 peer address. 474 o Link Attribute TLVs include the PeerNode SID TLV as defined in 475 Figure 3. 477 4.2. Advertisement of the PeerAdj SID 479 The PeerAdj SID TLV includes a SID associated with the underlying 480 link to the BGP peer node that is described by a BGP-LS Link NLRI as 481 specified in Section 3. 483 The PeerAdj SID, at the BGP node advertising it, has the following 484 semantics (as defined in [RFC8402]): 486 o SR operation: NEXT. 488 o Next-Hop: the interface peer address. 490 The PeerAdj SID is advertised with a BGP-LS Link NLRI, where: 492 o Local Node Descriptors include: 494 * Local BGP Router-ID (TLV 516) of the BGP-EPE enabled egress PE. 496 * Local ASN (TLV 512). 498 o Remote Node Descriptors include: 500 * Peer BGP Router-ID (TLV 516) (i.e., the peer BGP ID used in the 501 BGP session). 503 * Peer ASN (TLV 512). 505 o Link Descriptors MUST include the following TLV, as defined in 506 [RFC7752]: 508 * Link Local/Remote Identifiers (TLV 258) contains the 4-octet 509 Link Local Identifier followed by the 4-octet Link Remote 510 Identifier. The value 0 is used by default when the link 511 remote identifier is unknown. 513 o Additional Link Descriptors TLVs, as defined in [RFC7752], MAY 514 also be included to describe the addresses corresponding to the 515 link between the BGP routers: 517 * IPv4 Interface Address (Sub-TLV 259) contains the address of 518 the local interface through which the BGP session is 519 established. 521 * IPv6 Interface Address (Sub-TLV 261) contains the address of 522 the local interface through which the BGP session is 523 established. 525 * IPv4 Neighbor Address (Sub-TLV 260) contains the IPv4 address 526 of the peer interface used by the BGP session. 528 * IPv6 Neighbor Address (Sub-TLV 262) contains the IPv6 address 529 of the peer interface used by the BGP session. 531 o Link Attribute TLVs include the PeerAdj SID TLV as defined in 532 Figure 3. 534 4.3. Advertisement of the PeerSet SID 536 The PeerSet SID TLV includes a SID that is shared amongst BGP peer 537 nodes or the underlying links that are described by BGP-LS Link NLRI 538 as specified in Section 3. 540 The PeerSet SID, at the BGP node advertising it, has the following 541 semantics (as defined in [RFC8402]): 543 o SR operation: NEXT. 545 o Next-Hop: load balance across any connected interface to any peer 546 in the associated peer set. 548 The PeerSet SID TLV containing the same SID value (encoded as defined 549 in Figure 3) is included in the BGP-LS Attribute for all of the BGP- 550 LS Link NLRI corresponding to the PeerNode or PeerAdj segments 551 associated with the peer set. 553 5. IANA Considerations 555 This document defines: 557 A new Protocol-ID: BGP. The codepoint is from the "BGP-LS 558 Protocol-IDs" registry. 560 Two new TLVs: BGP-Router-ID and BGP Confederation Member. The 561 codepoints are in the "BGP-LS Node Descriptor, Link Descriptor, 562 Prefix Descriptor, and Attribute TLVs" registry. 564 Three new BGP-LS Attribute TLVs: PeerNode SID, PeerAdj SID and 565 PeerSet SID. The codepoints are in the "BGP-LS Node Descriptor, 566 Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry. 568 5.1. New BGP-LS Protocol-ID 570 This document defines a new value in the registry "BGP-LS Protocol- 571 IDs": 573 +------------------------------------------------------+ 574 | Codepoint | Description | Status | 575 +------------------------------------------------------+ 576 | 7 | BGP | Early Allocation by IANA | 577 +------------------------------------------------------+ 579 Figure 5: BGP Protocol Codepoint 581 5.2. Node Descriptors and Link Attribute TLVs 583 This document defines 5 new TLVs in the registry "BGP-LS Node 584 Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs": 586 o Two new node descriptor TLVs 588 o Three new link attribute TLVs 590 All the new 5 codepoints are in the same registry: "BGP-LS Node 591 Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs". 593 The following new Node Descriptors TLVs are defined: 595 +-------------------------------------------------------------------+ 596 | Codepoint | Description | Status | 597 +-------------------------------------------------------------------+ 598 | 516 | BGP Router-ID | Early Allocation by IANA | 599 | 517 | BGP Confederation Member | Early Allocation by IANA | 600 +------------+------------------------------------------------------+ 602 Figure 6: BGP-LS Descriptor TLVs Codepoints 604 The following new Link Attribute TLVs are defined: 606 +-------------------------------------------------------------------+ 607 | Codepoint | Description | Status | 608 +-------------------------------------------------------------------+ 609 | 1101 | PeerNode SID | Early Allocation by IANA | 610 | 1102 | PeerAdj SID | Early Allocation by IANA | 611 | 1103 | PeerSet SID | Early Allocation by IANA | 612 +------------+------------------------------------------------------+ 614 Figure 7: BGP-LS Attribute TLVs Codepoints 616 6. Manageability Considerations 618 The new protocol extensions introduced in this document augment the 619 existing IGP topology information BGP-LS distribution [RFC7752] by 620 adding support for distribution of BGP peering topology information. 621 As such, the Manageability Considerations section of [RFC7752] 622 applies to these new extensions as well. 624 Specifically, the malformed Link-State NLRI and BGP-LS Attribute 625 tests for syntactic checks in the Fault Management section of 626 [RFC7752] now apply to the TLVs defined in this document. The 627 semantic or content checking for the TLVs specified in this document 628 and their association with the BGP-LS NLRI types or their associated 629 BGP-LS Attributes is left to the consumer of the BGP-LS information 630 (e.g., an application or a controller) and not the BGP protocol. 632 A consumer of the BGP-LS information retrieves this information from 633 a BGP Speaker, over a BGP-LS session (refer Section 1 and 2 of 634 [RFC7752]). The handling of semantic or content errors by the 635 consumer would be dictated by the nature of its application usage and 636 hence is beyond the scope of this document. It may be expected that 637 an error detected in the NLRI descriptor TLVs would result in that 638 specific NLRI update being unusable and hence its update to be 639 discarded along with an error log. While an error in Attribute TLVs 640 would result in only that specific attribute being discarded with an 641 error log. 643 The operator MUST be provided with the options of configuring, 644 enabling, and disabling the advertisement of each of the PeerNode 645 SID, PeerAdj SID, and PeerSet SID as well as control of which 646 information is advertised to which internal or external peer. This 647 is not different from what is required by a BGP speaker in terms of 648 information origination and advertisement. 650 BGP Peering Segments are associated with the normal BGP routing 651 peering sessions. However, the BGP peering information along with 652 these Peering Segments themselves are advertised via a distinct BGP- 653 LS peering session. It is expected that this isolation as described 654 in [RFC7752] is followed when advertising BGP peering topology 655 information via BGP-LS. 657 BGP-EPE functionality enables the capability for instantiation of an 658 SR path for traffic engineering a flow via an egress BGP router to a 659 specific peer, bypassing the normal BGP best path routing for that 660 flow and any routing policies implemented in BGP on that egress BGP 661 router. As with any traffic engineering solution, the controller or 662 application implementing the policy needs to ensure that there is no 663 looping or mis-routing of traffic. Traffic counters corresponding to 664 the MPLS label of the BGP Peering SID on the router would indicate 665 the traffic being forwarded based on the specific EPE path. 666 Monitoring these counters and the flows hitting the corresponding 667 MPLS forwarding entry would help identify issues, if any, with 668 traffic engineering over the EPE paths. Errors in the encoding or 669 decoding of the SR information in the TLVs defined in this document 670 may result in the unavailability of such information to a Centralized 671 EPE Controller or incorrect information being made available to it. 672 This may result in the controller not being able to perform the 673 desired SR based optimization functionality or to perform it in an 674 unexpected or inconsistent manner. The handling of such errors by 675 applications like such a controller may be implementation specific 676 and out of scope of this document. 678 7. Security Considerations 680 [RFC7752] defines BGP-LS NLRI to which the extensions defined in this 681 document apply. The Security Considerations section of [RFC7752] 682 also applies to these extensions. The procedures and new TLVs 683 defined in this document, by themselves, do not affect the BGP-LS 684 security model discussed in [RFC7752]. 686 BGP-EPE enables engineering of traffic when leaving the 687 administrative domain via an egress BGP router. Therefore precaution 688 is necessary to ensure that the BGP peering information collected via 689 BGP-LS is limited to specific consumers in a secure manner. Segment 690 Routing operates within a trusted domain [RFC8402] and its security 691 considerations also apply to BGP Peering Segments. The BGP-EPE 692 policies are expected to be used entirely within this trusted SR 693 domain (e.g., between multiple AS/domains within a single provider 694 network). 696 The isolation of BGP-LS peering sessions is also required to ensure 697 that BGP-LS topology information (including the newly added BGP 698 peering topology) is not advertised to an external BGP peering 699 session outside an administrative domain. 701 8. Contributors 703 Mach (Guoyi) Chen 704 Huawei Technologies 705 China 707 Email: mach.chen@huawei.com 708 Acee Lindem 709 Cisco Systems Inc. 710 US 712 Email: acee@cisco.com 714 9. Acknowledgements 716 The authors would like to thank Jakob Heitz, Howard Yang, Hannes 717 Gredler, Peter Psenak, Arjun Sreekantiah and Bruno Decraene for their 718 feedback and comments. Susan Hares helped in improving the clarity 719 of the document with her substantial contributions during her 720 shepherd's review. The authors would also like to thank Alvaro 721 Retana for his extensive review and comments which helped correct 722 issues and improve the document. 724 10. References 726 10.1. Normative References 728 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 729 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 730 and M. Chen, "BGP Link-State extensions for Segment 731 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-14 732 (work in progress), May 2019. 734 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 735 Requirement Levels", BCP 14, RFC 2119, 736 DOI 10.17487/RFC2119, March 1997, 737 . 739 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 740 System Confederations for BGP", RFC 5065, 741 DOI 10.17487/RFC5065, August 2007, 742 . 744 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 745 Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, 746 June 2011, . 748 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 749 S. Ray, "North-Bound Distribution of Link-State and 750 Traffic Engineering (TE) Information Using BGP", RFC 7752, 751 DOI 10.17487/RFC7752, March 2016, 752 . 754 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 755 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 756 May 2017, . 758 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 759 Decraene, B., Litkowski, S., and R. Shakir, "Segment 760 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 761 July 2018, . 763 10.2. Informative References 765 [I-D.dawra-idr-bgpls-srv6-ext] 766 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 767 daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., and 768 H. Elmalky, "BGP Link State Extensions for SRv6", draft- 769 dawra-idr-bgpls-srv6-ext-06 (work in progress), March 770 2019. 772 [I-D.ietf-spring-segment-routing-central-epe] 773 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 774 Afanasiev, "Segment Routing Centralized BGP Egress Peer 775 Engineering", draft-ietf-spring-segment-routing-central- 776 epe-10 (work in progress), December 2017. 778 [I-D.ietf-spring-segment-routing-policy] 779 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 780 bogdanov@google.com, b., and P. Mattes, "Segment Routing 781 Policy Architecture", draft-ietf-spring-segment-routing- 782 policy-03 (work in progress), May 2019. 784 Authors' Addresses 786 Stefano Previdi 787 Individual 789 Email: stefano@previdi.net 791 Ketan Talaulikar (editor) 792 Cisco Systems, Inc. 793 India 795 Email: ketant@cisco.com 796 Clarence Filsfils 797 Cisco Systems, Inc. 798 Brussels 799 Belgium 801 Email: cfilsfil@cisco.com 803 Keyur Patel 804 Arrcus, Inc. 806 Email: Keyur@arrcus.com 808 Saikat Ray 809 Individual Contributor 811 Email: raysaikat@gmail.com 813 Jie Dong 814 Huawei Technologies 815 Huawei Campus, No. 156 Beiqing Rd. 816 Beijing 100095 817 China 819 Email: jie.dong@huawei.com