idnits 2.17.1 draft-ietf-idr-bgp-prefix-sid-04.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 12, 2016) is 2684 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 (-26) exists of draft-ietf-6man-segment-routing-header-02 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-00 == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-06 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-10 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-10 == Outdated reference: A later version (-10) exists of draft-ietf-spring-segment-routing-central-epe-03 == Outdated reference: A later version (-11) exists of draft-ietf-spring-segment-routing-msdc-02 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 8 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 5 Expires: June 15, 2017 K. Patel 6 A. Sreekantiah 7 Cisco Systems 8 S. Ray 9 Unaffiliated 10 H. Gredler 11 RtBrick Inc. 12 December 12, 2016 14 Segment Routing Prefix SID extensions for BGP 15 draft-ietf-idr-bgp-prefix-sid-04 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 15, 2017. 54 Copyright Notice 56 Copyright (c) 2016 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 [RFC7752], [I-D.ietf-idr-bgpls-segment-routing-epe] and 191 [I-D.ietf-idr-bgp-ls-segment-routing-ext]. However, as an 192 optional alternative for the advertisement of the local SRGB 193 without the topology nor the peer SID's, hence without 194 applicability for TE, the Originator SRGB TLV of the prefix-SID 195 attribute, is specified in Section 4.3 of this document. 197 The index L_I is a 32 bit offset in the SRGB. Each BGP speaker 198 derives its local MPLS label, L, by adding L_I to the start value 199 of its own SRGB, and programs L in its MPLS dataplane as its 200 incoming/local label for the prefix. See Section 5.1 for more 201 details. 203 The outgoing label for the prefix is found in the NLRI of the 204 Multiprotocol BGP labeled IPv4/IPv6 Unicast prefix advertisement. 205 The index L_I is only used as a hint to derive the local/incoming 206 label. 208 Section 4.1 of this document specifies the Label-Index TLV of the 209 BGP Prefix-SID attribute; this TLV can be used to advertise the 210 label index of a given prefix. 212 In order to advertise the label index of a given prefix P and, 213 optionally, the SRGB, a new extension to BGP is needed: the BGP 214 Prefix SID attribute. This extension is described in subsequent 215 sections. 217 3.2. IPv6 Prefix Segment 219 As defined in [I-D.ietf-6man-segment-routing-header], and as 220 illustrated in [I-D.ietf-spring-segment-routing-msdc], when SR is 221 used over an IPv6 dataplane, the BGP Prefix Segment is instantiated 222 by an IPv6 prefix originated by the BGP speaker. 224 Each node advertises a globally unique IPv6 address representing 225 itself in the domain. This prefix (e.g.: its loopback interface 226 address) is advertised to all other BGP speakers in the SR domain. 228 Also, each node MUST advertise its support of Segment Routing for 229 IPv6 dataplane. This is realized using the flags contained in the 230 Prefix SID Attribute defined below. 232 4. BGP-Prefix-SID Attribute 234 The BGP Prefix SID attribute is an optional, transitive BGP path 235 attribute. The attribute type code is to be assigned by IANA 236 (suggested value: 40). The value field of the BGP-Prefix-SID 237 attribute has the following format: 239 The value field of the BGP Prefix SID attribute is defined here to be 240 a set of elements encoded as "Type/Length/Value" (i.e., a set of 241 TLVs). Following TLVs are defined: 243 o Label-Index TLV 245 o IPv6 SID TLV 247 o Originator SRGB TLV 249 Label-Index and Originator SRGB TLVs are used only when SR is applied 250 to the MPLS dataplane. 252 IPv6 SID TLV is used only when SR is applied to the IPv6 dataplane. 254 4.1. Label-Index TLV 256 The Label-Index TLV MUST be present in the Prefix-SID attribute 257 attached to Labeled IPv4/IPv6 unicast prefixes ([RFC3107]) and has 258 the following format: 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Type | Length | RESERVED | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Flags | Label Index | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Label Index | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 where: 272 o Type is 1. 274 o Length: is 7, the total length of the value portion of the TLV. 276 o RESERVED: 8 bit field. SHOULD be 0 on transmission and MUST be 277 ignored on reception. 279 o Flags: 16 bits of flags. None are defined at this stage of the 280 document. The flag field SHOULD be clear on transmission and MUST 281 be ignored at reception. 283 o Label Index: 32 bit value representing the index value in the SRGB 284 space. 286 4.2. IPv6 SID 288 The IPv6-SID TLV MUST be present in the Prefix-SID attribute attached 289 to MP-BGP unlabeled IPv6 unicast prefixes ([RFC4760]) and has the 290 following format: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type | Length | RESERVED | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Flags | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 where: 302 o Type is 2. 304 o Length: is 3, the total length of the value portion of the TLV. 306 o RESERVED: 8 bit field. SHOULD be 0 on transmission and MUST be 307 ignored on reception. 309 o Flags: 16 bits of flags defined as follow: 311 0 1 312 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 |S| | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 where: 319 * S flag: if set then it means that the BGP speaker attaching the 320 Prefix-SID Attribute to a prefix is capable of processing the 321 IPv6 Segment Routing Header (SRH, 322 [I-D.ietf-6man-segment-routing-header]) for the segment 323 corresponding to the originated IPv6 prefix. The use case 324 leveraging the S flag is described in 325 [I-D.ietf-spring-segment-routing-msdc]. 327 The other bits of the flag field SHOULD be clear on transmission 328 an MUST be ignored at reception. 330 4.3. Originator SRGB TLV 332 The Originator SRGB TLV is an optional TLV and has the following 333 format: 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Type | Length | Flags | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Flags | 341 +-+-+-+-+-+-+-+-+ 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | SRGB 1 (6 octets) | 345 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | SRGB n (6 octets) | 351 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 where: 357 o Type is 3. 359 o Length is the total length of the value portion of the TLV: 2 + 360 multiple of 6. 362 o Flags: 16 bits of flags. None are defined in this document. 363 Flags SHOULD be clear on transmission an MUST be ignored at 364 reception. 366 o SRGB: 3 octets of base followed by 3 octets of range. Note that 367 the SRGB field MAY appear multiple times. If the SRGB field 368 appears multiple times, the SRGB consists of multiple ranges. The 369 meaning of an SRGB with multiple ranges is explained in 370 Section 3.2 ("SID/Label Range TLV") of 371 [I-D.ietf-ospf-segment-routing-extensions]. 373 The Originator SRGB TLV contains the SRGB of the router originating 374 the prefix to which the BGP Prefix SID is attached and MUST be kept 375 in the Prefix-SID Attribute unchanged during the propagation of the 376 BGP update. 378 The originator SRGB describes the SRGB of the node where the BGP 379 Prefix Segment end. It is used to build SRTE policies when different 380 SRGB's are used in the fabric 381 ([I-D.ietf-spring-segment-routing-msdc]). 383 The originator SRGB may only appear on Prefix-SID attribute attached 384 to prefixes of SAFI 4 (labeled unicast, [RFC3107]). 386 5. Receiving BGP-Prefix-SID Attribute 388 A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP 389 neighbor residing outside the boundaries of the SR domain, SHOULD 390 discard the attribute unless it is configured to accept the attribute 391 from the EBGP neighbor. A BGP speaker MAY log an error for further 392 analysis when discarding an attribute. 394 5.1. MPLS Dataplane: Labeled Unicast 396 A Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC3107]) session 397 type is required. 399 A BGP speaker may be locally configured with an SRGB=[GB_S, GB_E]. 400 The preferred method for deriving the SRGB is a matter of local 401 router configuration. 403 Given a label index L_I, we call L = L_I + GB_S as the derived label. 404 A BGP Prefix-SID attribute is called "unacceptable" for a speaker M 405 if the derived label value L lies outside the SRGB configured on M. 406 Otherwise the Label Index attribute is called "acceptable" to speaker 407 M. 409 The mechanisms through which a given label_index value is assigned to 410 a given prefix are outside the scope of this document. The label- 411 index value associated with a prefix is locally configured at the BGP 412 router originating the prefix. 414 The Prefix-SID attribute MUST contain the Label-Index TLV and MAY 415 contain the Originator SRGB TLV. A BGP Prefix-SID attribute received 416 without a Label-Index TLV MUST be considered as "unacceptable" by the 417 receiving speaker. 419 When a BGP speaker receives a path from a neighbor with an acceptable 420 BGP Prefix-SID attribute, it MUST program the derived label as the 421 local label for the prefix in its MPLS dataplane. In case of any 422 error, a BGP speaker MUST resort to the error handling rules 423 specified in Section 7. A BGP speaker MAY log an error for further 424 analysis. 426 When a BGP speaker receives a path from a neighbor with an 427 unacceptable BGP Prefix-SID attribute or when a BGP speaker receives 428 a path from a neighbor with a BGP-Prefix-SID attribute but is unable 429 to process it (it does not have the capability or local policy 430 disables the capability), it MUST treat the path as if it came 431 without a Prefix-SID attribute. For the purposes of local label 432 allocation, a BGP speaker MUST assign a local (also called dynamic) 433 label (non-SRGB) for such a prefix as per classic Multiprotocol BGP 434 labeled IPv4/IPv6 Unicast ([RFC3107]) operation. A BGP speaker MAY 435 log an error for further analysis. 437 The outgoing label is always programmed as per classic Multiprotocol 438 BGP labeled IPv4/IPv6 Unicast (RFC3107 [RFC3107]) operation. 440 Specifically, a BGP speaker receiving a prefix with a Prefix-SID 441 attribute and a label NLRI field of implicit-null from a neighbor 442 MUST adhere to standard behavior and program its MPLS dataplane to 443 pop the top label when forwarding traffic to the prefix. The label 444 NLRI defines the outbound label that MUST be used by the receiving 445 node. The Label Index gives a hint to the receiving node on which 446 local/incoming label the BGP speaker SHOULD use. 448 5.2. IPv6 Dataplane 450 When a SR IPv6 BGP speaker receives a IPv6 Unicast BGP Update with a 451 prefix having the BGP Prefix SID attribute attached, it checks 452 whether the IPv6 SID TLV is present and if the S-flag is set. If the 453 IPv6 SID TLV is present and if the S-flag is not set, then the 454 Prefix-SID attribute MUST be considered as "unacceptable" by the 455 receiving speaker. 457 The Originator SRGB MUST be ignored on reception. 459 A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP 460 neighbor residing outside the boundaries of the SR domain, SHOULD 461 discard the attribute unless it is configured to accept the attribute 462 from the EBGP neighbor. A BGP speaker MAY log an error for further 463 analysis when discarding an attribute. 465 6. Announcing BGP-Prefix-SID Attribute 467 The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes 468 (IPv4/IPv6) [RFC3107]or to IPv6 prefixes [RFC4760]. In order to 469 prevent distribution of the BGP Prefix-SID attribute beyond its 470 intended scope of applicability, attribute filtering MAY be deployed. 472 6.1. MPLS Dataplane: Labeled Unicast 474 A BGP speaker that originates a prefix attaches the Prefix-SID 475 attribute when it advertises the prefix to its neighbors via 476 Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC3107])The value of 477 the Label-Index in the Label-Index TLV is determined by 478 configuration. 480 A BGP speaker that originates a Prefix-SID attribute MAY optionally 481 announce Originator SRGB TLV along with the mandatory Label-Index 482 TLV. The content of the Originator SRGB TLV is determined by the 483 configuration. 485 Since the Label-index value must be unique within an SR domain, by 486 default an implementation SHOULD NOT advertise the BGP Prefix-SID 487 attribute outside an Autonomous System unless it is explicitly 488 configured to do so. 490 A BGP speaker that advertises a path received from one of its 491 neighbors SHOULD advertise the Prefix-SID received with the path 492 without modification regardless of whether the Prefix-SID was 493 acceptable. If the path did not come with a Prefix-SID attribute, 494 the speaker MAY attach a Prefix-SID to the path if configured to do 495 so. The content of the TLVs present in the Prefix-SID is determined 496 by the configuration. 498 In all cases, the label field of the advertised NLRI ([RFC3107], 499 [RFC4364]) MUST be set to the local/incoming label programmed in the 500 MPLS dataplane for the given advertised prefix. If the prefix is 501 associated with one of the BGP speakers interfaces, this label is the 502 usual MPLS label (such as the implicit or explicit NULL label). 504 6.2. IPv6 Dataplane 506 A BGP speaker that originates a prefix attaches the Prefix-SID 507 attribute when it advertises the prefix to its neighbors. The IPv6 508 SID TLV MUST be present and the S-flag MUST be set. 510 A BGP speaker that advertises a path received from one of its 511 neighbors SHOULD advertise the Prefix-SID received with the path 512 without modification regardless of whether the Prefix-SID was 513 acceptable. If the path did not come with a Prefix-SID attribute, 514 the speaker MAY attach a Prefix-SID to the path if configured to do 515 so. The IPv6-SID TLV MUST be present in the Prefix-SID and with the 516 S-flag set. 518 7. Error Handling of BGP-Prefix-SID Attribute 520 When a BGP Speaker receives a BGP Update message containing a 521 malformed BGP Prefix-SID attribute, it MUST ignore the received BGP 522 Prefix-SID attributes and not pass it to other BGP peers. This is 523 equivalent to the -attribute discard- action specified in [RFC7606]. 524 When discarding an attribute, a BGP speaker MAY log an error for 525 further analysis. 527 If the BGP Prefix-SID attribute appears more than once in an BGP 528 Update message, then, according to [RFC7606], all the occurrences of 529 the attribute other than the first one SHALL be discarded and the BGP 530 Update message shall continue to be processed. 532 When a BGP speaker receives an unacceptable Prefix-SID attribute, it 533 MAY log an error for further analysis. 535 8. IANA Considerations 537 This document defines a new BGP path attribute known as the BGP 538 Prefix-SID attribute. This document requests IANA to assign a new 539 attribute code type (suggested value: 40) for BGP the Prefix-SID 540 attribute from the BGP Path Attributes registry. 542 Currently, IANA temporarily assigned the following: 544 40 BGP Prefix-SID (TEMPORARY - registered 2015-09-30, expires 545 2016-09-30) [draft-ietf-idr-bgp-prefix-sid] 547 This document defines 3 new TLVs for BGP Prefix-SID attribute. These 548 TLVs need to be registered with IANA. We request IANA to create a 549 new registry for BGP Prefix-SID Attribute TLVs as follows: 551 Under "Border Gateway Protocol (BGP) Parameters" registry, "BGP 552 Prefix SID attribute Types" Reference: draft-ietf-idr-bgp-prefix-sid 553 Registration Procedure(s): Values 1-254 First Come, First Served, 554 Value 0 and 255 reserved 556 Value Type Reference 557 0 Reserved this document 558 1 Label-Index this document 559 2 IPv6 SID this document 560 3 Originator SRGB this document 561 4-254 Unassigned 562 255 Reserved this document 564 9. Security Considerations 566 This document introduces no new security considerations above and 567 beyond those already specified in [RFC4271] and [RFC3107]. 569 10. Acknowledgements 571 The authors would like to thanks Satya Mohanty for his contribution 572 to this document. 574 11. Change Log 576 Initial Version: Sep 21 2014 578 12. References 580 12.1. Normative References 582 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 583 Requirement Levels", BCP 14, RFC 2119, 584 DOI 10.17487/RFC2119, March 1997, 585 . 587 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 588 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 589 . 591 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 592 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 593 DOI 10.17487/RFC4271, January 2006, 594 . 596 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 597 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 598 2006, . 600 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 601 Patel, "Revised Error Handling for BGP UPDATE Messages", 602 RFC 7606, DOI 10.17487/RFC7606, August 2015, 603 . 605 12.2. Informative References 607 [I-D.ietf-6man-segment-routing-header] 608 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, 609 J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun, 610 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 611 segment-routing-header-02 (work in progress), September 612 2016. 614 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 615 Previdi, S., Psenak, P., Filsfils, C., Gredler, H., Chen, 616 M., and j. jefftant@gmail.com, "BGP Link-State extensions 617 for Segment Routing", draft-ietf-idr-bgp-ls-segment- 618 routing-ext-00 (work in progress), November 2016. 620 [I-D.ietf-idr-bgpls-segment-routing-epe] 621 Previdi, S., Filsfils, C., Ray, S., Patel, K., Dong, J., 622 and M. Chen, "Segment Routing BGP Egress Peer Engineering 623 BGP-LS Extensions", draft-ietf-idr-bgpls-segment-routing- 624 epe-06 (work in progress), November 2016. 626 [I-D.ietf-ospf-segment-routing-extensions] 627 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 628 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 629 Extensions for Segment Routing", draft-ietf-ospf-segment- 630 routing-extensions-10 (work in progress), October 2016. 632 [I-D.ietf-spring-segment-routing] 633 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 634 and R. Shakir, "Segment Routing Architecture", draft-ietf- 635 spring-segment-routing-10 (work in progress), November 636 2016. 638 [I-D.ietf-spring-segment-routing-central-epe] 639 Filsfils, C., Previdi, S., Aries, E., and D. Afanasiev, 640 "Segment Routing Centralized BGP Peer Engineering", draft- 641 ietf-spring-segment-routing-central-epe-03 (work in 642 progress), November 2016. 644 [I-D.ietf-spring-segment-routing-msdc] 645 Filsfils, C., Previdi, S., Mitchell, J., Aries, E., and P. 646 Lapukhov, "BGP-Prefix Segment in large-scale data 647 centers", draft-ietf-spring-segment-routing-msdc-02 (work 648 in progress), October 2016. 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, 653 . 655 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 656 S. Ray, "North-Bound Distribution of Link-State and 657 Traffic Engineering (TE) Information Using BGP", RFC 7752, 658 DOI 10.17487/RFC7752, March 2016, 659 . 661 Authors' Addresses 663 Stefano Previdi (editor) 664 Cisco Systems 665 Via Del Serafico, 200 666 Rome 00142 667 Italy 669 Email: sprevidi@cisco.com 671 Clarence Filsfils 672 Cisco Systems 673 Brussels 674 Belgium 676 Email: cfilsfils@cisco.com 678 Acee Lindem 679 Cisco Systems 680 170 W. Tasman Drive 681 San Jose, CA 95124 95134 682 USA 684 Email: acee@cisco.com 686 Keyur Patel 687 Cisco Systems 688 170 W. Tasman Drive 689 San Jose, CA 95124 95134 690 USA 692 Email: keyupate@cisco.com 693 Arjun Sreekantiah 694 Cisco Systems 695 170 W. Tasman Drive 696 San Jose, CA 95124 95134 697 USA 699 Email: asreekan@cisco.com 701 Saikat Ray 702 Unaffiliated 704 Email: raysaikat@gmail.com 706 Hannes Gredler 707 RtBrick Inc. 709 Email: hannes@rtbrick.com