idnits 2.17.1 draft-ietf-idr-bgpls-segment-routing-epe-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2563 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 (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-01 == Outdated reference: A later version (-10) exists of draft-ietf-spring-segment-routing-central-epe-05 -- 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 14, 2017 K. Patel 6 Arrcus, Inc. 7 S. Ray 8 Individual Contributor 9 J. Dong 10 M. Chen 11 Huawei Technologies 12 March 13, 2017 14 Segment Routing BGP Egress Peer Engineering BGP-LS Extensions 15 draft-ietf-idr-bgpls-segment-routing-epe-11 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 14, 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 F . . . . . . . . . . . . . . 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 SRGB (Segment 368 Routing Global Block as defined in 369 [I-D.ietf-spring-segment-routing] advertised by this router. 370 In this case the SRGB MUST be advertised using the extensions 371 defined in [I-D.ietf-idr-bgp-ls-segment-routing-ext]. 373 * A 16 octet IPv6 address. In this case the V flag MUST be set. 374 The L flag MUST be unset if the IPv6 address is globally 375 unique. 377 The values of the Peer-Node-SID, Peer-Adj-SID and Peer-Set-SID Sub- 378 TLVs SHOULD be persistent across router restart. 380 The Peer-Node-SID MUST be present when BGP-LS is used for the use 381 case described in [I-D.ietf-spring-segment-routing-central-epe] and 382 MAY be omitted for other use cases. 384 The Peer-Adj-SID and Peer-Set-SID SubTLVs MAY be present when BGP-LS 385 is used for the use case described in 386 [I-D.ietf-spring-segment-routing-central-epe] and MAY be omitted for 387 other use cases. 389 In addition, BGP-LS Nodes and Link Attributes, as defined in 390 [RFC7752] MAY be inserted in order to advertise the characteristics 391 of the link. 393 5. Peer Node and Peer Adjacency Segments 395 In this section the following Peer Segments are defined: 397 Peer Node Segment (Peer-Node-SID) 399 Peer Adjacency Segment (Peer-Adj-SID) 401 Peer Set Segment (Peer-Set-SID) 403 The Peer Node, Peer Adjacency and Peer Set segments can be either a 404 local or a global segment (depending on the setting of the V and L 405 flags defined in Figure 2. For example, when BGP-EPE is used in the 406 context of a SR network over the IPv6 dataplane, it is likely the 407 case that the IPv6 addresses used as SIDs will be global. 409 5.1. Peer Node Segment (Peer-Node-SID) 411 The Peer Node Segment describes the BGP session peer (neighbor). It 412 MUST be present when describing a BGP-EPE topology as defined in 413 [I-D.ietf-spring-segment-routing-central-epe]. The Peer Node Segment 414 is encoded within the BGP-LS Link NLRI specified in Section 4. 416 The Peer Node Segment, at the BGP node advertising it, has the 417 following semantic: 419 o SR header operation: NEXT (as defined in 420 [I-D.ietf-spring-segment-routing]). 422 o Next-Hop: the connected peering node to which the segment is 423 related. 425 The Peer Node Segment is advertised with a Link NLRI, where: 427 o Local Node Descriptors contains 429 Local BGP Router-ID of the BGP-EPE enabled egress PE. 430 Local ASN. 431 BGP-LS Identifier. 433 o Remote Node Descriptors contains 435 Peer BGP Router-ID (i.e.: the peer BGP ID used in the BGP session). 436 Peer ASN. 438 o Link Descriptors Sub-TLVs, as defined in [RFC7752], contain the 439 addresses used by the BGP session: 441 * IPv4 Interface Address (Sub-TLV 259) contains the BGP session 442 IPv4 local address. 444 * IPv4 Neighbor Address (Sub-TLV 260) contains the BGP session 445 IPv4 peer address. 447 * IPv6 Interface Address (Sub-TLV 261) contains the BGP session 448 IPv6 local address. 450 * IPv6 Neighbor Address (Sub-TLV 262) contains the BGP session 451 IPv6 peer address. 453 o Link Attribute contains the Peer-Node-SID TLV as defined in 454 Section 4.3. 456 o In addition, BGP-LS Link Attributes, as defined in [RFC7752], MAY 457 be inserted in order to advertise the characteristics of the link. 459 5.2. Peer Adjacency Segment (Peer-Adj-SID) 461 The Peer Adjacency Segment, at the BGP node advertising it, has the 462 following semantic: 464 o SR header operation: NEXT (as defined in 465 [I-D.ietf-spring-segment-routing]). 467 o Next-Hop: the interface peer address. 469 The Peer Adjacency Segment is advertised with a Link NLRI, where: 471 o Local Node Descriptors contains 473 Local BGP Router-ID of the BGP-EPE enabled egress PE. 474 Local ASN. 475 BGP-LS Identifier. 477 o Remote Node Descriptors contains 479 Peer BGP Router-ID (i.e.: the peer BGP ID used in the BGP session). 480 Peer ASN. 482 o Link Descriptors Sub-TLVs, as defined in [RFC7752], MUST contain 483 the following TLVs: 485 * Link Local/Remote Identifiers (Sub-TLV 258) contains the 486 4-octet Link Local Identifier followed by the 4-octet value 0 487 indicating the Link Remote Identifier in unknown [RFC5307]. 489 o In addition, Link Descriptors Sub-TLVs, as defined in [RFC7752], 490 MAY contain the following TLVs: 492 * IPv4 Interface Address (Sub-TLV 259) contains the address of 493 the local interface through which the BGP session is 494 established. 496 * IPv6 Interface Address (Sub-TLV 261) contains the address of 497 the local interface through which the BGP session is 498 established. 500 * IPv4 Neighbor Address (Sub-TLV 260) contains the IPv4 address 501 of the peer interface used by the BGP session. 503 * IPv6 Neighbor Address (Sub-TLV 262) contains the IPv6 address 504 of the peer interface used by the BGP session. 506 o Link attribute used with the Peer-Adj-SID contains the TLV as 507 defined in Section 4.3. 509 In addition, BGP-LS Link Attributes, as defined in [RFC7752], MAY be 510 inserted in order to advertise the characteristics of the link. 512 5.3. Peer Set Segment 514 The Peer Adjacency Segment, at the BGP node advertising it, has the 515 following semantic: 517 o SR header operation: NEXT (as defined in 518 [I-D.ietf-spring-segment-routing]). 520 o Next-Hop: load balance across any connected interface to any peer 521 in the related set. 523 The Peer Set Segment is advertised within a Link NLRI (describing a 524 Peer Node Segment or a Peer Adjacency segment) as a BGP-LS attribute. 526 The Peer Set Attribute contains the Peer-Set-SID TLV, defined in 527 Section 4.3 identifying the set of which the Peer Node Segment or 528 Peer Adjacency Segment is a member. 530 6. Illustration 532 6.1. Reference Diagram 534 The following reference diagram is used throughout this document. 535 The solution is illustrated for IPv6 with MPLS-based segments and the 536 BGP-EPE topology is based on eBGP sessions between external peers. 538 As stated in Section 3, the solution illustrated hereafter is equally 539 applicable to an iBGP session topology. In other words, the solution 540 also applies to the case where C, D, F, and E are in the same AS and 541 run iBGP sessions between each other. 543 +------+ 544 | | 545 +---D H 546 +---------+ / | AS 2 |\ +------+ 547 | X |/ +------+ \ | Z |---L/8 548 A C---+ \| | 549 | |\\ \ +------+ /| AS 4 |---M/8 550 | AS1 | \\ +-F |/ +------+ 551 | | \\ | G 552 +----P----+ +===E AS 3 | 553 | +--Q---+ 554 | | 555 +----------------+ 557 Figure 3: Reference Diagram 559 IP addressing: 561 o C's IP address of interface to D: 2001:db8:cd::c/64, D's 562 interface: 2001:db8:cd::d/64 564 o C's IP address of interface to F: 2001:db8:cf::c/64, F's 565 interface: 2001:db8:cf::f/64 567 o C's IP address of upper interface to E: 2001:db8:ce1::c/64, E's 568 interface: 2001:db8:ce1::e 570 o C's local identifier of upper interface to E: 0.0.0.1.0.0.0.0 572 o C's IP address of lower interface to E: 2001:db8:ce2::c, E's 573 interface: 2001:db8:ce2::e 575 o C's local identifier of lower interface to E: 0.0.0.2.0.0.0.0 576 o Loopback of E used for eBGP multi-hop peering to C: 577 2001:db8:e::e/128 579 o C's loopback is 2001:db8:c::c/128 with SID 64 581 BGP Router-IDs are C, D, F and E. 583 o C's BGP Router-ID: 192.0.2.3 585 o D's BGP Router-ID: 192.0.2.4 587 o E's BGP Router-ID: 192.0.2.5 589 o F's BGP Router-ID: 192.0.2.6 591 C's BGP peering: 593 o Single-hop eBGP peering with neighbor 2001:db8:cd::d (D) 595 o Single-hop eBGP peering with neighbor 2001:db8:cf::f (F) 597 o Multi-hop eBGP peering with E on ip address 2001:db8:e::e (E) 599 C's resolution of the multi-hop eBGP session to E: 601 o Static route 2001:db8:e::e/128 via 2001:db8:ce1::e 603 o Static route 2001:db8:e::e/128 via 2001:db8:ce2::e 605 Node C configuration is such that: 607 o A Peer Node segment (Peer-Node-SID) is allocated to each peer (D, 608 F and E). 610 o An Peer Adjacency segment (Peer-Adj-SID) is defined for each 611 recursing interface to a multi-hop peer (CE upper and lower 612 interfaces). 614 o A Peer Set segment (Peer-Set-SID) is defined to include all peers 615 in AS3 (peers F and E). 617 Local BGP-LS Identifier in router C is set to 10000. 619 The Link NLRI Type is used in order to encode C's connectivity. The 620 Link NLRI uses the Protocol-ID value (to be assigned by IANA) 621 Once the BGP-LS update is originated by C, it may be advertised to 622 internal (iBGP) as well as external (eBGP) neighbors supporting the 623 BGP-LS EPE extensions defined in this document. 625 6.2. Peer Node Segment for Node D 627 Descriptors: 629 o Local Node Descriptors (BGP Router-ID, local ASN, BGP-LS 630 Identifier): 192.0.2.3, AS1, 10000 632 o Remote Node Descriptors (BGP Router-ID, peer ASN): 192.0.2.4, AS2 634 o Link Descriptors (BGP session IPv6 local address, BGP session IPv6 635 neighbor address): 2001:db8:cd::c, 2001:db8:cd::d 637 Attributes: 639 o Peer-Node-SID: 1012 641 o Link Attributes: see section 3.3.2 of [RFC7752] 643 6.3. Peer Node Segment for Node F 645 Descriptors: 647 o Local Node Descriptors (BGP Router-ID, ASN, BGPLS Identifier): 648 192.0.2.3, AS1, 10000 650 o Remote Node Descriptors (BGP Router-ID ASN): 192.0.2.6, AS3 652 o Link Descriptors (BGP session IPv6 local address, BGP session IPv6 653 peer address): 2001:db8:cf::c, 2001:db8:cf::f 655 Attributes: 657 o Peer-Node-SID: 1022 659 o Peer-Set-SID: 1060 661 o Link Attributes: see section 3.3.2 of [RFC7752] 663 6.4. Peer Node Segment for Node E 665 Descriptors: 667 o Local Node Descriptors (BGP Router-ID, ASN, BGP-LS Identifier): 668 192.0.2.3, AS1, 10000 670 o Remote Node Descriptors (BGP Router-ID, ASN): 192.0.2.5, AS3 672 o Link Descriptors (BGP session IPv6 local address, BGP session IPv6 673 peer address): 2001:db8:c::c, 2001:db8:e::e 675 Attributes: 677 o Peer-Node-SID: 1052 679 o Peer-Set-SID: 1060 681 6.5. Peer Adjacency Segment for Node E, Link 1 683 Descriptors: 685 o Local Node Descriptors (BGP Router-ID, ASN, BGP-LS Identifier): 686 192.0.2.3, AS1, 10000 688 o Remote Node Descriptors (BGP Router-ID, ASN): 192.0.2.5, AS3 690 o Link Descriptors (local interface identifier, IPv6 peer interface 691 address): 0.0.0.1.0.0.0.0 , 2001:db8:ce1::e 693 Attributes: 695 o Peer-Adj-SID: 1032 697 o LinkAttributes: see section 3.3.2 of [RFC7752] 699 6.6. Peer Adjacency Segment for Node E, Link 2 701 Descriptors: 703 o Local Node Descriptors (BGP Router-ID, ASN, BGP-LS Identifier): 704 192.0.2.3, AS1, 10000 706 o Remote Node Descriptors (BGP Router-ID, ASN): 192.0.2.5, AS3 708 o Link Descriptors (local interface identifier, IPv6 peer interface 709 address): 0.0.0.2.0.0.0.0 , 2001:db8:ce2::e 711 Attributes: 713 o Peer-Adj-SID: 1042 715 o LinkAttributes: see section 3.3.2 of [RFC7752] 717 7. Implementation Status 719 Note to RFC Editor: Please remove this section prior to publication, 720 as well as the reference to RFC 7942. 722 This section records the status of known implementations of the 723 protocol defined by this specification at the time of posting of this 724 Internet-Draft, and is based on a proposal described in [RFC7942]. 725 The description of implementations in this section is intended to 726 assist the IETF in its decision processes in progressing drafts to 727 RFCs. Please note that the listing of any individual implementation 728 here does not imply endorsement by the IETF. Furthermore, no effort 729 has been spent to verify the information presented here that was 730 supplied by IETF contributors. This is not intended as, and must not 731 be construed to be, a catalog of available implementations or their 732 features. Readers are advised to note that other implementations may 733 exist. 735 According to [RFC7942], "this will allow reviewers and working groups 736 to assign due consideration to documents that have the benefit of 737 running code, which may serve as evidence of valuable experimentation 738 and feedback that have made the implemented protocols more mature. 739 It is up to the individual working groups to use this information as 740 they see fit". 742 Several early implementations exist and will be reported in detail in 743 a forthcoming version of this document. For purposes of early 744 interoperability testing, when no FCFS code point was available, 745 implementations have made use of the following values: 747 +---------------------------------------+ 748 | Codepoint | Description | 749 +---------------------------------------+ 750 | 7 | Protocol-ID BGP | 751 | 516 | BGP Router-ID | 752 | 517 | BGP Confederation Member | 753 | 1101 | Peer-Node-SID | 754 | 1102 | Peer-Adj-SID | 755 | 1103 | Peer-Set-SID | 756 +------------+--------------------------+ 758 IANA has now confirmed the assignment of the above coidepoints. 759 SeeSection 8. 761 8. IANA Considerations 763 This document defines: 765 A new Protocol-ID: BGP. The codepoint is from the "BGP-LS 766 Protocol-IDs" registry. 768 Two new TLVs: BGP-Router-ID and BGP Confederation Member. The 769 codepoints are in the "BGP-LS Node Descriptor, Link Descriptor, 770 Prefix Descriptor, and Attribute TLVs" registry. 772 Three new BGP-LS Attribute TLVs: Peer-Node-SID, Peer-Adj-SID and 773 Peer-Set-SID. The codepoints are in the "BGP-LS Node Descriptor, 774 Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry. 776 8.1. New BGP-LS Protocol-ID 778 This document defines a new value in the registry "BGP-LS Protocol- 779 IDs": 781 +----------------------------------------------+ 782 | Codepoint | Description | Status | 783 +----------------------------------------------+ 784 | 7 | BGP | Assigned by IANA | 785 +----------------------------------------------+ 787 8.2. Node Descriptors and Link Attribute TLVs 789 This document defines 5 new TLVs in the registry "BGP-LS Node 790 Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs": 792 o Two new node descriptor TLVs 794 o Three new link attribute TLVs 796 All the new 5 codepoints are in the same registry: "BGP-LS Node 797 Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs". 798 However, the registry is organized in ranges (node descriptors, link 799 descriptors, node attributes, link attributes). 801 The following new Node Descriptors TLVs are defined: 803 +-----------------------------------------------------------+ 804 | Codepoint | Description | Status | 805 +-----------------------------------------------------------+ 806 | 516 | BGP Router-ID | Assigned by IANA | 807 | 517 | BGP Confederation Member | Assigned by IANA | 808 +------------+----------------------------------------------+ 810 The following new Link Attribute TLVs are defined: 812 +-----------------------------------------------------------+ 813 | Codepoint | Description | Status | 814 +-----------------------------------------------------------+ 815 | 1101 | Peer-Node-SID | Assigned by IANA | 816 | 1102 | Peer-Adj-SID | Assigned by IANA | 817 | 1103 | Peer-Set-SID | Assigned by IANA | 818 +------------+----------------------------------------------+ 820 9. Manageability Considerations 822 This BGP-LS ([RFC7752]) extensions that are described in this 823 document consists of additional BGP-LS descriptors and TLVs that will 824 follow the same manageability functions of BGP-LS, described in 825 [RFC7752]. 827 The operator MUST be capable of configuring, enabling, disabling the 828 advertisement of each of the Peer-Node-SID, Peer-Adj-SID and Peer- 829 Set-SID as well as to control which information is advertised to 830 which internal or external peer. This is not different from what is 831 required by a BGP speaker in terms of information origination and 832 advertisement. In addition, the advertisement of EPE information 833 MUST conform to standard BGP advertisement and propagation rules 834 (iBGP, eBGP, Route-Reflectors, Confederations). 836 10. Security Considerations 838 [RFC7752] defines BGP-LS NLRIs to which the extensions defined in 839 this document apply. 841 The Security Section of [RFC7752] also applies to: 843 o New Node Descriptors Sub-TLVs: BGP-Router-ID and BGP- 844 Confederation-Member; 846 o New BGP-LS Attributes TLVs: Peer-Node-SID, Peer-Adj-SID and Peer- 847 Set-SID. 849 11. Contributors 851 Acee Lindem gave a substantial contribution to this document. 853 12. Acknowledgements 855 The authors would like to thank Jakob Heitz, Howard Yang, Hannes 856 Gredler, Peter Psenak, Ketan Jivan Talaulikar, Arjun Sreekantiah and 857 Bruno Decraene for their feedback and comments. 859 13. References 861 13.1. Normative References 863 [I-D.ietf-spring-segment-routing] 864 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 865 and R. Shakir, "Segment Routing Architecture", draft-ietf- 866 spring-segment-routing-11 (work in progress), February 867 2017. 869 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 870 Requirement Levels", BCP 14, RFC 2119, 871 DOI 10.17487/RFC2119, March 1997, 872 . 874 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 875 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 876 DOI 10.17487/RFC4271, January 2006, 877 . 879 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 880 System Confederations for BGP", RFC 5065, 881 DOI 10.17487/RFC5065, August 2007, 882 . 884 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 885 in Support of Generalized Multi-Protocol Label Switching 886 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 887 . 889 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 890 Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, 891 June 2011, . 893 13.2. Informative References 895 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 896 Previdi, S., Psenak, P., Filsfils, C., Gredler, H., Chen, 897 M., and j. jefftant@gmail.com, "BGP Link-State extensions 898 for Segment Routing", draft-ietf-idr-bgp-ls-segment- 899 routing-ext-01 (work in progress), February 2017. 901 [I-D.ietf-spring-segment-routing-central-epe] 902 Filsfils, C., Previdi, S., Aries, E., and D. Afanasiev, 903 "Segment Routing Centralized BGP Egress Peer Engineering", 904 draft-ietf-spring-segment-routing-central-epe-05 (work in 905 progress), March 2017. 907 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 908 S. Ray, "North-Bound Distribution of Link-State and 909 Traffic Engineering (TE) Information Using BGP", RFC 7752, 910 DOI 10.17487/RFC7752, March 2016, 911 . 913 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 914 Code: The Implementation Status Section", BCP 205, 915 RFC 7942, DOI 10.17487/RFC7942, July 2016, 916 . 918 Authors' Addresses 920 Stefano Previdi (editor) 921 Cisco Systems, Inc. 922 Via Del Serafico, 200 923 Rome 00142 924 Italy 926 Email: sprevidi@cisco.com 928 Clarence Filsfils 929 Cisco Systems, Inc. 930 Brussels 931 BE 933 Email: cfilsfil@cisco.com 935 Keyur Patel 936 Arrcus, Inc. 938 Email: Keyur@arrcus.com 940 Saikat Ray 941 Individual Contributor 943 Email: raysaikat@gmail.com 944 Jie Dong 945 Huawei Technologies 946 Huawei Campus, No. 156 Beiqing Rd. 947 Beijing 100095 948 China 950 Email: jie.dong@huawei.com 952 Mach (Guoyi) Chen 953 Huawei Technologies 954 Huawei Campus, No. 156 Beiqing Rd. 955 Beijing 100095 956 China 958 Email: mach.chen@huawei.com