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