idnits 2.17.1 draft-ietf-idr-bgpls-segment-routing-epe-02.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 (December 21, 2015) is 3047 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-07 == Outdated reference: A later version (-10) exists of draft-ietf-spring-segment-routing-central-epe-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: June 23, 2016 S. Ray 6 Individual Contributor 7 K. Patel 8 Cisco Systems, Inc. 9 J. Dong 10 M. Chen 11 Huawei Technologies 12 December 21, 2015 14 Segment Routing Egress Peer Engineering BGP-LS Extensions 15 draft-ietf-idr-bgpls-segment-routing-epe-02 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 egress 31 point topology information (including its peers, interfaces and 32 peering ASs) in a way that is exploitable in order to compute 33 efficient Egress Point 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 June 23, 2016. 58 Copyright Notice 60 Copyright (c) 2015 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 EPE Connectivity Description . . . . . . . . . 5 79 4.1. BGP Router ID and Member ASN . . . . . . . . . . . . . . 5 80 4.2. EPE 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 egress 117 point topology information (including its peers, interfaces and 118 peering ASs) in a way that is exploitable in order to compute 119 efficient Egress Point Engineering policies and strategies. 121 This document defines new types of segments: a Peer Node segment 122 describing the BGP session between two nodes; a Peer Adjacency 123 Segment describing the link (one or more) that is used by the BGP 124 session; the Peer Set Segment describing an arbitrary set of sessions 125 or links between the local BGP node and its peers. 127 While an egress point topology usually refers to eBGP sessions 128 between external peers, there's nothing in the extensions defined in 129 this document that would prevent the use of these extensions in the 130 context of iBGP sessions. 132 2. Segment Routing Documents 134 The main reference for this document is the SR architecture defined 135 in [I-D.ietf-spring-segment-routing]. 137 The Segment Routing Egress Peer Engineering architecture is described 138 in [I-D.ietf-spring-segment-routing-central-epe]. 140 3. BGP Peering Segments 142 As defined in [I-D.ietf-spring-segment-routing-central-epe], an EPE 143 enabled Egress PE node MAY advertise segments corresponding to its 144 attached peers. These segments are called BGP peering segments or 145 BGP Peering SIDs. They enable the expression of source-routed inter- 146 domain paths. 148 An ingress border router of an AS may compose a list of segments to 149 steer a flow along a selected path within the AS, towards a selected 150 egress border router C of the AS and through a specific peer. At 151 minimum, a BGP Peering Engineering policy applied at an ingress PE 152 involves two segments: the Node SID of the chosen egress PE and then 153 the BGP Peering Segment for the chosen egress PE peer or peering 154 interface. 156 This document defines the BGP EPE Peering Segments: 158 o Peer Node Segment (Peer-Node-SID) 160 o Peer Adjacency Segment (Peer-Adj-SID) 162 o Peer Set Segment (Peer-Set-SID) 164 Each BGP session MUST be described by a Peer Node Segment. The 165 description of the BGP session MAY be augmented by additional 166 Adjacency Segments. Finally, each Peer Node Segment and Peer 167 Adjacency Segment MAY be part of the same group/set so to be able to 168 group EPE resources under a common Peer-Set Segment Identifier (SID). 170 Therefore, when the extensions defined in this document are applied 171 to the use case defined in 172 [I-D.ietf-spring-segment-routing-central-epe]: 174 o One Peer Node Segment MUST be present. 176 o One or more Peer Adjacency Segments MAY be present. 178 o Each of the Peer Node and Peer Adjacency Segment MAY use the same 179 Peer-Set. 181 While an egress point topology usually refers to eBGP sessions 182 between external peers, there's nothing in the extensions defined in 183 this document that would prevent the use of these extensions in the 184 context of iBGP sessions. 186 4. Link NLRI for EPE Connectivity Description 188 This section describes the NLRI used for describing the connectivity 189 of the BGP Egress router. The connectivity is based on links and 190 remote peers/ASs and therefore the existing Link-Type NLRI (defined 191 in [I-D.ietf-idr-ls-distribution]) is used. A new Protocol ID is 192 used (codepoint to be assigned by IANA, suggested value 7). 194 The use of a new Protocol-ID allows separation and differentiation 195 between the NLRIs carrying BGP-EPE descriptors from the NLRIs 196 carrying IGP link-state information as defined in 197 [I-D.ietf-idr-ls-distribution]. The Link NLRI Type uses descriptors 198 and attributes already defined in [I-D.ietf-idr-ls-distribution] in 199 addition to new TLVs defined in the following sections of this 200 document. 202 The extensions defined in this document apply to both internal and 203 external BGP-LS EPE advertisements. 205 [I-D.ietf-idr-ls-distribution] 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 223 [I-D.ietf-idr-ls-distribution]. 225 4.1. BGP Router ID and Member ASN 227 Two new Node Descriptors Sub-TLVs are defined in this document: 229 o BGP Router Identifier (BGP Router-ID): 231 Type: TBA (suggested value 516). 233 Length: 4 octets 234 Value: 4 octet unsigned integer representing the BGP Identifier 235 as defined in [RFC4271] and [RFC6286]. 237 o Confederation Member ASN (Member-ASN) 239 Type: TBA (suggested value 517). 241 Length: 4 octets 243 Value: 4 octet unsigned integer representing the Member ASN 244 inside the Confederation.[RFC5065]. 246 4.2. EPE Node Descriptors 248 The following Node Descriptors Sub-TLVs MUST appear in the Link NLRI 249 as Local Node Descriptors: 251 o BGP Router ID, which contains the BGP Identifier of the local BGP 252 EPE node. 254 o Autonomous System Number, which contains the local ASN or local 255 confederation identifier (ASN) if confederations are used. 257 o BGP-LS Identifier. 259 It has to be noted that [RFC6286] (section 2.1) requires the BGP 260 identifier (router-id) to be unique within an Autonomous System. 261 Therefore, the tuple is globally unique. 263 The following Node Descriptors Sub-TLVs MAY appear in the Link NLRI 264 as Local Node Descriptors: 266 o Member-ASN, which contains the ASN of the confederation member 267 (when BGP confederations are used). 269 o Node Descriptors as defined in [I-D.ietf-idr-ls-distribution]. 271 The following Node Descriptors Sub-TLVs MUST appear in the Link NLRI 272 as Remote Node Descriptors: 274 o BGP Router ID, which contains the BGP Identifier of the peer node. 276 o Autonomous System Number, which contains the peer ASN or the peer 277 confederation identifier (ASN), if confederations are used. 279 The following Node Descriptors Sub-TLVs MAY appear in the Link NLRI 280 as Remote Node Descriptors: 282 o Member-ASN, which contains the ASN of the confederation member 283 (when BGP confederations are used). 285 o Node Descriptors as defined in defined in 286 [I-D.ietf-idr-ls-distribution]. 288 4.3. Link Attributes 290 The following BGP-LS Link attributes TLVs are used with the Link 291 NLRI: 293 +----------+---------------------------+----------+ 294 | TLV Code | Description | Length | 295 | Point | | | 296 +----------+---------------------------+----------+ 297 | 1101 | Peer Node Segment | variable | 298 | | Identifier (Peer-Node-SID)| | 299 | 1102 | Peer Adjacency Segment | variable | 300 | | Identifier (Peer-Adj-SID) | | 301 | 1103 | Peer Set Segment | variable | 302 | | Identifier (Peer-Set-SID) | | 303 +----------+---------------------------+----------+ 305 Figure 1: TLV code points for BGP-LS EPE 307 Peer-Node-SID, Peer-Adj-SID and Peer-Set-SID have all the same format 308 defined here below: 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Type | Length | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Flags | Weight | Reserved | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | SID/Label/Index (variable) | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 where: 322 Figure 2 324 o Type: To be assigned by IANA. The suggested values are defined in 325 Figure 1. 327 o Length: variable. 329 o Flags: following flags have been defined: 331 0 1 2 3 4 5 6 7 332 +-+-+-+-+-+-+-+-+ 333 |V|L| | 334 +-+-+-+-+-+-+-+-+ 336 where: 338 * V-Flag: Value flag. If set, then the Adj-SID carries a value. 339 By default the flag is SET. 341 * L-Flag: Local Flag. If set, then the value/index carried by 342 the Adj-SID has local significance. By default the flag is 343 SET. 345 * Other bits: MUST be zero when originated and ignored when 346 received. 348 o Weight: 1 octet. The value represents the weight of the SID for 349 the purpose of load balancing. An example use of the weight is 350 described in [I-D.ietf-spring-segment-routing]. 352 o SID/Index/Label. According to the TLV length and to the V and L 353 flags settings, it contains either: 355 * A 3 octet local label where the 20 rightmost bits are used for 356 encoding the label value. In this case the V and L flags MUST 357 be set. 359 * A 4 octet index defining the offset in the SID/Label space 360 advertised by this router using the encodings defined in 361 Section 3.1. In this case V and L flags MUST be unset. 363 * A 16 octet IPv6 address. In this case the V flag MUST be set. 364 The L flag MUST be unset if the IPv6 address is globally 365 unique. 367 The values of the Peer-Node-SID, Peer-Adj-SID and Peer-Set-SID Sub- 368 TLVs SHOULD be persistent across router restart. 370 The Peer-Node-SID MUST be present when BGP-LS is used for the use 371 case described in [I-D.ietf-spring-segment-routing-central-epe] and 372 MAY be omitted for other use cases. 374 The Peer-Adj-SID and Peer-Set-SID SubTLVs MAY be present when BGP-LS 375 is used for the use case described in 376 [I-D.ietf-spring-segment-routing-central-epe] and MAY be omitted for 377 other use cases. 379 In addition, BGP-LS Nodes and Link Attributes, as defined in 380 [I-D.ietf-idr-ls-distribution]MAY be inserted in order to advertise 381 the characteristics of the link. 383 5. Peer Node and Peer Adjacency Segments 385 In this section the following Peer Segments are defined: 387 Peer Node Segment (Peer-Node-SID) 389 Peer Adjacency Segment (Peer-Adj-SID) 391 Peer Set Segment (Peer-Set-SID) 393 The Peer Node, Peer Adjacency and Peer Set segments can be either a 394 local or a global segment (depending on the setting of the V and L 395 flags defined in Figure 2. For example, when EPE is used in the 396 context of a SR network over the IPv6 dataplane, it is likely the 397 case that the IPv6 addresses used as SIDs will be global. 399 5.1. Peer Node Segment (Peer-Node-SID) 401 The Peer Node Segment describes the BGP session peer (neighbor). It 402 MUST be present when describing an EPE topology as defined in 403 [I-D.ietf-spring-segment-routing-central-epe]. The Peer Node Segment 404 is encoded within the BGP-LS Link NLRI specified in Section 4. 406 The Peer Node Segment, at the BGP node advertising it, has the 407 following semantic: 409 o SR header operation: NEXT (as defined in 410 [I-D.ietf-spring-segment-routing]). 412 o Next-Hop: the connected peering node to which the segment is 413 related. 415 The Peer Node Segment is advertised with a Link NLRI, where: 417 o Local Node Descriptors contains 419 Local BGP Router ID of the EPE enabled egress PE. 420 Local ASN. 421 BGP-LS Identifier. 423 o Remote Node Descriptors contains 425 Peer BGP Router ID (i.e.: the peer BGP ID used in the BGP session). 426 Peer ASN. 428 o Link Descriptors Sub-TLVs, as defined in 429 [I-D.ietf-idr-ls-distribution], contain the addresses used by the 430 BGP session: 432 * IPv4 Interface Address (Sub-TLV 259) contains the BGP session 433 IPv4 local address. 435 * IPv4 Neighbor Address (Sub-TLV 260) contains the BGP session 436 IPv4 peer address. 438 * IPv6 Interface Address (Sub-TLV 261) contains the BGP session 439 IPv6 local address. 441 * IPv6 Neighbor Address (Sub-TLV 262) contains the BGP session 442 IPv6 peer address. 444 o Link Attribute contains the Peer-Node-SID TLV as defined in 445 Section 4.3. 447 o In addition, BGP-LS Link Attributes, as defined in 448 [I-D.ietf-idr-ls-distribution], MAY be inserted in order to 449 advertise the characteristics of the link. 451 5.2. Peer Adjacency Segment (Peer-Adj-SID) 453 The Peer Adjacency Segment, at the BGP node advertising it, has the 454 following semantic: 456 o SR header operation: NEXT (as defined in 457 [I-D.ietf-spring-segment-routing]). 459 o Next-Hop: the interface peer address. 461 The Peer Adjacency Segment is advertised with a Link NLRI, where: 463 o Local Node Descriptors contains 465 Local BGP Router ID of the EPE enabled egress PE. 466 Local ASN. 467 BGP-LS Identifier. 469 o Remote Node Descriptors contains 471 Peer BGP Router ID (i.e.: the peer BGP ID used in the BGP session). 472 Peer ASN. 474 o Link Descriptors Sub-TLVs, as defined in 475 [I-D.ietf-idr-ls-distribution], MUST contain the following TLVs: 477 * Link Local/Remote Identifiers (Sub-TLV 258) contains the 478 4-octet Link Local Identifier followed by the 4-octet value 0 479 indicating the Link Remote Identifier in unknown [RFC5307]. 481 o In addition, Link Descriptors Sub-TLVs, as defined in 482 [I-D.ietf-idr-ls-distribution], MAY contain the following TLVs: 484 * IPv4 Interface Address (Sub-TLV 259) contains the address of 485 the local interface through which the BGP session is 486 established. 488 * IPv6 Interface Address (Sub-TLV 261) contains the address of 489 the local interface through which the BGP session is 490 established. 492 * IPv4 Neighbor Address (Sub-TLV 260) contains the IPv4 address 493 of the peer interface used by the BGP session. 495 * IPv6 Neighbor Address (Sub-TLV 262) contains the IPv6 address 496 of the peer interface used by the BGP session. 498 o Link attribute used with the Peer-Adj-SID contains the TLV as 499 defined in Section 4.3. 501 In addition, BGP-LS Link Attributes, as defined in 502 [I-D.ietf-idr-ls-distribution], MAY be inserted in order to advertise 503 the characteristics of the link. 505 5.3. Peer Set Segment 507 The Peer Adjacency Segment, at the BGP node advertising it, has the 508 following semantic: 510 o SR header operation: NEXT (as defined in 511 [I-D.ietf-spring-segment-routing]). 513 o Next-Hop: load balance across any connected interface to any peer 514 in the related set. 516 The Peer Set Segment is advertised within a Link NLRI (describing a 517 Peer Node Segment or a Peer Adjacency segment) as a BGP-LS attribute. 519 The Peer Set Attribute contains the Peer-Set-SID TLV, defined in 520 Section 4.3 identifying the set of which the Peer Node Segment or 521 Peer Adjacency Segment is a member. 523 6. Illustration 525 6.1. Reference Diagram 527 The following reference diagram is used throughout this document. 528 The solution is illustrated for IPv4 with MPLS-based segments and the 529 EPE topology is based on eBGP sessions between external peers. 531 As stated in Section 3, the solution illustrated hereafter is equally 532 applicable to an iBGP session topology. In other words, the solution 533 also applies to the case where C, D, H, and E are in the same AS and 534 run iBGP sessions between each other. 536 +------+ 537 | | 538 +---D F 539 +---------+ / | AS 2 |\ +------+ 540 | X |/ +------+ \ | Z |---L/8 541 A C---+ \| | 542 | |\\ \ +------+ /| AS 4 |---M/8 543 | AS1 | \\ +-H |/ +------+ 544 | | \\ | G 545 +----P----+ +===E AS 3 | 546 | +--Q---+ 547 | | 548 +----------------+ 550 Figure 3: Reference Diagram 552 IPv4 addressing: 554 o C's IPv4 address of interface to D: 1.0.1.1/24, D's interface: 555 1.0.1.2/24 557 o C's IPv4 address of interface to H: 1.0.2.1/24, H's interface: 558 1.0.2.2/24 560 o C's IPv4 address of upper interface to E: 1.0.3.1, E's interface: 561 1.0.3.2/24 563 o C's local identifier of upper interface to E: 0.0.0.1.0.0.0.0 565 o C's IPv4 address of lower interface to E: 1.0.4.1/24, E's 566 interface: 1.0.4.2/24 568 o C's local identifier of lower interface to E: 0.0.0.2.0.0.0.0 570 o Loopback of E used for eBGP multi-hop peering to C: 1.0.5.2/32 571 o C's loopback is 3.3.3.3/32 with SID 64 573 BGP Router-IDs are C, D, H and E. 575 o C's BGP Router-ID: 3.3.3.3 577 o D's BGP Router-ID: 4.4.4.4 579 o E's BGP Router-ID: 5.5.5.5 581 o H's BGP Router-ID: 6.6.6.6 583 C's BGP peering: 585 o Single-hop eBGP peering with neighbor 1.0.1.2 (D) 587 o Single-hop eBGP peering with neighbor 1.0.2.2 (H) 589 o Multi-hop eBGP peering with E on ip address 1.0.5.2 (E) 591 C's resolution of the multi-hop eBGP session to E: 593 o Static route 1.0.5.2/32 via 1.0.3.2 595 o Static route 1.0.5.2/32 via 1.0.4.2 597 Node C configuration is such that: 599 o A Peer Node segment (Peer-Node-SID) is allocated to each peer (D, 600 H and E). 602 o An Peer Adjacency segment (Peer-Adj-SID) is defined for each 603 recursing interface to a multi-hop peer (CE upper and lower 604 interfaces). 606 o A Peer Set segment (Peer-Set-SID) is defined to include all peers 607 in AS3 (peers H and E). 609 Local BGP-LS Identifier in router C is set to 10000. 611 The Link NLRI Type is used in order to encode C's connectivity. The 612 Link NLRI uses the new Protocol-ID value (to be assigned by IANA) 614 Once the BGP-LS update is originated by C, it may be advertised to 615 internal (iBGP) as well as external (eBGP) neighbors supporting the 616 BGP-LS EPE extensions defined in this document. 618 6.2. Peer Node Segment for Node D 620 Descriptors: 622 o Local Node Descriptors (BGP Router-ID, local ASN, BGP-LS 623 Identifier): 3.3.3.3 , AS1, 10000 625 o Remote Node Descriptors (BGP Router-ID, peer ASN): 4.4.4.4, AS2 627 o Link Descriptors (BGP session IPv4 local address, BGP session IPv4 628 neighbor address): 1.0.1.1, 1.0.1.2 630 Attributes: 632 o Peer-Node-SID: 1012 634 o Link Attributes: see section 3.3.2 of 635 [I-D.ietf-idr-ls-distribution] 637 6.3. Peer Node Segment for Node H 639 Descriptors: 641 o Local Node Descriptors (BGP Router-ID, ASN, BGPL Identifier): 642 3.3.3.3 , AS1, 10000 644 o Remote Node Descriptors (BGP Router-ID ASN): 6.6.6.6, AS3 646 o Link Descriptors (BGP session IPv4 local address, BGP session IPv4 647 peer address): 1.0.2.1, 1.0.2.2 649 Attributes: 651 o Peer-Node-SID: 1022 653 o Peer-Set-SID: 1060 655 o Link Attributes: see section 3.3.2 of 656 [I-D.ietf-idr-ls-distribution] 658 6.4. Peer Node Segment for Node E 660 Descriptors: 662 o Local Node Descriptors (BGP Router-ID, ASN, BGP-LS Identifier): 663 3.3.3.3 , AS1, 10000 665 o Remote Node Descriptors (BGP Router-ID, ASN): 5.5.5.5, AS3 666 o Link Descriptors (BGP session IPv4 local address, BGP session IPv4 667 peer address): 3.3.3.3, 1.0.5.2 669 Attributes: 671 o Peer-Node-SID: 1052 673 o Peer-Set-SID: 1060 675 6.5. Peer Adjacency Segment for Node E, Link 1 677 Descriptors: 679 o Local Node Descriptors (BGP Router-ID, ASN, BGP-LS Identifier): 680 3.3.3.3 , AS1, 10000 682 o Remote Node Descriptors (BGP Router-ID, ASN): 5.5.5.5, AS3 684 o Link Descriptors (local interface identifier, IPv4 peer interface 685 address): 0.0.0.1.0.0.0.0 , 1.0.3.2 687 Attributes: 689 o Peer-Adj-SID: 1032 691 o LinkAttributes: see section 3.3.2 of 692 [I-D.ietf-idr-ls-distribution] 694 6.6. Peer Adjacency Segment for Node E, Link 2 696 Descriptors: 698 o Local Node Descriptors (BGP Router-ID, ASN, BGP-LS Identifier): 699 3.3.3.3 , AS1, 10000 701 o Remote Node Descriptors (BGP Router-ID, ASN): 5.5.5.5, AS3 703 o Link Descriptors (local interface identifier, IPv4 peer interface 704 address): 0.0.0.2.0.0.0.0 , 1.0.4.2 706 Attributes: 708 o Peer-Adj-SID: 1042 710 o LinkAttributes: see section 3.3.2 of 711 [I-D.ietf-idr-ls-distribution] 713 7. IANA Considerations 715 This document defines: 717 Two new Node Descriptors Sub-TLVs: BGP-Router-ID and BGP 718 Confederation Member. 720 A new Protocol-ID for EPE: BGP-EPE. 722 Three new BGP-LS Attribute Sub-TLVs: Peer-Node-SID, Peer-Adj-SID 723 and Peer-Set-SID. 725 The codepoints are to be assigned by IANA. The following are the 726 suggested values: 728 +---------------------+--------------------------+-------------+ 729 | Suggested Codepoint | Description | Defined in: | 730 +---------------------+--------------------------+-------------+ 731 | 7 | Protocol-ID | Section 4 | 732 | 516 | BGP Router ID | Section 4.1 | 733 | 517 | BGP Confederation Member | Section 4.1 | 734 | 1101 | Peer-Node-SID | Section 4.3 | 735 | 1102 | Peer-Adj-SID | Section 4.3 | 736 | 1103 | Peer-Set-SID | Section 4.3 | 737 +---------------------+--------------------------+-------------+ 739 Table 1: Summary Table of BGP-LS EPE Codepoints 741 8. Manageability Considerations 743 TBD 745 9. Security Considerations 747 [I-D.ietf-idr-ls-distribution] defines BGP-LS NLRIs to which the 748 extensions defined in this document apply. 750 The Security Section of [I-D.ietf-idr-ls-distribution] also applies 751 to: 753 o New Node Descriptors Sub-TLVs: BGP-Router-ID and BGP- 754 Confederation-Member; 756 o New BGP-LS Attributes TLVs: Peer-Node-SID, Peer-Adj-SID and Peer- 757 Set-SID. 759 10. Contributors 761 Acee Lindem gave a substantial contribution to this document. 763 11. Acknowledgements 765 The authors would like to thank Jakob Heitz, Howard Yang, Hannes 766 Gredler, Peter Psenak, Ketan Jivan Talaulikar, and Arjun Sreekantiah 767 for their feedback and comments. 769 12. References 771 12.1. Normative References 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, 775 DOI 10.17487/RFC2119, March 1997, 776 . 778 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 779 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 780 DOI 10.17487/RFC4271, January 2006, 781 . 783 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 784 System Confederations for BGP", RFC 5065, 785 DOI 10.17487/RFC5065, August 2007, 786 . 788 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 789 in Support of Generalized Multi-Protocol Label Switching 790 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 791 . 793 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 794 Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, 795 June 2011, . 797 12.2. Informative References 799 [I-D.ietf-idr-ls-distribution] 800 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 801 Ray, "North-Bound Distribution of Link-State and TE 802 Information using BGP", draft-ietf-idr-ls-distribution-13 803 (work in progress), October 2015. 805 [I-D.ietf-spring-segment-routing] 806 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 807 and r. rjs@rob.sh, "Segment Routing Architecture", draft- 808 ietf-spring-segment-routing-07 (work in progress), 809 December 2015. 811 [I-D.ietf-spring-segment-routing-central-epe] 812 Filsfils, C., Previdi, S., Ginsburg, D., and D. Afanasiev, 813 "Segment Routing Centralized Egress Peer Engineering", 814 draft-ietf-spring-segment-routing-central-epe-00 (work in 815 progress), October 2015. 817 Authors' Addresses 819 Stefano Previdi (editor) 820 Cisco Systems, Inc. 821 Via Del Serafico, 200 822 Rome 00142 823 Italy 825 Email: sprevidi@cisco.com 827 Clarence Filsfils 828 Cisco Systems, Inc. 829 Brussels 830 BE 832 Email: cfilsfil@cisco.com 834 Saikat Ray 835 Individual Contributor 837 Email: raysaikat@gmail.com 839 Keyur Patel 840 Cisco Systems, Inc. 841 170, West Tasman Drive 842 San Jose, CA 95134 843 US 845 Email: keyupate@cisco.com 846 Jie Dong 847 Huawei Technologies 848 Huawei Campus, No. 156 Beiqing Rd. 849 Beijing 100095 850 China 852 Email: jie.dong@huawei.com 854 Mach (Guoyi) Chen 855 Huawei Technologies 856 Huawei Campus, No. 156 Beiqing Rd. 857 Beijing 100095 858 China 860 Email: mach.chen@huawei.com