idnits 2.17.00 (12 Aug 2021) /tmp/idnits40276/draft-ietf-idr-bgp-prefix-sid-02.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 (December 21, 2015) is 2343 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) ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) == Outdated reference: A later version (-04) exists of draft-gredler-idr-bgp-ls-segment-routing-ext-01 == Outdated reference: draft-ietf-6man-segment-routing-header has been published as RFC 8754 == Outdated reference: draft-ietf-idr-bgpls-segment-routing-epe has been published as RFC 9086 == Outdated reference: draft-ietf-idr-ls-distribution has been published as RFC 7752 == Outdated reference: draft-ietf-ospf-segment-routing-extensions has been published as RFC 8665 == Outdated reference: draft-ietf-spring-segment-routing has been published as RFC 8402 == Outdated reference: draft-ietf-spring-segment-routing-central-epe has been published as RFC 9087 == Outdated reference: draft-ietf-spring-segment-routing-msdc has been published as RFC 8670 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR S. Previdi 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track A. Lindem 5 Expires: June 23, 2016 K. Patel 6 A. Sreekantiah 7 Cisco Systems 8 S. Ray 9 Unaffiliated 10 H. Gredler 11 Individual 12 December 21, 2015 14 Segment Routing Prefix SID extensions for BGP 15 draft-ietf-idr-bgp-prefix-sid-02 17 Abstract 19 Segment Routing (SR) architecture allows a node to steer a packet 20 flow through any topological path and service chain by leveraging 21 source routing. The ingress node prepends a SR header to a packet 22 containing a set of "segments". Each segment represents a 23 topological or a service-based instruction. Per-flow state is 24 maintained only at the ingress node of the SR domain. 26 This document describes the BGP extension for announcing BGP Prefix 27 Segment Identifier (BGP Prefix SID) information. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119] 34 only when they appear in all upper case. They may also appear in 35 lower or mixed case as English words, without any normative meaning. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on June 23, 2016. 54 Copyright Notice 56 Copyright (c) 2015 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Segment Routing Documents . . . . . . . . . . . . . . . . . . 3 72 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. BGP-Prefix-SID . . . . . . . . . . . . . . . . . . . . . . . 4 74 3.1. MPLS Prefix Segment . . . . . . . . . . . . . . . . . . . 4 75 3.2. IPv6 Prefix Segment . . . . . . . . . . . . . . . . . . . 5 76 4. BGP-Prefix-SID Attribute . . . . . . . . . . . . . . . . . . 5 77 4.1. Label-Index TLV . . . . . . . . . . . . . . . . . . . . . 6 78 4.2. IPv6 SID . . . . . . . . . . . . . . . . . . . . . . . . 7 79 4.3. Originator SRGB TLV . . . . . . . . . . . . . . . . . . . 8 80 5. Receiving BGP-Prefix-SID Attribute . . . . . . . . . . . . . 9 81 5.1. MPLS Dataplane: Labeled Unicast . . . . . . . . . . . . . 9 82 5.2. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . . . 10 83 6. Announcing BGP-Prefix-SID Attribute . . . . . . . . . . . . . 10 84 6.1. MPLS Dataplane: Labeled Unicast . . . . . . . . . . . . . 11 85 6.2. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . . . 11 86 7. Error Handling of BGP-Prefix-SID Attribute . . . . . . . . . 12 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 90 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 93 12.2. Informative References . . . . . . . . . . . . . . . . . 13 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 96 1. Segment Routing Documents 98 The main references for this document are the SR architecture defined 99 in [I-D.ietf-spring-segment-routing] and the related use case 100 illustrated in [I-D.ietf-spring-segment-routing-msdc]. 102 The Segment Routing Egress Peer Engineering architecture is described 103 in [I-D.ietf-spring-segment-routing-central-epe]. 105 The Segment Routing Egress Peer Engineering BGPLS extensions are 106 described in [I-D.ietf-idr-bgpls-segment-routing-epe]. 108 2. Introduction 110 Segment Routing (SR) architecture leverages the source routing 111 paradigm. A group of inter-connected nodes that use SR forms a SR 112 domain. The ingress node of the SR domain prepends a SR header 113 containing "segments" to an incoming packet. Each segment represents 114 a topological instruction such as "go to prefix P following shortest 115 path" or a service instruction (e.g.: "pass through deep packet 116 inspection"). By inserting the desired sequence of instructions, the 117 ingress node is able to steer a packet via any topological path and/ 118 or service chain; per-flow state is maintained only at the ingress 119 node of the SR domain. 121 Each segment is identified by a Segment Identifier (SID). As 122 described in [I-D.ietf-spring-segment-routing], when SR is applied to 123 the MPLS dataplane the SID consists of a label while when SR is 124 applied to the IPv6 dataplane the SID consists of an IPv6 prefix (see 125 [I-D.ietf-6man-segment-routing-header]). 127 A BGP-Prefix Segment (aka BGP-Prefix-SID), is a BGP segment attached 128 to a BGP prefix. A BGP-Prefix-SID is always global within the SR/BGP 129 domain and identifies an instruction to forward the packet over the 130 ECMP-aware best-path computed by BGP to the related prefix. The BGP- 131 Prefix-SID is the identifier of the BGP prefix segment. 133 This document describes the BGP extension to signal the BGP-Prefix- 134 SID. Specifically, this document defines a new BGP attribute known 135 as the BGP Prefix SID attribute and specifies the rules to originate, 136 receive and handle error conditions of the new attribute. 138 As described in [I-D.ietf-spring-segment-routing-msdc], the newly 139 proposed BGP Prefix-SID attribute can be attached to prefixes from 140 AFI/SAFI: 142 Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC3107]). 144 Multiprotocol BGP ([RFC4760]) unlabeled IPv6 Unicast. 146 [I-D.ietf-spring-segment-routing-msdc] describes use cases where the 147 Prefix-SID is used for the above AFI/SAFI. 149 3. BGP-Prefix-SID 151 The BGP-Prefix-SID attached to a BGP prefix P represents the 152 instruction "go to Prefix P" along its BGP bestpath (potentially 153 ECMP-enabled). 155 3.1. MPLS Prefix Segment 157 The BGP Prefix Segment is realized on the MPLS dataplane in the 158 following way: 160 As described in [I-D.ietf-spring-segment-routing-msdc] the 161 operator assigns a globally unique "index", L_I, to a locally 162 sourced prefix of a BGP speaker N which is advertised to all other 163 BGP speakers in the SR domain. 165 According to [I-D.ietf-spring-segment-routing], each BGP speaker 166 is configured with a label block called the Segment Routing Global 167 Block (SRGB). While it is recommended to use the same SRGB across 168 all the nodes within the SR domain, the SRGB of a node is a local 169 property and could be different on different speakers. The 170 drawbacks of the use case where BGP speakers have different SRGBs 171 are documented in [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 SID's for each of its links and peers. This informations 177 is required in order to perform the explicit path computation and 178 to express any explicit path into a list of segments. The 179 advertisement of topological information and Peer segments is 180 assumed to be done through 181 [I-D.ietf-idr-bgpls-segment-routing-epe]. 183 If the BGP speakers are not all configured with the same SRGB, and 184 if traffic-engineering within the SR domain is required, each node 185 may be required to advertise its local SRGB in addition to the 186 topological information. 188 This documents assumes that BGP-LS is the preferred method for 189 collecting both topological, peer segments and SRGB information 190 through [I-D.ietf-idr-ls-distribution], 191 [I-D.ietf-idr-bgpls-segment-routing-epe] and 193 [I-D.gredler-idr-bgp-ls-segment-routing-ext]. However, as an 194 optional alternative for the advertisement of the local SRGB 195 without the topology nor the peer SID's, hence without 196 applicability for TE, the Originator SRGB TLV of the prefix-SID 197 attribute, is specified in Section 4.3 of this document. 199 The index L_I is a 32 bit offset in the SRGB. Each BGP speaker 200 derives its local MPLS label, L, by adding L_I to the start value 201 of its own SRGB, and programs L in its MPLS dataplane as its 202 incoming/local label for the prefix. See Section 5.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 The index L_I is only used as a hint to derive the local/incoming 208 label. 210 Section 4.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 of a given prefix. 214 In order to advertise the label index of a given prefix P and, 215 optionally, the SRGB, a new extension to BGP is needed: the BGP 216 Prefix SID attribute. This extension is described in subsequent 217 sections. 219 3.2. IPv6 Prefix Segment 221 As defined in [I-D.ietf-6man-segment-routing-header], and as 222 illustrated in [I-D.ietf-spring-segment-routing-msdc], when SR is 223 used over an IPv6 dataplane, the BGP Prefix Segment is instantiated 224 by an IPv6 prefix originated by the BGP speaker. 226 Each node advertises a globally unique IPv6 address representing 227 itself in the domain. This prefix (e.g.: its loopback interface 228 address) is advertised to all other BGP speakers in the SR domain. 230 Also, each node MUST advertise its support of Segment Routing for 231 IPv6 dataplane. This is realized using the flags contained in the 232 Prefix SID Attribute defined below. 234 4. BGP-Prefix-SID Attribute 236 The BGP Prefix SID attribute is an optional, transitive BGP path 237 attribute. The attribute type code is to be assigned by IANA 238 (suggested value: 40). The value field of the BGP-Prefix-SID 239 attribute has the following format: 241 The value field of the BGP Prefix SID attribute is defined here to be 242 a set of elements encoded as "Type/Length/Value" (i.e., a set of 243 TLVs). Following TLVs are defined: 245 o Label-Index TLV 247 o IPv6 SID TLV 249 o Originator SRGB TLV 251 Label-Index and Originator SRGB TLVs are used only when SR is applied 252 to the MPLS dataplane. 254 IPv6 SID TLV is used only when SR is applied to the IPv6 dataplane. 256 4.1. Label-Index TLV 258 The Label-Index TLV MUST be present in the Prefix-SID attribute 259 attached to Labeled IPv4/IPv6 unicast prefixes ([RFC3107]) and has 260 the following format: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Type | Length | RESERVED | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Flags | Label Index | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Label Index | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 where: 274 o Type is 1. 276 o Length: is 7, the total length of the value portion of the TLV. 278 o RESERVED: 8 bit field. SHOULD be 0 on transmission and MUST be 279 ignored on reception. 281 o Flags: 16 bits of flags. None are defined at this stage of the 282 document. The flag field SHOULD be clear on transmission and MUST 283 be ignored at reception. 285 o Label Index: 32 bit value representing the index value in the SRGB 286 space. 288 4.2. IPv6 SID 290 The IPv6-SID TLV MUST be present in the Prefix-SID attribute attached 291 to MP-BGP unlabeled IPv6 unicast prefixes ([RFC4760]) and has the 292 following format: 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Type | Length | RESERVED | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Flags | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 where: 304 o Type is 2. 306 o Length: is 3, the total length of the value portion of the TLV. 308 o RESERVED: 8 bit field. SHOULD be 0 on transmission and MUST be 309 ignored on reception. 311 o Flags: 16 bits of flags defined as follow: 313 0 1 314 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 |S| | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 where: 321 * S flag: if set then it means that the BGP speaker attaching the 322 Prefix-SID Attribute to a prefix is capable of processing the 323 IPv6 Segment Routing Header (SRH, 324 [I-D.ietf-6man-segment-routing-header]) for the segment 325 corresponding to the originated IPv6 prefix. The use case 326 leveraging the S flag is described in 327 [I-D.ietf-spring-segment-routing-msdc]. 329 The other bits of the flag field SHOULD be clear on transmission 330 an MUST be ignored at reception. 332 4.3. Originator SRGB TLV 334 The Originator SRGB TLV is an optional TLV and has the following 335 format: 337 0 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Type | Length | Flags | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Flags | 343 +-+-+-+-+-+-+-+-+ 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | SRGB 1 (6 octets) | 347 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | SRGB n (6 octets) | 353 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 where: 359 o Type is 3. 361 o Length is the total length of the value portion of the TLV: 2 + 362 multiple of 6. 364 o Flags: 16 bits of flags. None are defined in this document. 365 Flags SHOULD be clear on transmission an MUST be ignored at 366 reception. 368 o SRGB: 3 octets of base followed by 3 octets of range. Note that 369 the SRGB field MAY appear multiple times. If the SRGB field 370 appears multiple times, the SRGB consists of multiple ranges. The 371 meaning of an SRGB with multiple ranges is explained in 372 Section 3.2 ("SID/Label Range TLV") of 373 [I-D.ietf-ospf-segment-routing-extensions]. 375 The Originator SRGB TLV contains the SRGB of the router originating 376 the prefix to which the BGP Prefix SID is attached and MUST be kept 377 in the Prefix-SID Attribute unchanged during the propagation of the 378 BGP update. 380 The originator SRGB describes the SRGB of the node where the BGP 381 Prefix Segment end. It is used to build SRTE policies when different 382 SRGB's are used in the fabric 383 ([I-D.ietf-spring-segment-routing-msdc]). 385 The originator SRGB may only appear on Prefix-SID attribute attached 386 to prefixes of SAFI 4 (labeled unicast, [RFC3107]). 388 5. Receiving BGP-Prefix-SID Attribute 390 A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP 391 neighbor residing outside the boundaries of the SR domain, SHOULD 392 discard the attribute unless it is configured to accept the attribute 393 from the EBGP neighbor. A BGP speaker MAY log an error for further 394 analysis when discarding an attribute. 396 5.1. MPLS Dataplane: Labeled Unicast 398 A Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC3107]) session 399 type is required. 401 A BGP speaker may be locally configured with an SRGB=[GB_S, GB_E]. 402 The preferred method for deriving the SRGB is a matter of local 403 router configuration. 405 Given a label index L_I, we call L = L_I + GB_S as the derived label. 406 A BGP Prefix-SID attribute is called "unacceptable" for a speaker M 407 if the derived label value L lies outside the SRGB configured on M. 408 Otherwise the Label Index attribute is called "acceptable" to speaker 409 M. 411 The mechanisms through which a given label_index value is assigned to 412 a given prefix are outside the scope of this document. The label- 413 index value associated with a prefix is locally configured at the BGP 414 router originating the prefix. 416 The Prefix-SID attribute MUST contain the Label-Index TLV and MAY 417 contain the Originator SRGB TLV. A BGP Prefix-SID attribute received 418 without a Label-Index TLV MUST be considered as "unacceptable" by the 419 receiving speaker. 421 When a BGP speaker receives a path from a neighbor with an acceptable 422 BGP Prefix-SID attribute, it MUST program the derived label as the 423 local label for the prefix in its MPLS dataplane. In case of any 424 error, a BGP speaker MUST resort to the error handling rules 425 specified in Section 7. A BGP speaker MAY log an error for further 426 analysis. 428 When a BGP speaker receives a path from a neighbor with an 429 unacceptable BGP Prefix-SID attribute or when a BGP speaker receives 430 a path from a neighbor with a BGP-Prefix-SID attribute but is unable 431 to process it (it does not have the capability or local policy 432 disables the capability), it MUST treat the path as if it came 433 without a Prefix-SID attribute. For the purposes of local label 434 allocation, a BGP speaker MUST assign a local (also called dynamic) 435 label (non-SRGB) for such a prefix as per classic Multiprotocol BGP 436 labeled IPv4/IPv6 Unicast ([RFC3107]) operation. A BGP speaker MAY 437 log an error for further analysis. 439 The outgoing label is always programmed as per classic Multiprotocol 440 BGP labeled IPv4/IPv6 Unicast (RFC3107 [RFC3107]) operation. 442 Specifically, a BGP speaker receiving a prefix with a Prefix-SID 443 attribute and a label NLRI field of implicit-null from a neighbor 444 MUST adhere to standard behavior and program its MPLS dataplane to 445 pop the top label when forwarding traffic to the prefix. The label 446 NLRI defines the outbound label that MUST be used by the receiving 447 node. The Label Index gives a hint to the receiving node on which 448 local/incoming label the BGP speaker SHOULD use. 450 5.2. IPv6 Dataplane 452 When a SR IPv6 BGP speaker receives a IPv6 Unicast BGP Update with a 453 prefix having the BGP Prefix SID attribute attached, it checks 454 whether the IPv6 SID TLV is present and if the S-flag is set. If the 455 IPv6 SID TLV is present and if the S-flag is not set, then the 456 Prefix-SID attribute MUST be considered as "unacceptable" by the 457 receiving speaker. 459 The Originator SRGB MUST be ignored on reception. 461 A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP 462 neighbor residing outside the boundaries of the SR domain, SHOULD 463 discard the attribute unless it is configured to accept the attribute 464 from the EBGP neighbor. A BGP speaker MAY log an error for further 465 analysis when discarding an attribute. 467 6. Announcing BGP-Prefix-SID Attribute 469 The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes 470 (IPv4/IPv6) [RFC3107]or to IPv6 prefixes [RFC4760]. In order to 471 prevent distribution of the BGP Prefix-SID attribute beyond its 472 intended scope of applicability, attribute filtering MAY be deployed. 474 6.1. MPLS Dataplane: Labeled Unicast 476 A BGP speaker that originates a prefix attaches the Prefix-SID 477 attribute when it advertises the prefix to its neighbors via 478 Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC3107])The value of 479 the Label-Index in the Label-Index TLV is determined by 480 configuration. 482 A BGP speaker that originates a Prefix-SID attribute MAY optionally 483 announce Originator SRGB TLV along with the mandatory Label-Index 484 TLV. The content of the Originator SRGB TLV is determined by the 485 configuration. 487 Since the Label-index value must be unique within an SR domain, by 488 default an implementation SHOULD NOT advertise the BGP Prefix-SID 489 attribute outside an Autonomous System unless it is explicitly 490 configured to do so. 492 A BGP speaker that advertises a path received from one of its 493 neighbors SHOULD advertise the Prefix-SID received with the path 494 without modification regardless of whether the Prefix-SID was 495 acceptable. If the path did not come with a Prefix-SID attribute, 496 the speaker MAY attach a Prefix-SID to the path if configured to do 497 so. The content of the TLVs present in the Prefix-SID is determined 498 by the configuration. 500 In all cases, the label field of the advertised NLRI ([RFC3107], 501 [RFC4364]) MUST be set to the local/incoming label programmed in the 502 MPLS dataplane for the given advertised prefix. If the prefix is 503 associated with one of the BGP speakers interfaces, this label is the 504 usual MPLS label (such as the implicit or explicit NULL label). 506 6.2. IPv6 Dataplane 508 A BGP speaker that originates a prefix attaches the Prefix-SID 509 attribute when it advertises the prefix to its neighbors. The IPv6 510 SID TLV MUST be present and the S-flag MUST be set. 512 A BGP speaker that advertises a path received from one of its 513 neighbors SHOULD advertise the Prefix-SID received with the path 514 without modification regardless of whether the Prefix-SID was 515 acceptable. If the path did not come with a Prefix-SID attribute, 516 the speaker MAY attach a Prefix-SID to the path if configured to do 517 so. The IPv6-SID TLV MUST be present in the Prefix-SID and with the 518 S-flag set. 520 7. Error Handling of BGP-Prefix-SID Attribute 522 When a BGP Speaker receives a BGP Update message containing a 523 malformed BGP Prefix-SID attribute, it MUST ignore the received BGP 524 Prefix-SID attributes and not pass it to other BGP peers. This is 525 equivalent to the -attribute discard- action specified in [RFC7606]. 526 When discarding an attribute, a BGP speaker MAY log an error for 527 further analysis. 529 If the BGP Prefix-SID attribute appears more than once in an BGP 530 Update message, then, according to [RFC7606], all the occurrences of 531 the attribute other than the first one SHALL be discarded and the BGP 532 Update message shall continue to be processed. 534 When a BGP speaker receives an unacceptable Prefix-SID attribute, it 535 MAY log an error for further analysis. 537 8. IANA Considerations 539 This document defines a new BGP path attribute known as the BGP 540 Prefix-SID attribute. This document requests IANA to assign a new 541 attribute code type (suggested value: 40) for BGP the Prefix-SID 542 attribute from the BGP Path Attributes registry. 544 Currently, IANA temporarily assigned the following: 546 40 BGP Prefix-SID (TEMPORARY - registered 2015-09-30, expires 547 2016-09-30) [draft-ietf-idr-bgp-prefix-sid] 549 This document defines 3 new TLVs for BGP Prefix-SID attribute. These 550 TLVs need to be registered with IANA. We request IANA to create a 551 new registry for BGP Prefix-SID Attribute TLVs as follows: 553 Under "Border Gateway Protocol (BGP) Parameters" registry, "BGP 554 Prefix SID attribute Types" Reference: draft-ietf-idr-bgp-prefix-sid 555 Registration Procedure(s): Values 1-254 First Come, First Served, 556 Value 0 and 255 reserved 558 Value Type Reference 559 0 Reserved this document 560 1 Label-Index this document 561 2 IPv6 SID this document 562 3 Originator SRGB this document 563 4-254 Unassigned 564 255 Reserved this document 566 9. Security Considerations 568 This document introduces no new security considerations above and 569 beyond those already specified in [RFC4271] and [RFC3107]. 571 10. Acknowledgements 573 The authors would like to thanks Satya Mohanty for his contribution 574 to this document. 576 11. Change Log 578 Initial Version: Sep 21 2014 580 12. References 582 12.1. Normative References 584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 585 Requirement Levels", BCP 14, RFC 2119, 586 DOI 10.17487/RFC2119, March 1997, 587 . 589 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 590 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 591 . 593 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 594 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 595 DOI 10.17487/RFC4271, January 2006, 596 . 598 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 599 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 600 2006, . 602 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 603 Patel, "Revised Error Handling for BGP UPDATE Messages", 604 RFC 7606, DOI 10.17487/RFC7606, August 2015, 605 . 607 12.2. Informative References 609 [I-D.gredler-idr-bgp-ls-segment-routing-ext] 610 Previdi, S., Psenak, P., Filsfils, C., Gredler, H., Chen, 611 M., and J. Tantsura, "BGP Link-State extensions for 612 Segment Routing", draft-gredler-idr-bgp-ls-segment- 613 routing-ext-01 (work in progress), December 2015. 615 [I-D.ietf-6man-segment-routing-header] 616 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, 617 J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment 618 Routing Header (SRH)", draft-ietf-6man-segment-routing- 619 header-00 (work in progress), December 2015. 621 [I-D.ietf-idr-bgpls-segment-routing-epe] 622 Previdi, S., Filsfils, C., Ray, S., Patel, K., Dong, J., 623 and M. Chen, "Segment Routing Egress Peer Engineering BGP- 624 LS Extensions", draft-ietf-idr-bgpls-segment-routing- 625 epe-02 (work in progress), December 2015. 627 [I-D.ietf-idr-ls-distribution] 628 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 629 Ray, "North-Bound Distribution of Link-State and TE 630 Information using BGP", draft-ietf-idr-ls-distribution-13 631 (work in progress), October 2015. 633 [I-D.ietf-ospf-segment-routing-extensions] 634 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 635 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 636 Extensions for Segment Routing", draft-ietf-ospf-segment- 637 routing-extensions-05 (work in progress), June 2015. 639 [I-D.ietf-spring-segment-routing] 640 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 641 and r. rjs@rob.sh, "Segment Routing Architecture", draft- 642 ietf-spring-segment-routing-07 (work in progress), 643 December 2015. 645 [I-D.ietf-spring-segment-routing-central-epe] 646 Filsfils, C., Previdi, S., Ginsburg, D., and D. Afanasiev, 647 "Segment Routing Centralized Egress Peer Engineering", 648 draft-ietf-spring-segment-routing-central-epe-00 (work in 649 progress), October 2015. 651 [I-D.ietf-spring-segment-routing-msdc] 652 Filsfils, C., Previdi, S., Mitchell, J., and P. Lapukhov, 653 "BGP-Prefix Segment in large-scale data centers", draft- 654 ietf-spring-segment-routing-msdc-00 (work in progress), 655 October 2015. 657 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 658 "Multiprotocol Extensions for BGP-4", RFC 4760, 659 DOI 10.17487/RFC4760, January 2007, 660 . 662 Authors' Addresses 664 Stefano Previdi 665 Cisco Systems 666 Via Del Serafico, 200 667 Rome 00142 668 Italy 670 Email: sprevidi@cisco.com 672 Clarence Filsfils 673 Cisco Systems 674 Brussels 675 Belgium 677 Email: cfilsfils@cisco.com 679 Acee Lindem 680 Cisco Systems 681 170 W. Tasman Drive 682 San Jose, CA 95124 95134 683 USA 685 Email: acee@cisco.com 687 Keyur Patel 688 Cisco Systems 689 170 W. Tasman Drive 690 San Jose, CA 95124 95134 691 USA 693 Email: keyupate@cisco.com 695 Arjun Sreekantiah 696 Cisco Systems 697 170 W. Tasman Drive 698 San Jose, CA 95124 95134 699 USA 701 Email: asreekan@cisco.com 702 Saikat Ray 703 Unaffiliated 705 Email: raysaikat@gmail.com 707 Hannes Gredler 708 Individual 709 AT 711 Email: hannes@gredler.at