idnits 2.17.1 draft-ietf-idr-bgpls-segment-routing-epe-04.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 : ---------------------------------------------------------------------------- == There are 32 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 12, 2016) is 2899 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 (-15) exists of draft-ietf-spring-segment-routing-08 == Outdated reference: A later version (-10) exists of draft-ietf-spring-segment-routing-central-epe-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 Network Working Group S. Previdi, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: November 13, 2016 S. Ray 6 Individual Contributor 7 K. Patel 8 Cisco Systems, Inc. 9 J. Dong 10 M. Chen 11 Huawei Technologies 12 May 12, 2016 14 Segment Routing BGP Egress Peer Engineering BGP-LS Extensions 15 draft-ietf-idr-bgpls-segment-routing-epe-04 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 http://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 November 13, 2016. 58 Copyright Notice 60 Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . . . . . . 3 77 3. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 4 78 4. Link NLRI for BGP-PE Connectivity Description . . . . . . . . 5 79 4.1. BGP Router ID and Member ASN . . . . . . . . . . . . . . 5 80 4.2. BGP-PE Node Descriptors . . . . . . . . . . . . . . . . . 6 81 4.3. Link Attributes . . . . . . . . . . . . . . . . . . . . . 7 82 5. Peer Node and Peer Adjacency Segments . . . . . . . . . . . . 9 83 5.1. Peer Node Segment (Peer-Node-SID) . . . . . . . . . . . . 9 84 5.2. Peer Adjacency Segment (Peer-Adj-SID) . . . . . . . . . . 10 85 5.3. Peer Set Segment . . . . . . . . . . . . . . . . . . . . 11 86 6. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 12 87 6.1. Reference Diagram . . . . . . . . . . . . . . . . . . . . 12 88 6.2. Peer Node Segment for Node D . . . . . . . . . . . . . . 14 89 6.3. Peer Node Segment for Node H . . . . . . . . . . . . . . 14 90 6.4. Peer Node Segment for Node E . . . . . . . . . . . . . . 14 91 6.5. Peer Adjacency Segment for Node E, Link 1 . . . . . . . . 15 92 6.6. Peer Adjacency Segment for Node E, Link 2 . . . . . . . . 15 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 94 8. Manageability Considerations . . . . . . . . . . . . . . . . 16 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 96 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 97 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 98 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 99 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 100 12.2. Informative References . . . . . . . . . . . . . . . . . 17 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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. A segment can represent any 108 instruction, topological or service-based. SR allows to enforce a 109 flow through any topological path and service chain while maintaining 110 per-flow state only at the ingress node of the SR domain. 112 The Segment Routing architecture can be directly applied to the MPLS 113 dataplane with no change on the forwarding plane. It requires minor 114 extension to the existing link-state routing protocols. 116 This document outline a BGP-LS extension for exporting BGP peering 117 node topology information (including its peers, interfaces and 118 peering ASs) in a way that is exploitable in order to compute 119 efficient BGP Egress Peer Engineering (BGP-EPE) policies and 120 strategies. 122 This document defines new types of segments: a Peer Node segment 123 describing the BGP session between two nodes; a Peer Adjacency 124 Segment describing the link (one or more) that is used by the BGP 125 session; the Peer Set Segment describing an arbitrary set of sessions 126 or links between the local BGP node and its peers. 128 While an egress point topology usually refers to eBGP sessions 129 between external peers, there's nothing in the extensions defined in 130 this document that would prevent the use of these extensions in the 131 context of iBGP sessions. 133 2. Segment Routing Documents 135 The main reference for this document is the SR architecture defined 136 in [I-D.ietf-spring-segment-routing]. 138 The Segment Routing BGP Egress Peer Engineering (BGP-EPE) 139 architecture is described in 140 [I-D.ietf-spring-segment-routing-central-epe]. 142 3. BGP Peering Segments 144 As defined in [I-D.ietf-spring-segment-routing-central-epe], an BGP- 145 EPE enabled Egress PE node MAY advertise segments corresponding to 146 its attached peers. These segments are called BGP peering segments 147 or BGP Peering SIDs. In case of eBGP, they enable the expression of 148 source-routed inter-domain paths. 150 An ingress border router of an AS may compose a list of segments to 151 steer a flow along a selected path within the AS, towards a selected 152 egress border router C of the AS and through a specific peer. At 153 minimum, a BGP-EPE policy applied at an ingress PE involves two 154 segments: the Node SID of the chosen egress PE and then the BGP 155 Peering Segment for the chosen egress PE peer or peering interface. 157 This document defines the BGP-EPE Peering Segments: 159 o Peer Node Segment (Peer-Node-SID) 161 o Peer Adjacency Segment (Peer-Adj-SID) 163 o Peer Set Segment (Peer-Set-SID) 165 Each BGP session MUST be described by a Peer Node Segment. The 166 description of the BGP session MAY be augmented by additional 167 Adjacency Segments. Finally, each Peer Node Segment and Peer 168 Adjacency Segment MAY be part of the same group/set so to be able to 169 group EPE resources under a common Peer-Set Segment Identifier (SID). 171 Therefore, when the extensions defined in this document are applied 172 to the use case defined in 173 [I-D.ietf-spring-segment-routing-central-epe]: 175 o One Peer Node Segment MUST be present. 177 o One or more Peer Adjacency Segments MAY be present. 179 o Each of the Peer Node and Peer Adjacency Segment MAY use the same 180 Peer-Set. 182 While an egress point topology usually refers to eBGP sessions 183 between external peers, there's nothing in the extensions defined in 184 this document that would prevent the use of these extensions in the 185 context of iBGP sessions. 187 4. Link NLRI for BGP-PE Connectivity Description 189 This section describes the NLRI used for describing the connectivity 190 of the BGP Egress router. The connectivity is based on links and 191 remote peers/ASs and therefore the existing Link-Type NLRI (defined 192 in [RFC7752]) is used. A new Protocol ID is used (codepoint to be 193 assigned by IANA, suggested value 7). 195 The use of a new Protocol-ID allows separation and differentiation 196 between the NLRIs carrying BGP-EPE descriptors from the NLRIs 197 carrying IGP link-state information as defined in [RFC7752]. The 198 Link NLRI Type uses descriptors and attributes already defined in 199 [RFC7752] in addition to new TLVs defined in the following sections 200 of this document. 202 The extensions defined in this document apply to both internal and 203 external BGP-LS EPE advertisements. 205 [RFC7752] defines Link NLRI Type is as follows: 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+ 210 | Protocol-ID | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Identifier | 213 | (64 bits) | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 // Local Node Descriptors // 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 // Remote Node Descriptors // 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 // Link Descriptors // 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Node Descriptors and Link Descriptors are defined in [RFC7752]. 224 4.1. BGP Router ID and Member ASN 226 Two new Node Descriptors Sub-TLVs are defined in this document: 228 o BGP Router Identifier (BGP Router-ID): 230 Type: TBA (suggested value 516). 232 Length: 4 octets 233 Value: 4 octet unsigned integer representing the BGP Identifier 234 as defined in [RFC4271] and [RFC6286]. 236 o Confederation Member ASN (Member-ASN) 238 Type: TBA (suggested value 517). 240 Length: 4 octets 242 Value: 4 octet unsigned integer representing the Member ASN 243 inside the Confederation.[RFC5065]. 245 4.2. BGP-PE Node Descriptors 247 The following Node Descriptors Sub-TLVs MUST appear in the Link NLRI 248 as Local Node Descriptors: 250 o BGP Router ID, which contains the BGP Identifier of the local BGP- 251 EPE capable node. 253 o Autonomous System Number, which contains the local ASN or local 254 confederation identifier (ASN) if confederations are used. 256 o BGP-LS Identifier. 258 It has to be noted that [RFC6286] (section 2.1) requires the BGP 259 identifier (router-id) to be unique within an Autonomous System. 260 Therefore, the tuple is globally unique. 262 The following Node Descriptors Sub-TLVs MAY appear in the Link NLRI 263 as Local Node Descriptors: 265 o Member-ASN, which contains the ASN of the confederation member 266 (when BGP confederations are used). 268 o Node Descriptors as defined in [RFC7752]. 270 The following Node Descriptors Sub-TLVs MUST appear in the Link NLRI 271 as Remote Node Descriptors: 273 o BGP Router ID, which contains the BGP Identifier of the peer node. 275 o Autonomous System Number, which contains the peer ASN or the peer 276 confederation identifier (ASN), if confederations are used. 278 The following Node Descriptors Sub-TLVs MAY appear in the Link NLRI 279 as Remote Node Descriptors: 281 o Member-ASN, which contains the ASN of the confederation member 282 (when BGP confederations are used). 284 o Node Descriptors as defined in defined in [RFC7752]. 286 4.3. Link Attributes 288 The following BGP-LS Link attributes TLVs are used with the Link 289 NLRI: 291 +----------+---------------------------+----------+ 292 | TLV Code | Description | Length | 293 | Point | | | 294 +----------+---------------------------+----------+ 295 | 1101 | Peer Node Segment | variable | 296 | | Identifier (Peer-Node-SID)| | 297 | 1102 | Peer Adjacency Segment | variable | 298 | | Identifier (Peer-Adj-SID) | | 299 | 1103 | Peer Set Segment | variable | 300 | | Identifier (Peer-Set-SID) | | 301 +----------+---------------------------+----------+ 303 Figure 1: BGP-LS TLV code points for BGP-PE 305 Peer-Node-SID, Peer-Adj-SID and Peer-Set-SID have all the same format 306 defined here below: 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Type | Length | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Flags | Weight | Reserved | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | SID/Label/Index (variable) | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 where: 320 Figure 2 322 o Type: To be assigned by IANA. The suggested values are defined in 323 Figure 1. 325 o Length: variable. 327 o Flags: following flags have been defined: 329 0 1 2 3 4 5 6 7 330 +-+-+-+-+-+-+-+-+ 331 |V|L| | 332 +-+-+-+-+-+-+-+-+ 334 where: 336 * V-Flag: Value flag. If set, then the Adj-SID carries a value. 337 By default the flag is SET. 339 * L-Flag: Local Flag. If set, then the value/index carried by 340 the Adj-SID has local significance. By default the flag is 341 SET. 343 * Other bits: MUST be zero when originated and ignored when 344 received. 346 o Weight: 1 octet. The value represents the weight of the SID for 347 the purpose of load balancing. An example use of the weight is 348 described in [I-D.ietf-spring-segment-routing]. 350 o SID/Index/Label. According to the TLV length and to the V and L 351 flags settings, it contains either: 353 * A 3 octet local label where the 20 rightmost bits are used for 354 encoding the label value. In this case the V and L flags MUST 355 be set. 357 * A 4 octet index defining the offset in the SID/Label space 358 advertised by this router using the encodings defined in 359 Section 3.1. In this case V and L flags MUST be unset. 361 * A 16 octet IPv6 address. In this case the V flag MUST be set. 362 The L flag MUST be unset if the IPv6 address is globally 363 unique. 365 The values of the Peer-Node-SID, Peer-Adj-SID and Peer-Set-SID Sub- 366 TLVs SHOULD be persistent across router restart. 368 The Peer-Node-SID MUST be present when BGP-LS is used for the use 369 case described in [I-D.ietf-spring-segment-routing-central-epe] and 370 MAY be omitted for other use cases. 372 The Peer-Adj-SID and Peer-Set-SID SubTLVs MAY be present when BGP-LS 373 is used for the use case described in 374 [I-D.ietf-spring-segment-routing-central-epe] and MAY be omitted for 375 other use cases. 377 In addition, BGP-LS Nodes and Link Attributes, as defined in 378 [RFC7752] MAY be inserted in order to advertise the characteristics 379 of the link. 381 5. Peer Node and Peer Adjacency Segments 383 In this section the following Peer Segments are defined: 385 Peer Node Segment (Peer-Node-SID) 387 Peer Adjacency Segment (Peer-Adj-SID) 389 Peer Set Segment (Peer-Set-SID) 391 The Peer Node, Peer Adjacency and Peer Set segments can be either a 392 local or a global segment (depending on the setting of the V and L 393 flags defined in Figure 2. For example, when BGP-EPE is used in the 394 context of a SR network over the IPv6 dataplane, it is likely the 395 case that the IPv6 addresses used as SIDs will be global. 397 5.1. Peer Node Segment (Peer-Node-SID) 399 The Peer Node Segment describes the BGP session peer (neighbor). It 400 MUST be present when describing a BGP-EPE topology as defined in 401 [I-D.ietf-spring-segment-routing-central-epe]. The Peer Node Segment 402 is encoded within the BGP-LS Link NLRI specified in Section 4. 404 The Peer Node Segment, at the BGP node advertising it, has the 405 following semantic: 407 o SR header operation: NEXT (as defined in 408 [I-D.ietf-spring-segment-routing]). 410 o Next-Hop: the connected peering node to which the segment is 411 related. 413 The Peer Node Segment is advertised with a Link NLRI, where: 415 o Local Node Descriptors contains 417 Local BGP Router ID of the BGP-EPE enabled egress PE. 418 Local ASN. 419 BGP-LS Identifier. 421 o Remote Node Descriptors contains 423 Peer BGP Router ID (i.e.: the peer BGP ID used in the BGP session). 424 Peer ASN. 426 o Link Descriptors Sub-TLVs, as defined in [RFC7752], contain the 427 addresses used by the BGP session: 429 * IPv4 Interface Address (Sub-TLV 259) contains the BGP session 430 IPv4 local address. 432 * IPv4 Neighbor Address (Sub-TLV 260) contains the BGP session 433 IPv4 peer address. 435 * IPv6 Interface Address (Sub-TLV 261) contains the BGP session 436 IPv6 local address. 438 * IPv6 Neighbor Address (Sub-TLV 262) contains the BGP session 439 IPv6 peer address. 441 o Link Attribute contains the Peer-Node-SID TLV as defined in 442 Section 4.3. 444 o In addition, BGP-LS Link Attributes, as defined in [RFC7752], MAY 445 be inserted in order to advertise the characteristics of the link. 447 5.2. Peer Adjacency Segment (Peer-Adj-SID) 449 The Peer Adjacency Segment, at the BGP node advertising it, has the 450 following semantic: 452 o SR header operation: NEXT (as defined in 453 [I-D.ietf-spring-segment-routing]). 455 o Next-Hop: the interface peer address. 457 The Peer Adjacency Segment is advertised with a Link NLRI, where: 459 o Local Node Descriptors contains 461 Local BGP Router ID of the BGP-EPE enabled egress PE. 462 Local ASN. 463 BGP-LS Identifier. 465 o Remote Node Descriptors contains 467 Peer BGP Router ID (i.e.: the peer BGP ID used in the BGP session). 468 Peer ASN. 470 o Link Descriptors Sub-TLVs, as defined in [RFC7752], MUST contain 471 the following TLVs: 473 * Link Local/Remote Identifiers (Sub-TLV 258) contains the 474 4-octet Link Local Identifier followed by the 4-octet value 0 475 indicating the Link Remote Identifier in unknown [RFC5307]. 477 o In addition, Link Descriptors Sub-TLVs, as defined in [RFC7752], 478 MAY contain the following TLVs: 480 * IPv4 Interface Address (Sub-TLV 259) contains the address of 481 the local interface through which the BGP session is 482 established. 484 * IPv6 Interface Address (Sub-TLV 261) contains the address of 485 the local interface through which the BGP session is 486 established. 488 * IPv4 Neighbor Address (Sub-TLV 260) contains the IPv4 address 489 of the peer interface used by the BGP session. 491 * IPv6 Neighbor Address (Sub-TLV 262) contains the IPv6 address 492 of the peer interface used by the BGP session. 494 o Link attribute used with the Peer-Adj-SID contains the TLV as 495 defined in Section 4.3. 497 In addition, BGP-LS Link Attributes, as defined in [RFC7752], MAY be 498 inserted in order to advertise the characteristics of the link. 500 5.3. Peer Set Segment 502 The Peer Adjacency Segment, at the BGP node advertising it, has the 503 following semantic: 505 o SR header operation: NEXT (as defined in 506 [I-D.ietf-spring-segment-routing]). 508 o Next-Hop: load balance across any connected interface to any peer 509 in the related set. 511 The Peer Set Segment is advertised within a Link NLRI (describing a 512 Peer Node Segment or a Peer Adjacency segment) as a BGP-LS attribute. 514 The Peer Set Attribute contains the Peer-Set-SID TLV, defined in 515 Section 4.3 identifying the set of which the Peer Node Segment or 516 Peer Adjacency Segment is a member. 518 6. Illustration 520 6.1. Reference Diagram 522 The following reference diagram is used throughout this document. 523 The solution is illustrated for IPv4 with MPLS-based segments and the 524 BGP-EPE topology is based on eBGP sessions between external peers. 526 As stated in Section 3, the solution illustrated hereafter is equally 527 applicable to an iBGP session topology. In other words, the solution 528 also applies to the case where C, D, H, and E are in the same AS and 529 run iBGP sessions between each other. 531 +------+ 532 | | 533 +---D F 534 +---------+ / | AS 2 |\ +------+ 535 | X |/ +------+ \ | Z |---L/8 536 A C---+ \| | 537 | |\\ \ +------+ /| AS 4 |---M/8 538 | AS1 | \\ +-H |/ +------+ 539 | | \\ | G 540 +----P----+ +===E AS 3 | 541 | +--Q---+ 542 | | 543 +----------------+ 545 Figure 3: Reference Diagram 547 IPv4 addressing: 549 o C's IPv4 address of interface to D: 1.0.1.1/24, D's interface: 550 1.0.1.2/24 552 o C's IPv4 address of interface to H: 1.0.2.1/24, H's interface: 553 1.0.2.2/24 555 o C's IPv4 address of upper interface to E: 1.0.3.1, E's interface: 556 1.0.3.2/24 558 o C's local identifier of upper interface to E: 0.0.0.1.0.0.0.0 560 o C's IPv4 address of lower interface to E: 1.0.4.1/24, E's 561 interface: 1.0.4.2/24 563 o C's local identifier of lower interface to E: 0.0.0.2.0.0.0.0 565 o Loopback of E used for eBGP multi-hop peering to C: 1.0.5.2/32 566 o C's loopback is 3.3.3.3/32 with SID 64 568 BGP Router-IDs are C, D, H and E. 570 o C's BGP Router-ID: 3.3.3.3 572 o D's BGP Router-ID: 4.4.4.4 574 o E's BGP Router-ID: 5.5.5.5 576 o H's BGP Router-ID: 6.6.6.6 578 C's BGP peering: 580 o Single-hop eBGP peering with neighbor 1.0.1.2 (D) 582 o Single-hop eBGP peering with neighbor 1.0.2.2 (H) 584 o Multi-hop eBGP peering with E on ip address 1.0.5.2 (E) 586 C's resolution of the multi-hop eBGP session to E: 588 o Static route 1.0.5.2/32 via 1.0.3.2 590 o Static route 1.0.5.2/32 via 1.0.4.2 592 Node C configuration is such that: 594 o A Peer Node segment (Peer-Node-SID) is allocated to each peer (D, 595 H and E). 597 o An Peer Adjacency segment (Peer-Adj-SID) is defined for each 598 recursing interface to a multi-hop peer (CE upper and lower 599 interfaces). 601 o A Peer Set segment (Peer-Set-SID) is defined to include all peers 602 in AS3 (peers H and E). 604 Local BGP-LS Identifier in router C is set to 10000. 606 The Link NLRI Type is used in order to encode C's connectivity. The 607 Link NLRI uses the new Protocol-ID value (to be assigned by IANA) 609 Once the BGP-LS update is originated by C, it may be advertised to 610 internal (iBGP) as well as external (eBGP) neighbors supporting the 611 BGP-LS EPE extensions defined in this document. 613 6.2. Peer Node Segment for Node D 615 Descriptors: 617 o Local Node Descriptors (BGP Router-ID, local ASN, BGP-LS 618 Identifier): 3.3.3.3 , AS1, 10000 620 o Remote Node Descriptors (BGP Router-ID, peer ASN): 4.4.4.4, AS2 622 o Link Descriptors (BGP session IPv4 local address, BGP session IPv4 623 neighbor address): 1.0.1.1, 1.0.1.2 625 Attributes: 627 o Peer-Node-SID: 1012 629 o Link Attributes: see section 3.3.2 of [RFC7752] 631 6.3. Peer Node Segment for Node H 633 Descriptors: 635 o Local Node Descriptors (BGP Router-ID, ASN, BGPLS Identifier): 636 3.3.3.3 , AS1, 10000 638 o Remote Node Descriptors (BGP Router-ID ASN): 6.6.6.6, AS3 640 o Link Descriptors (BGP session IPv4 local address, BGP session IPv4 641 peer address): 1.0.2.1, 1.0.2.2 643 Attributes: 645 o Peer-Node-SID: 1022 647 o Peer-Set-SID: 1060 649 o Link Attributes: see section 3.3.2 of [RFC7752] 651 6.4. Peer Node Segment for Node E 653 Descriptors: 655 o Local Node Descriptors (BGP Router-ID, ASN, BGP-LS Identifier): 656 3.3.3.3 , AS1, 10000 658 o Remote Node Descriptors (BGP Router-ID, ASN): 5.5.5.5, AS3 659 o Link Descriptors (BGP session IPv4 local address, BGP session IPv4 660 peer address): 3.3.3.3, 1.0.5.2 662 Attributes: 664 o Peer-Node-SID: 1052 666 o Peer-Set-SID: 1060 668 6.5. Peer Adjacency Segment for Node E, Link 1 670 Descriptors: 672 o Local Node Descriptors (BGP Router-ID, ASN, BGP-LS Identifier): 673 3.3.3.3 , AS1, 10000 675 o Remote Node Descriptors (BGP Router-ID, ASN): 5.5.5.5, AS3 677 o Link Descriptors (local interface identifier, IPv4 peer interface 678 address): 0.0.0.1.0.0.0.0 , 1.0.3.2 680 Attributes: 682 o Peer-Adj-SID: 1032 684 o LinkAttributes: see section 3.3.2 of [RFC7752] 686 6.6. Peer Adjacency Segment for Node E, Link 2 688 Descriptors: 690 o Local Node Descriptors (BGP Router-ID, ASN, BGP-LS Identifier): 691 3.3.3.3 , AS1, 10000 693 o Remote Node Descriptors (BGP Router-ID, ASN): 5.5.5.5, AS3 695 o Link Descriptors (local interface identifier, IPv4 peer interface 696 address): 0.0.0.2.0.0.0.0 , 1.0.4.2 698 Attributes: 700 o Peer-Adj-SID: 1042 702 o LinkAttributes: see section 3.3.2 of [RFC7752] 704 7. IANA Considerations 706 This document defines: 708 Two new Node Descriptors Sub-TLVs: BGP-Router-ID and BGP 709 Confederation Member. 711 A new Protocol-ID: BGP-EPE. 713 Three new BGP-LS Attribute Sub-TLVs: Peer-Node-SID, Peer-Adj-SID 714 and Peer-Set-SID. 716 The codepoints are to be assigned by IANA. The following are the 717 suggested values: 719 +---------------------+--------------------------+-------------+ 720 | Suggested Codepoint | Description | Defined in: | 721 +---------------------+--------------------------+-------------+ 722 | 7 | Protocol-ID | Section 4 | 723 | 516 | BGP Router ID | Section 4.1 | 724 | 517 | BGP Confederation Member | Section 4.1 | 725 | 1101 | Peer-Node-SID | Section 4.3 | 726 | 1102 | Peer-Adj-SID | Section 4.3 | 727 | 1103 | Peer-Set-SID | Section 4.3 | 728 +---------------------+--------------------------+-------------+ 730 Table 1: Summary Table of BGP-LS Codepoints for BGP-PE 732 8. Manageability Considerations 734 TBD 736 9. Security Considerations 738 [RFC7752] defines BGP-LS NLRIs to which the extensions defined in 739 this document apply. 741 The Security Section of [RFC7752] also applies to: 743 o New Node Descriptors Sub-TLVs: BGP-Router-ID and BGP- 744 Confederation-Member; 746 o New BGP-LS Attributes TLVs: Peer-Node-SID, Peer-Adj-SID and Peer- 747 Set-SID. 749 10. Contributors 751 Acee Lindem gave a substantial contribution to this document. 753 11. Acknowledgements 755 The authors would like to thank Jakob Heitz, Howard Yang, Hannes 756 Gredler, Peter Psenak, Ketan Jivan Talaulikar, and Arjun Sreekantiah 757 for their feedback and comments. 759 12. References 761 12.1. Normative References 763 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 764 Requirement Levels", BCP 14, RFC 2119, 765 DOI 10.17487/RFC2119, March 1997, 766 . 768 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 769 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 770 DOI 10.17487/RFC4271, January 2006, 771 . 773 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 774 System Confederations for BGP", RFC 5065, 775 DOI 10.17487/RFC5065, August 2007, 776 . 778 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 779 in Support of Generalized Multi-Protocol Label Switching 780 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 781 . 783 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 784 Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, 785 June 2011, . 787 12.2. Informative References 789 [I-D.ietf-spring-segment-routing] 790 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 791 and R. Shakir, "Segment Routing Architecture", draft-ietf- 792 spring-segment-routing-08 (work in progress), May 2016. 794 [I-D.ietf-spring-segment-routing-central-epe] 795 Filsfils, C., Previdi, S., Ginsburg, D., and D. Afanasiev, 796 "Segment Routing Centralized BGP Peer Engineering", draft- 797 ietf-spring-segment-routing-central-epe-01 (work in 798 progress), March 2016. 800 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 801 S. Ray, "North-Bound Distribution of Link-State and 802 Traffic Engineering (TE) Information Using BGP", RFC 7752, 803 DOI 10.17487/RFC7752, March 2016, 804 . 806 Authors' Addresses 808 Stefano Previdi (editor) 809 Cisco Systems, Inc. 810 Via Del Serafico, 200 811 Rome 00142 812 Italy 814 Email: sprevidi@cisco.com 816 Clarence Filsfils 817 Cisco Systems, Inc. 818 Brussels 819 BE 821 Email: cfilsfil@cisco.com 823 Saikat Ray 824 Individual Contributor 826 Email: raysaikat@gmail.com 828 Keyur Patel 829 Cisco Systems, Inc. 830 170, West Tasman Drive 831 San Jose, CA 95134 832 US 834 Email: keyupate@cisco.com 835 Jie Dong 836 Huawei Technologies 837 Huawei Campus, No. 156 Beiqing Rd. 838 Beijing 100095 839 China 841 Email: jie.dong@huawei.com 843 Mach (Guoyi) Chen 844 Huawei Technologies 845 Huawei Campus, No. 156 Beiqing Rd. 846 Beijing 100095 847 China 849 Email: mach.chen@huawei.com