idnits 2.17.1 draft-ietf-idr-bgp-prefix-sid-21.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 29, 2018) is 2159 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-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-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 30, 2018 Cisco Systems 6 A. Sreekantiah 8 H. Gredler 9 RtBrick Inc. 10 May 29, 2018 12 Segment Routing Prefix SID extensions for BGP 13 draft-ietf-idr-bgp-prefix-sid-21 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 November 30, 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 (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 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 [RFC3032] from a neighbor MUST 438 adhere to standard behavior and program its MPLS dataplane to pop the 439 top label when forwarding traffic to the prefix. The label NLRI 440 defines the outbound label that MUST be used by the receiving node. 442 5. Advertising BGP Prefix-SID Attribute 444 The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes 445 (IPv4/IPv6) [RFC8277]. In order to prevent distribution of the BGP 446 Prefix-SID attribute beyond its intended scope of applicability, 447 attribute filtering SHOULD be deployed to remove the BGP Prefix-SID 448 attribute at the administrative boundary of the segment routing 449 domain. 451 A BGP speaker that advertises a path received from one of its 452 neighbors SHOULD advertise the BGP Prefix-SID received with the path 453 without modification, as long as the BGP Prefix-SID was acceptable. 454 If the path did not come with a BGP Prefix-SID attribute, the speaker 455 MAY attach a BGP Prefix-SID to the path if configured to do so. The 456 content of the TLVs present in the BGP Prefix-SID is determined by 457 the configuration. 459 5.1. MPLS Dataplane: Labeled Unicast 461 A BGP speaker that originates a prefix attaches the BGP Prefix-SID 462 attribute when it advertises the prefix to its neighbors via 463 Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC8277]). The value 464 of the label index in the Label-Index TLV is determined by 465 configuration. 467 A BGP speaker that originates a BGP Prefix-SID attribute MAY 468 optionally announce the Originator SRGB TLV along with the mandatory 469 Label-Index TLV. The content of the Originator SRGB TLV is 470 determined by configuration. 472 Since the label index value must be unique within an SR domain, by 473 default an implementation SHOULD NOT advertise the BGP Prefix-SID 474 attribute outside an Autonomous System unless it is explicitly 475 configured to do so. 477 In all cases, the label field of the advertised NLRI ([RFC8277], 478 [RFC4364]) MUST be set to the local/incoming label programmed in the 479 MPLS dataplane for the given advertised prefix. If the prefix is 480 associated with one of the BGP speaker's interfaces, this is the 481 usual MPLS label (such as the Implicit or Explicit NULL label 482 [RFC3032]). 484 6. Error Handling of BGP Prefix-SID Attribute 486 When a BGP Speaker receives a BGP Update message containing a 487 malformed or invalid BGP Prefix-SID attribute attached to a Labeled 488 IPv4/IPv6 unicast prefix [RFC8277], it MUST ignore the received BGP 489 Prefix-SID attributes and not advertise it to other BGP peers. In 490 this context, a malformed BGP Prefix-SID attribute is one that cannot 491 be parsed due to not meeting the minimum attribute length 492 requirement, contains a TLV length that doesn't conform to the length 493 constraints for the TLV, or a contains TLV length that would extend 494 beyond the end of the attribute (as defined by the attribute length). 495 This is equivalent to the "Attribute discard" action specified in 496 [RFC7606]. When discarding an attribute, a BGP speaker SHOULD log an 497 error for further analysis. 499 Consistent with [RFC7606], only the first occurrence of the BGP 500 Prefix-SID attribute will be considered and subsequent occurrences 501 will be discarded. Similarly, only the first occurrence of a BGP 502 Prefix-SID attribute TLV of a given TLV type will be considered 503 unless the specification of that TLV type allows for multiple 504 occurrences. 506 For future extensibility, unknown TLVs MUST be ignored and propagated 507 unmodified. 509 7. IANA Considerations 511 This document defines a BGP path attribute known as the BGP Prefix- 512 SID attribute. This document requests IANA to assign an attribute 513 code type (suggested value: 40) to the BGP Prefix-SID attribute from 514 the BGP Path Attributes registry. 516 Currently, IANA temporarily assigned the following: 518 40 BGP Prefix-SID (TEMPORARY - registered 2015-09-30, expires 519 2016-09-30) [draft-ietf-idr-bgp-prefix-sid] 521 This document defines 3 TLVs for the BGP Prefix-SID attribute. These 522 TLVs need to be registered with IANA. We request IANA to create a 523 registry for BGP Prefix-SID Attribute TLVs as follows: 525 Under "Border Gateway Protocol (BGP) Parameters" registry, "BGP 526 Prefix-SID TLV Types" Reference: draft-ietf-idr-bgp-prefix-sid 527 Registration Procedure(s): Values 1-254 First Come First Served 528 (FCFS), Value 0 and 255 reserved 530 Value Type Reference 531 0 Reserved this document 532 1 Label-Index this document 533 2 Deprecated this document 534 3 Originator SRGB this document 535 4-254 Unassigned 536 255 Reserved this document 538 This document also requests creation of the "BGP Prefix-SID Label- 539 Index TLV Flags" registry under the "Border Gateway Protocol (BGP) 540 Parameters" registry, Reference: draft-ietf-idr-bgp-prefix-sid. 541 Initially, this 16 bit flags registry will be empty. Flag bits will 542 be allocated First Come First Served (FCFS) consistent with the BGP- 543 SID TLV Types registry. 545 Finally, this document requests creation of the "BGP Prefix-SID 546 Originator SRGB TLV Flags" registry under the "Border Gateway 547 Protocol (BGP) Parameters" registry, Reference: draft-ietf-idr-bgp- 548 prefix-sid. Initially, this 16 bit flags registry will be empty. 549 Flag bits will be allocated First Come First Served (FCFS) consistent 550 with the BGP-SID TLV Types registry. 552 8. Manageability Considerations 554 This document defines a BGP attribute to address use cases such as 555 the one described in [I-D.ietf-spring-segment-routing-msdc]. It is 556 assumed that advertisement of the BGP Prefix-SID attribute is 557 controlled by the operator in order to: 559 o Prevent undesired origination/advertisement of the BGP Prefix-SID 560 attribute. By default, a BGP Prefix-SID attribute SHOULD NOT be 561 attached to a prefix and advertised. Hence, BGP Prefix-SID 562 advertisement SHOULD require explicit enablement. 564 o Prevent any undesired propagation of the BGP Prefix-SID attribute. 565 By default, the BGP Prefix-SID is not advertised outside the 566 boundary of a single SR/administrative domain which may include 567 one or more ASes. The propagation to other ASes MUST be 568 explicitly configured. 570 The deployment model described in 571 [I-D.ietf-spring-segment-routing-msdc] assumes multiple Autonomous 572 Systems (ASes) under a common administrative domain. For this use 573 case, the BGP Prefix-SID advertisement is applicable to the inter-AS 574 context, i.e., EBGP, while it is confined to a single administrative 575 domain. 577 9. Security Considerations 579 This document introduces a BGP attribute (BGP Prefix-SID) which 580 inherits the security considerations expressed in: [RFC4271], 581 [RFC8277], and [I-D.ietf-spring-segment-routing]. 583 When advertised using BGPsec as described in [RFC8205], the BGP 584 Prefix-SID attribute doesn't impose any unique security 585 considerations. It should be noted that the BGP Prefix-SID attribute 586 is not protected by the BGPsec signatures. 588 It should be noted that, as described in Section 8, this document 589 refers to a deployment model where all nodes are under the single 590 administrative domain. In this context, we assume that the operator 591 doesn't want to leak any information related to internal prefixes and 592 topology outside of the administrative domain. The internal 593 information includes the BGP Prefix-SID. In order to prevent such 594 leaking, the common BGP mechanisms (filters) are applied at the 595 boundary of the SR/administrative domain. Local BGP attribute 596 filtering policies and mechanisms are not standardized and, 597 consequently, beyond the scope of this document. 599 To prevent a Denial-of-Service (DoS) or Distributed-Denial-of-Service 600 (DDoS) attack due to excessive BGP updates with an invalid or 601 conflicting BGP Prefix-SID attribute, message rate-limiting as well 602 as suppression of duplicate messages SHOULD be deployed. 604 10. Contributors 606 Keyur Patel 607 Arrcus, Inc. 608 US 610 Email: Keyur@arrcus.com 612 Saikat Ray 613 Unaffiliated 614 US 616 Email: raysaikat@gmail.com 618 11. Acknowledgements 620 The authors would like to thank Satya Mohanty for his contribution to 621 this document. 623 The authors would like to thank Alvaro Retana for substantive 624 comments as part of the Routing AD review. 626 The authors would like to thank Shyam Sethuram for comments and 627 discussion of TLV processing and validation. 629 The authors would like to thank Robert Raszuk for comments and 630 suggestions regarding the MPLS data plane behavior. 632 The authors would like to thank Krishna Deevi, Juan Alcaide, Howard 633 Yang, and Jakob Heitz for discussions on conflicting BGP Prefix-SID 634 label indices and BGP add paths. 636 The authors would like to thank Peter Yee, Tony Przygienda, Mirja 637 Kuehlewind, Alexey Melnikov, Eric Rescorla, Suresh Krishnan, Warren 638 Kumari, Ben Campbell and Sue Hares for IDR Working Group last call, 639 IETF Last Call, directorate, and IESG reviews. 641 12. References 643 12.1. Normative References 645 [I-D.ietf-spring-segment-routing] 646 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 647 Litkowski, S., and R. Shakir, "Segment Routing 648 Architecture", draft-ietf-spring-segment-routing-15 (work 649 in progress), January 2018. 651 [I-D.ietf-spring-segment-routing-mpls] 652 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 653 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 654 data plane", draft-ietf-spring-segment-routing-mpls-13 655 (work in progress), April 2018. 657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 658 Requirement Levels", BCP 14, RFC 2119, 659 DOI 10.17487/RFC2119, March 1997, . 662 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 663 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 664 DOI 10.17487/RFC4271, January 2006, . 667 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 668 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 669 2006, . 671 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 672 "Multiprotocol Extensions for BGP-4", RFC 4760, 673 DOI 10.17487/RFC4760, January 2007, . 676 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 677 Patel, "Revised Error Handling for BGP UPDATE Messages", 678 RFC 7606, DOI 10.17487/RFC7606, August 2015, 679 . 681 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 682 "Advertisement of Multiple Paths in BGP", RFC 7911, 683 DOI 10.17487/RFC7911, July 2016, . 686 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 687 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 688 May 2017, . 690 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 691 Specification", RFC 8205, DOI 10.17487/RFC8205, September 692 2017, . 694 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 695 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 696 . 698 12.2. Informative References 700 [I-D.ietf-6man-segment-routing-header] 701 Previdi, S., Filsfils, C., Leddy, J., Matsushima, S., and 702 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 703 (SRH)", draft-ietf-6man-segment-routing-header-13 (work in 704 progress), May 2018. 706 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 707 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 708 and M. Chen, "BGP Link-State extensions for Segment 709 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-08 710 (work in progress), May 2018. 712 [I-D.ietf-idr-bgpls-segment-routing-epe] 713 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 714 Dong, "BGP-LS extensions for Segment Routing BGP Egress 715 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 716 epe-15 (work in progress), March 2018. 718 [I-D.ietf-spring-segment-routing-msdc] 719 Filsfils, C., Previdi, S., Mitchell, J., Aries, E., and P. 720 Lapukhov, "BGP-Prefix Segment in large-scale data 721 centers", draft-ietf-spring-segment-routing-msdc-08 (work 722 in progress), December 2017. 724 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 725 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 726 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 727 . 729 [RFC5004] Chen, E. and S. Sangli, "Avoid BGP Best Path Transitions 730 from One External to Another", RFC 5004, 731 DOI 10.17487/RFC5004, September 2007, . 734 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 735 S. Ray, "North-Bound Distribution of Link-State and 736 Traffic Engineering (TE) Information Using BGP", RFC 7752, 737 DOI 10.17487/RFC7752, March 2016, . 740 Authors' Addresses 742 Stefano Previdi (editor) 743 Cisco Systems 744 IT 746 Email: stefano@previdi.net 748 Clarence Filsfils 749 Cisco Systems 750 Brussels 751 Belgium 753 Email: cfilsfils@cisco.com 754 Acee Lindem (editor) 755 Cisco Systems 756 301 Midenhall Way 757 Cary, NC 27513 758 USA 760 Email: acee@cisco.com 762 Arjun Sreekantiah 764 Email: arjunhrs@gmail.com 766 Hannes Gredler 767 RtBrick Inc. 769 Email: hannes@rtbrick.com