idnits 2.17.1 draft-ietf-idr-bgp-prefix-sid-16.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 (February 13, 2018) is 2264 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) -- Looks like a reference, but probably isn't: '100' on line 377 -- Looks like a reference, but probably isn't: '199' on line 377 -- Looks like a reference, but probably isn't: '1000' on line 378 -- Looks like a reference, but probably isn't: '1099' on line 378 -- Looks like a reference, but probably isn't: '500' on line 379 -- Looks like a reference, but probably isn't: '599' on line 379 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-11 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-04 == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-14 == Outdated reference: A later version (-11) exists of draft-ietf-spring-segment-routing-msdc-08 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR S. Previdi, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track A. Lindem 5 Expires: August 17, 2018 Cisco Systems 6 A. Sreekantiah 8 H. Gredler 9 RtBrick Inc. 10 February 13, 2018 12 Segment Routing Prefix SID extensions for BGP 13 draft-ietf-idr-bgp-prefix-sid-16 15 Abstract 17 The Segment Routing (SR) architecture allows a node to steer a packet 18 flow through any topological path and service chain by leveraging 19 source routing. The ingress node prepends an SR header to a packet 20 containing a set of segment identifiers (SID). Each SID represents a 21 topological or a service-based instruction. Per-flow state is 22 maintained only on the ingress node of the SR domain. 24 This document defines an optional, transitive BGP attribute for 25 announcing BGP Prefix Segment Identifiers (BGP Prefix-SID) 26 information. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 32 "OPTIONAL" in this document are to be interpreted as described in BCP 33 14 [RFC2119] [RFC8174] when, and only when, they appear in all 34 capitals, as shown here. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on August 17, 2018. 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. BGP-Prefix-SID . . . . . . . . . . . . . . . . . . . . . . . 4 72 2.1. MPLS BGP Prefix SID . . . . . . . . . . . . . . . . . . . 4 73 2.2. IPv6 Prefix Segment . . . . . . . . . . . . . . . . . . . 5 74 3. BGP Prefix-SID Attribute . . . . . . . . . . . . . . . . . . 5 75 3.1. Label-Index TLV . . . . . . . . . . . . . . . . . . . . . 6 76 3.2. IPv6 SID . . . . . . . . . . . . . . . . . . . . . . . . 7 77 3.3. Originator SRGB TLV . . . . . . . . . . . . . . . . . . . 7 78 4. Receiving BGP Prefix-SID Attribute . . . . . . . . . . . . . 9 79 4.1. MPLS Dataplane: Labeled Unicast . . . . . . . . . . . . . 9 80 4.2. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . . . 11 81 5. Advertising BGP Prefix-SID Attribute . . . . . . . . . . . . 12 82 5.1. MPLS Dataplane: Labeled Unicast . . . . . . . . . . . . . 12 83 5.2. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . . . 13 84 6. Error Handling of BGP Prefix-SID Attribute . . . . . . . . . 13 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 8. Manageability Considerations . . . . . . . . . . . . . . . . 14 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 88 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 89 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 92 12.2. Informative References . . . . . . . . . . . . . . . . . 17 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 95 1. Introduction 97 The Segment Routing (SR) architecture leverages the source routing 98 paradigm. A group of inter-connected nodes that use SR forms an SR 99 domain. A segment represents either a topological instruction such 100 as "go to prefix P following shortest path" or a service instruction. 101 Other types of segments may be defined in the future. 103 A segment is identified through a Segment Identifier (SID). 104 Typically, the ingress node of the SR domain prepends an SR header 105 containing segments identifiers (SIDs) to an incoming packet. 107 As described in [I-D.ietf-spring-segment-routing], when SR is applied 108 to the MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]), the 109 SID consists of a label, while when SR is applied to the IPv6 110 dataplane the SID consists of an IPv6 address. 112 A BGP-Prefix Segment (and its BGP Prefix-SID) is a BGP segment 113 attached to a BGP prefix. A BGP Prefix-SID is always a global SID 114 ([I-D.ietf-spring-segment-routing]) within the SR/BGP domain (i.e., 115 the set of Autonomous Systems under a common administration and 116 control and where SR is used) and identifies an instruction to 117 forward the packet over the ECMP-aware best-path computed by BGP to 118 the related prefix. The BGP Prefix-SID is the identifier of the BGP 119 prefix segment. In this document, we always refer to the BGP segment 120 by the BGP Prefix-SID. 122 This document describes the BGP extension to signal the BGP Prefix- 123 SID. Specifically, this document defines a BGP attribute known as 124 the BGP Prefix-SID attribute and specifies the rules to originate, 125 receive, and handle error conditions for the attribute. 127 The BGP Prefix-SID attribute defined in this document can be attached 128 to prefixes from Address Family Identifier (AFI)/ Subsequent Address 129 Family Identifier (SAFI) combinations: 131 Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC8277]). 133 Multiprotocol BGP ([RFC4760]) unlabeled IPv6 Unicast. 135 Usage of the BGP Prefix-SID attribute for other AFI/SAFI combinations 136 is not defined herein but may be specified in future specifications. 138 [I-D.ietf-spring-segment-routing-msdc] describes example use cases 139 where the BGP Prefix-SID is used for the above AFI/SAFI combinations. 141 It should be noted that: 143 o A BGP Prefix-SID MAY be global between domains when the 144 interconnected domains agree on the SID allocation scheme. 145 Alternatively, when interconnecting domains, the ASBRs of each 146 domain will have to handle the advertisement of unique SIDs. The 147 mechanisms for such interconnection are outside the scope of the 148 protocol extensions defined in this document. 150 o A BGP Prefix-SID MAY be attached to a prefix. In addition, each 151 prefix will likely have a different AS_PATH attribute. This 152 implies that each prefix is advertised individually, reducing the 153 ability to pack BGP advertisements (when sharing common 154 attributes). 156 2. BGP-Prefix-SID 158 The BGP Prefix-SID advertised for BGP prefix P indicates that the 159 segment routed path should be used (as described below) if the BGP 160 best path selects the corresponding Network Layer Reachability 161 Information (NLRI). 163 2.1. MPLS BGP Prefix SID 165 The BGP Prefix-SID is realized on the MPLS dataplane 166 ([I-D.ietf-spring-segment-routing-mpls]) in the following way: 168 The operator assigns a globally unique label index, L_I, to a 169 locally sourced prefix of a BGP speaker N which is advertised to 170 all other BGP speakers in the SR domain. 172 According to [I-D.ietf-spring-segment-routing], each BGP speaker 173 is configured with a label block called the Segment Routing Global 174 Block (SRGB). While [I-D.ietf-spring-segment-routing] recommends 175 using the same SRGB across all the nodes within the SR domain, the 176 SRGB of a node is a local property and could be different on 177 different speakers. The drawbacks of the use case where BGP 178 speakers have different SRGBs are documented in 179 [I-D.ietf-spring-segment-routing] and 180 [I-D.ietf-spring-segment-routing-msdc]. 182 If traffic-engineering within the SR domain is required, each node 183 may also be required to advertise topological information and 184 Peering SIDs for each of its links and peers. This information is 185 required to perform the explicit path computation and to express 186 an explicit path as a list of SIDs. The advertisement of 187 topological information and peer segments (Peer SIDs) is done 188 through [I-D.ietf-idr-bgpls-segment-routing-epe]. 190 If the BGP speakers are not all configured with the same SRGB, and 191 if traffic-engineering within the SR domain is required, each node 192 may be required to advertise its local SRGB in addition to the 193 topological information. 195 This document assumes that BGP-LS is the preferred method for 196 collecting both peer segments (Peer SIDs) and SRGB information 197 through [RFC7752], [I-D.ietf-idr-bgpls-segment-routing-epe], and 198 [I-D.ietf-idr-bgp-ls-segment-routing-ext]. However, as an 199 optional alternative for the advertisement of the local SRGB 200 without the topology nor the peer SIDs, hence without 201 applicability for TE, the Originator SRGB TLV of the prefix-SID 202 attribute is specified in Section 3.3 of this document. 204 As defined in [I-D.ietf-spring-segment-routing], the label index 205 L_I is an offset into the SRGB. Each BGP speaker derives its 206 local MPLS label, L, by adding L_I to the start value of its own 207 SRGB, and programs L in its MPLS dataplane as its incoming/local 208 label for the prefix. It should be noted that while SRGBs and 209 SIDs are advertised using 32-bit values, the derived label is 210 advertised in the 20 right-most bits. See Section 4.1 for more 211 details. 213 The outgoing label for the prefix is found in the NLRI of the 214 Multiprotocol BGP labeled IPv4/IPv6 Unicast prefix advertisement 215 as defined in [RFC8277]. The label index L_I is only used as a 216 hint to derive the local/incoming label. 218 Section 3.1 of this document specifies the Label-Index TLV of the 219 BGP Prefix-SID attribute; this TLV can be used to advertise the 220 label index for a given prefix. 222 In order to advertise the label index of a given prefix P and, 223 optionally, the SRGB, an extension to BGP is needed: the BGP Prefix- 224 SID attribute. This extension is described in subsequent sections. 226 2.2. IPv6 Prefix Segment 228 When SR is used over an IPv6 dataplane, the BGP Prefix-SID consists 229 of an IPv6 address assigned to the BGP speaker. 231 3. BGP Prefix-SID Attribute 233 The BGP Prefix-SID attribute is an optional, transitive BGP path 234 attribute. The attribute type code 40 has been assigned by IANA (see 235 Section 7). 237 The BGP Prefix-SID attribute is defined here to be a set of elements 238 encoded as "Type/Length/Value" tuples (i.e., a set of TLVs). All BGP 239 Prefix-SID attribute TLVs will start with a 1-octet type and a 240 2-octet length. The following TLVs are defined in this document: 242 o Label-Index TLV 244 o IPv6 SID TLV 246 o Originator SRGB TLV 248 The Label-Index and Originator SRGB TLVs are used only when SR is 249 applied to the MPLS dataplane. 251 The IPv6 SID TLV is used only when SR is applied to the IPv6 252 dataplane. 254 For future extensibility, unknown TLVs MUST be ignored and propagated 255 unmodified. 257 3.1. Label-Index TLV 259 The Label-Index TLV MUST be present in the BGP Prefix-SID attribute 260 attached to Labeled IPv4/IPv6 unicast prefixes ([RFC8277]). It MUST 261 be ignored when received for other BGP AFI/SAFI combinations. The 262 Label-Index TLV has the following format: 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Type | Length | RESERVED | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Flags | Label Index | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Label Index | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 where: 276 o Type is 1. 278 o Length: is 7, the total length in octets of the value portion of 279 the TLV. 281 o RESERVED: 8-bit field. MUST be clear on transmission and MUST be 282 ignored on reception. 284 o Flags: 16 bits of flags. None are defined by this document. The 285 flag field MUST be clear on transmission and MUST be ignored on 286 reception. 288 o Label Index: 32-bit value representing the index value in the SRGB 289 space. 291 3.2. IPv6 SID 293 The IPv6 SID TLV MAY be present in the BGP Prefix-SID attribute 294 attached to MP-BGP unlabeled IPv6 unicast prefixes ([RFC4760]). It 295 MUST be ignored for other BGP AFI/SAFI combinations. The IPv6 SID 296 TLV has the following format: 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Type | Length | RESERVED | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | RESERVED | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 305 | | 306 | IPv6 SID (16 octets) | 307 | | 308 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 where: 314 o Type is 2. 316 o Length: is 19, the total length in octets of the value portion of 317 the TLV. 319 o RESERVED: 24-bit field for future use. MUST be clear on 320 transmission and MUST be ignored on reception. 322 o IPv6 SID: 16 octets. 324 3.3. Originator SRGB TLV 326 The Originator SRGB TLV is an optional TLV and has the following 327 format: 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Type | Length | Flags | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Flags | 335 +-+-+-+-+-+-+-+-+ 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | SRGB 1 (6 octets) | 339 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | SRGB n (6 octets) | 345 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 where: 351 o Type is 3. 353 o Length is the total length in octets of the value portion of the 354 TLV: 2 + (multiple of 6). 356 o Flags: 16 bits of flags. None are defined in this document. 357 Flags MUST be clear on transmission and MUST be ignored on 358 reception. 360 o SRGB: 3 octets of base followed by 3 octets of range. Note that 361 the SRGB field MAY appear multiple times. If the SRGB field 362 appears multiple times, the SRGB consists of multiple ranges that 363 are concatenated. 365 The Originator SRGB TLV contains the SRGB of the node originating the 366 prefix to which the BGP Prefix-SID is attached. The Originator SRGB 367 TLV MUST NOT be changed during the propagation of the BGP update. 369 The originator SRGB describes the SRGB of the node where the BGP 370 Prefix SID is attached. It is used to build segment routing policies 371 when different SRGBs are used in the fabric, for example 372 ([I-D.ietf-spring-segment-routing-msdc]). 374 The receiving routers concatenate the ranges and build the Segment 375 Routing Global Block (SRGB) as follows: 377 SRGB = [100, 199] 378 [1000, 1099] 379 [500, 599] 381 The indexes span multiple ranges: 383 index=0 means label 100 384 ... 385 index 99 means label 199 386 index 100 means label 1000 387 index 199 means label 1099 388 ... 389 index 200 means label 500 390 ... 392 The originator SRGB may only appear in a BGP Prefix-SID attribute 393 attached to Labeled IPv4/IPv6 unicast prefixes ([RFC8277]). It MUST 394 be ignored when received for other BGP AFI/SAFI combinations. Since 395 the Label-Index TLV is required for IPv4/IPv6 prefix applicability, 396 the originator SRGB will be ignored if it is not specified consistent 397 with Section 6. 399 4. Receiving BGP Prefix-SID Attribute 401 A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP 402 neighbor residing outside the boundaries of the SR domain MUST 403 discard the attribute unless it is configured to accept the attribute 404 from the EBGP neighbor. A BGP speaker SHOULD log an error for 405 further analysis when discarding an attribute. 407 4.1. MPLS Dataplane: Labeled Unicast 409 A BGP session supporting the Multiprotocol BGP labeled IPv4 or IPv6 410 Unicast ([RFC8277]) AFI/SAFI is required. 412 The BGP Prefix-SID attribute MUST contain the Label-Index TLV and MAY 413 contain the Originator SRGB TLV. A BGP Prefix-SID attribute received 414 without a Label-Index TLV MUST be considered as "invalid" by the 415 receiving speaker. 417 The label index provides the receiving BGP speaker with guidance as 418 to the incoming label that SHOULD be assigned by that BGP speaker. 420 A BGP speaker may be locally configured with an SRGB=[SRGB_Start, 421 SRGB_End]. The preferred method for deriving the SRGB is a matter of 422 local node configuration. 424 The mechanisms through which a given label index value is assigned to 425 a given prefix are outside the scope of this document. 427 Given a label index L_I, we refer to (L = L_I + SRGB_Start) as the 428 derived label. A BGP Prefix-SID attribute is designated 429 "conflicting" for a speaker M if the derived label value L lies 430 outside the SRGB configured on M. Otherwise the Label-Index TLV is 431 designated "acceptable" to speaker M. 433 If multiple different prefixes are received with the same label 434 index, either all or all but one of the different prefixes MUST have 435 their BGP Prefix-SID attribute considered as "conflicting". If one 436 of the different prefixes is considered "acceptable", it is 437 RECOMMENDED that the first prefix using the label index is selected. 439 If multiple valid paths for the same prefix are received from 440 multiple BGP speakers or, in the case of [RFC7911], from the same BGP 441 speaker, and the BGP Prefix-SID attributes do not contain the same 442 label index, then the label index from the best path BGP Prefix-SID 443 attribute SHOULD be chosen with a notable exception being when 444 [RFC5005] is being used to dampen route changes. 446 When a BGP speaker receives a path from a neighbor with an 447 "acceptable" BGP Prefix-SID attribute and that path is selected as 448 the best path, it SHOULD program the derived label as the label for 449 the prefix in its local MPLS dataplane. 451 When a BGP speaker receives a path from a neighbor with an "invalid" 452 or "conflicting" BGP Prefix-SID attribute or when a BGP speaker 453 receives a path from a neighbor with a BGP Prefix-SID attribute but 454 is unable to process it (e.g., local policy disables the 455 functionality), it MUST ignore the BGP Prefix-SID attribute. For the 456 purposes of label allocation, a BGP speaker MUST assign a local (also 457 called dynamic) label (non-SRGB) for such a prefix as per classic 458 Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC8277]) operation. 460 In the case of an "invalid" BGP Prefix-SID attribute, a BGP speaker 461 MUST follow to the error handling rules specified in Section 6. A 462 BGP speaker SHOULD log an error for further analysis. In the case of 463 a "conflicting" BGP Prefix-SID attribute, a BGP speaker SHOULD NOT 464 treat it as error and SHOULD propagate the attribute unchanged. A 465 BGP Speaker SHOULD log a warning for further analysis, i.e., in the 466 case the conflict is not due to a label index transition. 468 When a BGP Prefix-SID attribute changes and transitions from 469 "conflicting" to "acceptable", the BGP Prefix-SID attributes for 470 other prefixes may also transition to "acceptable" as well. 471 Implementations SHOULD assure all impacted prefixes revert to using 472 the label indices corresponding to these newly "acceptable" BGP 473 Prefix-SID attributes. 475 The outgoing label is always programmed as per classic Multiprotocol 476 BGP labeled IPv4/IPv6 Unicast ([RFC8277]) operation. Specifically, a 477 BGP speaker receiving a prefix with a BGP Prefix-SID attribute and a 478 label NLRI field of Implicit NULL from a neighbor MUST adhere to 479 standard behavior and program its MPLS dataplane to pop the top label 480 when forwarding traffic to the prefix. The label NLRI defines the 481 outbound label that MUST be used by the receiving node. 483 4.2. IPv6 Dataplane 485 When an SR IPv6 BGP speaker receives an IPv6 Unicast BGP Update with 486 a prefix having the BGP Prefix-SID attribute attached, it checks 487 whether the IPv6 SID TLV is present and "acceptable". 489 If multiple different prefixes are received with the same IPv6 SID, 490 either all or all but one of the different prefixes MUST have their 491 BGP Prefix-SID attribute considered as "conflicting". If one of the 492 different prefixes is considered "acceptable", it is RECOMMENDED that 493 the first prefix using the IPv6 SID is selected. 495 If multiple valid paths for the same prefix are received from 496 multiple BGP speakers or, in the case of [RFC7911], from the same BGP 497 speaker, and the BGP Prefix-SID attributes do not contain the same 498 IPv6 SID, then the IPv6 SID from the best path BGP Prefix-SID 499 attribute SHOULD be chosen with a notable exception being when 500 [RFC5005] is being used to dampen route changes. 502 If "acceptable" and chosen as the best path, the prefix is installed 503 into the Segment Routing IPv6 dataplane as described in 504 [I-D.ietf-spring-segment-routing]. 506 When a BGP speaker receives a path from a neighbor with an "invalid" 507 or "conflicting" BGP Prefix-SID attribute or when a BGP speaker 508 receives a path from a neighbor with a BGP Prefix-SID attribute but 509 is unable to process it (e.g, local policy disables the 510 functionality), it MUST ignore the BGP Prefix-SID attribute and 511 revert to [RFC2545] and [RFC4271]. Consistent with the MPLS 512 dataplane Section 4.1, a BGP speaker SHOULD log the condition for 513 further analysis. 515 When a BGP Prefix-SID attribute changes and transitions from 516 "conflicting" to "acceptable", the BGP Prefix-SID attributes for 517 other prefixes may also transition to "acceptable" as well. 518 Implementations SHOULD assure all impacted prefixes revert to using 519 the IPv6 SIDs corresponding to these newly "acceptable" BGP Prefix- 520 SID attributes. 522 The Label-Index and Originator SRGB TLVs MUST be ignored on 523 reception. For future extensibility, no TLVs are required for the 524 BGP IPv6 unicast address family. However, a BGP Prefix-SID attribute 525 corresponding to the BGP IPv6 address family without an IPv6 SID TLV 526 SHOULD be ignored. 528 5. Advertising BGP Prefix-SID Attribute 530 The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes 531 (IPv4/IPv6) [RFC8277] or to IPv6 unicast prefixes [RFC4760]. In 532 order to prevent distribution of the BGP Prefix-SID attribute beyond 533 its intended scope of applicability, attribute filtering SHOULD be 534 deployed to remove the BGP Prefix-SID attribute at the administrative 535 boundary of the segment routing domain. 537 A BGP speaker that advertises a path received from one of its 538 neighbors SHOULD advertise the BGP Prefix-SID received with the path 539 without modification, as long as the BGP Prefix-SID was acceptable. 540 If the path did not come with a BGP Prefix-SID attribute, the speaker 541 MAY attach a BGP Prefix-SID to the path if configured to do so. The 542 content of the TLVs present in the BGP Prefix-SID is determined by 543 the configuration. 545 5.1. MPLS Dataplane: Labeled Unicast 547 A BGP speaker that originates a prefix attaches the BGP Prefix-SID 548 attribute when it advertises the prefix to its neighbors via 549 Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC8277]). The value 550 of the label index in the Label-Index TLV is determined by 551 configuration. 553 A BGP speaker that originates a BGP Prefix-SID attribute MAY 554 optionally announce the Originator SRGB TLV along with the mandatory 555 Label-Index TLV. The content of the Originator SRGB TLV is 556 determined by configuration. 558 Since the label index value must be unique within an SR domain, by 559 default an implementation SHOULD NOT advertise the BGP Prefix-SID 560 attribute outside an Autonomous System unless it is explicitly 561 configured to do so. 563 In all cases, the label field of the advertised NLRI ([RFC8277], 564 [RFC4364]) MUST be set to the local/incoming label programmed in the 565 MPLS dataplane for the given advertised prefix. If the prefix is 566 associated with one of the BGP speaker's interfaces, this is the 567 usual MPLS label (such as the Implicit or Explicit NULL label). 569 5.2. IPv6 Dataplane 571 A BGP speaker that originates an IPv6 prefix with the BGP Prefix-SID 572 attribute SHOULD include the IPv6 SID TLV. 574 6. Error Handling of BGP Prefix-SID Attribute 576 When a BGP Speaker receives a BGP Update message containing a 577 malformed or invalid BGP Prefix-SID attribute attached to a Labeled 578 IPv4/IPv6 unicast prefix [RFC8277], it MUST ignore the received BGP 579 Prefix-SID attributes and not advertise it to other BGP peers. This 580 is equivalent to the "Attribute discard" action specified in 581 [RFC7606]. When discarding an attribute, a BGP speaker SHOULD log an 582 error for further analysis. 584 When a BGP Speaker receives a BGP Update message containing a 585 malformed or invalid BGP Prefix-SID attribute attached to an 586 unlabeled IPv6 unicast prefix [RFC4760], it MUST treat the 587 advertisement as a withdrawal. This is equivalent to the "Treat-as- 588 withdraw" action specified in [RFC7606]. This action is required 589 since simply ignoring the BGP Prefix-SID attribute would modify the 590 installed path and the "Attribute discard" option is not applicable 591 in this case [RFC7606]. When withdrawing the prefix, a BGP speaker 592 SHOULD log an error for further analysis. 594 Consistent with [RFC7606], only the first occurrence of the BGP 595 Prefix-SID attribute will be considered and subsequent occurrences 596 will be discarded. Similarly, only the first occurrence of a BGP 597 Prefix-SID attribute TLV of a given TLV type will be considered 598 unless the specification of that TLV type allows for multiple 599 occurrences. 601 For future extensibility, unknown TLVs MUST be ignored and propagated 602 unmodified. 604 7. IANA Considerations 606 This document defines a BGP path attribute known as the BGP Prefix- 607 SID attribute. This document requests IANA to assign an attribute 608 code type (suggested value: 40) to the BGP Prefix-SID attribute from 609 the BGP Path Attributes registry. 611 Currently, IANA temporarily assigned the following: 613 40 BGP Prefix-SID (TEMPORARY - registered 2015-09-30, expires 614 2016-09-30) [draft-ietf-idr-bgp-prefix-sid] 616 This document defines 3 TLVs for the BGP Prefix-SID attribute. These 617 TLVs need to be registered with IANA. We request IANA to create a 618 registry for BGP Prefix-SID Attribute TLVs as follows: 620 Under "Border Gateway Protocol (BGP) Parameters" registry, "BGP 621 Prefix-SID TLV Types" Reference: draft-ietf-idr-bgp-prefix-sid 622 Registration Procedure(s): Values 1-254 First Come First Served 623 (FCFS), Value 0 and 255 reserved 625 Value Type Reference 626 0 Reserved this document 627 1 Label-Index this document 628 2 IPv6 SID this document 629 3 Originator SRGB this document 630 4-254 Unassigned 631 255 Reserved this document 633 This document also creates a registry for the 16 bits of flags in the 634 Label-Index TLV. Initially, the registry will be empty. Flag bits 635 will be allocated First Come First Served (FCFS) consistent with the 636 BGP-SID TLV Types registry. 638 Finally, this document creates a registry for the 16 bits of flags in 639 the SRGB Originator TLV. Initially, the registry will be empty. 640 Flag bits will be allocated First Come First Served (FCFS) consistent 641 with the BGP-SID TLV Types registry. 643 8. Manageability Considerations 645 This document defines a BGP attribute to address use cases such as 646 the one described in [I-D.ietf-spring-segment-routing-msdc]. It is 647 assumed that advertisement of the BGP Prefix-SID attribute is 648 controlled by the operator in order to: 650 o Prevent undesired origination/advertisement of the BGP Prefix-SID 651 attribute. By default, a BGP Prefix-SID attribute SHOULD NOT be 652 attached to a prefix and advertised. Hence, BGP Prefix-SID 653 advertisement SHOULD require explicit enablement. 655 o Prevent any undesired propagation of the BGP Prefix-SID attribute. 656 By default, the BGP Prefix-SID is not advertised outside the 657 boundary of a single SR/administrative domain which may include 658 one or more ASes. The propagation to other ASes MUST be 659 explicitly configured. 661 The deployment model described in 662 [I-D.ietf-spring-segment-routing-msdc] assumes multiple Autonomous 663 Systems (ASes) under a common administrative domain. For this use 664 case, the BGP Prefix-SID advertisement is applicable to the inter-AS 665 context, i.e., EBGP, while it is confined to a single administrative 666 domain. 668 9. Security Considerations 670 This document introduces a BGP attribute (BGP Prefix-SID) which 671 inherits the security considerations expressed in: [RFC4271], 672 [RFC8277], and [I-D.ietf-spring-segment-routing]. 674 When advertised using BGPsec as described in [RFC8205], the BGP 675 Prefix-SID attribute doesn't impose any unique security 676 considerations. It should be noted that the BGP Prefix-SID attribute 677 is not protected by the BGPsec signatures. 679 It should be noted that, as described in Section 8, this document 680 refers to a deployment model where all nodes are under the single 681 administrative domain. In this context, we assume that the operator 682 doesn't want to leak any information related to internal prefixes and 683 topology outside of the administrative domain. The internal 684 information includes the BGP Prefix-SID. In order to prevent such 685 leaking, the common BGP mechanisms (filters) are applied at the 686 boundary of the SR/administrative domain. Local BGP attribute 687 filtering policies and mechanisms are not standardized and, 688 consequently, beyond the scope of this document. 690 To prevent a Denial-of-Service (DoS) or Distributed-Denial-of-Service 691 (DDoS) attack due to excessive BGP updates with an invalid or 692 conflicting BGP Prefix-SID attribute, message rate-limiting as well 693 as suppression of duplicate messages SHOULD be deployed. 695 10. Contributors 697 Keyur Patel 698 Arrcus, Inc. 699 US 701 Email: Keyur@arrcus.com 703 Saikat Ray 704 Unaffiliated 705 US 707 Email: raysaikat@gmail.com 709 11. Acknowledgements 711 The authors would like to thank Satya Mohanty for his contribution to 712 this document. 714 The authors would like to thank Alvaro Retana for substantive 715 comments as part of the Routing AD review. 717 The authors would like to thank Shyam Sethuram for comments and 718 discussion of TLV processing and validation. 720 The authors would like to thank Robert Raszuk for comments and 721 suggestions regarding the MPLS and IPv6 data plane behavior. 723 The authors would like to thank Krishna Deevi, Juan Alcaide, Howard 724 Yang, and Jakob Heitz for discussions on conflicting BGP Prefix-SID 725 label indices and BGP add paths. 727 The authors would like to thank Peter Yee, Tony Przygienda, Mirja 728 Kuehlewind, Alexey Melnikov, Eric Rescorla, Suresh Krishnan, Warren 729 Kumari, and Ben Campbell for IETF Last Call directorate and IESG 730 reviews. 732 12. References 734 12.1. Normative References 736 [I-D.ietf-spring-segment-routing] 737 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 738 Litkowski, S., and R. Shakir, "Segment Routing 739 Architecture", draft-ietf-spring-segment-routing-15 (work 740 in progress), January 2018. 742 [I-D.ietf-spring-segment-routing-mpls] 743 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 744 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 745 data plane", draft-ietf-spring-segment-routing-mpls-11 746 (work in progress), October 2017. 748 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 749 Requirement Levels", BCP 14, RFC 2119, 750 DOI 10.17487/RFC2119, March 1997, . 753 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 754 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 755 DOI 10.17487/RFC2545, March 1999, . 758 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 759 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 760 DOI 10.17487/RFC4271, January 2006, . 763 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 764 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 765 2006, . 767 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 768 "Multiprotocol Extensions for BGP-4", RFC 4760, 769 DOI 10.17487/RFC4760, January 2007, . 772 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 773 Patel, "Revised Error Handling for BGP UPDATE Messages", 774 RFC 7606, DOI 10.17487/RFC7606, August 2015, 775 . 777 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 778 "Advertisement of Multiple Paths in BGP", RFC 7911, 779 DOI 10.17487/RFC7911, July 2016, . 782 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 783 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 784 May 2017, . 786 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 787 Specification", RFC 8205, DOI 10.17487/RFC8205, September 788 2017, . 790 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 791 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 792 . 794 12.2. Informative References 796 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 797 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 798 and M. Chen, "BGP Link-State extensions for Segment 799 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-04 800 (work in progress), January 2018. 802 [I-D.ietf-idr-bgpls-segment-routing-epe] 803 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 804 Dong, "BGP-LS extensions for Segment Routing BGP Egress 805 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 806 epe-14 (work in progress), December 2017. 808 [I-D.ietf-spring-segment-routing-msdc] 809 Filsfils, C., Previdi, S., Mitchell, J., Aries, E., and P. 810 Lapukhov, "BGP-Prefix Segment in large-scale data 811 centers", draft-ietf-spring-segment-routing-msdc-08 (work 812 in progress), December 2017. 814 [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, 815 DOI 10.17487/RFC5005, September 2007, . 818 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 819 S. Ray, "North-Bound Distribution of Link-State and 820 Traffic Engineering (TE) Information Using BGP", RFC 7752, 821 DOI 10.17487/RFC7752, March 2016, . 824 Authors' Addresses 826 Stefano Previdi (editor) 827 Cisco Systems 828 IT 830 Email: stefano@previdi.net 832 Clarence Filsfils 833 Cisco Systems 834 Brussels 835 Belgium 837 Email: cfilsfils@cisco.com 839 Acee Lindem 840 Cisco Systems 841 301 Midenhall Way 842 Cary, NC 27513 843 USA 845 Email: acee@cisco.com 846 Arjun Sreekantiah 848 Email: arjunhrs@gmail.com 850 Hannes Gredler 851 RtBrick Inc. 853 Email: hannes@rtbrick.com