idnits 2.17.1 draft-ietf-idr-bgpls-segment-routing-epe-15.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 5, 2018) is 2215 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 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 2 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 C. Filsfils 5 Expires: September 6, 2018 Cisco Systems, Inc. 6 K. Patel 7 Arrcus, Inc. 8 S. Ray 9 Individual Contributor 10 J. Dong 11 Huawei Technologies 12 March 5, 2018 14 BGP-LS extensions for Segment Routing BGP Egress Peer Engineering 15 draft-ietf-idr-bgpls-segment-routing-epe-15 17 Abstract 19 Segment Routing (SR) leverages source routing. A node steers a 20 packet through a controlled set of instructions, called segments, by 21 prepending the packet with an SR header. A segment can represent any 22 instruction, topological or service-based. SR allows to enforce a 23 flow through any topological path and service chain while maintaining 24 per-flow state only at the ingress node of the SR domain. 26 The Segment Routing architecture can be directly applied to the MPLS 27 dataplane with no change on the forwarding plane. It requires minor 28 extension to the existing link-state routing protocols. 30 This document outline a BGP-LS extension for exporting BGP peering 31 node topology information (including its peers, interfaces and 32 peering ASs) in a way that is exploitable in order to compute 33 efficient BGP Peering Engineering policies and strategies. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC 2119 [RFC2119]. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on September 6, 2018. 58 Copyright Notice 60 Copyright (c) 2018 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Segment Routing Documents . . . . . . . . . . . . . . . . . . 4 77 3. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 4 78 4. Link NLRI for BGP-EPE Connectivity Description . . . . . . . 5 79 4.1. BGP Router ID and Member ASN . . . . . . . . . . . . . . 6 80 4.2. Mandatory BGP-EPE Node Descriptors . . . . . . . . . . . 6 81 4.3. Optional BGP-EPE Node Descriptors . . . . . . . . . . . . 7 82 4.4. Link Attributes . . . . . . . . . . . . . . . . . . . . . 7 83 5. Peer-Node and Peer-Adj SIDs . . . . . . . . . . . . . . . . . 9 84 5.1. Peer-Node-SID . . . . . . . . . . . . . . . . . . . . . . 10 85 5.2. Peer-Adj-SID . . . . . . . . . . . . . . . . . . . . . . 11 86 5.3. Peer-Set-SID . . . . . . . . . . . . . . . . . . . . . . 12 87 6. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 12 88 6.1. Reference Diagram . . . . . . . . . . . . . . . . . . . . 12 89 6.2. Peer-Node-SID for Node D . . . . . . . . . . . . . . . . 14 90 6.3. Peer-Node-SID for Node F . . . . . . . . . . . . . . . . 15 91 6.4. Peer-Node-SID for Node E . . . . . . . . . . . . . . . . 15 92 6.5. Peer-Adj-SID for Node E, Link 1 . . . . . . . . . . . . . 15 93 6.6. Peer-Adj-SID for Node E, Link 2 . . . . . . . . . . . . . 16 94 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 96 8.1. New BGP-LS Protocol-ID . . . . . . . . . . . . . . . . . 17 97 8.2. Node Descriptors and Link Attribute TLVs . . . . . . . . 17 98 9. Manageability Considerations . . . . . . . . . . . . . . . . 18 99 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 100 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 101 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 102 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 103 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 104 13.2. Informative References . . . . . . . . . . . . . . . . . 20 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 107 1. Introduction 109 Segment Routing (SR) leverages source routing. A node steers a 110 packet through a controlled set of instructions, called segments, by 111 prepending the packet with an SR header with segment identifiers 112 (SID). A SID can represent any instruction, topological or service- 113 based. SR allows to enforce a flow through any topological path and 114 service chain while maintaining per-flow state only at the ingress 115 node of the SR domain. 117 The Segment Routing architecture can be directly applied to the MPLS 118 dataplane with no change on the forwarding plane. It requires minor 119 extension to the existing link-state routing protocols. 121 This document outline a BGP-LS extension for exporting BGP peering 122 node topology information (including its peers, interfaces and 123 peering ASs) in a way that is exploitable in order to compute 124 efficient BGP Egress Peer Engineering (BGP-EPE) policies and 125 strategies. 127 This document defines the BGP-LS extensions required to support the 128 Peer Node SID describing the BGP session between two nodes, the Peer 129 Adjacency SID describing the link (one or more) that is used by the 130 BGP session and the Peer Set SID describing an arbitrary set of 131 sessions or links between the local BGP node and its peers. These 132 SIDs represent the segments defined in 133 [I-D.ietf-spring-segment-routing-central-epe]. 135 While an egress point topology usually refers to eBGP sessions 136 between external peers, there's nothing in the extensions defined in 137 this document that would prevent the use of these extensions in the 138 context of iBGP sessions. 140 2. Segment Routing Documents 142 The main reference for this document is the SR architecture defined 143 in [I-D.ietf-spring-segment-routing]. 145 The Segment Routing BGP Egress Peer Engineering (BGP-EPE) 146 architecture is described in 147 [I-D.ietf-spring-segment-routing-central-epe]. 149 3. BGP Peering Segments 151 As defined in [I-D.ietf-spring-segment-routing-central-epe], a BGP- 152 EPE enabled Egress PE node MAY advertise SIDs corresponding to its 153 attached peers. These SIDs are called BGP peering segments or BGP 154 Peering SIDs. In case of eBGP, they enable the expression of source- 155 routed inter-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 through a specific peer. At minimum, a 160 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 This document defines the BGP-LS extensions for the BGP-EPE Peering 165 SIDs: 167 o Peer Node Segment (Peer-Node-SID) 169 o Peer Adjacency Segment (Peer-Adj-SID) 171 o Peer Set Segment (Peer-Set-SID) 173 that have been defined in 174 [I-D.ietf-spring-segment-routing-central-epe]. 176 Each BGP session MUST be described by a Peer Node SID. The 177 description of the BGP session MAY be augmented by additional 178 Adjacency SIDs. Finally, each Peer Node SID and Peer Adjacency SID 179 MAY be part of the same group/set so to be able to group EPE 180 resources under a common Peer-Set SID. 182 Therefore, when the extensions defined in this document are applied 183 to the use case defined in 184 [I-D.ietf-spring-segment-routing-central-epe]: 186 o One Peer-Node-SID MUST be present. 188 o One or more Peer-Adj-SID MAY be present. 190 o Each of the Peer-Node-SID Peer-Adj-SID MAY use the same Peer-Set- 191 SID. 193 While an egress point topology usually refers to eBGP sessions 194 between external peers, there's nothing in the extensions defined in 195 this document that would prevent the use of these extensions in the 196 context of iBGP sessions. 198 4. Link NLRI for BGP-EPE Connectivity Description 200 This section describes the NLRI used for describing the connectivity 201 of the BGP Egress router. The connectivity is based on links and 202 remote peers/ASs and therefore the existing Link NLRI Type (defined 203 in [RFC7752]) is used. A new Protocol-ID is used: BGP (codepoint 7 204 assigned by IANA (Section 8) from the registry "BGP-LS Protocol- 205 IDs"). 207 The use of a new Protocol-ID allows separation and differentiation 208 between the NLRIs carrying BGP-EPE descriptors from the NLRIs 209 carrying IGP link-state information as defined in [RFC7752]. The 210 Link NLRI Type uses descriptors and attributes already defined in 211 [RFC7752] in addition to new TLVs defined in the following sections 212 of this document. 214 The extensions defined in this document apply to both internal and 215 external BGP-LS EPE advertisements. 217 [RFC7752] defines Link NLRI Type is as follows: 219 0 1 2 3 220 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 221 +-+-+-+-+-+-+-+-+ 222 | Protocol-ID | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Identifier | 225 | (64 bits) | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 // Local Node Descriptors // 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 // Remote Node Descriptors // 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 // Link Descriptors // 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Node Descriptors and Link Descriptors are defined in [RFC7752]. 236 4.1. BGP Router ID and Member ASN 238 Two new Node Descriptors Sub-TLVs are defined in this document: 240 o BGP Router Identifier (BGP Router-ID): 242 Type: 516 (assigned by IANA (Section 8) from the registry "BGP- 243 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 244 Attribute TLVs"). 246 Length: 4 octets 248 Value: 4 octet unsigned integer representing the BGP Identifier 249 as defined in [RFC4271] and [RFC6286]. 251 o Confederation Member ASN (Member-ASN) 253 Type: 517 (assigned by IANA (Section 8) from the registry "BGP- 254 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 255 Attribute TLVs"). 257 Length: 4 octets 259 Value: 4 octet unsigned integer representing the Member ASN 260 inside the Confederation.[RFC5065]. 262 4.2. Mandatory BGP-EPE Node Descriptors 264 The following Node Descriptors Sub-TLVs MUST appear in the Link NLRI 265 as Local Node Descriptors: 267 o BGP Router-ID, which contains the BGP Identifier of the local BGP- 268 EPE capable node. 270 o Autonomous System Number, which contains the local ASN or local 271 confederation identifier (ASN) if confederations are used. 273 It has to be noted that [RFC6286] (section 2.1) requires the BGP 274 identifier (router-id) to be unique within an Autonomous System. 275 Therefore, the tuple is globally unique. 277 The following Node Descriptors Sub-TLVs MUST appear in the Link NLRI 278 as Remote Node Descriptors: 280 o BGP Router-ID, which contains the BGP Identifier of the peer node. 282 o Autonomous System Number, which contains the peer ASN or the peer 283 confederation identifier (ASN), if confederations are used. 285 4.3. Optional BGP-EPE Node Descriptors 287 The following Node Descriptors Sub-TLVs MAY appear in the Link NLRI 288 as Local Node Descriptors: 290 o Member-ASN, which contains the ASN of the confederation member 291 (when BGP confederations are used). 293 o Node Descriptors as defined in [RFC7752]. 295 The following Node Descriptors Sub-TLVs MAY appear in the Link NLRI 296 as Remote Node Descriptors: 298 o Member-ASN, which contains the ASN of the confederation member 299 (when BGP confederations are used). 301 o Node Descriptors as defined in defined in [RFC7752]. 303 4.4. Link Attributes 305 The following BGP-LS Link attributes TLVs are used with the Link 306 NLRI: 308 +----------+---------------------------+----------+ 309 | TLV Code | Description | Length | 310 | Point | | | 311 +----------+---------------------------+----------+ 312 | 1101 | Peer Node Segment | variable | 313 | | Identifier (Peer-Node-SID)| | 314 | 1102 | Peer Adjacency Segment | variable | 315 | | Identifier (Peer-Adj-SID) | | 316 | 1103 | Peer Set Segment | variable | 317 | | Identifier (Peer-Set-SID) | | 318 +----------+---------------------------+----------+ 320 Figure 1: BGP-LS TLV code points for BGP-EPE 322 Peer-Node-SID, Peer-Adj-SID and Peer-Set-SID have all the same format 323 defined here below: 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Type | Length | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Flags | Weight | Reserved | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | SID/Label/Index (variable) | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 where: 337 Figure 2 339 o Type: 1101 or 1102 or 1103 (assigned by IANA (Section 8) from the 340 registry "BGP-LS Node Descriptor, Link Descriptor, Prefix 341 Descriptor, and Attribute TLVs"). 343 o Length: variable. 345 o Flags: one octet of flags used when advertising a Peer-Adj-SID 346 (Peer-Node and Peer-Set SIDs don't have flags defined). The 347 following Peer-Adj-SID flags have been defined: 349 0 1 2 3 4 5 6 7 350 +-+-+-+-+-+-+-+-+ 351 |V|L|B|P| | 352 +-+-+-+-+-+-+-+-+ 354 where: 356 * V-Flag: Value flag. If set, then the SID carries a label 357 value. By default the flag is SET. 359 * L-Flag: Local Flag. If set, then the value/index carried by 360 the SID has local significance. By default the flag is SET. 362 * B-Flag: Backup Flag. If set, the SID refers to a path that is 363 eligible for protection. 365 * P-Flag: Persistent Flag: If set, the SID is persistently 366 allocated, i.e., the SID value remains consistent across router 367 restart and session/interface flap. 369 * Other bits: MUST be zero when originated and ignored when 370 received. 372 o Weight: 1 octet. The value represents the weight of the SID for 373 the purpose of load balancing. An example use of the weight is 374 described in [I-D.ietf-spring-segment-routing]. 376 o SID/Index/Label. According to the TLV length and to the V and L 377 flags settings, it contains either: 379 * A 3 octet local label where the 20 rightmost bits are used for 380 encoding the label value. In this case the V and L flags MUST 381 be set. 383 * A 4 octet index defining the offset in the SRGB (Segment 384 Routing Global Block as defined in 385 [I-D.ietf-spring-segment-routing] advertised by this router. 386 In this case, the SRGB MUST be advertised using the extensions 387 defined in [I-D.ietf-idr-bgp-ls-segment-routing-ext]. 389 The values of the Peer-Node-SID, Peer-Adj-SID and Peer-Set-SID Sub- 390 TLVs SHOULD be persistent across router restart. 392 The Peer-Node-SID MUST be present when BGP-LS is used for the use 393 case described in [I-D.ietf-spring-segment-routing-central-epe] and 394 MAY be omitted for other use cases. 396 The Peer-Adj-SID and Peer-Set-SID SubTLVs MAY be present when BGP-LS 397 is used for the use case described in 398 [I-D.ietf-spring-segment-routing-central-epe] and MAY be omitted for 399 other use cases. 401 In addition, BGP-LS Node and Link Attributes, as defined in [RFC7752] 402 MAY be inserted in order to advertise the characteristics of the 403 link. 405 5. Peer-Node and Peer-Adj SIDs 407 In this section the following SIDs are defined: 409 Peer Node Segment Identifier (Peer-Node-SID) 411 Peer Adjacency Segment Identifier (Peer-Adj-SID) 413 Peer Set Segment Identifier (Peer-Set-SID) 415 The Peer-Node, Peer-Adj and Peer-Set SIDs can be either a local or a 416 global (depending on the setting of the V and L flags defined in 417 Figure 2. 419 5.1. Peer-Node-SID 421 The Peer-Node-SID describes the BGP session peer (neighbor). It MUST 422 be present when describing a BGP-EPE topology as defined in 423 [I-D.ietf-spring-segment-routing-central-epe]. The Peer-Node-SID is 424 encoded within the BGP-LS Link NLRI specified in Section 4. 426 The Peer-Node-SID, at the BGP node advertising it, has the following 427 semantic: 429 o SR header operation: NEXT (as defined in 430 [I-D.ietf-spring-segment-routing]). 432 o Next-Hop: the connected peering node to which the segment is 433 related. 435 The Peer-Node-SID is advertised with a Link NLRI, where: 437 o Local Node Descriptors contains 439 * Local BGP Router-ID of the BGP-EPE enabled egress PE. 441 * Local ASN. 443 o Remote Node Descriptors contains 445 * Peer BGP Router-ID (i.e.: the peer BGP ID used in the BGP 446 session). 448 * Peer ASN. 450 o Link Descriptors Sub-TLVs, as defined in [RFC7752], contain the 451 addresses used by the BGP session: 453 * IPv4 Interface Address (Sub-TLV 259) contains the BGP session 454 IPv4 local address. 456 * IPv4 Neighbor Address (Sub-TLV 260) contains the BGP session 457 IPv4 peer address. 459 * IPv6 Interface Address (Sub-TLV 261) contains the BGP session 460 IPv6 local address. 462 * IPv6 Neighbor Address (Sub-TLV 262) contains the BGP session 463 IPv6 peer address. 465 o Link Attribute contains the Peer-Node-SID TLV as defined in 466 Section 4.4. 468 o In addition, BGP-LS Link Attributes, as defined in [RFC7752], MAY 469 be inserted in order to advertise the characteristics of the link. 471 5.2. Peer-Adj-SID 473 The Peer-Adj-SID, at the BGP node advertising it, has the following 474 semantic: 476 o SR header operation: NEXT (as defined in 477 [I-D.ietf-spring-segment-routing]). 479 o Next-Hop: the interface peer address. 481 The Peer-Adj-SID is advertised with a Link NLRI, where: 483 o Local Node Descriptors contains 485 * Local BGP Router-ID of the BGP-EPE enabled egress PE. 487 * Local ASN. 489 o Remote Node Descriptors contains 491 * Peer BGP Router-ID (i.e.: the peer BGP ID used in the BGP 492 session). 494 * Peer ASN. 496 o Link Descriptors Sub-TLVs, as defined in [RFC7752], MUST contain 497 the following TLVs: 499 * Link Local/Remote Identifiers (Sub-TLV 258) contains the 500 4-octet Link Local Identifier followed by the 4-octet value 0 501 indicating the Link Remote Identifier in unknown [RFC5307]. 503 o In addition, Link Descriptors Sub-TLVs, as defined in [RFC7752], 504 MAY contain the following TLVs: 506 * IPv4 Interface Address (Sub-TLV 259) contains the address of 507 the local interface through which the BGP session is 508 established. 510 * IPv6 Interface Address (Sub-TLV 261) contains the address of 511 the local interface through which the BGP session is 512 established. 514 * IPv4 Neighbor Address (Sub-TLV 260) contains the IPv4 address 515 of the peer interface used by the BGP session. 517 * IPv6 Neighbor Address (Sub-TLV 262) contains the IPv6 address 518 of the peer interface used by the BGP session. 520 o Link attribute used with the Peer-Adj-SID contains the TLV as 521 defined in Section 4.4. 523 In addition, BGP-LS Link Attributes, as defined in [RFC7752], MAY be 524 inserted in order to advertise the characteristics of the link. 526 5.3. Peer-Set-SID 528 The Peer-Set-SID, at the BGP node advertising it, has the following 529 semantic: 531 o SR header operation: NEXT (as defined in 532 [I-D.ietf-spring-segment-routing]). 534 o Next-Hop: load balance across any connected interface to any peer 535 in the related set. 537 The Peer-Set-SID is advertised within a Link NLRI (describing a Peer 538 Node Segment or a Peer Adjacency segment) as a BGP-LS attribute. 540 The Link Attribute contains the Peer-Set-SID TLV, defined in 541 Section 4.4 identifying the set of which the Peer-Node-SID or Peer- 542 Adj-SID is a member. 544 6. Illustration 546 6.1. Reference Diagram 548 The following reference diagram is used throughout this document. 549 The solution is illustrated for IPv6 with MPLS-based SIDs and the 550 BGP-EPE topology is based on eBGP sessions between external peers. 552 As stated in Section 3, the solution illustrated hereafter is equally 553 applicable to an iBGP session topology. In other words, the solution 554 also applies to the case where C, D, F, and E are in the same AS and 555 run iBGP sessions between each other. 557 +------+ 558 | | 559 +---D H 560 +---------+ / | AS 2 |\ +------+ 561 | X |/ +------+ \ | Z |---L/8 562 A C---+ \| | 563 | |\\ \ +------+ /| AS 4 |---M/8 564 | AS1 | \\ +-F |/ +------+ 565 | | \\ | G 566 +----P----+ +===E AS 3 | 567 | +--Q---+ 568 | | 569 +----------------+ 571 Figure 3: Reference Diagram 573 IP addressing: 575 o C's IP address of interface to D: 2001:db8:cd::c/64, D's 576 interface: 2001:db8:cd::d/64 578 o C's IP address of interface to F: 2001:db8:cf::c/64, F's 579 interface: 2001:db8:cf::f/64 581 o C's IP address of upper interface to E: 2001:db8:ce1::c/64, E's 582 interface: 2001:db8:ce1::e 584 o C's local identifier of upper interface to E: 0.0.0.1.0.0.0.0 586 o C's IP address of lower interface to E: 2001:db8:ce2::c, E's 587 interface: 2001:db8:ce2::e 589 o C's local identifier of lower interface to E: 0.0.0.2.0.0.0.0 591 o Loopback of E used for eBGP multi-hop peering to C: 592 2001:db8:e::e/128 594 o C's loopback is 2001:db8:c::c/128 with SID 64 596 BGP Router-IDs are C, D, F and E. 598 o C's BGP Router-ID: 192.0.2.3 600 o D's BGP Router-ID: 192.0.2.4 602 o E's BGP Router-ID: 192.0.2.5 604 o F's BGP Router-ID: 192.0.2.6 605 C's BGP peering: 607 o Single-hop eBGP peering with neighbor 2001:db8:cd::d (D) 609 o Single-hop eBGP peering with neighbor 2001:db8:cf::f (F) 611 o Multi-hop eBGP peering with E on ip address 2001:db8:e::e (E) 613 C's resolution of the multi-hop eBGP session to E: 615 o Static route 2001:db8:e::e/128 via 2001:db8:ce1::e 617 o Static route 2001:db8:e::e/128 via 2001:db8:ce2::e 619 Node C configuration is such that: 621 o A Peer-Node-SID is allocated to each peer (D, F and E). 623 o An Peer-Adj-SID is defined for each recursing interface to a 624 multi-hop peer (CE upper and lower interfaces). 626 o A Peer-Set-SID is defined to include all peers in AS3 (peers F and 627 E). 629 The Link NLRI Type is used in order to encode C's connectivity. The 630 Link NLRI uses the Protocol-ID for BGP value 7 assigned by IANA. 632 Once the BGP-LS update is originated by C, it may be advertised to 633 internal (iBGP) as well as external (eBGP) neighbors supporting the 634 BGP-LS EPE extensions defined in this document. 636 6.2. Peer-Node-SID for Node D 638 Descriptors: 640 o Local Node Descriptors (BGP Router-ID, local ASN): 192.0.2.3, AS1 642 o Remote Node Descriptors (BGP Router-ID, peer ASN): 192.0.2.4, AS2 644 o Link Descriptors (BGP session IPv6 local address, BGP session IPv6 645 neighbor address): 2001:db8:cd::c, 2001:db8:cd::d 647 Attributes: 649 o Peer-Node-SID: 1012 651 o Link Attributes: see section 3.3.2 of [RFC7752] 653 6.3. Peer-Node-SID for Node F 655 Descriptors: 657 o Local Node Descriptors (BGP Router-ID, ASN): 192.0.2.3, AS1 659 o Remote Node Descriptors (BGP Router-ID ASN): 192.0.2.6, AS3 661 o Link Descriptors (BGP session IPv6 local address, BGP session IPv6 662 peer address): 2001:db8:cf::c, 2001:db8:cf::f 664 Attributes: 666 o Peer-Node-SID: 1022 668 o Peer-Set-SID: 1060 670 o Link Attributes: see section 3.3.2 of [RFC7752] 672 6.4. Peer-Node-SID for Node E 674 Descriptors: 676 o Local Node Descriptors (BGP Router-ID, ASN): 192.0.2.3, AS1 678 o Remote Node Descriptors (BGP Router-ID, ASN): 192.0.2.5, AS3 680 o Link Descriptors (BGP session IPv6 local address, BGP session IPv6 681 peer address): 2001:db8:c::c, 2001:db8:e::e 683 Attributes: 685 o Peer-Node-SID: 1052 687 o Peer-Set-SID: 1060 689 6.5. Peer-Adj-SID for Node E, Link 1 691 Descriptors: 693 o Local Node Descriptors (BGP Router-ID, ASN): 192.0.2.3, AS1 695 o Remote Node Descriptors (BGP Router-ID, ASN): 192.0.2.5, AS3 697 o Link Descriptors (local interface identifier, IPv6 peer interface 698 address): 0.0.0.1.0.0.0.0 , 2001:db8:ce1::e 700 Attributes: 702 o Peer-Adj-SID: 1032 704 o LinkAttributes: see section 3.3.2 of [RFC7752] 706 6.6. Peer-Adj-SID for Node E, Link 2 708 Descriptors: 710 o Local Node Descriptors (BGP Router-ID, ASN): 192.0.2.3, AS1 712 o Remote Node Descriptors (BGP Router-ID, ASN): 192.0.2.5, AS3 714 o Link Descriptors (local interface identifier, IPv6 peer interface 715 address): 0.0.0.2.0.0.0.0 , 2001:db8:ce2::e 717 Attributes: 719 o Peer-Adj-SID: 1042 721 o LinkAttributes: see section 3.3.2 of [RFC7752] 723 7. Implementation Status 725 Note to RFC Editor: Please remove this section prior to publication, 726 as well as the reference to RFC 7942. 728 This section records the status of known implementations of the 729 protocol defined by this specification at the time of posting of this 730 Internet-Draft, and is based on a proposal described in [RFC7942]. 731 The description of implementations in this section is intended to 732 assist the IETF in its decision processes in progressing drafts to 733 RFCs. Please note that the listing of any individual implementation 734 here does not imply endorsement by the IETF. Furthermore, no effort 735 has been spent to verify the information presented here that was 736 supplied by IETF contributors. This is not intended as, and must not 737 be construed to be, a catalog of available implementations or their 738 features. Readers are advised to note that other implementations may 739 exist. 741 According to [RFC7942], "this will allow reviewers and working groups 742 to assign due consideration to documents that have the benefit of 743 running code, which may serve as evidence of valuable experimentation 744 and feedback that have made the implemented protocols more mature. 745 It is up to the individual working groups to use this information as 746 they see fit". 748 Several early implementations exist and will be reported in detail in 749 a forthcoming version of this document. For purposes of early 750 interoperability testing, when no FCFS code point was available, 751 implementations have made use of the following values: 753 +---------------------------------------+ 754 | Codepoint | Description | 755 +---------------------------------------+ 756 | 7 | Protocol-ID BGP | 757 | 516 | BGP Router-ID | 758 | 517 | BGP Confederation Member | 759 | 1101 | Peer-Node-SID | 760 | 1102 | Peer-Adj-SID | 761 | 1103 | Peer-Set-SID | 762 +------------+--------------------------+ 764 IANA has now confirmed the assignment of the above coidepoints. 765 SeeSection 8. 767 8. IANA Considerations 769 This document defines: 771 A new Protocol-ID: BGP. The codepoint is from the "BGP-LS 772 Protocol-IDs" registry. 774 Two new TLVs: BGP-Router-ID and BGP Confederation Member. The 775 codepoints are in the "BGP-LS Node Descriptor, Link Descriptor, 776 Prefix Descriptor, and Attribute TLVs" registry. 778 Three new BGP-LS Attribute TLVs: Peer-Node-SID, Peer-Adj-SID and 779 Peer-Set-SID. The codepoints are in the "BGP-LS Node Descriptor, 780 Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry. 782 8.1. New BGP-LS Protocol-ID 784 This document defines a new value in the registry "BGP-LS Protocol- 785 IDs": 787 +----------------------------------------------+ 788 | Codepoint | Description | Status | 789 +----------------------------------------------+ 790 | 7 | BGP | Assigned by IANA | 791 +----------------------------------------------+ 793 8.2. Node Descriptors and Link Attribute TLVs 795 This document defines 5 new TLVs in the registry "BGP-LS Node 796 Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs": 798 o Two new node descriptor TLVs 800 o Three new link attribute TLVs 802 All the new 5 codepoints are in the same registry: "BGP-LS Node 803 Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs". 804 However, the registry is organized in ranges (node descriptors, link 805 descriptors, node attributes, link attributes). 807 The following new Node Descriptors TLVs are defined: 809 +-----------------------------------------------------------+ 810 | Codepoint | Description | Status | 811 +-----------------------------------------------------------+ 812 | 516 | BGP Router-ID | Assigned by IANA | 813 | 517 | BGP Confederation Member | Assigned by IANA | 814 +------------+----------------------------------------------+ 816 The following new Link Attribute TLVs are defined: 818 +-----------------------------------------------------------+ 819 | Codepoint | Description | Status | 820 +-----------------------------------------------------------+ 821 | 1101 | Peer-Node-SID | Assigned by IANA | 822 | 1102 | Peer-Adj-SID | Assigned by IANA | 823 | 1103 | Peer-Set-SID | Assigned by IANA | 824 +------------+----------------------------------------------+ 826 9. Manageability Considerations 828 The BGP-LS ([RFC7752]) extensions that are described in this document 829 consist of additional BGP-LS descriptors and TLVs that will follow 830 the same manageability functions of BGP-LS, described in [RFC7752]. 832 The operator MUST be capable of configuring, enabling, disabling the 833 advertisement of each of the Peer-Node-SID, Peer-Adj-SID and Peer- 834 Set-SID as well as to control which information is advertised to 835 which internal or external peer. This is not different from what is 836 required by a BGP speaker in terms of information origination and 837 advertisement. In addition, the advertisement of EPE information 838 MUST conform to standard BGP advertisement and propagation rules 839 (iBGP, eBGP, Route-Reflectors, Confederations). 841 10. Security Considerations 843 [RFC7752] defines BGP-LS NLRIs to which the extensions defined in 844 this document apply. 846 The Security Section of [RFC7752] also applies to: 848 o New Node Descriptors Sub-TLVs: BGP-Router-ID and BGP- 849 Confederation-Member; 851 o New BGP-LS Attributes TLVs: Peer-Node-SID, Peer-Adj-SID and Peer- 852 Set-SID. 854 The extensions defined in this document do not introduce any 855 additional security aspects of BGP-LS. 857 11. Contributors 859 Mach (Guoyi) Chen 860 Huawei Technologies 861 China 863 Email: mach.chen@huawei.com 865 Acee Lindem 866 Cisco Systems Inc. 867 US 869 Email: acee@cisco.com 871 Ketan Talaulikar 872 Cisco Systems Inc. 873 India 875 Email: ketant@cisco.com 877 12. Acknowledgements 879 The authors would like to thank Jakob Heitz, Howard Yang, Hannes 880 Gredler, Peter Psenak, Arjun Sreekantiah and Bruno Decraene for their 881 feedback and comments. 883 13. References 885 13.1. Normative References 887 [I-D.ietf-spring-segment-routing] 888 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 889 Litkowski, S., and R. Shakir, "Segment Routing 890 Architecture", draft-ietf-spring-segment-routing-15 (work 891 in progress), January 2018. 893 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 894 Requirement Levels", BCP 14, RFC 2119, 895 DOI 10.17487/RFC2119, March 1997, 896 . 898 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 899 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 900 DOI 10.17487/RFC4271, January 2006, 901 . 903 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 904 System Confederations for BGP", RFC 5065, 905 DOI 10.17487/RFC5065, August 2007, 906 . 908 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 909 in Support of Generalized Multi-Protocol Label Switching 910 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 911 . 913 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 914 Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, 915 June 2011, . 917 13.2. Informative References 919 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 920 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 921 and M. Chen, "BGP Link-State extensions for Segment 922 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-04 923 (work in progress), January 2018. 925 [I-D.ietf-spring-segment-routing-central-epe] 926 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 927 Afanasiev, "Segment Routing Centralized BGP Egress Peer 928 Engineering", draft-ietf-spring-segment-routing-central- 929 epe-10 (work in progress), December 2017. 931 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 932 S. Ray, "North-Bound Distribution of Link-State and 933 Traffic Engineering (TE) Information Using BGP", RFC 7752, 934 DOI 10.17487/RFC7752, March 2016, 935 . 937 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 938 Code: The Implementation Status Section", BCP 205, 939 RFC 7942, DOI 10.17487/RFC7942, July 2016, 940 . 942 Authors' Addresses 944 Stefano Previdi (editor) 945 Individual 947 Email: stefano@previdi.net 949 Clarence Filsfils 950 Cisco Systems, Inc. 951 Brussels 952 Belgium 954 Email: cfilsfil@cisco.com 956 Keyur Patel 957 Arrcus, Inc. 959 Email: Keyur@arrcus.com 961 Saikat Ray 962 Individual Contributor 964 Email: raysaikat@gmail.com 966 Jie Dong 967 Huawei Technologies 968 Huawei Campus, No. 156 Beiqing Rd. 969 Beijing 100095 970 China 972 Email: jie.dong@huawei.com