idnits 2.17.1 draft-ietf-idr-bgp-prefix-sid-22.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 (June 13, 2018) is 2144 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 337 -- Looks like a reference, but probably isn't: '199' on line 337 -- Looks like a reference, but probably isn't: '1000' on line 338 -- Looks like a reference, but probably isn't: '1099' on line 338 -- Looks like a reference, but probably isn't: '500' on line 339 -- Looks like a reference, but probably isn't: '599' on line 339 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-14 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-13 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-08 == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-15 == Outdated reference: A later version (-11) exists of draft-ietf-spring-segment-routing-msdc-09 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 6 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, Ed. 5 Expires: December 15, 2018 Cisco Systems 6 A. Sreekantiah 8 H. Gredler 9 RtBrick Inc. 10 June 13, 2018 12 Segment Routing Prefix SID extensions for BGP 13 draft-ietf-idr-bgp-prefix-sid-22 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. An SR domain 23 is defined as a single administrative domain for global SID 24 assignment. 26 This document defines an optional, transitive BGP attribute for 27 announcing BGP Prefix Segment Identifiers (BGP Prefix-SID) 28 information. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 34 "OPTIONAL" in this document are to be interpreted as described in BCP 35 14 [RFC2119] [RFC8174] when, and only when, they appear in all 36 capitals, as shown here. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on December 15, 2018. 55 Copyright Notice 57 Copyright (c) 2018 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. BGP-Prefix-SID . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.1. MPLS BGP Prefix SID . . . . . . . . . . . . . . . . . . . 4 75 3. BGP Prefix-SID Attribute . . . . . . . . . . . . . . . . . . 5 76 3.1. Label-Index TLV . . . . . . . . . . . . . . . . . . . . . 6 77 3.2. Originator SRGB TLV . . . . . . . . . . . . . . . . . . . 7 78 4. Receiving BGP Prefix-SID Attribute . . . . . . . . . . . . . 8 79 4.1. MPLS Dataplane: Labeled Unicast . . . . . . . . . . . . . 8 80 5. Advertising BGP Prefix-SID Attribute . . . . . . . . . . . . 10 81 5.1. MPLS Dataplane: Labeled Unicast . . . . . . . . . . . . . 10 82 6. Error Handling of BGP Prefix-SID Attribute . . . . . . . . . 11 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 8. Manageability Considerations . . . . . . . . . . . . . . . . 12 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 87 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 90 12.2. Informative References . . . . . . . . . . . . . . . . . 15 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 The Segment Routing (SR) architecture leverages the source routing 96 paradigm. A group of inter-connected nodes that use SR forms an SR 97 domain. A segment represents either a topological instruction such 98 as "go to prefix P following shortest path" or a service instruction. 99 Other types of segments may be defined in the future. 101 A segment is identified through a Segment Identifier (SID). An SR 102 domain is defined as a single administrative domain for global SID 103 assignment. It may be comprised of a single Autonomous System (AS) 104 or multiple ASes under consolidated global SID administration. 105 Typically, the ingress node of the SR domain prepends an SR header 106 containing segments identifiers (SIDs) to an incoming packet. 108 As described in [I-D.ietf-spring-segment-routing], when SR is applied 109 to the MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]), the 110 SID consists of a label. 112 [I-D.ietf-spring-segment-routing] also describes how segment routing 113 can be applied to an IPv6 dataplane (SRv6) using an IPv6 routing 114 header containing a stack of SR SIDs encoded as IPv6 addresses 115 [I-D.ietf-6man-segment-routing-header]. The applicability and 116 support for Segment Routing over IPv6 is beyond the scope of this 117 document. 119 A BGP-Prefix Segment (and its BGP Prefix-SID) is a BGP segment 120 attached to a BGP prefix. A BGP Prefix-SID is always a global SID 121 ([I-D.ietf-spring-segment-routing]) within the SR/BGP domain (i.e., 122 the set of Autonomous Systems under a common administration and 123 control and where SR is used) and identifies an instruction to 124 forward the packet over the Equal-Cost Multi-Path (ECMP) best-path 125 computed by BGP to the related prefix. The BGP Prefix-SID is the 126 identifier of the BGP prefix segment. In this document, we always 127 refer to the BGP segment by the BGP Prefix-SID. 129 This document describes the BGP extension to signal the BGP Prefix- 130 SID. Specifically, this document defines a BGP attribute known as 131 the BGP Prefix-SID attribute and specifies the rules to originate, 132 receive, and handle error conditions for the attribute. 134 The BGP Prefix-SID attribute defined in this document can be attached 135 to prefixes from Multiprotocol BGP labeled IPv4/IPv6 Unicast 136 ([RFC4760], [RFC8277]). Usage of the BGP Prefix-SID attribute for 137 other Address Family Identifier (AFI)/ Subsequent Address Family 138 Identifier (SAFI) combinations is not defined herein but may be 139 specified in future specifications. 141 [I-D.ietf-spring-segment-routing-msdc] describes example use cases 142 where the BGP Prefix-SID is used for the above AFI/SAFI combinations. 144 It should be noted that: 146 o A BGP Prefix-SID MAY be global between domains when the 147 interconnected domains agree on the SID allocation scheme. 148 Alternatively, when interconnecting domains, the ASBRs of each 149 domain will have to handle the advertisement of unique SIDs. The 150 mechanisms for such interconnection are outside the scope of the 151 protocol extensions defined in this document. 153 o A BGP Prefix-SID MAY be attached to a prefix. In addition, each 154 prefix will likely have a different AS_PATH attribute. This 155 implies that each prefix is advertised individually, reducing the 156 ability to pack BGP advertisements (when sharing common 157 attributes). 159 2. BGP-Prefix-SID 161 The BGP Prefix-SID advertised for BGP prefix P indicates that the 162 segment routed path should be used (as described below) if the BGP 163 best path selects the corresponding Network Layer Reachability 164 Information (NLRI). 166 2.1. MPLS BGP Prefix SID 168 The BGP Prefix-SID is realized on the MPLS dataplane 169 ([I-D.ietf-spring-segment-routing-mpls]) in the following way: 171 The operator assigns a globally unique label index, L_I, to a 172 locally sourced prefix of a BGP speaker N which is advertised to 173 all other BGP speakers in the SR domain. 175 According to [I-D.ietf-spring-segment-routing], each BGP speaker 176 is configured with a label block called the Segment Routing Global 177 Block (SRGB). While [I-D.ietf-spring-segment-routing] recommends 178 using the same SRGB across all the nodes within the SR domain, the 179 SRGB of a node is a local property and could be different on 180 different speakers. The drawbacks of the use case where BGP 181 speakers have different SRGBs are documented in 182 [I-D.ietf-spring-segment-routing] and 183 [I-D.ietf-spring-segment-routing-msdc]. 185 If traffic-engineering within the SR domain is required, each node 186 may also be required to advertise topological information and 187 Peering SIDs for each of its links and peers. This information is 188 required to perform the explicit path computation and to express 189 an explicit path as a list of SIDs. The advertisement of 190 topological information and peer segments (Peer SIDs) is done 191 through [I-D.ietf-idr-bgpls-segment-routing-epe]. 193 If the BGP speakers are not all configured with the same SRGB, and 194 if traffic-engineering within the SR domain is required, each node 195 may be required to advertise its local SRGB in addition to the 196 topological information. 198 This document assumes that BGP-LS is the preferred method for 199 collecting both peer segments (Peer SIDs) and SRGB information 200 through [RFC7752], [I-D.ietf-idr-bgpls-segment-routing-epe], and 201 [I-D.ietf-idr-bgp-ls-segment-routing-ext]. However, as an 202 optional alternative for the advertisement of the local SRGB 203 without the topology nor the peer SIDs, hence without 204 applicability for TE, the Originator SRGB TLV of the BGP Prefix- 205 SID attribute is specified in Section 3.2 of this document. 207 As defined in [I-D.ietf-spring-segment-routing], the label index 208 L_I is an offset into the SRGB. Each BGP speaker derives its 209 local MPLS label, L, by adding L_I to the start value of its own 210 SRGB, and programs L in its MPLS dataplane as its incoming/local 211 label for the prefix. It should be noted that while SRGBs and 212 SIDs are advertised using 32-bit values, the derived label is 213 advertised in the 20 right-most bits. See Section 4.1 for more 214 details. 216 The outgoing label for the prefix is found in the NLRI of the 217 Multiprotocol BGP labeled IPv4/IPv6 Unicast prefix advertisement 218 as defined in [RFC8277]. The label index L_I is only used as a 219 hint to derive the local/incoming label. 221 Section 3.1 of this document specifies the Label-Index TLV of the 222 BGP Prefix-SID attribute; this TLV can be used to advertise the 223 label index for a given prefix. 225 In order to advertise the label index of a given prefix P and, 226 optionally, the SRGB, an extension to BGP is needed: the BGP Prefix- 227 SID attribute. This extension is described in subsequent sections. 229 3. BGP Prefix-SID Attribute 231 The BGP Prefix-SID attribute is an optional, transitive BGP path 232 attribute. The attribute type code 40 has been assigned by IANA (see 233 Section 7). 235 The BGP Prefix-SID attribute is defined here to be a set of elements 236 encoded as "Type/Length/Value" tuples (i.e., a set of TLVs). All BGP 237 Prefix-SID attribute TLVs will start with a 1-octet type and a 238 2-octet length. The following TLVs are defined in this document: 240 o Label-Index TLV 242 o Originator SRGB TLV 244 The Label-Index and Originator SRGB TLVs are used only when SR is 245 applied to the MPLS dataplane. 247 For future extensibility, unknown TLVs MUST be ignored and propagated 248 unmodified. 250 3.1. Label-Index TLV 252 The Label-Index TLV MUST be present in the BGP Prefix-SID attribute 253 attached to Labeled IPv4/IPv6 unicast prefixes ([RFC8277]). It MUST 254 be ignored when received for other BGP AFI/SAFI combinations. The 255 Label-Index TLV has the following format: 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Type | Length | RESERVED | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Flags | Label Index | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Label Index | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 where: 269 o Type is 1. 271 o Length: is 7, the total length in octets of the value portion of 272 the TLV. 274 o RESERVED: 8-bit field. MUST be clear on transmission and MUST be 275 ignored on reception. 277 o Flags: 16 bits of flags. None are defined by this document. The 278 flag field MUST be clear on transmission and MUST be ignored on 279 reception. 281 o Label Index: 32-bit value representing the index value in the SRGB 282 space. 284 3.2. Originator SRGB TLV 286 The Originator SRGB TLV is an optional TLV and has the following 287 format: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Type | Length | Flags | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Flags | 295 +-+-+-+-+-+-+-+-+ 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | SRGB 1 (6 octets) | 299 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | SRGB n (6 octets) | 305 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 where: 311 o Type is 3. 313 o Length is the total length in octets of the value portion of the 314 TLV: 2 + (non-zero multiple of 6). 316 o Flags: 16 bits of flags. None are defined in this document. 317 Flags MUST be clear on transmission and MUST be ignored on 318 reception. 320 o SRGB: 3 octets of base followed by 3 octets of range. Note that 321 the SRGB field MAY appear multiple times. If the SRGB field 322 appears multiple times, the SRGB consists of multiple ranges that 323 are concatenated. 325 The Originator SRGB TLV contains the SRGB of the node originating the 326 prefix to which the BGP Prefix-SID is attached. The Originator SRGB 327 TLV MUST NOT be changed during the propagation of the BGP update. 329 The originator SRGB describes the SRGB of the node where the BGP 330 Prefix SID is attached. It is used to build segment routing policies 331 when different SRGBs are used in the fabric, for example 332 ([I-D.ietf-spring-segment-routing-msdc]). 334 The receiving routers concatenate the ranges and build the Segment 335 Routing Global Block (SRGB) as follows: 337 SRGB = [100, 199] 338 [1000, 1099] 339 [500, 599] 341 The indexes span multiple ranges: 343 index=0 means label 100 344 ... 345 index 99 means label 199 346 index 100 means label 1000 347 index 199 means label 1099 348 ... 349 index 200 means label 500 350 ... 352 The originator SRGB may only appear in a BGP Prefix-SID attribute 353 attached to Labeled IPv4/IPv6 unicast prefixes ([RFC8277]). It MUST 354 be ignored when received for other BGP AFI/SAFI combinations. Since 355 the Label-Index TLV is required for IPv4/IPv6 prefix applicability, 356 the originator SRGB will be ignored if it is not specified consistent 357 with Section 6. 359 4. Receiving BGP Prefix-SID Attribute 361 A BGP speaker receiving a BGP Prefix-SID attribute from an External 362 BGP (EBGP) neighbor residing outside the boundaries of the SR domain 363 MUST discard the attribute unless it is configured to accept the 364 attribute from the EBGP neighbor. A BGP speaker SHOULD log an error 365 for further analysis when discarding an attribute. 367 4.1. MPLS Dataplane: Labeled Unicast 369 A BGP session supporting the Multiprotocol BGP labeled IPv4 or IPv6 370 Unicast ([RFC8277]) AFI/SAFI is required. 372 The BGP Prefix-SID attribute MUST contain the Label-Index TLV and MAY 373 contain the Originator SRGB TLV. A BGP Prefix-SID attribute received 374 without a Label-Index TLV MUST be considered as "invalid" by the 375 receiving speaker. 377 The label index provides the receiving BGP speaker with guidance as 378 to the incoming label that SHOULD be assigned by that BGP speaker. 380 A BGP speaker may be locally configured with an SRGB=[SRGB_Start, 381 SRGB_End]. The preferred method for deriving the SRGB is a matter of 382 local node configuration. 384 The mechanisms through which a given label index value is assigned to 385 a given prefix are outside the scope of this document. 387 Given a label index L_I, we refer to (L = L_I + SRGB_Start) as the 388 derived label. A BGP Prefix-SID attribute is designated 389 "conflicting" for a speaker M if the derived label value L lies 390 outside the SRGB configured on M. Otherwise the Label-Index TLV is 391 designated "acceptable" to speaker M. 393 If multiple different prefixes are received with the same label 394 index, all of the different prefixes MUST have their BGP Prefix-SID 395 attribute considered as "conflicting". 397 If multiple valid paths for the same prefix are received from 398 multiple BGP speakers or, in the case of [RFC7911], from the same BGP 399 speaker, and the BGP Prefix-SID attributes do not contain the same 400 label index, then the label index from the best path BGP Prefix-SID 401 attribute SHOULD be chosen with a notable exception being when 402 [RFC5004] is being used to dampen route changes. 404 When a BGP speaker receives a path from a neighbor with an 405 "acceptable" BGP Prefix-SID attribute and that path is selected as 406 the best path, it SHOULD program the derived label as the label for 407 the prefix in its local MPLS dataplane. 409 When a BGP speaker receives a path from a neighbor with an "invalid" 410 or "conflicting" BGP Prefix-SID attribute or when a BGP speaker 411 receives a path from a neighbor with a BGP Prefix-SID attribute but 412 is unable to process it (e.g., local policy disables the 413 functionality), it MUST ignore the BGP Prefix-SID attribute. For the 414 purposes of label allocation, a BGP speaker MUST assign a local (also 415 called dynamic) label (non-SRGB) for such a prefix as per classic 416 Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC8277]) operation. 418 In the case of an "invalid" BGP Prefix-SID attribute, a BGP speaker 419 MUST follow the error handling rules specified in Section 6. A BGP 420 speaker SHOULD log an error for further analysis. In the case of a 421 "conflicting" BGP Prefix-SID attribute, a BGP speaker SHOULD NOT 422 treat it as error and SHOULD propagate the attribute unchanged. A 423 BGP Speaker SHOULD log a warning for further analysis, i.e., in the 424 case the conflict is not due to a label index transition. 426 When a BGP Prefix-SID attribute changes and transitions from 427 "conflicting" to "acceptable", the BGP Prefix-SID attributes for 428 other prefixes may also transition to "acceptable" as well. 429 Implementations SHOULD assure all impacted prefixes revert to using 430 the label indices corresponding to these newly "acceptable" BGP 431 Prefix-SID attributes. 433 The outgoing label is always programmed as per classic Multiprotocol 434 BGP labeled IPv4/IPv6 Unicast ([RFC8277]) operation. Specifically, a 435 BGP speaker receiving a prefix with a BGP Prefix-SID attribute and a 436 label NLRI field of Implicit NULL [RFC3032] from a neighbor MUST 437 adhere to standard behavior and program its MPLS dataplane to pop the 438 top label when forwarding traffic to the prefix. The label NLRI 439 defines the outbound label that MUST be used by the receiving node. 441 5. Advertising BGP Prefix-SID Attribute 443 The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes 444 (IPv4/IPv6) [RFC8277]. In order to prevent distribution of the BGP 445 Prefix-SID attribute beyond its intended scope of applicability, 446 attribute filtering SHOULD be deployed to remove the BGP Prefix-SID 447 attribute at the administrative boundary of the segment routing 448 domain. 450 A BGP speaker that advertises a path received from one of its 451 neighbors SHOULD advertise the BGP Prefix-SID received with the path 452 without modification, as long as the BGP Prefix-SID was acceptable. 453 If the path did not come with a BGP Prefix-SID attribute, the speaker 454 MAY attach a BGP Prefix-SID to the path if configured to do so. The 455 content of the TLVs present in the BGP Prefix-SID is determined by 456 the configuration. 458 5.1. MPLS Dataplane: Labeled Unicast 460 A BGP speaker that originates a prefix attaches the BGP Prefix-SID 461 attribute when it advertises the prefix to its neighbors via 462 Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC8277]). The value 463 of the label index in the Label-Index TLV is determined by 464 configuration. 466 A BGP speaker that originates a BGP Prefix-SID attribute MAY 467 optionally announce the Originator SRGB TLV along with the mandatory 468 Label-Index TLV. The content of the Originator SRGB TLV is 469 determined by configuration. 471 Since the label index value must be unique within an SR domain, by 472 default an implementation SHOULD NOT advertise the BGP Prefix-SID 473 attribute outside an Autonomous System unless it is explicitly 474 configured to do so. 476 In all cases, the label field of the advertised NLRI ([RFC8277], 477 [RFC4364]) MUST be set to the local/incoming label programmed in the 478 MPLS dataplane for the given advertised prefix. If the prefix is 479 associated with one of the BGP speaker's interfaces, this is the 480 usual MPLS label (such as the Implicit or Explicit NULL label 481 [RFC3032]). 483 6. Error Handling of BGP Prefix-SID Attribute 485 When a BGP Speaker receives a BGP Update message containing a 486 malformed or invalid BGP Prefix-SID attribute attached to a Labeled 487 IPv4/IPv6 unicast prefix [RFC8277], it MUST ignore the received BGP 488 Prefix-SID attributes and not advertise it to other BGP peers. In 489 this context, a malformed BGP Prefix-SID attribute is one that cannot 490 be parsed due to not meeting the minimum attribute length 491 requirement, contains a TLV length that doesn't conform to the length 492 constraints for the TLV, or a contains TLV length that would extend 493 beyond the end of the attribute (as defined by the attribute length). 494 This is equivalent to the "Attribute discard" action specified in 495 [RFC7606]. When discarding an attribute, a BGP speaker SHOULD log an 496 error for further analysis. 498 Consistent with [RFC7606], only the first occurrence of the BGP 499 Prefix-SID attribute will be considered and subsequent occurrences 500 will be discarded. Similarly, only the first occurrence of a BGP 501 Prefix-SID attribute TLV of a given TLV type will be considered 502 unless the specification of that TLV type allows for multiple 503 occurrences. 505 For future extensibility, unknown TLVs MUST be ignored and propagated 506 unmodified. 508 7. IANA Considerations 510 This document defines a BGP path attribute known as the BGP Prefix- 511 SID attribute. This document requests IANA to assign an attribute 512 code type (suggested value: 40) to the BGP Prefix-SID attribute from 513 the BGP Path Attributes registry. 515 Currently, IANA temporarily assigned the following: 517 40 BGP Prefix-SID (TEMPORARY - registered 2015-09-30, expires 518 2016-09-30) [draft-ietf-idr-bgp-prefix-sid] 520 This document defines 3 TLVs for the BGP Prefix-SID attribute. These 521 TLVs need to be registered with IANA. We request IANA to create a 522 registry for BGP Prefix-SID Attribute TLVs as follows: 524 Under "Border Gateway Protocol (BGP) Parameters" registry, "BGP 525 Prefix-SID TLV Types" Reference: draft-ietf-idr-bgp-prefix-sid 526 Registration Procedure(s): Values 1-254 First Come First Served 527 (FCFS), Value 0 and 255 reserved 529 Value Type Reference 530 0 Reserved this document 531 1 Label-Index this document 532 2 Deprecated this document 533 3 Originator SRGB this document 534 4-254 Unassigned 535 255 Reserved this document 537 This document also requests creation of the "BGP Prefix-SID Label- 538 Index TLV Flags" registry under the "Border Gateway Protocol (BGP) 539 Parameters" registry, Reference: draft-ietf-idr-bgp-prefix-sid. 540 Initially, this 16 bit flags registry will be empty. Flag bits will 541 be allocated First Come First Served (FCFS) consistent with the BGP 542 Prefix-SID TLV Types registry. 544 Finally, this document requests creation of the "BGP Prefix-SID 545 Originator SRGB TLV Flags" registry under the "Border Gateway 546 Protocol (BGP) Parameters" registry, Reference: draft-ietf-idr-bgp- 547 prefix-sid. Initially, this 16 bit flags registry will be empty. 548 Flag bits will be allocated First Come First Served (FCFS) consistent 549 with the BGP Prefix-SID TLV Types registry. 551 8. Manageability Considerations 553 This document defines a BGP attribute to address use cases such as 554 the one described in [I-D.ietf-spring-segment-routing-msdc]. It is 555 assumed that advertisement of the BGP Prefix-SID attribute is 556 controlled by the operator in order to: 558 o Prevent undesired origination/advertisement of the BGP Prefix-SID 559 attribute. By default, a BGP Prefix-SID attribute SHOULD NOT be 560 attached to a prefix and advertised. Hence, BGP Prefix-SID 561 advertisement SHOULD require explicit enablement. 563 o Prevent any undesired propagation of the BGP Prefix-SID attribute. 564 By default, the BGP Prefix-SID is not advertised outside the 565 boundary of a single SR/administrative domain which may include 566 one or more ASes. The propagation to other ASes MUST be 567 explicitly configured. 569 The deployment model described in 570 [I-D.ietf-spring-segment-routing-msdc] assumes multiple Autonomous 571 Systems (ASes) under a common administrative domain. For this use 572 case, the BGP Prefix-SID advertisement is applicable to the inter-AS 573 context, i.e., EBGP, while it is confined to a single administrative 574 domain. 576 9. Security Considerations 578 This document introduces a BGP attribute (BGP Prefix-SID) which 579 inherits the security considerations expressed in: [RFC4271], 580 [RFC8277], and [I-D.ietf-spring-segment-routing]. 582 When advertised using BGPsec as described in [RFC8205], the BGP 583 Prefix-SID attribute doesn't impose any unique security 584 considerations. It should be noted that the BGP Prefix-SID attribute 585 is not protected by the BGPsec signatures. 587 It should be noted that, as described in Section 8, this document 588 refers to a deployment model where all nodes are under the single 589 administrative domain. In this context, we assume that the operator 590 doesn't want to leak any information related to internal prefixes and 591 topology outside of the administrative domain. The internal 592 information includes the BGP Prefix-SID. In order to prevent such 593 leaking, the common BGP mechanisms (filters) are applied at the 594 boundary of the SR/administrative domain. Local BGP attribute 595 filtering policies and mechanisms are not standardized and, 596 consequently, beyond the scope of this document. 598 To prevent a Denial-of-Service (DoS) or Distributed-Denial-of-Service 599 (DDoS) attack due to excessive BGP updates with an invalid or 600 conflicting BGP Prefix-SID attribute, message rate-limiting as well 601 as suppression of duplicate messages SHOULD be deployed. 603 10. Contributors 605 Keyur Patel 606 Arrcus, Inc. 607 US 609 Email: Keyur@arrcus.com 611 Saikat Ray 612 Unaffiliated 613 US 615 Email: raysaikat@gmail.com 617 11. Acknowledgements 619 The authors would like to thank Satya Mohanty for his contribution to 620 this document. 622 The authors would like to thank Alvaro Retana for substantive 623 comments as part of the Routing AD review. 625 The authors would like to thank Shyam Sethuram for comments and 626 discussion of TLV processing and validation. 628 The authors would like to thank Robert Raszuk for comments and 629 suggestions regarding the MPLS data plane behavior. 631 The authors would like to thank Krishna Deevi, Juan Alcaide, Howard 632 Yang, and Jakob Heitz for discussions on conflicting BGP Prefix-SID 633 label indices and BGP add paths. 635 The authors would like to thank Peter Yee, Tony Przygienda, Mirja 636 Kuehlewind, Alexey Melnikov, Eric Rescorla, Suresh Krishnan, Warren 637 Kumari, Ben Campbell and Sue Hares for IDR Working Group last call, 638 IETF Last Call, directorate, and IESG reviews. 640 12. References 642 12.1. Normative References 644 [I-D.ietf-spring-segment-routing] 645 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 646 Litkowski, S., and R. Shakir, "Segment Routing 647 Architecture", draft-ietf-spring-segment-routing-15 (work 648 in progress), January 2018. 650 [I-D.ietf-spring-segment-routing-mpls] 651 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 652 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 653 data plane", draft-ietf-spring-segment-routing-mpls-14 654 (work in progress), June 2018. 656 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 657 Requirement Levels", BCP 14, RFC 2119, 658 DOI 10.17487/RFC2119, March 1997, . 661 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 662 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 663 DOI 10.17487/RFC4271, January 2006, . 666 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 667 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 668 2006, . 670 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 671 "Multiprotocol Extensions for BGP-4", RFC 4760, 672 DOI 10.17487/RFC4760, January 2007, . 675 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 676 Patel, "Revised Error Handling for BGP UPDATE Messages", 677 RFC 7606, DOI 10.17487/RFC7606, August 2015, 678 . 680 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 681 "Advertisement of Multiple Paths in BGP", RFC 7911, 682 DOI 10.17487/RFC7911, July 2016, . 685 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 686 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 687 May 2017, . 689 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 690 Specification", RFC 8205, DOI 10.17487/RFC8205, September 691 2017, . 693 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 694 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 695 . 697 12.2. Informative References 699 [I-D.ietf-6man-segment-routing-header] 700 Previdi, S., Filsfils, C., Leddy, J., Matsushima, S., and 701 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 702 (SRH)", draft-ietf-6man-segment-routing-header-13 (work in 703 progress), May 2018. 705 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 706 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 707 and M. Chen, "BGP Link-State extensions for Segment 708 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-08 709 (work in progress), May 2018. 711 [I-D.ietf-idr-bgpls-segment-routing-epe] 712 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 713 Dong, "BGP-LS extensions for Segment Routing BGP Egress 714 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 715 epe-15 (work in progress), March 2018. 717 [I-D.ietf-spring-segment-routing-msdc] 718 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and P. 719 Lapukhov, "BGP-Prefix Segment in large-scale data 720 centers", draft-ietf-spring-segment-routing-msdc-09 (work 721 in progress), May 2018. 723 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 724 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 725 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 726 . 728 [RFC5004] Chen, E. and S. Sangli, "Avoid BGP Best Path Transitions 729 from One External to Another", RFC 5004, 730 DOI 10.17487/RFC5004, September 2007, . 733 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 734 S. Ray, "North-Bound Distribution of Link-State and 735 Traffic Engineering (TE) Information Using BGP", RFC 7752, 736 DOI 10.17487/RFC7752, March 2016, . 739 Authors' Addresses 741 Stefano Previdi (editor) 742 Cisco Systems 743 IT 745 Email: stefano@previdi.net 747 Clarence Filsfils 748 Cisco Systems 749 Brussels 750 Belgium 752 Email: cfilsfils@cisco.com 753 Acee Lindem (editor) 754 Cisco Systems 755 301 Midenhall Way 756 Cary, NC 27513 757 USA 759 Email: acee@cisco.com 761 Arjun Sreekantiah 763 Email: arjunhrs@gmail.com 765 Hannes Gredler 766 RtBrick Inc. 768 Email: hannes@rtbrick.com