idnits 2.17.1 draft-ietf-idr-bgp-prefix-sid-23.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 14, 2018) is 2143 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) == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-14 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-13 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-08 == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-15 == Outdated reference: A later version (-11) exists of draft-ietf-spring-segment-routing-msdc-09 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR S. Previdi, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track A. Lindem, Ed. 5 Expires: December 16, 2018 Cisco Systems 6 A. Sreekantiah 8 H. Gredler 9 RtBrick Inc. 10 June 14, 2018 12 Segment Routing Prefix SID extensions for BGP 13 draft-ietf-idr-bgp-prefix-sid-23 15 Abstract 17 The Segment Routing (SR) architecture allows a node to steer a packet 18 flow through any topological path and service chain by leveraging 19 source routing. The ingress node prepends an SR header to a packet 20 containing a set of segment identifiers (SID). Each SID represents a 21 topological or a service-based instruction. Per-flow state is 22 maintained only on the ingress node of the SR domain. An SR domain 23 is defined as a single administrative domain for global SID 24 assignment. 26 This document defines an optional, transitive BGP attribute for 27 announcing BGP Prefix Segment Identifiers (BGP Prefix-SID) 28 information. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 34 "OPTIONAL" in this document are to be interpreted as described in BCP 35 14 [RFC2119] [RFC8174] when, and only when, they appear in all 36 capitals, as shown here. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on December 16, 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 . . . . . . . . . . . . . . . . . . . 6 78 4. Receiving BGP Prefix-SID Attribute . . . . . . . . . . . . . 8 79 4.1. MPLS Dataplane: Labeled Unicast . . . . . . . . . . . . . 8 80 5. Advertising BGP Prefix-SID Attribute . . . . . . . . . . . . 9 81 5.1. MPLS Dataplane: Labeled Unicast . . . . . . . . . . . . . 10 82 6. Error Handling of BGP Prefix-SID Attribute . . . . . . . . . 10 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 8. Manageability Considerations . . . . . . . . . . . . . . . . 12 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 87 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 90 12.2. Informative References . . . . . . . . . . . . . . . . . 15 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 The Segment Routing (SR) architecture leverages the source routing 96 paradigm. A group of inter-connected nodes that use SR forms an SR 97 domain. A segment represents either a topological instruction such 98 as "go to prefix P following shortest path" or a service instruction. 99 Other types of segments may be defined in the future. 101 A segment is identified through a Segment Identifier (SID). An SR 102 domain is defined as a single administrative domain for global SID 103 assignment. It may be comprised of a single Autonomous System (AS) 104 or multiple ASes under consolidated global SID administration. 105 Typically, the ingress node of the SR domain prepends an SR header 106 containing segments identifiers (SIDs) to an incoming packet. 108 As described in [I-D.ietf-spring-segment-routing], when SR is applied 109 to the MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]), the 110 SID consists of a label. 112 [I-D.ietf-spring-segment-routing] also describes how segment routing 113 can be applied to an IPv6 dataplane (SRv6) using an IPv6 routing 114 header containing a stack of SR SIDs encoded as IPv6 addresses 115 [I-D.ietf-6man-segment-routing-header]. The applicability and 116 support for Segment Routing over IPv6 is beyond the scope of this 117 document. 119 A BGP-Prefix Segment is a BGP prefix with a Prefix-SID attached. A 120 BGP Prefix-SID is always a global SID 121 ([I-D.ietf-spring-segment-routing]) within the SR domain (i.e., the 122 set of Autonomous Systems under a common administration and control 123 and where SR is used) and identifies an instruction to forward the 124 packet over the Equal-Cost Multi-Path (ECMP) best-path computed by 125 BGP to the related prefix. The BGP Prefix-SID is the identifier of 126 the BGP prefix segment. In this document, we always refer to the BGP 127 segment by the BGP Prefix-SID. 129 This document describes the BGP extension to signal the BGP Prefix- 130 SID. Specifically, this document defines a BGP attribute known as 131 the BGP Prefix-SID attribute and specifies the rules to originate, 132 receive, and handle error conditions for the attribute. 134 The BGP Prefix-SID attribute defined in this document can be attached 135 to prefixes from Multiprotocol BGP IPv4/IPv6 Labeled Unicast 136 ([RFC4760], [RFC8277]). Usage of the BGP Prefix-SID attribute for 137 other Address Family Identifier (AFI)/ Subsequent Address Family 138 Identifier (SAFI) combinations is not defined herein but may be 139 specified in future specifications. 141 [I-D.ietf-spring-segment-routing-msdc] describes example use cases 142 where the BGP Prefix-SID is used for the above AFI/SAFI combinations. 144 It should be noted that: 146 o A BGP Prefix-SID MAY be global across ASes when the interconnected 147 ASes agree on the SID allocation scheme. Alternatively, when 148 interconnecting ASes, the ASBRs of each domain will have to handle 149 the advertisement of unique SIDs. The mechanisms for such 150 interconnection are outside the scope of the protocol extensions 151 defined in this document. 153 o A BGP Prefix-SID MAY be attached to a prefix. This implies that 154 each prefix is advertised individually, reducing the ability to 155 pack BGP advertisements (when sharing common attributes). 157 2. BGP-Prefix-SID 159 The BGP Prefix-SID advertised for BGP prefix P indicates that the 160 segment routed path should be used (as described below) if the BGP 161 best path selects the corresponding Network Layer Reachability 162 Information (NLRI). 164 2.1. MPLS BGP Prefix SID 166 The BGP Prefix-SID is realized on the MPLS dataplane 167 ([I-D.ietf-spring-segment-routing-mpls]) in the following way: 169 The operator assigns a globally unique label index, L_I, to a 170 locally originated prefix of a BGP speaker N which is advertised 171 to all other BGP speakers in the SR domain. 173 According to [I-D.ietf-spring-segment-routing], each BGP speaker 174 is configured with a label block called the Segment Routing Global 175 Block (SRGB). While [I-D.ietf-spring-segment-routing] recommends 176 using the same SRGB across all the nodes within the SR domain, the 177 SRGB of a node is a local property and could be different on 178 different speakers. The drawbacks of the use case where BGP 179 speakers have different SRGBs are documented in 180 [I-D.ietf-spring-segment-routing] and 181 [I-D.ietf-spring-segment-routing-msdc]. 183 If traffic-engineering within the SR domain is required, each node 184 may also be required to advertise topological information and 185 Peering SIDs for each of its links and peers. This information is 186 required to perform the explicit path computation and to express 187 an explicit path as a list of SIDs. The advertisement of 188 topological information and peer segments (Peer SIDs) is done 189 through [I-D.ietf-idr-bgpls-segment-routing-epe]. 191 If the BGP speakers are not all configured with the same SRGB, and 192 if traffic-engineering within the SR domain is required, each node 193 may be required to advertise its local SRGB in addition to the 194 topological information. 196 This document assumes that BGP-LS is the preferred method for 197 collecting both peer segments (Peer SIDs) and SRGB information 198 through [RFC7752], [I-D.ietf-idr-bgpls-segment-routing-epe], and 199 [I-D.ietf-idr-bgp-ls-segment-routing-ext]. However, as an 200 optional alternative for the advertisement of the local SRGB 201 without the topology nor the peer SIDs, hence without 202 applicability for TE, the Originator SRGB TLV of the BGP Prefix- 203 SID attribute is specified in Section 3.2 of this document. 205 A BGP speaker will derive its local MPLS label L from the label 206 index L_I and its local SRGB as described in 207 [I-D.ietf-spring-segment-routing-mpls]. The BGP speaker then 208 programs the MPLS label L in its MPLS dataplane as its incoming/ 209 local label for the prefix. See Section 4.1 for more details. 211 The outgoing label for the prefix is found in the NLRI of the 212 Multiprotocol BGP IPv4/IPv6 Labeled Unicast prefix advertisement 213 as defined in [RFC8277]. The label index L_I is only used as a 214 hint to derive the local/incoming label. 216 Section 3.1 of this document specifies the Label-Index TLV of the 217 BGP Prefix-SID attribute; this TLV can be used to advertise the 218 label index for a given prefix. 220 3. BGP Prefix-SID Attribute 222 The BGP Prefix-SID attribute is an optional, transitive BGP path 223 attribute. The attribute type code 40 has been assigned by IANA (see 224 Section 7). 226 The BGP Prefix-SID attribute is defined here to be a set of elements 227 encoded as "Type/Length/Value" tuples (i.e., a set of TLVs). All BGP 228 Prefix-SID attribute TLVs will start with a 1-octet type and a 229 2-octet length. The following TLVs are defined in this document: 231 o Label-Index TLV 233 o Originator SRGB TLV 234 The Label-Index and Originator SRGB TLVs are used only when SR is 235 applied to the MPLS dataplane. 237 For future extensibility, unknown TLVs MUST be ignored and propagated 238 unmodified. 240 3.1. Label-Index TLV 242 The Label-Index TLV MUST be present in the BGP Prefix-SID attribute 243 attached to IPv4/IPv6 Labeled Unicast prefixes ([RFC8277]). It MUST 244 be ignored when received for other BGP AFI/SAFI combinations. The 245 Label-Index TLV has the following format: 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type | Length | RESERVED | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Flags | Label Index | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Label Index | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 where: 259 o Type is 1. 261 o Length: is 7, the total length in octets of the value portion of 262 the TLV. 264 o RESERVED: 8-bit field. MUST be clear on transmission and MUST be 265 ignored on reception. 267 o Flags: 16 bits of flags. None are defined by this document. The 268 flag field MUST be clear on transmission and MUST be ignored on 269 reception. 271 o Label Index: 32-bit value representing the index value in the SRGB 272 space. 274 3.2. Originator SRGB TLV 276 The Originator SRGB TLV is an optional TLV and has the following 277 format: 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Type | Length | Flags | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Flags | 285 +-+-+-+-+-+-+-+-+ 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | SRGB 1 (6 octets) | 289 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | SRGB n (6 octets) | 295 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 where: 301 o Type is 3. 303 o Length is the total length in octets of the value portion of the 304 TLV: 2 + (non-zero multiple of 6). 306 o Flags: 16 bits of flags. None are defined in this document. 307 Flags MUST be clear on transmission and MUST be ignored on 308 reception. 310 o SRGB: 3 octets specifying the first label in the range followed by 311 3 octets specifying the number of labels in the range. Note that 312 the SRGB field MAY appear multiple times. If the SRGB field 313 appears multiple times, the SRGB consists of multiple ranges that 314 are concatenated. 316 The Originator SRGB TLV contains the SRGB of the node originating the 317 prefix to which the BGP Prefix-SID is attached. The Originator SRGB 318 TLV MUST NOT be changed during the propagation of the BGP update. It 319 is used to build segment routing policies when different SRGBs are 320 used in the fabric, for example 321 ([I-D.ietf-spring-segment-routing-msdc]). 323 Examples of how the receiving routers concatenate the ranges and 324 build their neighbor's Segment Routing Global Block (SRGB) are 325 included in [I-D.ietf-spring-segment-routing-mpls]). 327 The originator SRGB may only appear in a BGP Prefix-SID attribute 328 attached to IPv4/IPv6 Labeled Unicast prefixes ([RFC8277]). It MUST 329 be ignored when received for other BGP AFI/SAFI combinations. Since 330 the Label-Index TLV is required for IPv4/IPv6 prefix applicability, 331 the originator SRGB will be ignored if it is not specified consistent 332 with Section 6. 334 4. Receiving BGP Prefix-SID Attribute 336 A BGP speaker receiving a BGP Prefix-SID attribute from an External 337 BGP (EBGP) neighbor residing outside the boundaries of the SR domain 338 MUST discard the attribute unless it is configured to accept the 339 attribute from the EBGP neighbor. A BGP speaker SHOULD log an error 340 for further analysis when discarding an attribute. 342 4.1. MPLS Dataplane: Labeled Unicast 344 A BGP session supporting the Multiprotocol BGP labeled IPv4 or IPv6 345 Unicast ([RFC8277]) AFI/SAFI is required. 347 When the BGP Prefix-SID attribute is attached to a BGP labeled IPv4 348 or IPv6 Unicast [RFC8277] AFI/SAFI, it MUST contain the Label-Index 349 TLV and MAY contain the Originator SRGB TLV. A BGP Prefix-SID 350 attribute received without a Label-Index TLV MUST be considered as 351 "invalid" by the receiving speaker. 353 The label index provides guidance to the receiving BGP speaker as to 354 the incoming label that SHOULD be allocated to the prefix. 356 A BGP speaker may be locally configured with an SRGB=[SRGB_Start, 357 SRGB_End]. The preferred method for deriving the SRGB is a matter of 358 local node configuration. 360 The mechanisms through which a given label index value is assigned to 361 a given prefix are outside the scope of this document. 363 Given a label index L_I, we refer to (L = L_I + SRGB_Start) as the 364 derived label. A BGP Prefix-SID attribute is designated 365 "conflicting" for a speaker M if the derived label value L lies 366 outside the SRGB configured on M. Otherwise the Label-Index TLV is 367 designated "acceptable" to speaker M. 369 If multiple different prefixes are received with the same label 370 index, all of the different prefixes MUST have their BGP Prefix-SID 371 attribute considered as "conflicting". 373 If multiple valid paths for the same prefix are received from 374 multiple BGP speakers or, in the case of [RFC7911], from the same BGP 375 speaker, and the BGP Prefix-SID attributes do not contain the same 376 label index, then the label index from the best path BGP Prefix-SID 377 attribute SHOULD be chosen with a notable exception being when 378 [RFC5004] is being used to dampen route changes. 380 When a BGP speaker receives a path from a neighbor with an 381 "acceptable" BGP Prefix-SID attribute and that path is selected as 382 the best path, it SHOULD program the derived label as the label for 383 the prefix in its local MPLS dataplane. 385 When a BGP speaker receives a path from a neighbor with an "invalid" 386 or "conflicting" BGP Prefix-SID attribute or when a BGP speaker 387 receives a path from a neighbor with a BGP Prefix-SID attribute but 388 is unable to process it (e.g., local policy disables the 389 functionality), it MUST ignore the BGP Prefix-SID attribute. For the 390 purposes of label allocation, a BGP speaker MUST assign a local (also 391 called dynamic) label (non-SRGB) for such a prefix as per classic 392 Multiprotocol BGP IPv4/IPv6 Labeled Unicast ([RFC8277]) operation. 394 In the case of an "invalid" BGP Prefix-SID attribute, a BGP speaker 395 MUST follow the error handling rules specified in Section 6. A BGP 396 speaker SHOULD log an error for further analysis. In the case of a 397 "conflicting" BGP Prefix-SID attribute, a BGP speaker SHOULD NOT 398 treat it as error and SHOULD propagate the attribute unchanged. A 399 BGP Speaker SHOULD log a warning for further analysis, i.e., in the 400 case the conflict is not due to a label index transition. 402 When a BGP Prefix-SID attribute changes and transitions from 403 "conflicting" to "acceptable", the BGP Prefix-SID attributes for 404 other prefixes may also transition to "acceptable" as well. 405 Implementations SHOULD assure all impacted prefixes revert to using 406 the label indices corresponding to these newly "acceptable" BGP 407 Prefix-SID attributes. 409 The outgoing label is always programmed as per classic Multiprotocol 410 BGP IPv4/IPv6 Labeled Unicast ([RFC8277]) operation. Specifically, a 411 BGP speaker receiving a prefix with a BGP Prefix-SID attribute and a 412 label NLRI field of Implicit NULL [RFC3032] from a neighbor MUST 413 adhere to standard behavior and program its MPLS dataplane to pop the 414 top label when forwarding traffic to the prefix. The label NLRI 415 defines the outbound label that MUST be used by the receiving node. 417 5. Advertising BGP Prefix-SID Attribute 419 The BGP Prefix-SID attribute MAY be attached to BGP IPv4/IPv6 Label 420 Unicast prefixes [RFC8277]. In order to prevent distribution of the 421 BGP Prefix-SID attribute beyond its intended scope of applicability, 422 attribute filtering SHOULD be deployed to remove the BGP Prefix-SID 423 attribute at the administrative boundary of the segment routing 424 domain. 426 A BGP speaker that advertises a path received from one of its 427 neighbors SHOULD advertise the BGP Prefix-SID received with the path 428 without modification, as long as the BGP Prefix-SID was acceptable. 429 If the path did not come with a BGP Prefix-SID attribute, the speaker 430 MAY attach a BGP Prefix-SID to the path if configured to do so. The 431 content of the TLVs present in the BGP Prefix-SID is determined by 432 the configuration. 434 5.1. MPLS Dataplane: Labeled Unicast 436 A BGP speaker that originates a prefix attaches the BGP Prefix-SID 437 attribute when it advertises the prefix to its neighbors via 438 Multiprotocol BGP IPv4/IPv6 Labeled Unicast ([RFC8277]). The value 439 of the label index in the Label-Index TLV is determined by 440 configuration. 442 A BGP speaker that originates a BGP Prefix-SID attribute MAY 443 optionally announce the Originator SRGB TLV along with the mandatory 444 Label-Index TLV. The content of the Originator SRGB TLV is 445 determined by configuration. 447 Since the label index value must be unique within an SR domain, by 448 default an implementation SHOULD NOT advertise the BGP Prefix-SID 449 attribute outside an Autonomous System unless it is explicitly 450 configured to do so. 452 In all cases, the label field of the advertised NLRI ([RFC8277], 453 [RFC4364]) MUST be set to the local/incoming label programmed in the 454 MPLS dataplane for the given advertised prefix. If the prefix is 455 associated with one of the BGP speaker's interfaces, this is the 456 usual MPLS label (such as the Implicit or Explicit NULL label 457 [RFC3032]). 459 6. Error Handling of BGP Prefix-SID Attribute 461 When a BGP Speaker receives a BGP Update message containing a 462 malformed or invalid BGP Prefix-SID attribute attached to a IPv4/IPv6 463 Labeled Unicast prefix [RFC8277], it MUST ignore the received BGP 464 Prefix-SID attributes and not advertise it to other BGP peers. In 465 this context, a malformed BGP Prefix-SID attribute is one that cannot 466 be parsed due to not meeting the minimum attribute length 467 requirement, contains a TLV length that doesn't conform to the length 468 constraints for the TLV, or a contains TLV length that would extend 469 beyond the end of the attribute (as defined by the attribute length). 470 This is equivalent to the "Attribute discard" action specified in 472 [RFC7606]. When discarding an attribute, a BGP speaker SHOULD log an 473 error for further analysis. 475 As per with [RFC7606], if the BGP Prefix-SID attribute appears more 476 than once in an UPDATE message, then all the occurrences of the 477 attribute other than the first one SHALL be discarded and the UPDATE 478 message will continue to be processed. Similarly, if a recognized 479 TLV appears more than once in an BGP Prefix-SID attribute while the 480 specification only allows for a single occurrence, then all the 481 occurrences of the TLV other than the first one SHALL be discarded 482 and the Prefix-SID attribute will continue to be processed. 484 For future extensibility, unknown TLVs MUST be ignored and propagated 485 unmodified. 487 7. IANA Considerations 489 This document defines a BGP path attribute known as the BGP Prefix- 490 SID attribute. This document requests IANA to assign an attribute 491 code type (suggested value: 40) to the BGP Prefix-SID attribute from 492 the BGP Path Attributes registry. 494 Currently, IANA temporarily assigned the following: 496 40 BGP Prefix-SID (TEMPORARY - registered 2015-09-30, expires 497 2016-09-30) [draft-ietf-idr-bgp-prefix-sid] 499 This document defines 3 TLVs for the BGP Prefix-SID attribute. These 500 TLVs need to be registered with IANA. We request IANA to create a 501 registry for BGP Prefix-SID Attribute TLVs as follows: 503 Under "Border Gateway Protocol (BGP) Parameters" registry, "BGP 504 Prefix-SID TLV Types" Reference: draft-ietf-idr-bgp-prefix-sid 505 Registration Procedure(s): Values 1-254 First Come First Served 506 (FCFS), Value 0 and 255 reserved 508 Value Type Reference 509 0 Reserved this document 510 1 Label-Index this document 511 2 Deprecated this document 512 3 Originator SRGB this document 513 4-254 Unassigned 514 255 Reserved this document 516 This document also requests creation of the "BGP Prefix-SID Label- 517 Index TLV Flags" registry under the "Border Gateway Protocol (BGP) 518 Parameters" registry, Reference: draft-ietf-idr-bgp-prefix-sid. 519 Initially, this 16-bit flags registry will be empty. Flag bits will 520 be allocated First Come First Served (FCFS) consistent with the BGP 521 Prefix-SID TLV Types registry. 523 Finally, this document requests creation of the "BGP Prefix-SID 524 Originator SRGB TLV Flags" registry under the "Border Gateway 525 Protocol (BGP) Parameters" registry, Reference: draft-ietf-idr-bgp- 526 prefix-sid. Initially, this 16-bit flags registry will be empty. 527 Flag bits will be allocated First Come First Served (FCFS) consistent 528 with the BGP Prefix-SID TLV Types registry. 530 8. Manageability Considerations 532 This document defines a BGP attribute to address use cases such as 533 the one described in [I-D.ietf-spring-segment-routing-msdc]. It is 534 assumed that advertisement of the BGP Prefix-SID attribute is 535 controlled by the operator in order to: 537 o Prevent undesired origination/advertisement of the BGP Prefix-SID 538 attribute. By default, a BGP Prefix-SID attribute SHOULD NOT be 539 attached to a prefix and advertised. Hence, BGP Prefix-SID 540 advertisement SHOULD require explicit enablement. 542 o Prevent any undesired propagation of the BGP Prefix-SID attribute. 543 By default, the BGP Prefix-SID is not advertised outside the 544 boundary of a single SR/administrative domain which may include 545 one or more ASes. The propagation to other ASes MUST be 546 explicitly configured. 548 The deployment model described in 549 [I-D.ietf-spring-segment-routing-msdc] assumes multiple Autonomous 550 Systems (ASes) under a common administrative domain. For this use 551 case, the BGP Prefix-SID advertisement is applicable to the inter-AS 552 context, i.e., EBGP, while it is confined to a single administrative 553 domain. 555 9. Security Considerations 557 This document introduces a BGP attribute (BGP Prefix-SID) which 558 inherits the security considerations expressed in: [RFC4271], 559 [RFC8277], and [I-D.ietf-spring-segment-routing]. 561 When advertised using BGPsec as described in [RFC8205], the BGP 562 Prefix-SID attribute doesn't impose any unique security 563 considerations. It should be noted that the BGP Prefix-SID attribute 564 is not protected by the BGPsec signatures. 566 It should be noted that, as described in Section 8, this document 567 refers to a deployment model where all nodes are under the single 568 administrative domain. In this context, we assume that the operator 569 doesn't want to leak any information related to internal prefixes and 570 topology outside of the administrative domain. The internal 571 information includes the BGP Prefix-SID. In order to prevent such 572 leaking, the common BGP mechanisms (filters) are applied at the 573 boundary of the SR/administrative domain. Local BGP attribute 574 filtering policies and mechanisms are not standardized and, 575 consequently, beyond the scope of this document. 577 To prevent a Denial-of-Service (DoS) or Distributed-Denial-of-Service 578 (DDoS) attack due to excessive BGP updates with an invalid or 579 conflicting BGP Prefix-SID attribute, error log message rate-limiting 580 as well as suppression of duplicate error log messages SHOULD be 581 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 Bruno Decraene for substantive 606 comments and suggested text as part of the Routing Directorate 607 review. 609 The authors would like to thank Shyam Sethuram for comments and 610 discussion of TLV processing and validation. 612 The authors would like to thank Robert Raszuk for comments and 613 suggestions regarding the MPLS data plane behavior. 615 The authors would like to thank Krishna Deevi, Juan Alcaide, Howard 616 Yang, and Jakob Heitz for discussions on conflicting BGP Prefix-SID 617 label indices and BGP add paths. 619 The authors would like to thank Peter Yee, Tony Przygienda, Mirja 620 Kuehlewind, Alexey Melnikov, Eric Rescorla, Suresh Krishnan, Warren 621 Kumari, Ben Campbell and Sue Hares for IDR Working Group last call, 622 IETF Last Call, directorate, and IESG reviews. 624 12. References 626 12.1. Normative References 628 [I-D.ietf-spring-segment-routing] 629 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 630 Litkowski, S., and R. Shakir, "Segment Routing 631 Architecture", draft-ietf-spring-segment-routing-15 (work 632 in progress), January 2018. 634 [I-D.ietf-spring-segment-routing-mpls] 635 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 636 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 637 data plane", draft-ietf-spring-segment-routing-mpls-14 638 (work in progress), June 2018. 640 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 641 Requirement Levels", BCP 14, RFC 2119, 642 DOI 10.17487/RFC2119, March 1997, . 645 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 646 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 647 DOI 10.17487/RFC4271, January 2006, . 650 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 651 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 652 2006, . 654 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 655 "Multiprotocol Extensions for BGP-4", RFC 4760, 656 DOI 10.17487/RFC4760, January 2007, . 659 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 660 Patel, "Revised Error Handling for BGP UPDATE Messages", 661 RFC 7606, DOI 10.17487/RFC7606, August 2015, 662 . 664 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 665 "Advertisement of Multiple Paths in BGP", RFC 7911, 666 DOI 10.17487/RFC7911, July 2016, . 669 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 670 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 671 May 2017, . 673 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 674 Specification", RFC 8205, DOI 10.17487/RFC8205, September 675 2017, . 677 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 678 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 679 . 681 12.2. Informative References 683 [I-D.ietf-6man-segment-routing-header] 684 Previdi, S., Filsfils, C., Leddy, J., Matsushima, S., and 685 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 686 (SRH)", draft-ietf-6man-segment-routing-header-13 (work in 687 progress), May 2018. 689 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 690 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 691 and M. Chen, "BGP Link-State extensions for Segment 692 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-08 693 (work in progress), May 2018. 695 [I-D.ietf-idr-bgpls-segment-routing-epe] 696 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 697 Dong, "BGP-LS extensions for Segment Routing BGP Egress 698 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 699 epe-15 (work in progress), March 2018. 701 [I-D.ietf-spring-segment-routing-msdc] 702 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and P. 703 Lapukhov, "BGP-Prefix Segment in large-scale data 704 centers", draft-ietf-spring-segment-routing-msdc-09 (work 705 in progress), May 2018. 707 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 708 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 709 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 710 . 712 [RFC5004] Chen, E. and S. Sangli, "Avoid BGP Best Path Transitions 713 from One External to Another", RFC 5004, 714 DOI 10.17487/RFC5004, September 2007, . 717 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 718 S. Ray, "North-Bound Distribution of Link-State and 719 Traffic Engineering (TE) Information Using BGP", RFC 7752, 720 DOI 10.17487/RFC7752, March 2016, . 723 Authors' Addresses 725 Stefano Previdi (editor) 726 Cisco Systems 727 IT 729 Email: stefano@previdi.net 731 Clarence Filsfils 732 Cisco Systems 733 Brussels 734 Belgium 736 Email: cfilsfils@cisco.com 738 Acee Lindem (editor) 739 Cisco Systems 740 301 Midenhall Way 741 Cary, NC 27513 742 USA 744 Email: acee@cisco.com 746 Arjun Sreekantiah 748 Email: arjunhrs@gmail.com 750 Hannes Gredler 751 RtBrick Inc. 753 Email: hannes@rtbrick.com