idnits 2.17.1 draft-ietf-idr-bgp-prefix-sid-20.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 (May 8, 2018) is 2151 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 338 -- Looks like a reference, but probably isn't: '199' on line 338 -- Looks like a reference, but probably isn't: '1000' on line 339 -- Looks like a reference, but probably isn't: '1099' on line 339 -- Looks like a reference, but probably isn't: '500' on line 340 -- Looks like a reference, but probably isn't: '599' on line 340 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-13 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-12 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-06 == 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-08 -- 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: November 9, 2018 Cisco Systems 6 A. Sreekantiah 8 H. Gredler 9 RtBrick Inc. 10 May 8, 2018 12 Segment Routing Prefix SID extensions for BGP 13 draft-ietf-idr-bgp-prefix-sid-20 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. Ah 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 November 9, 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 AS or multiple ASes 104 under consolidated global SID administration. Typically, the ingress 105 node of the SR domain prepends an SR header containing segments 106 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 114 [I-D.ietf-6man-segment-routing-header] (SRv6) using a new IPv6 115 routing header containing a stack of SR SIDs encoded as IPv6 116 addresses. The applicability and support for Segment Routing over 117 IPv6 is beyond the scope of this 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 ECMP-aware best-path computed by BGP to 125 the related prefix. The BGP Prefix-SID is the identifier of the BGP 126 prefix segment. In this document, we always refer to the BGP segment 127 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]). Address Family Identifier (AFI)/ Subsequent 137 Address Family Identifier (SAFI) combinations. 139 Usage of the BGP Prefix-SID attribute for other AFI/SAFI combinations 140 is not defined herein but may be specified in future specifications. 142 [I-D.ietf-spring-segment-routing-msdc] describes example use cases 143 where the BGP Prefix-SID is used for the above AFI/SAFI combinations. 145 It should be noted that: 147 o A BGP Prefix-SID MAY be global between domains when the 148 interconnected domains agree on the SID allocation scheme. 149 Alternatively, when interconnecting domains, the ASBRs of each 150 domain will have to handle the advertisement of unique SIDs. The 151 mechanisms for such interconnection are outside the scope of the 152 protocol extensions defined in this document. 154 o A BGP Prefix-SID MAY be attached to a prefix. In addition, each 155 prefix will likely have a different AS_PATH attribute. This 156 implies that each prefix is advertised individually, reducing the 157 ability to pack BGP advertisements (when sharing common 158 attributes). 160 2. BGP-Prefix-SID 162 The BGP Prefix-SID advertised for BGP prefix P indicates that the 163 segment routed path should be used (as described below) if the BGP 164 best path selects the corresponding Network Layer Reachability 165 Information (NLRI). 167 2.1. MPLS BGP Prefix SID 169 The BGP Prefix-SID is realized on the MPLS dataplane 170 ([I-D.ietf-spring-segment-routing-mpls]) in the following way: 172 The operator assigns a globally unique label index, L_I, to a 173 locally sourced prefix of a BGP speaker N which is advertised to 174 all other BGP speakers in the SR domain. 176 According to [I-D.ietf-spring-segment-routing], each BGP speaker 177 is configured with a label block called the Segment Routing Global 178 Block (SRGB). While [I-D.ietf-spring-segment-routing] recommends 179 using the same SRGB across all the nodes within the SR domain, the 180 SRGB of a node is a local property and could be different on 181 different speakers. The drawbacks of the use case where BGP 182 speakers have different SRGBs are documented in 183 [I-D.ietf-spring-segment-routing] and 184 [I-D.ietf-spring-segment-routing-msdc]. 186 If traffic-engineering within the SR domain is required, each node 187 may also be required to advertise topological information and 188 Peering SIDs for each of its links and peers. This information is 189 required to perform the explicit path computation and to express 190 an explicit path as a list of SIDs. The advertisement of 191 topological information and peer segments (Peer SIDs) is done 192 through [I-D.ietf-idr-bgpls-segment-routing-epe]. 194 If the BGP speakers are not all configured with the same SRGB, and 195 if traffic-engineering within the SR domain is required, each node 196 may be required to advertise its local SRGB in addition to the 197 topological information. 199 This document assumes that BGP-LS is the preferred method for 200 collecting both peer segments (Peer SIDs) and SRGB information 201 through [RFC7752], [I-D.ietf-idr-bgpls-segment-routing-epe], and 202 [I-D.ietf-idr-bgp-ls-segment-routing-ext]. However, as an 203 optional alternative for the advertisement of the local SRGB 204 without the topology nor the peer SIDs, hence without 205 applicability for TE, the Originator SRGB TLV of the prefix-SID 206 attribute is specified in Section 3.2 of this document. 208 As defined in [I-D.ietf-spring-segment-routing], the label index 209 L_I is an offset into the SRGB. Each BGP speaker derives its 210 local MPLS label, L, by adding L_I to the start value of its own 211 SRGB, and programs L in its MPLS dataplane as its incoming/local 212 label for the prefix. It should be noted that while SRGBs and 213 SIDs are advertised using 32-bit values, the derived label is 214 advertised in the 20 right-most bits. See Section 4.1 for more 215 details. 217 The outgoing label for the prefix is found in the NLRI of the 218 Multiprotocol BGP labeled IPv4/IPv6 Unicast prefix advertisement 219 as defined in [RFC8277]. The label index L_I is only used as a 220 hint to derive the local/incoming label. 222 Section 3.1 of this document specifies the Label-Index TLV of the 223 BGP Prefix-SID attribute; this TLV can be used to advertise the 224 label index for a given prefix. 226 In order to advertise the label index of a given prefix P and, 227 optionally, the SRGB, an extension to BGP is needed: the BGP Prefix- 228 SID attribute. This extension is described in subsequent sections. 230 3. BGP Prefix-SID Attribute 232 The BGP Prefix-SID attribute is an optional, transitive BGP path 233 attribute. The attribute type code 40 has been assigned by IANA (see 234 Section 7). 236 The BGP Prefix-SID attribute is defined here to be a set of elements 237 encoded as "Type/Length/Value" tuples (i.e., a set of TLVs). All BGP 238 Prefix-SID attribute TLVs will start with a 1-octet type and a 239 2-octet length. The following TLVs are defined in this document: 241 o Label-Index TLV 243 o Originator SRGB TLV 245 The Label-Index and Originator SRGB TLVs are used only when SR is 246 applied to the MPLS dataplane. 248 For future extensibility, unknown TLVs MUST be ignored and propagated 249 unmodified. 251 3.1. Label-Index TLV 253 The Label-Index TLV MUST be present in the BGP Prefix-SID attribute 254 attached to Labeled IPv4/IPv6 unicast prefixes ([RFC8277]). It MUST 255 be ignored when received for other BGP AFI/SAFI combinations. The 256 Label-Index TLV has the following format: 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Type | Length | RESERVED | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Flags | Label Index | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Label Index | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 where: 270 o Type is 1. 272 o Length: is 7, the total length in octets of the value portion of 273 the TLV. 275 o RESERVED: 8-bit field. MUST be clear on transmission and MUST be 276 ignored on reception. 278 o Flags: 16 bits of flags. None are defined by this document. The 279 flag field MUST be clear on transmission and MUST be ignored on 280 reception. 282 o Label Index: 32-bit value representing the index value in the SRGB 283 space. 285 3.2. Originator SRGB TLV 287 The Originator SRGB TLV is an optional TLV and has the following 288 format: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type | Length | Flags | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Flags | 296 +-+-+-+-+-+-+-+-+ 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | SRGB 1 (6 octets) | 300 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | SRGB n (6 octets) | 306 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 where: 312 o Type is 3. 314 o Length is the total length in octets of the value portion of the 315 TLV: 2 + (multiple of 6). 317 o Flags: 16 bits of flags. None are defined in this document. 318 Flags MUST be clear on transmission and MUST be ignored on 319 reception. 321 o SRGB: 3 octets of base followed by 3 octets of range. Note that 322 the SRGB field MAY appear multiple times. If the SRGB field 323 appears multiple times, the SRGB consists of multiple ranges that 324 are concatenated. 326 The Originator SRGB TLV contains the SRGB of the node originating the 327 prefix to which the BGP Prefix-SID is attached. The Originator SRGB 328 TLV MUST NOT be changed during the propagation of the BGP update. 330 The originator SRGB describes the SRGB of the node where the BGP 331 Prefix SID is attached. It is used to build segment routing policies 332 when different SRGBs are used in the fabric, for example 333 ([I-D.ietf-spring-segment-routing-msdc]). 335 The receiving routers concatenate the ranges and build the Segment 336 Routing Global Block (SRGB) as follows: 338 SRGB = [100, 199] 339 [1000, 1099] 340 [500, 599] 342 The indexes span multiple ranges: 344 index=0 means label 100 345 ... 346 index 99 means label 199 347 index 100 means label 1000 348 index 199 means label 1099 349 ... 350 index 200 means label 500 351 ... 353 The originator SRGB may only appear in a BGP Prefix-SID attribute 354 attached to Labeled IPv4/IPv6 unicast prefixes ([RFC8277]). It MUST 355 be ignored when received for other BGP AFI/SAFI combinations. Since 356 the Label-Index TLV is required for IPv4/IPv6 prefix applicability, 357 the originator SRGB will be ignored if it is not specified consistent 358 with Section 6. 360 4. Receiving BGP Prefix-SID Attribute 362 A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP 363 neighbor residing outside the boundaries of the SR domain MUST 364 discard the attribute unless it is configured to accept the attribute 365 from the EBGP neighbor. A BGP speaker SHOULD log an error for 366 further analysis when discarding an attribute. 368 4.1. MPLS Dataplane: Labeled Unicast 370 A BGP session supporting the Multiprotocol BGP labeled IPv4 or IPv6 371 Unicast ([RFC8277]) AFI/SAFI is required. 373 The BGP Prefix-SID attribute MUST contain the Label-Index TLV and MAY 374 contain the Originator SRGB TLV. A BGP Prefix-SID attribute received 375 without a Label-Index TLV MUST be considered as "invalid" by the 376 receiving speaker. 378 The label index provides the receiving BGP speaker with guidance as 379 to the incoming label that SHOULD be assigned by that BGP speaker. 381 A BGP speaker may be locally configured with an SRGB=[SRGB_Start, 382 SRGB_End]. The preferred method for deriving the SRGB is a matter of 383 local node configuration. 385 The mechanisms through which a given label index value is assigned to 386 a given prefix are outside the scope of this document. 388 Given a label index L_I, we refer to (L = L_I + SRGB_Start) as the 389 derived label. A BGP Prefix-SID attribute is designated 390 "conflicting" for a speaker M if the derived label value L lies 391 outside the SRGB configured on M. Otherwise the Label-Index TLV is 392 designated "acceptable" to speaker M. 394 If multiple different prefixes are received with the same label 395 index, all of the different prefixes MUST have their BGP Prefix-SID 396 attribute considered as "conflicting". 398 If multiple valid paths for the same prefix are received from 399 multiple BGP speakers or, in the case of [RFC7911], from the same BGP 400 speaker, and the BGP Prefix-SID attributes do not contain the same 401 label index, then the label index from the best path BGP Prefix-SID 402 attribute SHOULD be chosen with a notable exception being when 403 [RFC5004] is being used to dampen route changes. 405 When a BGP speaker receives a path from a neighbor with an 406 "acceptable" BGP Prefix-SID attribute and that path is selected as 407 the best path, it SHOULD program the derived label as the label for 408 the prefix in its local MPLS dataplane. 410 When a BGP speaker receives a path from a neighbor with an "invalid" 411 or "conflicting" BGP Prefix-SID attribute or when a BGP speaker 412 receives a path from a neighbor with a BGP Prefix-SID attribute but 413 is unable to process it (e.g., local policy disables the 414 functionality), it MUST ignore the BGP Prefix-SID attribute. For the 415 purposes of label allocation, a BGP speaker MUST assign a local (also 416 called dynamic) label (non-SRGB) for such a prefix as per classic 417 Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC8277]) operation. 419 In the case of an "invalid" BGP Prefix-SID attribute, a BGP speaker 420 MUST follow to the error handling rules specified in Section 6. A 421 BGP speaker SHOULD log an error for further analysis. In the case of 422 a "conflicting" BGP Prefix-SID attribute, a BGP speaker SHOULD NOT 423 treat it as error and SHOULD propagate the attribute unchanged. A 424 BGP Speaker SHOULD log a warning for further analysis, i.e., in the 425 case the conflict is not due to a label index transition. 427 When a BGP Prefix-SID attribute changes and transitions from 428 "conflicting" to "acceptable", the BGP Prefix-SID attributes for 429 other prefixes may also transition to "acceptable" as well. 430 Implementations SHOULD assure all impacted prefixes revert to using 431 the label indices corresponding to these newly "acceptable" BGP 432 Prefix-SID attributes. 434 The outgoing label is always programmed as per classic Multiprotocol 435 BGP labeled IPv4/IPv6 Unicast ([RFC8277]) operation. Specifically, a 436 BGP speaker receiving a prefix with a BGP Prefix-SID attribute and a 437 label NLRI field of Implicit NULL [IANA-MPLS-SPECIAL-LABEL] from a 438 neighbor MUST adhere to standard behavior and program its MPLS 439 dataplane to pop the top label when forwarding traffic to the prefix. 440 The label NLRI defines the outbound label that MUST be used by the 441 receiving node. 443 5. Advertising BGP Prefix-SID Attribute 445 The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes 446 (IPv4/IPv6) [RFC8277]. In order to prevent distribution of the BGP 447 Prefix-SID attribute beyond its intended scope of applicability, 448 attribute filtering SHOULD be deployed to remove the BGP Prefix-SID 449 attribute at the administrative boundary of the segment routing 450 domain. 452 A BGP speaker that advertises a path received from one of its 453 neighbors SHOULD advertise the BGP Prefix-SID received with the path 454 without modification, as long as the BGP Prefix-SID was acceptable. 455 If the path did not come with a BGP Prefix-SID attribute, the speaker 456 MAY attach a BGP Prefix-SID to the path if configured to do so. The 457 content of the TLVs present in the BGP Prefix-SID is determined by 458 the configuration. 460 5.1. MPLS Dataplane: Labeled Unicast 462 A BGP speaker that originates a prefix attaches the BGP Prefix-SID 463 attribute when it advertises the prefix to its neighbors via 464 Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC8277]). The value 465 of the label index in the Label-Index TLV is determined by 466 configuration. 468 A BGP speaker that originates a BGP Prefix-SID attribute MAY 469 optionally announce the Originator SRGB TLV along with the mandatory 470 Label-Index TLV. The content of the Originator SRGB TLV is 471 determined by configuration. 473 Since the label index value must be unique within an SR domain, by 474 default an implementation SHOULD NOT advertise the BGP Prefix-SID 475 attribute outside an Autonomous System unless it is explicitly 476 configured to do so. 478 In all cases, the label field of the advertised NLRI ([RFC8277], 479 [RFC4364]) MUST be set to the local/incoming label programmed in the 480 MPLS dataplane for the given advertised prefix. If the prefix is 481 associated with one of the BGP speaker's interfaces, this is the 482 usual MPLS label (such as the Implicit or Explicit NULL label 483 [IANA-MPLS-SPECIAL-LABEL]). 485 6. Error Handling of BGP Prefix-SID Attribute 487 When a BGP Speaker receives a BGP Update message containing a 488 malformed or invalid BGP Prefix-SID attribute attached to a Labeled 489 IPv4/IPv6 unicast prefix [RFC8277], it MUST ignore the received BGP 490 Prefix-SID attributes and not advertise it to other BGP peers. In 491 this context, a malformed BGP Prefix-SID attribute is one that cannot 492 be parsed due to not meeting the minimum attribute length 493 requirement, contains a TLV length that doesn't conform to the length 494 constraints for the TLV, or a contains TLV length that would extend 495 beyond the end of the attribute (as defined by the attribute length). 496 This is equivalent to the "Attribute discard" action specified in 497 [RFC7606]. When discarding an attribute, a BGP speaker SHOULD log an 498 error for further analysis. 500 Consistent with [RFC7606], only the first occurrence of the BGP 501 Prefix-SID attribute will be considered and subsequent occurrences 502 will be discarded. Similarly, only the first occurrence of a BGP 503 Prefix-SID attribute TLV of a given TLV type will be considered 504 unless the specification of that TLV type allows for multiple 505 occurrences. 507 For future extensibility, unknown TLVs MUST be ignored and propagated 508 unmodified. 510 7. IANA Considerations 512 This document defines a BGP path attribute known as the BGP Prefix- 513 SID attribute. This document requests IANA to assign an attribute 514 code type (suggested value: 40) to the BGP Prefix-SID attribute from 515 the BGP Path Attributes registry. 517 Currently, IANA temporarily assigned the following: 519 40 BGP Prefix-SID (TEMPORARY - registered 2015-09-30, expires 520 2016-09-30) [draft-ietf-idr-bgp-prefix-sid] 522 This document defines 3 TLVs for the BGP Prefix-SID attribute. These 523 TLVs need to be registered with IANA. We request IANA to create a 524 registry for BGP Prefix-SID Attribute TLVs as follows: 526 Under "Border Gateway Protocol (BGP) Parameters" registry, "BGP 527 Prefix-SID TLV Types" Reference: draft-ietf-idr-bgp-prefix-sid 528 Registration Procedure(s): Values 1-254 First Come First Served 529 (FCFS), Value 0 and 255 reserved 531 Value Type Reference 532 0 Reserved this document 533 1 Label-Index this document 534 2 Deprecated this document 535 3 Originator SRGB this document 536 4-254 Unassigned 537 255 Reserved this document 539 This document also requests creation of the "BGP Prefix-SID Label- 540 Index TLV Flags" registry under the "Border Gateway Protocol (BGP) 541 Parameters" registry, Reference: draft-ietf-idr-bgp-prefix-sid. 542 Initially, this 16 bit flags registry will be empty. Flag bits will 543 be allocated First Come First Served (FCFS) consistent with the BGP- 544 SID TLV Types registry. 546 Finally, this document requests creation of the "BGP Prefix-SID 547 Originator SRGB TLV Flags" registry under the "Border Gateway 548 Protocol (BGP) Parameters" registry, Reference: draft-ietf-idr-bgp- 549 prefix-sid. Initially, this 16 bit flags registry will be empty. 550 Flag bits will be allocated First Come First Served (FCFS) consistent 551 with the BGP-SID TLV Types registry. 553 8. Manageability Considerations 555 This document defines a BGP attribute to address use cases such as 556 the one described in [I-D.ietf-spring-segment-routing-msdc]. It is 557 assumed that advertisement of the BGP Prefix-SID attribute is 558 controlled by the operator in order to: 560 o Prevent undesired origination/advertisement of the BGP Prefix-SID 561 attribute. By default, a BGP Prefix-SID attribute SHOULD NOT be 562 attached to a prefix and advertised. Hence, BGP Prefix-SID 563 advertisement SHOULD require explicit enablement. 565 o Prevent any undesired propagation of the BGP Prefix-SID attribute. 566 By default, the BGP Prefix-SID is not advertised outside the 567 boundary of a single SR/administrative domain which may include 568 one or more ASes. The propagation to other ASes MUST be 569 explicitly configured. 571 The deployment model described in 572 [I-D.ietf-spring-segment-routing-msdc] assumes multiple Autonomous 573 Systems (ASes) under a common administrative domain. For this use 574 case, the BGP Prefix-SID advertisement is applicable to the inter-AS 575 context, i.e., EBGP, while it is confined to a single administrative 576 domain. 578 9. Security Considerations 580 This document introduces a BGP attribute (BGP Prefix-SID) which 581 inherits the security considerations expressed in: [RFC4271], 582 [RFC8277], and [I-D.ietf-spring-segment-routing]. 584 When advertised using BGPsec as described in [RFC8205], the BGP 585 Prefix-SID attribute doesn't impose any unique security 586 considerations. It should be noted that the BGP Prefix-SID attribute 587 is not protected by the BGPsec signatures. 589 It should be noted that, as described in Section 8, this document 590 refers to a deployment model where all nodes are under the single 591 administrative domain. In this context, we assume that the operator 592 doesn't want to leak any information related to internal prefixes and 593 topology outside of the administrative domain. The internal 594 information includes the BGP Prefix-SID. In order to prevent such 595 leaking, the common BGP mechanisms (filters) are applied at the 596 boundary of the SR/administrative domain. Local BGP attribute 597 filtering policies and mechanisms are not standardized and, 598 consequently, beyond the scope of this document. 600 To prevent a Denial-of-Service (DoS) or Distributed-Denial-of-Service 601 (DDoS) attack due to excessive BGP updates with an invalid or 602 conflicting BGP Prefix-SID attribute, message rate-limiting as well 603 as suppression of duplicate messages SHOULD be deployed. 605 10. Contributors 607 Keyur Patel 608 Arrcus, Inc. 609 US 611 Email: Keyur@arrcus.com 613 Saikat Ray 614 Unaffiliated 615 US 617 Email: raysaikat@gmail.com 619 11. Acknowledgements 621 The authors would like to thank Satya Mohanty for his contribution to 622 this document. 624 The authors would like to thank Alvaro Retana for substantive 625 comments as part of the Routing AD review. 627 The authors would like to thank Shyam Sethuram for comments and 628 discussion of TLV processing and validation. 630 The authors would like to thank Robert Raszuk for comments and 631 suggestions regarding the MPLS data plane behavior. 633 The authors would like to thank Krishna Deevi, Juan Alcaide, Howard 634 Yang, and Jakob Heitz for discussions on conflicting BGP Prefix-SID 635 label indices and BGP add paths. 637 The authors would like to thank Peter Yee, Tony Przygienda, Mirja 638 Kuehlewind, Alexey Melnikov, Eric Rescorla, Suresh Krishnan, Warren 639 Kumari, Ben Campbell and Sue Hares for IDR Working Group last call, 640 IETF Last Call, directorate, and IESG reviews. 642 12. References 644 12.1. Normative References 646 [I-D.ietf-spring-segment-routing] 647 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 648 Litkowski, S., and R. Shakir, "Segment Routing 649 Architecture", draft-ietf-spring-segment-routing-15 (work 650 in progress), January 2018. 652 [I-D.ietf-spring-segment-routing-mpls] 653 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 654 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 655 data plane", draft-ietf-spring-segment-routing-mpls-13 656 (work in progress), April 2018. 658 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 659 Requirement Levels", BCP 14, RFC 2119, 660 DOI 10.17487/RFC2119, March 1997, . 663 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 664 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 665 DOI 10.17487/RFC4271, January 2006, . 668 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 669 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 670 2006, . 672 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 673 "Multiprotocol Extensions for BGP-4", RFC 4760, 674 DOI 10.17487/RFC4760, January 2007, . 677 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 678 Patel, "Revised Error Handling for BGP UPDATE Messages", 679 RFC 7606, DOI 10.17487/RFC7606, August 2015, 680 . 682 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 683 "Advertisement of Multiple Paths in BGP", RFC 7911, 684 DOI 10.17487/RFC7911, July 2016, . 687 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 688 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 689 May 2017, . 691 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 692 Specification", RFC 8205, DOI 10.17487/RFC8205, September 693 2017, . 695 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 696 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 697 . 699 12.2. Informative References 701 [I-D.ietf-6man-segment-routing-header] 702 Previdi, S., Filsfils, C., Leddy, J., Matsushima, S., and 703 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 704 (SRH)", draft-ietf-6man-segment-routing-header-12 (work in 705 progress), April 2018. 707 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 708 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 709 and M. Chen, "BGP Link-State extensions for Segment 710 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-06 711 (work in progress), April 2018. 713 [I-D.ietf-idr-bgpls-segment-routing-epe] 714 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 715 Dong, "BGP-LS extensions for Segment Routing BGP Egress 716 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 717 epe-15 (work in progress), March 2018. 719 [I-D.ietf-spring-segment-routing-msdc] 720 Filsfils, C., Previdi, S., Mitchell, J., Aries, E., and P. 721 Lapukhov, "BGP-Prefix Segment in large-scale data 722 centers", draft-ietf-spring-segment-routing-msdc-08 (work 723 in progress), December 2017. 725 [IANA-MPLS-SPECIAL-LABEL] 726 "IANA Special-Purpose Multiprotocol Label Switching (MPLS) 727 Label Values Registry", . 730 [RFC5004] Chen, E. and S. Sangli, "Avoid BGP Best Path Transitions 731 from One External to Another", RFC 5004, 732 DOI 10.17487/RFC5004, September 2007, . 735 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 736 S. Ray, "North-Bound Distribution of Link-State and 737 Traffic Engineering (TE) Information Using BGP", RFC 7752, 738 DOI 10.17487/RFC7752, March 2016, . 741 Authors' Addresses 743 Stefano Previdi (editor) 744 Cisco Systems 745 IT 747 Email: stefano@previdi.net 749 Clarence Filsfils 750 Cisco Systems 751 Brussels 752 Belgium 754 Email: cfilsfils@cisco.com 755 Acee Lindem (editor) 756 Cisco Systems 757 301 Midenhall Way 758 Cary, NC 27513 759 USA 761 Email: acee@cisco.com 763 Arjun Sreekantiah 765 Email: arjunhrs@gmail.com 767 Hannes Gredler 768 RtBrick Inc. 770 Email: hannes@rtbrick.com