idnits 2.17.1 draft-ietf-idr-bgpls-segment-routing-epe-08.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 (February 15, 2017) is 2621 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-10 == Outdated reference: A later version (-10) exists of draft-ietf-spring-segment-routing-central-epe-03 -- 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: August 19, 2017 K. Patel 6 Arrcus, Inc. 7 J. Dong 8 M. Chen 9 Huawei Technologies 10 February 15, 2017 12 Segment Routing BGP Egress Peer Engineering BGP-LS Extensions 13 draft-ietf-idr-bgpls-segment-routing-epe-08 15 Abstract 17 Segment Routing (SR) leverages source routing. A node steers a 18 packet through a controlled set of instructions, called segments, by 19 prepending the packet with an SR header. A segment can represent any 20 instruction, topological or service-based. SR allows to enforce a 21 flow through any topological path and service chain while maintaining 22 per-flow state only at the ingress node of the SR domain. 24 The Segment Routing architecture can be directly applied to the MPLS 25 dataplane with no change on the forwarding plane. It requires minor 26 extension to the existing link-state routing protocols. 28 This document outline a BGP-LS extension for exporting BGP peering 29 node topology information (including its peers, interfaces and 30 peering ASs) in a way that is exploitable in order to compute 31 efficient BGP Peering Engineering policies and strategies. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on August 19, 2017. 56 Copyright Notice 58 Copyright (c) 2017 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Segment Routing Documents . . . . . . . . . . . . . . . . . . 3 75 3. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 4 76 4. Link NLRI for BGP-EPE Connectivity Description . . . . . . . 5 77 4.1. BGP Router ID and Member ASN . . . . . . . . . . . . . . 5 78 4.2. BGP-EPE Node Descriptors . . . . . . . . . . . . . . . . 6 79 4.3. Link Attributes . . . . . . . . . . . . . . . . . . . . . 7 80 5. Peer Node and Peer Adjacency Segments . . . . . . . . . . . . 9 81 5.1. Peer Node Segment (Peer-Node-SID) . . . . . . . . . . . . 9 82 5.2. Peer Adjacency Segment (Peer-Adj-SID) . . . . . . . . . . 10 83 5.3. Peer Set Segment . . . . . . . . . . . . . . . . . . . . 11 84 6. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 12 85 6.1. Reference Diagram . . . . . . . . . . . . . . . . . . . . 12 86 6.2. Peer Node Segment for Node D . . . . . . . . . . . . . . 14 87 6.3. Peer Node Segment for Node H . . . . . . . . . . . . . . 14 88 6.4. Peer Node Segment for Node E . . . . . . . . . . . . . . 14 89 6.5. Peer Adjacency Segment for Node E, Link 1 . . . . . . . . 15 90 6.6. Peer Adjacency Segment for Node E, Link 2 . . . . . . . . 15 91 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 93 8.1. New BGP-LS Protocol-ID . . . . . . . . . . . . . . . . . 17 94 8.2. Node Descriptors and Link Attribute TLVs . . . . . . . . 17 95 9. Manageability Considerations . . . . . . . . . . . . . . . . 18 96 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 97 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 98 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 99 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 101 13.2. Informative References . . . . . . . . . . . . . . . . . 19 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 104 1. Introduction 106 Segment Routing (SR) leverages source routing. A node steers a 107 packet through a controlled set of instructions, called segments, by 108 prepending the packet with an SR header. A segment can represent any 109 instruction, topological or service-based. SR allows to enforce a 110 flow through any topological path and service chain while maintaining 111 per-flow state only at the ingress node of the SR domain. 113 The Segment Routing architecture can be directly applied to the MPLS 114 dataplane with no change on the forwarding plane. It requires minor 115 extension to the existing link-state routing protocols. 117 This document outline a BGP-LS extension for exporting BGP peering 118 node topology information (including its peers, interfaces and 119 peering ASs) in a way that is exploitable in order to compute 120 efficient BGP Egress Peer Engineering (BGP-EPE) policies and 121 strategies. 123 This document defines new types of segments: a Peer Node segment 124 describing the BGP session between two nodes; a Peer Adjacency 125 Segment describing the link (one or more) that is used by the BGP 126 session; the Peer Set Segment describing an arbitrary set of sessions 127 or links between the local BGP node and its peers. 129 While an egress point topology usually refers to eBGP sessions 130 between external peers, there's nothing in the extensions defined in 131 this document that would prevent the use of these extensions in the 132 context of iBGP sessions. 134 2. Segment Routing Documents 136 The main reference for this document is the SR architecture defined 137 in [I-D.ietf-spring-segment-routing]. 139 The Segment Routing BGP Egress Peer Engineering (BGP-EPE) 140 architecture is described in 141 [I-D.ietf-spring-segment-routing-central-epe]. 143 3. BGP Peering Segments 145 As defined in [I-D.ietf-spring-segment-routing-central-epe], an BGP- 146 EPE enabled Egress PE node MAY advertise segments corresponding to 147 its attached peers. These segments are called BGP peering segments 148 or BGP Peering SIDs. In case of eBGP, they enable the expression of 149 source-routed inter-domain paths. 151 An ingress border router of an AS may compose a list of segments to 152 steer a flow along a selected path within the AS, towards a selected 153 egress border router C of the AS and through a specific peer. At 154 minimum, a BGP-EPE policy applied at an ingress PE involves two 155 segments: the Node SID of the chosen egress PE and then the BGP 156 Peering Segment for the chosen egress PE peer or peering interface. 158 This document defines the BGP-EPE Peering Segments: 160 o Peer Node Segment (Peer-Node-SID) 162 o Peer Adjacency Segment (Peer-Adj-SID) 164 o Peer Set Segment (Peer-Set-SID) 166 Each BGP session MUST be described by a Peer Node Segment. The 167 description of the BGP session MAY be augmented by additional 168 Adjacency Segments. Finally, each Peer Node Segment and Peer 169 Adjacency Segment MAY be part of the same group/set so to be able to 170 group EPE resources under a common Peer-Set Segment Identifier (SID). 172 Therefore, when the extensions defined in this document are applied 173 to the use case defined in 174 [I-D.ietf-spring-segment-routing-central-epe]: 176 o One Peer Node Segment MUST be present. 178 o One or more Peer Adjacency Segments MAY be present. 180 o Each of the Peer Node and Peer Adjacency Segment MAY use the same 181 Peer-Set. 183 While an egress point topology usually refers to eBGP sessions 184 between external peers, there's nothing in the extensions defined in 185 this document that would prevent the use of these extensions in the 186 context of iBGP sessions. 188 4. Link NLRI for BGP-EPE Connectivity Description 190 This section describes the NLRI used for describing the connectivity 191 of the BGP Egress router. The connectivity is based on links and 192 remote peers/ASs and therefore the existing Link-Type NLRI (defined 193 in [RFC7752]) is used. A new Protocol ID is used: BGP (codepoint to 194 be assigned by IANA). 196 The use of a new Protocol-ID allows separation and differentiation 197 between the NLRIs carrying BGP-EPE descriptors from the NLRIs 198 carrying IGP link-state information as defined in [RFC7752]. The 199 Link NLRI Type uses descriptors and attributes already defined in 200 [RFC7752] in addition to new TLVs defined in the following sections 201 of this document. 203 The extensions defined in this document apply to both internal and 204 external BGP-LS EPE advertisements. 206 [RFC7752] defines Link NLRI Type is as follows: 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+ 211 | Protocol-ID | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Identifier | 214 | (64 bits) | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 // Local Node Descriptors // 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 // Remote Node Descriptors // 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 // Link Descriptors // 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Node Descriptors and Link Descriptors are defined in [RFC7752]. 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: TBD2 (to be assigned by IANA from the registry "BGP-LS 232 Node Descriptor, Link Descriptor, Prefix Descriptor, and 233 Attribute TLVs"). 235 Length: 4 octets 236 Value: 4 octet unsigned integer representing the BGP Identifier 237 as defined in [RFC4271] and [RFC6286]. 239 o Confederation Member ASN (Member-ASN) 241 Type: TBD3 (to be assigned by IANA from the registry "BGP-LS 242 Node Descriptor, Link Descriptor, Prefix Descriptor, and 243 Attribute TLVs"). 245 Length: 4 octets 247 Value: 4 octet unsigned integer representing the Member ASN 248 inside the Confederation.[RFC5065]. 250 4.2. BGP-EPE Node Descriptors 252 The following Node Descriptors Sub-TLVs MUST appear in the Link NLRI 253 as Local Node Descriptors: 255 o BGP Router ID, which contains the BGP Identifier of the local BGP- 256 EPE capable node. 258 o Autonomous System Number, which contains the local ASN or local 259 confederation identifier (ASN) if confederations are used. 261 o BGP-LS Identifier. 263 It has to be noted that [RFC6286] (section 2.1) requires the BGP 264 identifier (router-id) to be unique within an Autonomous System. 265 Therefore, the tuple is globally unique. 267 The following Node Descriptors Sub-TLVs MAY appear in the Link NLRI 268 as Local Node Descriptors: 270 o Member-ASN, which contains the ASN of the confederation member 271 (when BGP confederations are used). 273 o Node Descriptors as defined in [RFC7752]. 275 The following Node Descriptors Sub-TLVs MUST appear in the Link NLRI 276 as Remote Node Descriptors: 278 o BGP Router ID, which contains the BGP Identifier of the peer node. 280 o Autonomous System Number, which contains the peer ASN or the peer 281 confederation identifier (ASN), if confederations are used. 283 The following Node Descriptors Sub-TLVs MAY appear in the Link NLRI 284 as Remote Node Descriptors: 286 o Member-ASN, which contains the ASN of the confederation member 287 (when BGP confederations are used). 289 o Node Descriptors as defined in defined in [RFC7752]. 291 4.3. Link Attributes 293 The following BGP-LS Link attributes TLVs are used with the Link 294 NLRI: 296 +----------+---------------------------+----------+ 297 | TLV Code | Description | Length | 298 | Point | | | 299 +----------+---------------------------+----------+ 300 | TBD4 | Peer Node Segment | variable | 301 | | Identifier (Peer-Node-SID)| | 302 | TBD5 | Peer Adjacency Segment | variable | 303 | | Identifier (Peer-Adj-SID) | | 304 | TBD6 | Peer Set Segment | variable | 305 | | Identifier (Peer-Set-SID) | | 306 +----------+---------------------------+----------+ 308 Figure 1: BGP-LS TLV code points for BGP-EPE 310 Peer-Node-SID, Peer-Adj-SID and Peer-Set-SID have all the same format 311 defined here below: 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Type | Length | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Flags | Weight | Reserved | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | SID/Label/Index (variable) | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 where: 325 Figure 2 327 o Type: TBD4 or TBD5 or TBD6, to be assigned by IANA. 329 o Length: variable. 331 o Flags: following flags have been defined: 333 0 1 2 3 4 5 6 7 334 +-+-+-+-+-+-+-+-+ 335 |V|L| | 336 +-+-+-+-+-+-+-+-+ 338 where: 340 * V-Flag: Value flag. If set, then the Adj-SID carries a value. 341 By default the flag is SET. 343 * L-Flag: Local Flag. If set, then the value/index carried by 344 the Adj-SID has local significance. By default the flag is 345 SET. 347 * Other bits: MUST be zero when originated and ignored when 348 received. 350 o Weight: 1 octet. The value represents the weight of the SID for 351 the purpose of load balancing. An example use of the weight is 352 described in [I-D.ietf-spring-segment-routing]. 354 o SID/Index/Label. According to the TLV length and to the V and L 355 flags settings, it contains either: 357 * A 3 octet local label where the 20 rightmost bits are used for 358 encoding the label value. In this case the V and L flags MUST 359 be set. 361 * A 4 octet index defining the offset in the SID/Label space 362 advertised by this router using the encodings defined in 363 Section 3.1. In this case V and L flags MUST be unset. 365 * A 16 octet IPv6 address. In this case the V flag MUST be set. 366 The L flag MUST be unset if the IPv6 address is globally 367 unique. 369 The values of the Peer-Node-SID, Peer-Adj-SID and Peer-Set-SID Sub- 370 TLVs SHOULD be persistent across router restart. 372 The Peer-Node-SID MUST be present when BGP-LS is used for the use 373 case described in [I-D.ietf-spring-segment-routing-central-epe] and 374 MAY be omitted for other use cases. 376 The Peer-Adj-SID and Peer-Set-SID SubTLVs MAY be present when BGP-LS 377 is used for the use case described in 379 [I-D.ietf-spring-segment-routing-central-epe] and MAY be omitted for 380 other use cases. 382 In addition, BGP-LS Nodes and Link Attributes, as defined in 383 [RFC7752] MAY be inserted in order to advertise the characteristics 384 of the link. 386 5. Peer Node and Peer Adjacency Segments 388 In this section the following Peer Segments are defined: 390 Peer Node Segment (Peer-Node-SID) 392 Peer Adjacency Segment (Peer-Adj-SID) 394 Peer Set Segment (Peer-Set-SID) 396 The Peer Node, Peer Adjacency and Peer Set segments can be either a 397 local or a global segment (depending on the setting of the V and L 398 flags defined in Figure 2. For example, when BGP-EPE is used in the 399 context of a SR network over the IPv6 dataplane, it is likely the 400 case that the IPv6 addresses used as SIDs will be global. 402 5.1. Peer Node Segment (Peer-Node-SID) 404 The Peer Node Segment describes the BGP session peer (neighbor). It 405 MUST be present when describing a BGP-EPE topology as defined in 406 [I-D.ietf-spring-segment-routing-central-epe]. The Peer Node Segment 407 is encoded within the BGP-LS Link NLRI specified in Section 4. 409 The Peer Node Segment, at the BGP node advertising it, has the 410 following semantic: 412 o SR header operation: NEXT (as defined in 413 [I-D.ietf-spring-segment-routing]). 415 o Next-Hop: the connected peering node to which the segment is 416 related. 418 The Peer Node Segment is advertised with a Link NLRI, where: 420 o Local Node Descriptors contains 422 Local BGP Router ID of the BGP-EPE enabled egress PE. 423 Local ASN. 424 BGP-LS Identifier. 426 o Remote Node Descriptors contains 427 Peer BGP Router ID (i.e.: the peer BGP ID used in the BGP session). 428 Peer ASN. 430 o Link Descriptors Sub-TLVs, as defined in [RFC7752], contain the 431 addresses used by the BGP session: 433 * IPv4 Interface Address (Sub-TLV 259) contains the BGP session 434 IPv4 local address. 436 * IPv4 Neighbor Address (Sub-TLV 260) contains the BGP session 437 IPv4 peer address. 439 * IPv6 Interface Address (Sub-TLV 261) contains the BGP session 440 IPv6 local address. 442 * IPv6 Neighbor Address (Sub-TLV 262) contains the BGP session 443 IPv6 peer address. 445 o Link Attribute contains the Peer-Node-SID TLV as defined in 446 Section 4.3. 448 o In addition, BGP-LS Link Attributes, as defined in [RFC7752], MAY 449 be inserted in order to 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 BGP-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 [RFC7752], MUST contain 475 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 [RFC7752], 482 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 [RFC7752], MAY be 502 inserted in order to advertise the characteristics of the link. 504 5.3. Peer Set Segment 506 The Peer Adjacency Segment, at the BGP node advertising it, has the 507 following semantic: 509 o SR header operation: NEXT (as defined in 510 [I-D.ietf-spring-segment-routing]). 512 o Next-Hop: load balance across any connected interface to any peer 513 in the related set. 515 The Peer Set Segment is advertised within a Link NLRI (describing a 516 Peer Node Segment or a Peer Adjacency segment) as a BGP-LS attribute. 518 The Peer Set Attribute contains the Peer-Set-SID TLV, defined in 519 Section 4.3 identifying the set of which the Peer Node Segment or 520 Peer Adjacency Segment is a member. 522 6. Illustration 524 6.1. Reference Diagram 526 The following reference diagram is used throughout this document. 527 The solution is illustrated for IPv4 with MPLS-based segments and the 528 BGP-EPE topology is based on eBGP sessions between external peers. 530 As stated in Section 3, the solution illustrated hereafter is equally 531 applicable to an iBGP session topology. In other words, the solution 532 also applies to the case where C, D, H, and E are in the same AS and 533 run iBGP sessions between each other. 535 +------+ 536 | | 537 +---D F 538 +---------+ / | AS 2 |\ +------+ 539 | X |/ +------+ \ | Z |---L/8 540 A C---+ \| | 541 | |\\ \ +------+ /| AS 4 |---M/8 542 | AS1 | \\ +-H |/ +------+ 543 | | \\ | G 544 +----P----+ +===E AS 3 | 545 | +--Q---+ 546 | | 547 +----------------+ 549 Figure 3: Reference Diagram 551 IPv4 addressing: 553 o C's IPv4 address of interface to D: 1.0.1.1/24, D's interface: 554 1.0.1.2/24 556 o C's IPv4 address of interface to H: 1.0.2.1/24, H's interface: 557 1.0.2.2/24 559 o C's IPv4 address of upper interface to E: 1.0.3.1, E's interface: 560 1.0.3.2/24 562 o C's local identifier of upper interface to E: 0.0.0.1.0.0.0.0 564 o C's IPv4 address of lower interface to E: 1.0.4.1/24, E's 565 interface: 1.0.4.2/24 567 o C's local identifier of lower interface to E: 0.0.0.2.0.0.0.0 569 o Loopback of E used for eBGP multi-hop peering to C: 1.0.5.2/32 570 o C's loopback is 3.3.3.3/32 with SID 64 572 BGP Router-IDs are C, D, H and E. 574 o C's BGP Router-ID: 3.3.3.3 576 o D's BGP Router-ID: 4.4.4.4 578 o E's BGP Router-ID: 5.5.5.5 580 o H's BGP Router-ID: 6.6.6.6 582 C's BGP peering: 584 o Single-hop eBGP peering with neighbor 1.0.1.2 (D) 586 o Single-hop eBGP peering with neighbor 1.0.2.2 (H) 588 o Multi-hop eBGP peering with E on ip address 1.0.5.2 (E) 590 C's resolution of the multi-hop eBGP session to E: 592 o Static route 1.0.5.2/32 via 1.0.3.2 594 o Static route 1.0.5.2/32 via 1.0.4.2 596 Node C configuration is such that: 598 o A Peer Node segment (Peer-Node-SID) is allocated to each peer (D, 599 H and E). 601 o An Peer Adjacency segment (Peer-Adj-SID) is defined for each 602 recursing interface to a multi-hop peer (CE upper and lower 603 interfaces). 605 o A Peer Set segment (Peer-Set-SID) is defined to include all peers 606 in AS3 (peers H and E). 608 Local BGP-LS Identifier in router C is set to 10000. 610 The Link NLRI Type is used in order to encode C's connectivity. The 611 Link NLRI uses the new Protocol-ID value (to be assigned by IANA) 613 Once the BGP-LS update is originated by C, it may be advertised to 614 internal (iBGP) as well as external (eBGP) neighbors supporting the 615 BGP-LS EPE extensions defined in this document. 617 6.2. Peer Node Segment for Node D 619 Descriptors: 621 o Local Node Descriptors (BGP Router-ID, local ASN, BGP-LS 622 Identifier): 3.3.3.3 , AS1, 10000 624 o Remote Node Descriptors (BGP Router-ID, peer ASN): 4.4.4.4, AS2 626 o Link Descriptors (BGP session IPv4 local address, BGP session IPv4 627 neighbor address): 1.0.1.1, 1.0.1.2 629 Attributes: 631 o Peer-Node-SID: 1012 633 o Link Attributes: see section 3.3.2 of [RFC7752] 635 6.3. Peer Node Segment for Node H 637 Descriptors: 639 o Local Node Descriptors (BGP Router-ID, ASN, BGPLS Identifier): 640 3.3.3.3 , AS1, 10000 642 o Remote Node Descriptors (BGP Router-ID ASN): 6.6.6.6, AS3 644 o Link Descriptors (BGP session IPv4 local address, BGP session IPv4 645 peer address): 1.0.2.1, 1.0.2.2 647 Attributes: 649 o Peer-Node-SID: 1022 651 o Peer-Set-SID: 1060 653 o Link Attributes: see section 3.3.2 of [RFC7752] 655 6.4. Peer Node Segment for Node E 657 Descriptors: 659 o Local Node Descriptors (BGP Router-ID, ASN, BGP-LS Identifier): 660 3.3.3.3 , AS1, 10000 662 o Remote Node Descriptors (BGP Router-ID, ASN): 5.5.5.5, AS3 663 o Link Descriptors (BGP session IPv4 local address, BGP session IPv4 664 peer address): 3.3.3.3, 1.0.5.2 666 Attributes: 668 o Peer-Node-SID: 1052 670 o Peer-Set-SID: 1060 672 6.5. Peer Adjacency Segment for Node E, Link 1 674 Descriptors: 676 o Local Node Descriptors (BGP Router-ID, ASN, BGP-LS Identifier): 677 3.3.3.3 , AS1, 10000 679 o Remote Node Descriptors (BGP Router-ID, ASN): 5.5.5.5, AS3 681 o Link Descriptors (local interface identifier, IPv4 peer interface 682 address): 0.0.0.1.0.0.0.0 , 1.0.3.2 684 Attributes: 686 o Peer-Adj-SID: 1032 688 o LinkAttributes: see section 3.3.2 of [RFC7752] 690 6.6. Peer Adjacency Segment for Node E, Link 2 692 Descriptors: 694 o Local Node Descriptors (BGP Router-ID, ASN, BGP-LS Identifier): 695 3.3.3.3 , AS1, 10000 697 o Remote Node Descriptors (BGP Router-ID, ASN): 5.5.5.5, AS3 699 o Link Descriptors (local interface identifier, IPv4 peer interface 700 address): 0.0.0.2.0.0.0.0 , 1.0.4.2 702 Attributes: 704 o Peer-Adj-SID: 1042 706 o LinkAttributes: see section 3.3.2 of [RFC7752] 708 7. Implementation Status 710 Note to RFC Editor: Please remove this section prior to publication, 711 as well as the reference to RFC 7942. 713 This section records the status of known implementations of the 714 protocol defined by this specification at the time of posting of this 715 Internet-Draft, and is based on a proposal described in [RFC7942]. 716 The description of implementations in this section is intended to 717 assist the IETF in its decision processes in progressing drafts to 718 RFCs. Please note that the listing of any individual implementation 719 here does not imply endorsement by the IETF. Furthermore, no effort 720 has been spent to verify the information presented here that was 721 supplied by IETF contributors. This is not intended as, and must not 722 be construed to be, a catalog of available implementations or their 723 features. Readers are advised to note that other implementations may 724 exist. 726 According to [RFC7942], "this will allow reviewers and working groups 727 to assign due consideration to documents that have the benefit of 728 running code, which may serve as evidence of valuable experimentation 729 and feedback that have made the implemented protocols more mature. 730 It is up to the individual working groups to use this information as 731 they see fit". 733 Several early implementations exist and will be reported in detail in 734 a forthcoming version of this document. For purposes of early 735 interoperability testing, when no FCFS code point was available, 736 implementations have made use of the following values: 738 +---------------------------------------+ 739 | Codepoint | Description | 740 +---------------------------------------+ 741 | 7 | Protocol-ID BGP | 742 | 516 | BGP Router ID | 743 | 517 | BGP Confederation Member | 744 | 1101 | Peer-Node-SID | 745 | 1102 | Peer-Adj-SID | 746 | 1103 | Peer-Set-SID | 747 +------------+--------------------------+ 749 It will ease implementation interoperability and deployment if the 750 value could be preserved. However, when IANA-assigned values are 751 available, implementations will be updated to use them. 753 8. IANA Considerations 755 This document defines: 757 A new Protocol-ID: BGP. The codepoint is from the "BGP-LS 758 Protocol-IDs" registry. 760 Two new TLVs: BGP-Router-ID and BGP Confederation Member. The 761 codepoints are in the "BGP-LS Node Descriptor, Link Descriptor, 762 Prefix Descriptor, and Attribute TLVs" registry. 764 Three new BGP-LS Attribute TLVs: Peer-Node-SID, Peer-Adj-SID and 765 Peer-Set-SID. The codepoints are in the "BGP-LS Node Descriptor, 766 Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry. 768 8.1. New BGP-LS Protocol-ID 770 This document defines a new value in the registry "BGP-LS Protocol- 771 IDs": 773 +---------------------------------------+ 774 | Codepoint | Description | 775 +---------------------------------------+ 776 | TBD1 | BGP | 777 +---------------------------------------+ 779 8.2. Node Descriptors and Link Attribute TLVs 781 This document defines 5 new TLVs in the registry "BGP-LS Node 782 Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs": 784 o Two new node descriptor TLVs 786 o Three new link attribute TLVs 788 All the new 5 codepoints are in the same registry: "BGP-LS Node 789 Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs". 790 However, the registry is organized in ranges (node descriptors, link 791 descriptors, node attributes, link attributes). The allocation 792 should be done accordingly. 794 The following new Node Descriptors TLVs are defined: 796 +---------------------------------------+ 797 | Codepoint | Description | 798 +---------------------------------------+ 799 | TBD2 | BGP Router ID | 800 | TBD3 | BGP Confederation Member | 801 +------------+--------------------------+ 803 The following new Link Attribute TLVs are defined: 805 +---------------------------------------+ 806 | Codepoint | Description | 807 +---------------------------------------+ 808 | TBD4 | Peer-Node-SID | 809 | TBD5 | Peer-Adj-SID | 810 | TBD6 | Peer-Set-SID | 811 +------------+--------------------------+ 813 9. Manageability Considerations 815 This BGP-LS ([RFC7752]) extensions that are described in this 816 document consists of additional BGP-LS descriptors and TLVs that will 817 follow the same manageability functions of BGP-LS, described in 818 [RFC7752]. 820 The operator MUST be capable of configuring, enabling, disabling the 821 advertisement of each of the Peer-Node-SID, Peer-Adj-SID and Peer- 822 Set-SID as well as to control which information is advertised to 823 which internal or external peer. This is not different from what is 824 required by a BGP speaker in terms of information origination and 825 advertisement. In addition, the advertisement of EPE information 826 MUST conform to standard BGP advertisement and propagation rules 827 (iBGP, eBGP, Route-Reflectors, Confederations). 829 10. Security Considerations 831 [RFC7752] defines BGP-LS NLRIs to which the extensions defined in 832 this document apply. 834 The Security Section of [RFC7752] also applies to: 836 o New Node Descriptors Sub-TLVs: BGP-Router-ID and BGP- 837 Confederation-Member; 839 o New BGP-LS Attributes TLVs: Peer-Node-SID, Peer-Adj-SID and Peer- 840 Set-SID. 842 11. Contributors 844 Saikat Ray and Acee Lindem gave a substantial contribution to this 845 document. 847 12. Acknowledgements 849 The authors would like to thank Jakob Heitz, Howard Yang, Hannes 850 Gredler, Peter Psenak, Ketan Jivan Talaulikar, and Arjun Sreekantiah 851 for their feedback and comments. 853 13. References 855 13.1. Normative References 857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 858 Requirement Levels", BCP 14, RFC 2119, 859 DOI 10.17487/RFC2119, March 1997, 860 . 862 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 863 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 864 DOI 10.17487/RFC4271, January 2006, 865 . 867 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 868 System Confederations for BGP", RFC 5065, 869 DOI 10.17487/RFC5065, August 2007, 870 . 872 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 873 in Support of Generalized Multi-Protocol Label Switching 874 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 875 . 877 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 878 Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, 879 June 2011, . 881 13.2. Informative References 883 [I-D.ietf-spring-segment-routing] 884 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 885 and R. Shakir, "Segment Routing Architecture", draft-ietf- 886 spring-segment-routing-10 (work in progress), November 887 2016. 889 [I-D.ietf-spring-segment-routing-central-epe] 890 Filsfils, C., Previdi, S., Aries, E., and D. Afanasiev, 891 "Segment Routing Centralized BGP Peer Engineering", draft- 892 ietf-spring-segment-routing-central-epe-03 (work in 893 progress), November 2016. 895 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 896 S. Ray, "North-Bound Distribution of Link-State and 897 Traffic Engineering (TE) Information Using BGP", RFC 7752, 898 DOI 10.17487/RFC7752, March 2016, 899 . 901 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 902 Code: The Implementation Status Section", BCP 205, 903 RFC 7942, DOI 10.17487/RFC7942, July 2016, 904 . 906 Authors' Addresses 908 Stefano Previdi (editor) 909 Cisco Systems, Inc. 910 Via Del Serafico, 200 911 Rome 00142 912 Italy 914 Email: sprevidi@cisco.com 916 Clarence Filsfils 917 Cisco Systems, Inc. 918 Brussels 919 BE 921 Email: cfilsfil@cisco.com 923 Keyur Patel 924 Arrcus, Inc. 926 Email: Keyur@arrcus.com 927 Jie Dong 928 Huawei Technologies 929 Huawei Campus, No. 156 Beiqing Rd. 930 Beijing 100095 931 China 933 Email: jie.dong@huawei.com 935 Mach (Guoyi) Chen 936 Huawei Technologies 937 Huawei Campus, No. 156 Beiqing Rd. 938 Beijing 100095 939 China 941 Email: mach.chen@huawei.com