idnits 2.17.1 draft-ietf-idr-bgpls-segment-routing-epe-10.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 (March 9, 2017) is 2598 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-11 == Outdated reference: A later version (-10) exists of draft-ietf-spring-segment-routing-central-epe-04 -- 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: September 10, 2017 K. Patel 6 Arrcus, Inc. 7 S. Ray 8 Individual Contributor 9 J. Dong 10 M. Chen 11 Huawei Technologies 12 March 9, 2017 14 Segment Routing BGP Egress Peer Engineering BGP-LS Extensions 15 draft-ietf-idr-bgpls-segment-routing-epe-10 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 September 10, 2017. 58 Copyright Notice 60 Copyright (c) 2017 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-EPE Connectivity Description . . . . . . . 5 79 4.1. BGP Router ID and Member ASN . . . . . . . . . . . . . . 5 80 4.2. BGP-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. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 95 8.1. New BGP-LS Protocol-ID . . . . . . . . . . . . . . . . . 17 96 8.2. Node Descriptors and Link Attribute TLVs . . . . . . . . 17 97 9. Manageability Considerations . . . . . . . . . . . . . . . . 18 98 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 99 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 100 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 101 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 102 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 103 13.2. Informative References . . . . . . . . . . . . . . . . . 19 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 106 1. Introduction 108 Segment Routing (SR) leverages source routing. A node steers a 109 packet through a controlled set of instructions, called segments, by 110 prepending the packet with an SR header. A segment can represent any 111 instruction, topological or service-based. SR allows to enforce a 112 flow through any topological path and service chain while maintaining 113 per-flow state only at the ingress node of the SR domain. 115 The Segment Routing architecture can be directly applied to the MPLS 116 dataplane with no change on the forwarding plane. It requires minor 117 extension to the existing link-state routing protocols. 119 This document outline a BGP-LS extension for exporting BGP peering 120 node topology information (including its peers, interfaces and 121 peering ASs) in a way that is exploitable in order to compute 122 efficient BGP Egress Peer Engineering (BGP-EPE) policies and 123 strategies. 125 This document defines new types of segments: a Peer Node segment 126 describing the BGP session between two nodes; a Peer Adjacency 127 Segment describing the link (one or more) that is used by the BGP 128 session; the Peer Set Segment describing an arbitrary set of sessions 129 or links between the local BGP node and its peers. 131 While an egress point topology usually refers to eBGP sessions 132 between external peers, there's nothing in the extensions defined in 133 this document that would prevent the use of these extensions in the 134 context of iBGP sessions. 136 2. Segment Routing Documents 138 The main reference for this document is the SR architecture defined 139 in [I-D.ietf-spring-segment-routing]. 141 The Segment Routing BGP Egress Peer Engineering (BGP-EPE) 142 architecture is described in 143 [I-D.ietf-spring-segment-routing-central-epe]. 145 3. BGP Peering Segments 147 As defined in [I-D.ietf-spring-segment-routing-central-epe], an BGP- 148 EPE enabled Egress PE node MAY advertise segments corresponding to 149 its attached peers. These segments are called BGP peering segments 150 or BGP Peering SIDs. In case of eBGP, they enable the expression of 151 source-routed inter-domain paths. 153 An ingress border router of an AS may compose a list of segments to 154 steer a flow along a selected path within the AS, towards a selected 155 egress border router C of the AS and through a specific peer. At 156 minimum, a BGP-EPE policy applied at an ingress PE involves two 157 segments: the Node SID of the chosen egress PE and then the BGP 158 Peering Segment for the chosen egress PE peer or peering interface. 160 This document defines the BGP-EPE Peering Segments: 162 o Peer Node Segment (Peer-Node-SID) 164 o Peer Adjacency Segment (Peer-Adj-SID) 166 o Peer Set Segment (Peer-Set-SID) 168 Each BGP session MUST be described by a Peer Node Segment. The 169 description of the BGP session MAY be augmented by additional 170 Adjacency Segments. Finally, each Peer Node Segment and Peer 171 Adjacency Segment MAY be part of the same group/set so to be able to 172 group EPE resources under a common Peer-Set Segment Identifier (SID). 174 Therefore, when the extensions defined in this document are applied 175 to the use case defined in 176 [I-D.ietf-spring-segment-routing-central-epe]: 178 o One Peer Node Segment MUST be present. 180 o One or more Peer Adjacency Segments MAY be present. 182 o Each of the Peer Node and Peer Adjacency Segment MAY use the same 183 Peer-Set. 185 While an egress point topology usually refers to eBGP sessions 186 between external peers, there's nothing in the extensions defined in 187 this document that would prevent the use of these extensions in the 188 context of iBGP sessions. 190 4. Link NLRI for BGP-EPE Connectivity Description 192 This section describes the NLRI used for describing the connectivity 193 of the BGP Egress router. The connectivity is based on links and 194 remote peers/ASs and therefore the existing Link-Type NLRI (defined 195 in [RFC7752]) is used. A new Protocol-ID is used: BGP (codepoint 7 196 assigned by IANA (Section 8) from the registry "BGP-LS Protocol- 197 IDs"). 199 The use of a new Protocol-ID allows separation and differentiation 200 between the NLRIs carrying BGP-EPE descriptors from the NLRIs 201 carrying IGP link-state information as defined in [RFC7752]. The 202 Link NLRI Type uses descriptors and attributes already defined in 203 [RFC7752] in addition to new TLVs defined in the following sections 204 of this document. 206 The extensions defined in this document apply to both internal and 207 external BGP-LS EPE advertisements. 209 [RFC7752] defines Link NLRI Type is as follows: 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+ 214 | Protocol-ID | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Identifier | 217 | (64 bits) | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 // Local Node Descriptors // 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 // Remote Node Descriptors // 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 // Link Descriptors // 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Node Descriptors and Link Descriptors are defined in [RFC7752]. 228 4.1. BGP Router ID and Member ASN 230 Two new Node Descriptors Sub-TLVs are defined in this document: 232 o BGP Router Identifier (BGP Router-ID): 234 Type: 516 (assigned by IANA (Section 8) from the registry "BGP- 235 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 236 Attribute TLVs"). 238 Length: 4 octets 240 Value: 4 octet unsigned integer representing the BGP Identifier 241 as defined in [RFC4271] and [RFC6286]. 243 o Confederation Member ASN (Member-ASN) 245 Type: 517 (assigned by IANA (Section 8) from the registry "BGP- 246 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 247 Attribute TLVs"). 249 Length: 4 octets 251 Value: 4 octet unsigned integer representing the Member ASN 252 inside the Confederation.[RFC5065]. 254 4.2. BGP-EPE Node Descriptors 256 The following Node Descriptors Sub-TLVs MUST appear in the Link NLRI 257 as Local Node Descriptors: 259 o BGP Router-ID, which contains the BGP Identifier of the local BGP- 260 EPE capable node. 262 o Autonomous System Number, which contains the local ASN or local 263 confederation identifier (ASN) if confederations are used. 265 o BGP-LS Identifier. 267 It has to be noted that [RFC6286] (section 2.1) requires the BGP 268 identifier (router-id) to be unique within an Autonomous System. 269 Therefore, the tuple is globally unique. 271 The following Node Descriptors Sub-TLVs MAY appear in the Link NLRI 272 as Local Node Descriptors: 274 o Member-ASN, which contains the ASN of the confederation member 275 (when BGP confederations are used). 277 o Node Descriptors as defined in [RFC7752]. 279 The following Node Descriptors Sub-TLVs MUST appear in the Link NLRI 280 as Remote Node Descriptors: 282 o BGP Router-ID, which contains the BGP Identifier of the peer node. 284 o Autonomous System Number, which contains the peer ASN or the peer 285 confederation identifier (ASN), if confederations are used. 287 The following Node Descriptors Sub-TLVs MAY appear in the Link NLRI 288 as Remote 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 defined in [RFC7752]. 295 4.3. Link Attributes 297 The following BGP-LS Link attributes TLVs are used with the Link 298 NLRI: 300 +----------+---------------------------+----------+ 301 | TLV Code | Description | Length | 302 | Point | | | 303 +----------+---------------------------+----------+ 304 | 1101 | Peer Node Segment | variable | 305 | | Identifier (Peer-Node-SID)| | 306 | 1102 | Peer Adjacency Segment | variable | 307 | | Identifier (Peer-Adj-SID) | | 308 | 1103 | Peer Set Segment | variable | 309 | | Identifier (Peer-Set-SID) | | 310 +----------+---------------------------+----------+ 312 Figure 1: BGP-LS TLV code points for BGP-EPE 314 Peer-Node-SID, Peer-Adj-SID and Peer-Set-SID have all the same format 315 defined here below: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Type | Length | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Flags | Weight | Reserved | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | SID/Label/Index (variable) | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 where: 329 Figure 2 331 o Type: 1101 or 1102 or 1103 (assigned by IANA (Section 8) from the 332 registry "BGP-LS Node Descriptor, Link Descriptor, Prefix 333 Descriptor, and Attribute TLVs"). 335 o Length: variable. 337 o Flags: following flags have been defined: 339 0 1 2 3 4 5 6 7 340 +-+-+-+-+-+-+-+-+ 341 |V|L| | 342 +-+-+-+-+-+-+-+-+ 344 where: 346 * V-Flag: Value flag. If set, then the Adj-SID carries a value. 347 By default the flag is SET. 349 * L-Flag: Local Flag. If set, then the value/index carried by 350 the Adj-SID has local significance. By default the flag is 351 SET. 353 * Other bits: MUST be zero when originated and ignored when 354 received. 356 o Weight: 1 octet. The value represents the weight of the SID for 357 the purpose of load balancing. An example use of the weight is 358 described in [I-D.ietf-spring-segment-routing]. 360 o SID/Index/Label. According to the TLV length and to the V and L 361 flags settings, it contains either: 363 * A 3 octet local label where the 20 rightmost bits are used for 364 encoding the label value. In this case the V and L flags MUST 365 be set. 367 * A 4 octet index defining the offset in the SID/Label space 368 advertised by this router using the encodings defined in 369 Section 3.1. In this case V and L flags MUST be unset. 371 * A 16 octet IPv6 address. In this case the V flag MUST be set. 372 The L flag MUST be unset if the IPv6 address is globally 373 unique. 375 The values of the Peer-Node-SID, Peer-Adj-SID and Peer-Set-SID Sub- 376 TLVs SHOULD be persistent across router restart. 378 The Peer-Node-SID MUST be present when BGP-LS is used for the use 379 case described in [I-D.ietf-spring-segment-routing-central-epe] and 380 MAY be omitted for other use cases. 382 The Peer-Adj-SID and Peer-Set-SID SubTLVs MAY be present when BGP-LS 383 is used for the use case described in 384 [I-D.ietf-spring-segment-routing-central-epe] and MAY be omitted for 385 other use cases. 387 In addition, BGP-LS Nodes and Link Attributes, as defined in 388 [RFC7752] MAY be inserted in order to advertise the characteristics 389 of the link. 391 5. Peer Node and Peer Adjacency Segments 393 In this section the following Peer Segments are defined: 395 Peer Node Segment (Peer-Node-SID) 397 Peer Adjacency Segment (Peer-Adj-SID) 399 Peer Set Segment (Peer-Set-SID) 401 The Peer Node, Peer Adjacency and Peer Set segments can be either a 402 local or a global segment (depending on the setting of the V and L 403 flags defined in Figure 2. For example, when BGP-EPE is used in the 404 context of a SR network over the IPv6 dataplane, it is likely the 405 case that the IPv6 addresses used as SIDs will be global. 407 5.1. Peer Node Segment (Peer-Node-SID) 409 The Peer Node Segment describes the BGP session peer (neighbor). It 410 MUST be present when describing a BGP-EPE topology as defined in 411 [I-D.ietf-spring-segment-routing-central-epe]. The Peer Node Segment 412 is encoded within the BGP-LS Link NLRI specified in Section 4. 414 The Peer Node Segment, at the BGP node advertising it, has the 415 following semantic: 417 o SR header operation: NEXT (as defined in 418 [I-D.ietf-spring-segment-routing]). 420 o Next-Hop: the connected peering node to which the segment is 421 related. 423 The Peer Node Segment is advertised with a Link NLRI, where: 425 o Local Node Descriptors contains 427 Local BGP Router-ID of the BGP-EPE enabled egress PE. 428 Local ASN. 429 BGP-LS Identifier. 431 o Remote Node Descriptors contains 433 Peer BGP Router-ID (i.e.: the peer BGP ID used in the BGP session). 434 Peer ASN. 436 o Link Descriptors Sub-TLVs, as defined in [RFC7752], contain the 437 addresses used by the BGP session: 439 * IPv4 Interface Address (Sub-TLV 259) contains the BGP session 440 IPv4 local address. 442 * IPv4 Neighbor Address (Sub-TLV 260) contains the BGP session 443 IPv4 peer address. 445 * IPv6 Interface Address (Sub-TLV 261) contains the BGP session 446 IPv6 local address. 448 * IPv6 Neighbor Address (Sub-TLV 262) contains the BGP session 449 IPv6 peer address. 451 o Link Attribute contains the Peer-Node-SID TLV as defined in 452 Section 4.3. 454 o In addition, BGP-LS Link Attributes, as defined in [RFC7752], MAY 455 be inserted in order to advertise the characteristics of the link. 457 5.2. Peer Adjacency Segment (Peer-Adj-SID) 459 The Peer Adjacency Segment, at the BGP node advertising it, has the 460 following semantic: 462 o SR header operation: NEXT (as defined in 463 [I-D.ietf-spring-segment-routing]). 465 o Next-Hop: the interface peer address. 467 The Peer Adjacency Segment is advertised with a Link NLRI, where: 469 o Local Node Descriptors contains 471 Local BGP Router-ID of the BGP-EPE enabled egress PE. 472 Local ASN. 473 BGP-LS Identifier. 475 o Remote Node Descriptors contains 477 Peer BGP Router-ID (i.e.: the peer BGP ID used in the BGP session). 478 Peer ASN. 480 o Link Descriptors Sub-TLVs, as defined in [RFC7752], MUST contain 481 the following TLVs: 483 * Link Local/Remote Identifiers (Sub-TLV 258) contains the 484 4-octet Link Local Identifier followed by the 4-octet value 0 485 indicating the Link Remote Identifier in unknown [RFC5307]. 487 o In addition, Link Descriptors Sub-TLVs, as defined in [RFC7752], 488 MAY contain the following TLVs: 490 * IPv4 Interface Address (Sub-TLV 259) contains the address of 491 the local interface through which the BGP session is 492 established. 494 * IPv6 Interface Address (Sub-TLV 261) contains the address of 495 the local interface through which the BGP session is 496 established. 498 * IPv4 Neighbor Address (Sub-TLV 260) contains the IPv4 address 499 of the peer interface used by the BGP session. 501 * IPv6 Neighbor Address (Sub-TLV 262) contains the IPv6 address 502 of the peer interface used by the BGP session. 504 o Link attribute used with the Peer-Adj-SID contains the TLV as 505 defined in Section 4.3. 507 In addition, BGP-LS Link Attributes, as defined in [RFC7752], MAY be 508 inserted in order to advertise the characteristics of the link. 510 5.3. Peer Set Segment 512 The Peer Adjacency Segment, at the BGP node advertising it, has the 513 following semantic: 515 o SR header operation: NEXT (as defined in 516 [I-D.ietf-spring-segment-routing]). 518 o Next-Hop: load balance across any connected interface to any peer 519 in the related set. 521 The Peer Set Segment is advertised within a Link NLRI (describing a 522 Peer Node Segment or a Peer Adjacency segment) as a BGP-LS attribute. 524 The Peer Set Attribute contains the Peer-Set-SID TLV, defined in 525 Section 4.3 identifying the set of which the Peer Node Segment or 526 Peer Adjacency Segment is a member. 528 6. Illustration 530 6.1. Reference Diagram 532 The following reference diagram is used throughout this document. 533 The solution is illustrated for IPv4 with MPLS-based segments and the 534 BGP-EPE topology is based on eBGP sessions between external peers. 536 As stated in Section 3, the solution illustrated hereafter is equally 537 applicable to an iBGP session topology. In other words, the solution 538 also applies to the case where C, D, H, and E are in the same AS and 539 run iBGP sessions between each other. 541 +------+ 542 | | 543 +---D F 544 +---------+ / | AS 2 |\ +------+ 545 | X |/ +------+ \ | Z |---L/8 546 A C---+ \| | 547 | |\\ \ +------+ /| AS 4 |---M/8 548 | AS1 | \\ +-H |/ +------+ 549 | | \\ | G 550 +----P----+ +===E AS 3 | 551 | +--Q---+ 552 | | 553 +----------------+ 555 Figure 3: Reference Diagram 557 IPv4 addressing: 559 o C's IPv4 address of interface to D: 1.0.1.1/24, D's interface: 560 1.0.1.2/24 562 o C's IPv4 address of interface to H: 1.0.2.1/24, H's interface: 563 1.0.2.2/24 565 o C's IPv4 address of upper interface to E: 1.0.3.1/24, E's 566 interface: 1.0.3.2/24 568 o C's local identifier of upper interface to E: 0.0.0.1.0.0.0.0 570 o C's IPv4 address of lower interface to E: 1.0.4.1/24, E's 571 interface: 1.0.4.2/24 573 o C's local identifier of lower interface to E: 0.0.0.2.0.0.0.0 575 o Loopback of E used for eBGP multi-hop peering to C: 1.0.5.2/32 576 o C's loopback is 3.3.3.3/32 with SID 64 578 BGP Router-IDs are C, D, H and E. 580 o C's BGP Router-ID: 3.3.3.3 582 o D's BGP Router-ID: 4.4.4.4 584 o E's BGP Router-ID: 5.5.5.5 586 o H's BGP Router-ID: 6.6.6.6 588 C's BGP peering: 590 o Single-hop eBGP peering with neighbor 1.0.1.2 (D) 592 o Single-hop eBGP peering with neighbor 1.0.2.2 (H) 594 o Multi-hop eBGP peering with E on ip address 1.0.5.2 (E) 596 C's resolution of the multi-hop eBGP session to E: 598 o Static route 1.0.5.2/32 via 1.0.3.2 600 o Static route 1.0.5.2/32 via 1.0.4.2 602 Node C configuration is such that: 604 o A Peer Node segment (Peer-Node-SID) is allocated to each peer (D, 605 H and E). 607 o An Peer Adjacency segment (Peer-Adj-SID) is defined for each 608 recursing interface to a multi-hop peer (CE upper and lower 609 interfaces). 611 o A Peer Set segment (Peer-Set-SID) is defined to include all peers 612 in AS3 (peers H and E). 614 Local BGP-LS Identifier in router C is set to 10000. 616 The Link NLRI Type is used in order to encode C's connectivity. The 617 Link NLRI uses the new Protocol-ID value (to be assigned by IANA) 619 Once the BGP-LS update is originated by C, it may be advertised to 620 internal (iBGP) as well as external (eBGP) neighbors supporting the 621 BGP-LS EPE extensions defined in this document. 623 6.2. Peer Node Segment for Node D 625 Descriptors: 627 o Local Node Descriptors (BGP Router-ID, local ASN, BGP-LS 628 Identifier): 3.3.3.3 , AS1, 10000 630 o Remote Node Descriptors (BGP Router-ID, peer ASN): 4.4.4.4, AS2 632 o Link Descriptors (BGP session IPv4 local address, BGP session IPv4 633 neighbor address): 1.0.1.1, 1.0.1.2 635 Attributes: 637 o Peer-Node-SID: 1012 639 o Link Attributes: see section 3.3.2 of [RFC7752] 641 6.3. Peer Node Segment for Node H 643 Descriptors: 645 o Local Node Descriptors (BGP Router-ID, ASN, BGPLS Identifier): 646 3.3.3.3 , AS1, 10000 648 o Remote Node Descriptors (BGP Router-ID ASN): 6.6.6.6, AS3 650 o Link Descriptors (BGP session IPv4 local address, BGP session IPv4 651 peer address): 1.0.2.1, 1.0.2.2 653 Attributes: 655 o Peer-Node-SID: 1022 657 o Peer-Set-SID: 1060 659 o Link Attributes: see section 3.3.2 of [RFC7752] 661 6.4. Peer Node Segment for Node E 663 Descriptors: 665 o Local Node Descriptors (BGP Router-ID, ASN, BGP-LS Identifier): 666 3.3.3.3 , AS1, 10000 668 o Remote Node Descriptors (BGP Router-ID, ASN): 5.5.5.5, AS3 669 o Link Descriptors (BGP session IPv4 local address, BGP session IPv4 670 peer address): 3.3.3.3, 1.0.5.2 672 Attributes: 674 o Peer-Node-SID: 1052 676 o Peer-Set-SID: 1060 678 6.5. Peer Adjacency Segment for Node E, Link 1 680 Descriptors: 682 o Local Node Descriptors (BGP Router-ID, ASN, BGP-LS Identifier): 683 3.3.3.3 , AS1, 10000 685 o Remote Node Descriptors (BGP Router-ID, ASN): 5.5.5.5, AS3 687 o Link Descriptors (local interface identifier, IPv4 peer interface 688 address): 0.0.0.1.0.0.0.0 , 1.0.3.2 690 Attributes: 692 o Peer-Adj-SID: 1032 694 o LinkAttributes: see section 3.3.2 of [RFC7752] 696 6.6. Peer Adjacency Segment for Node E, Link 2 698 Descriptors: 700 o Local Node Descriptors (BGP Router-ID, ASN, BGP-LS Identifier): 701 3.3.3.3 , AS1, 10000 703 o Remote Node Descriptors (BGP Router-ID, ASN): 5.5.5.5, AS3 705 o Link Descriptors (local interface identifier, IPv4 peer interface 706 address): 0.0.0.2.0.0.0.0 , 1.0.4.2 708 Attributes: 710 o Peer-Adj-SID: 1042 712 o LinkAttributes: see section 3.3.2 of [RFC7752] 714 7. Implementation Status 716 Note to RFC Editor: Please remove this section prior to publication, 717 as well as the reference to RFC 7942. 719 This section records the status of known implementations of the 720 protocol defined by this specification at the time of posting of this 721 Internet-Draft, and is based on a proposal described in [RFC7942]. 722 The description of implementations in this section is intended to 723 assist the IETF in its decision processes in progressing drafts to 724 RFCs. Please note that the listing of any individual implementation 725 here does not imply endorsement by the IETF. Furthermore, no effort 726 has been spent to verify the information presented here that was 727 supplied by IETF contributors. This is not intended as, and must not 728 be construed to be, a catalog of available implementations or their 729 features. Readers are advised to note that other implementations may 730 exist. 732 According to [RFC7942], "this will allow reviewers and working groups 733 to assign due consideration to documents that have the benefit of 734 running code, which may serve as evidence of valuable experimentation 735 and feedback that have made the implemented protocols more mature. 736 It is up to the individual working groups to use this information as 737 they see fit". 739 Several early implementations exist and will be reported in detail in 740 a forthcoming version of this document. For purposes of early 741 interoperability testing, when no FCFS code point was available, 742 implementations have made use of the following values: 744 +---------------------------------------+ 745 | Codepoint | Description | 746 +---------------------------------------+ 747 | 7 | Protocol-ID BGP | 748 | 516 | BGP Router-ID | 749 | 517 | BGP Confederation Member | 750 | 1101 | Peer-Node-SID | 751 | 1102 | Peer-Adj-SID | 752 | 1103 | Peer-Set-SID | 753 +------------+--------------------------+ 755 IANA has now confirmed the assignment of the above coidepoints. 756 SeeSection 8. 758 8. IANA Considerations 760 This document defines: 762 A new Protocol-ID: BGP. The codepoint is from the "BGP-LS 763 Protocol-IDs" registry. 765 Two new TLVs: BGP-Router-ID and BGP Confederation Member. The 766 codepoints are in the "BGP-LS Node Descriptor, Link Descriptor, 767 Prefix Descriptor, and Attribute TLVs" registry. 769 Three new BGP-LS Attribute TLVs: Peer-Node-SID, Peer-Adj-SID and 770 Peer-Set-SID. The codepoints are in the "BGP-LS Node Descriptor, 771 Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry. 773 8.1. New BGP-LS Protocol-ID 775 This document defines a new value in the registry "BGP-LS Protocol- 776 IDs": 778 +----------------------------------------------+ 779 | Codepoint | Description | Status | 780 +----------------------------------------------+ 781 | 7 | BGP | Assigned by IANA | 782 +----------------------------------------------+ 784 8.2. Node Descriptors and Link Attribute TLVs 786 This document defines 5 new TLVs in the registry "BGP-LS Node 787 Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs": 789 o Two new node descriptor TLVs 791 o Three new link attribute TLVs 793 All the new 5 codepoints are in the same registry: "BGP-LS Node 794 Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs". 795 However, the registry is organized in ranges (node descriptors, link 796 descriptors, node attributes, link attributes). 798 The following new Node Descriptors TLVs are defined: 800 +-----------------------------------------------------------+ 801 | Codepoint | Description | Status | 802 +-----------------------------------------------------------+ 803 | 516 | BGP Router-ID | Assigned by IANA | 804 | 517 | BGP Confederation Member | Assigned by IANA | 805 +------------+----------------------------------------------+ 807 The following new Link Attribute TLVs are defined: 809 +-----------------------------------------------------------+ 810 | Codepoint | Description | Status | 811 +-----------------------------------------------------------+ 812 | 1101 | Peer-Node-SID | Assigned by IANA | 813 | 1102 | Peer-Adj-SID | Assigned by IANA | 814 | 1103 | Peer-Set-SID | Assigned by IANA | 815 +------------+----------------------------------------------+ 817 9. Manageability Considerations 819 This BGP-LS ([RFC7752]) extensions that are described in this 820 document consists of additional BGP-LS descriptors and TLVs that will 821 follow the same manageability functions of BGP-LS, described in 822 [RFC7752]. 824 The operator MUST be capable of configuring, enabling, disabling the 825 advertisement of each of the Peer-Node-SID, Peer-Adj-SID and Peer- 826 Set-SID as well as to control which information is advertised to 827 which internal or external peer. This is not different from what is 828 required by a BGP speaker in terms of information origination and 829 advertisement. In addition, the advertisement of EPE information 830 MUST conform to standard BGP advertisement and propagation rules 831 (iBGP, eBGP, Route-Reflectors, Confederations). 833 10. Security Considerations 835 [RFC7752] defines BGP-LS NLRIs to which the extensions defined in 836 this document apply. 838 The Security Section of [RFC7752] also applies to: 840 o New Node Descriptors Sub-TLVs: BGP-Router-ID and BGP- 841 Confederation-Member; 843 o New BGP-LS Attributes TLVs: Peer-Node-SID, Peer-Adj-SID and Peer- 844 Set-SID. 846 11. Contributors 848 Acee Lindem gave a substantial contribution to this document. 850 12. Acknowledgements 852 The authors would like to thank Jakob Heitz, Howard Yang, Hannes 853 Gredler, Peter Psenak, Ketan Jivan Talaulikar, and Arjun Sreekantiah 854 for their feedback and comments. 856 13. References 858 13.1. Normative References 860 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 861 Requirement Levels", BCP 14, RFC 2119, 862 DOI 10.17487/RFC2119, March 1997, 863 . 865 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 866 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 867 DOI 10.17487/RFC4271, January 2006, 868 . 870 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 871 System Confederations for BGP", RFC 5065, 872 DOI 10.17487/RFC5065, August 2007, 873 . 875 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 876 in Support of Generalized Multi-Protocol Label Switching 877 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 878 . 880 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 881 Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, 882 June 2011, . 884 13.2. Informative References 886 [I-D.ietf-spring-segment-routing] 887 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 888 and R. Shakir, "Segment Routing Architecture", draft-ietf- 889 spring-segment-routing-11 (work in progress), February 890 2017. 892 [I-D.ietf-spring-segment-routing-central-epe] 893 Filsfils, C., Previdi, S., Aries, E., and D. Afanasiev, 894 "Segment Routing Centralized BGP Egress Peer Engineering", 895 draft-ietf-spring-segment-routing-central-epe-04 (work in 896 progress), February 2017. 898 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 899 S. Ray, "North-Bound Distribution of Link-State and 900 Traffic Engineering (TE) Information Using BGP", RFC 7752, 901 DOI 10.17487/RFC7752, March 2016, 902 . 904 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 905 Code: The Implementation Status Section", BCP 205, 906 RFC 7942, DOI 10.17487/RFC7942, July 2016, 907 . 909 Authors' Addresses 911 Stefano Previdi (editor) 912 Cisco Systems, Inc. 913 Via Del Serafico, 200 914 Rome 00142 915 Italy 917 Email: sprevidi@cisco.com 919 Clarence Filsfils 920 Cisco Systems, Inc. 921 Brussels 922 BE 924 Email: cfilsfil@cisco.com 926 Keyur Patel 927 Arrcus, Inc. 929 Email: Keyur@arrcus.com 931 Saikat Ray 932 Individual Contributor 934 Email: raysaikat@gmail.com 936 Jie Dong 937 Huawei Technologies 938 Huawei Campus, No. 156 Beiqing Rd. 939 Beijing 100095 940 China 942 Email: jie.dong@huawei.com 943 Mach (Guoyi) Chen 944 Huawei Technologies 945 Huawei Campus, No. 156 Beiqing Rd. 946 Beijing 100095 947 China 949 Email: mach.chen@huawei.com