idnits 2.17.1 draft-ietf-idr-bgp-prefix-sid-06.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 16, 2017) is 2496 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 (-15) exists of draft-ietf-spring-segment-routing-11 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-08 ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-01 == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-12 == Outdated reference: A later version (-11) exists of draft-ietf-spring-segment-routing-msdc-04 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 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 5 Expires: December 18, 2017 A. Sreekantiah 6 Cisco Systems 7 H. Gredler 8 RtBrick Inc. 9 June 16, 2017 11 Segment Routing Prefix SID extensions for BGP 12 draft-ietf-idr-bgp-prefix-sid-06 14 Abstract 16 Segment Routing (SR) architecture allows a node to steer a packet 17 flow through any topological path and service chain by leveraging 18 source routing. The ingress node prepends a SR header to a packet 19 containing a set of segment identifiers (SID). Each SID represents a 20 topological or a service-based instruction. Per-flow state is 21 maintained only at the ingress node of the SR domain. 23 This document defines a new optional, transitive BGP attribute for 24 announcing BGP Prefix Segment Identifiers (BGP Prefix-SID) 25 information. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119] 32 only when they appear in all upper case. They may also appear in 33 lower or mixed case as English words, without any normative meaning. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on December 18, 2017. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. BGP-Prefix-SID . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.1. MPLS BGP Prefix SID . . . . . . . . . . . . . . . . . . . 4 71 2.2. IPv6 Prefix Segment . . . . . . . . . . . . . . . . . . . 5 72 3. BGP-Prefix-SID Attribute . . . . . . . . . . . . . . . . . . 5 73 3.1. Label-Index TLV . . . . . . . . . . . . . . . . . . . . . 6 74 3.2. IPv6 SID . . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.3. Originator SRGB TLV . . . . . . . . . . . . . . . . . . . 7 76 4. Receiving BGP-Prefix-SID Attribute . . . . . . . . . . . . . 9 77 4.1. MPLS Dataplane: Labeled Unicast . . . . . . . . . . . . . 9 78 4.2. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . . . 10 79 5. Announcing BGP-Prefix-SID Attribute . . . . . . . . . . . . . 10 80 5.1. MPLS Dataplane: Labeled Unicast . . . . . . . . . . . . . 10 81 5.2. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . . . 11 82 6. Error Handling of BGP-Prefix-SID Attribute . . . . . . . . . 11 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 8. Manageability Considerations . . . . . . . . . . . . . . . . 12 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 87 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 90 12.2. Informative References . . . . . . . . . . . . . . . . . 14 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 93 1. Introduction 95 Segment Routing (SR) architecture leverages the source routing 96 paradigm. A group of inter-connected nodes that use SR forms a 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 (e.g.: "pass through deep packet inspection"). Other types of 100 segments may be defined in the future. 102 A segment is identified through a Segment Identifier (SID). 103 Typically, the ingress node of the SR domain prepends a SR header 104 containing segments identifiers (SIDs) to an incoming packet. 106 As described in [I-D.ietf-spring-segment-routing], when SR is applied 107 to the MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]) the 108 SID consists of a label while when SR is applied to the IPv6 109 dataplane the SID consists of an IPv6 address. 111 A BGP-Prefix Segment (and its BGP Prefix-SID), is a BGP segment 112 attached to a BGP prefix. A BGP Prefix-SID is always a global SID 113 ([I-D.ietf-spring-segment-routing]) within the SR/BGP domain (i.e., 114 the set of Autonomous Systems under a common administration and 115 control and where SR is used) and identifies an instruction to 116 forward the packet over the ECMP-aware best-path computed by BGP to 117 the related prefix. The BGP Prefix-SID is the identifier of the BGP 118 prefix segment. In this document, we always refer to the BGP Segment 119 by the BGP Prefix-SID. 121 This document describes the BGP extension to signal the BGP Prefix- 122 SID. Specifically, this document defines a new BGP attribute known 123 as the BGP Prefix-SID attribute and specifies the rules to originate, 124 receive and handle error conditions of the new attribute. 126 As described in [I-D.ietf-spring-segment-routing-msdc], the BGP 127 Prefix-SID attribute defined in this document can be attached to 128 prefixes from AFI/SAFI: 130 Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC3107]). 132 Multiprotocol BGP ([RFC4760]) unlabeled IPv6 Unicast. 134 [I-D.ietf-spring-segment-routing-msdc] describes use cases where the 135 Prefix-SID is used for the above AFI/SAFI. 137 It has to be noted that: 139 o A BGP Prefix-SID MAY be global between domains when the 140 interconnected domains agree on the SID allocation scheme. 142 Alternatively, when interconnecting domains, the ASBRs of each 143 domain will have to handle the advertisement of unique SIDs. The 144 mechanisms for such interconnection are outside the scope of the 145 protocol extensions defined in this document. 147 o As described in [I-D.ietf-spring-segment-routing-msdc], a BGP 148 Prefix-SID MAY be attached to a prefix. In addition, each prefix 149 will likely have a different as_path attribute. This implies that 150 each prefix is advertised individually, reducing the ability to 151 pack BGP advertisements (when sharing common attributes). 153 2. BGP-Prefix-SID 155 The BGP Prefix-SID attached to a BGP prefix P represents the 156 instruction "go to Prefix P" along its BGP bestpath (potentially 157 ECMP-enabled). 159 2.1. MPLS BGP Prefix SID 161 The BGP Prefix-SID is realized on the MPLS dataplane 162 ([I-D.ietf-spring-segment-routing-mpls]) in the following way: 164 As described in [I-D.ietf-spring-segment-routing-msdc] the 165 operator assigns a globally unique "index", L_I, to a locally 166 sourced prefix of a BGP speaker N which is advertised to all other 167 BGP speakers in the SR domain. 169 According to [I-D.ietf-spring-segment-routing], each BGP speaker 170 is configured with a label block called the Segment Routing Global 171 Block (SRGB). While [I-D.ietf-spring-segment-routing] recommends 172 to use the same SRGB across all the nodes within the SR domain, 173 the SRGB of a node is a local property and could be different on 174 different speakers. The drawbacks of the use case where BGP 175 speakers have different SRGBs are documented in 176 [I-D.ietf-spring-segment-routing] and 177 [I-D.ietf-spring-segment-routing-msdc]. 179 If traffic-engineering within the SR domain is required, each node 180 may also be required to advertise topological information and 181 Peering SID's for each of its links and peers. This information 182 is required in order to perform the explicit path computation and 183 to express any explicit path into a list of SIDs. The 184 advertisement of topological information and Peer segments (Peer 185 SIDs) is assumed to be done through 186 [I-D.ietf-idr-bgpls-segment-routing-epe]. 188 If the BGP speakers are not all configured with the same SRGB, and 189 if traffic-engineering within the SR domain is required, each node 190 may be required to advertise its local SRGB in addition to the 191 topological information. 193 This documents assumes that BGP-LS is the preferred method for 194 collecting both topological, peer segments (Peer SIDs) and SRGB 195 information through [RFC7752], 196 [I-D.ietf-idr-bgpls-segment-routing-epe] and 197 [I-D.ietf-idr-bgp-ls-segment-routing-ext]. However, as an 198 optional alternative for the advertisement of the local SRGB 199 without the topology nor the peer SID's, hence without 200 applicability for TE, the Originator SRGB TLV of the prefix-SID 201 attribute, is specified in Section 3.3 of this document. 203 As defined in [I-D.ietf-spring-segment-routing-mpls], the index 204 L_I is an offset in the SRGB. Each BGP speaker derives its local 205 MPLS label, L, by adding L_I to the start value of its own SRGB, 206 and programs L in its MPLS dataplane as its incoming/local label 207 for the prefix. It has to be noted that while SRGBs and SIDs are 208 advertised using 32 bit values, the derived label is to be 209 considered as the 20 right-most bits. See Section 4.1 for more 210 details. 212 The outgoing label for the prefix is found in the NLRI of the 213 Multiprotocol BGP labeled IPv4/IPv6 Unicast prefix advertisement. 214 The index L_I is only used as a hint to derive the local/incoming 215 label. 217 Section 3.1 of this document specifies the Label-Index TLV of the 218 BGP Prefix-SID attribute; this TLV can be used to advertise the 219 label index of a given prefix. 221 In order to advertise the label index of a given prefix P and, 222 optionally, the SRGB, a new extension to BGP is needed: the BGP 223 Prefix-SID attribute. This extension is described in subsequent 224 sections. 226 2.2. IPv6 Prefix Segment 228 As illustrated in [I-D.ietf-spring-segment-routing-msdc], when SR is 229 used over an IPv6 dataplane, the BGP Prefix-SID consists of an IPv6 230 address assigned to the BGP speaker. 232 3. BGP-Prefix-SID Attribute 234 The BGP Prefix-SID attribute is an optional, transitive BGP path 235 attribute. The attribute type code 40 has been assigned by IANA (see 236 Section 7). 238 The BGP Prefix-SID attribute is defined here to be a set of elements 239 encoded as "Type/Length/Value" (i.e., a set of TLVs). The following 240 TLVs are defined: 242 o Label-Index TLV 244 o IPv6 SID TLV 246 o Originator SRGB TLV 248 Label-Index and Originator SRGB TLVs are used only when SR is applied 249 to the MPLS dataplane. 251 IPv6 SID TLV is used only when SR is applied to the IPv6 dataplane. 253 3.1. Label-Index TLV 255 The Label-Index TLV MUST be present in the Prefix-SID attribute 256 attached to Labeled IPv4/IPv6 unicast prefixes ([RFC3107]) and has 257 the following format: 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Type | Length | RESERVED | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Flags | Label Index | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Label Index | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 where: 271 o Type is 1. 273 o Length: is 7, the total length of the value portion of the TLV. 275 o RESERVED: 8 bit field. MUST be clear on transmission an MUST be 276 ignored at reception.. 278 o Flags: 16 bits of flags. None is defined by this document. The 279 flag field MUST be clear on transmission and MUST be ignored at 280 reception. 282 o Label Index: 32 bit value representing the index value in the SRGB 283 space. 285 3.2. IPv6 SID 287 The IPv6-SID TLV MAY be present in the Prefix-SID attribute attached 288 to MP-BGP unlabeled IPv6 unicast prefixes ([RFC4760]) and has the 289 following format: 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Type | Length | RESERVED | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | RESERVED | | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 298 | | 299 | IPv6 SID (16 octets) | 300 | | 301 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 where: 307 o Type is 2. 309 o Length: is 19, the total length of the value portion of the TLV. 311 o RESERVED: 24 bit field for future use. MUST be clear on 312 transmission an MUST be ignored at reception. 314 o IPv6 SID: 16 octets. 316 3.3. Originator SRGB TLV 318 The Originator SRGB TLV is an optional TLV and has the following 319 format: 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Type | Length | Flags | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Flags | 327 +-+-+-+-+-+-+-+-+ 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | SRGB 1 (6 octets) | 331 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | SRGB n (6 octets) | 337 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 where: 343 o Type is 3. 345 o Length is the total length of the value portion of the TLV: 2 + 346 multiple of 6. 348 o Flags: 16 bits of flags. None is defined in this document. Flags 349 MUST be clear on transmission an MUST be ignored at reception. 351 o SRGB: 3 octets of base followed by 3 octets of range. Note that 352 the SRGB field MAY appear multiple times. If the SRGB field 353 appears multiple times, the SRGB consists of multiple ranges. 355 The Originator SRGB TLV contains the SRGB of the node originating the 356 prefix to which the BGP Prefix-SID is attached. The Originator SRGB 357 TLV MUST NOT be changed during the propagation of the BGP update. 359 The originator SRGB describes the SRGB of the node where the BGP 360 Prefix SID is attached. It is used to build segment routing policies 361 when different SRGB's are used in the fabric 362 ([I-D.ietf-spring-segment-routing-msdc]). 364 The originator SRGB may only appear on Prefix-SID attribute attached 365 to prefixes of SAFI 4 (labeled unicast, [RFC3107]). 367 4. Receiving BGP-Prefix-SID Attribute 369 A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP 370 neighbor residing outside the boundaries of the SR domain, SHOULD 371 discard the attribute unless it is configured to accept the attribute 372 from the EBGP neighbor. A BGP speaker MAY log an error for further 373 analysis when discarding an attribute. 375 4.1. MPLS Dataplane: Labeled Unicast 377 A Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC3107]) session 378 type is required. 380 A BGP speaker MAY be locally configured with an SRGB=[SRGB_Start, 381 SRGB_End]. The preferred method for deriving the SRGB is a matter of 382 local node configuration. 384 Given a label_index L_I, we call L = L_I + SRGB_Start as the derived 385 label. A BGP Prefix-SID attribute is called "unacceptable" for a 386 speaker M if the derived label value L lies outside the SRGB 387 configured on M. Otherwise the Label Index attribute is called 388 "acceptable" to speaker M. 390 The mechanisms through which a given label_index value is assigned to 391 a given prefix are outside the scope of this document. The label- 392 index value associated with a prefix is locally configured at the BGP 393 node originating the prefix. 395 The Prefix-SID attribute MUST contain the Label-Index TLV and MAY 396 contain the Originator SRGB TLV. A BGP Prefix-SID attribute received 397 without a Label-Index TLV MUST be considered as "unacceptable" by the 398 receiving speaker. 400 If multiple prefixes are received with the same label_index value, 401 all these prefixes MUST have their BGP Prefix-SID attribute 402 considered as "unacceptable" by the receiving speaker. 404 When a BGP speaker receives a path from a neighbor with an acceptable 405 BGP Prefix-SID attribute, it MUST program the derived label as the 406 local label for the prefix in its MPLS dataplane. In case of any 407 error, a BGP speaker MUST resort to the error handling rules 408 specified in Section 6. A BGP speaker MAY log an error for further 409 analysis. 411 When a BGP speaker receives a path from a neighbor with an 412 unacceptable BGP Prefix-SID attribute or when a BGP speaker receives 413 a path from a neighbor with a BGP Prefix-SID attribute but is unable 414 to process it (it does not have the capability or local policy 415 disables the capability), it MUST treat the path as if it came 416 without a Prefix-SID attribute. For the purposes of local label 417 allocation, a BGP speaker MUST assign a local (also called dynamic) 418 label (non-SRGB) for such a prefix as per classic Multiprotocol BGP 419 labeled IPv4/IPv6 Unicast ([RFC3107]) operation. A BGP speaker MAY 420 log an error for further analysis. 422 The outgoing label is always programmed as per classic Multiprotocol 423 BGP labeled IPv4/IPv6 Unicast (RFC3107 [RFC3107]) operation. 425 Specifically, a BGP speaker receiving a prefix with a Prefix-SID 426 attribute and a label NLRI field of implicit-null from a neighbor 427 MUST adhere to standard behavior and program its MPLS dataplane to 428 pop the top label when forwarding traffic to the prefix. The label 429 NLRI defines the outbound label that MUST be used by the receiving 430 node. The Label Index gives the information to the receiving node on 431 which local/incoming label the BGP speaker SHOULD use. 433 4.2. IPv6 Dataplane 435 When an SR IPv6 BGP speaker receives a IPv6 Unicast BGP Update with a 436 prefix having the BGP Prefix-SID attribute attached, it checks 437 whether the IPv6 SID TLV is present. If present, then the receiver 438 assumes that the originator supports SR on the IPv6 dataplane. 440 The Originator SRGB MUST be ignored on reception. 442 A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP 443 neighbor residing outside the boundaries of the SR domain, SHOULD 444 discard the attribute unless it is configured to accept the attribute 445 from the EBGP neighbor. A BGP speaker MAY log an error for further 446 analysis when discarding an attribute. 448 5. Announcing BGP-Prefix-SID Attribute 450 The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes 451 (IPv4/IPv6) [RFC3107] or to IPv6 prefixes [RFC4760]. In order to 452 prevent distribution of the BGP Prefix-SID attribute beyond its 453 intended scope of applicability, attribute filtering SHOULD be 454 deployed. 456 5.1. MPLS Dataplane: Labeled Unicast 458 A BGP speaker that originates a prefix attaches the Prefix-SID 459 attribute when it advertises the prefix to its neighbors via 460 Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC3107]). The value 461 of the Label-Index in the Label-Index TLV is determined by 462 configuration. 464 A BGP speaker that originates a Prefix-SID attribute MAY optionally 465 announce Originator SRGB TLV along with the mandatory Label-Index 466 TLV. The content of the Originator SRGB TLV is determined by the 467 configuration. 469 Since the Label-index value must be unique within an SR domain, by 470 default an implementation SHOULD NOT advertise the BGP Prefix-SID 471 attribute outside an Autonomous System unless it is explicitly 472 configured to do so. 474 A BGP speaker that advertises a path received from one of its 475 neighbors SHOULD advertise the Prefix-SID received with the path 476 without modification regardless of whether the Prefix-SID was 477 acceptable. If the path did not come with a Prefix-SID attribute, 478 the speaker MAY attach a Prefix-SID to the path if configured to do 479 so. The content of the TLVs present in the Prefix-SID is determined 480 by the configuration. 482 In all cases, the label field of the advertised NLRI ([RFC3107], 483 [RFC4364]) MUST be set to the local/incoming label programmed in the 484 MPLS dataplane for the given advertised prefix. If the prefix is 485 associated with one of the BGP speakers interfaces, this label is the 486 usual MPLS label (such as the implicit or explicit NULL label). 488 5.2. IPv6 Dataplane 490 A BGP speaker that originates an IPv6 prefix with the Prefix-SID 491 attribute, MAY include the IPv6 SID TLV. 493 A BGP speaker that advertises a path received from one of its 494 neighbors SHOULD advertise the Prefix-SID received with the path 495 without modification regardless of whether the Prefix-SID was 496 acceptable. If the path did not come with a Prefix-SID attribute, 497 the speaker MAY attach a Prefix-SID to the path if configured to do 498 so. 500 6. Error Handling of BGP-Prefix-SID Attribute 502 When a BGP Speaker receives a BGP Update message containing a 503 malformed BGP Prefix-SID attribute, it MUST ignore the received BGP 504 Prefix-SID attributes and not pass it to other BGP peers. This is 505 equivalent to the -attribute discard- action specified in [RFC7606]. 506 When discarding an attribute, a BGP speaker MAY log an error for 507 further analysis. 509 If the BGP Prefix-SID attribute appears more than once in an BGP 510 Update message, then, according to [RFC7606], all the occurrences of 511 the attribute other than the first one SHALL be discarded and the BGP 512 Update message SHALL continue to be processed. 514 When a BGP speaker receives an unacceptable Prefix-SID attribute, it 515 MAY log an error for further analysis. 517 7. IANA Considerations 519 This document defines a new BGP path attribute known as the BGP 520 Prefix-SID attribute. This document requests IANA to assign a new 521 attribute code type (suggested value: 40) for BGP the Prefix-SID 522 attribute from the BGP Path Attributes registry. 524 Currently, IANA temporarily assigned the following: 526 40 BGP Prefix-SID (TEMPORARY - registered 2015-09-30, expires 527 2016-09-30) [draft-ietf-idr-bgp-prefix-sid] 529 This document defines 3 new TLVs for BGP Prefix-SID attribute. These 530 TLVs need to be registered with IANA. We request IANA to create a 531 new registry for BGP Prefix-SID Attribute TLVs as follows: 533 Under "Border Gateway Protocol (BGP) Parameters" registry, "BGP 534 Prefix-SID attribute Types" Reference: draft-ietf-idr-bgp-prefix-sid 535 Registration Procedure(s): Values 1-254 First Come, First Served, 536 Value 0 and 255 reserved 538 Value Type Reference 539 0 Reserved this document 540 1 Label-Index this document 541 2 IPv6 SID this document 542 3 Originator SRGB this document 543 4-254 Unassigned 544 255 Reserved this document 546 8. Manageability Considerations 548 This document defines a new BGP attribute in order to address the use 549 case described in [I-D.ietf-spring-segment-routing-msdc]. It i 550 assumed that the new attribute (BGP Prefix-SID) advertisement is 551 controlled by the operator in order to: 553 o prevent undesired origination/advertisement of the BGP Prefix-SID 554 attribute. By default, a BGP Prefix-SID attribute SHOULD NOT be 555 originated and attached to a prefix. The operator MUST be capable 556 of explicitly enabling the BGP Prefix-SID origination. 558 o Prevent any undesired propagation of the BGP Prefix-SID attribute. 559 By default the BGP Prefix-SID is not advertised outside the 560 boundary of an AS. The propagation to other ASs MUST be 561 explicitly configured. 563 The deployment model described in 564 [I-D.ietf-spring-segment-routing-msdc] assumes multiple Autonomous 565 Systems (AS) under a common administration. The BGP Prefix-SID 566 advertisement is therefore applicable to inter-AS context while it is 567 confined within a single SR Domain. 569 9. Security Considerations 571 This document introduces a new BGP attribute (BGP Prefix-SID) which 572 inherits the security considerations expressed in: [RFC4271] and 573 [RFC3107]. 575 The BGP Prefix-SID attribute addresses the requirements introduced in 576 [I-D.ietf-spring-segment-routing-msdc] and It has to be noted, as 577 described in Section 8, that this document refer to a deployment 578 model where all nodes are under the same administration. In this 579 context, we assume that the operator doesn't want to leak outside of 580 the domain any information related to internal prefixes and topology. 581 The internal information includes the BGP Prefix-SID. In order to 582 prevent such leaking, the standard BGP mechanisms (filters) are 583 applied on the boundary of the domain. 585 10. Contributors 587 Keyur Patel 588 Arrcus, Inc. 589 US 591 Email: Keyur@arrcus.com 593 Saikat Ray 594 Unaffiliated 595 US 597 Email: raysaikat@gmail.com 599 11. Acknowledgements 601 The authors would like to thanks Satya Mohanty for his contribution 602 to this document. 604 12. References 606 12.1. Normative References 608 [I-D.ietf-spring-segment-routing] 609 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 610 and R. Shakir, "Segment Routing Architecture", draft-ietf- 611 spring-segment-routing-11 (work in progress), February 612 2017. 614 [I-D.ietf-spring-segment-routing-mpls] 615 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 616 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 617 data plane", draft-ietf-spring-segment-routing-mpls-08 618 (work in progress), March 2017. 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, 622 DOI 10.17487/RFC2119, March 1997, 623 . 625 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 626 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 627 . 629 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 630 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 631 DOI 10.17487/RFC4271, January 2006, 632 . 634 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 635 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 636 2006, . 638 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 639 Patel, "Revised Error Handling for BGP UPDATE Messages", 640 RFC 7606, DOI 10.17487/RFC7606, August 2015, 641 . 643 12.2. Informative References 645 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 646 Previdi, S., Psenak, P., Filsfils, C., Gredler, H., Chen, 647 M., and j. jefftant@gmail.com, "BGP Link-State extensions 648 for Segment Routing", draft-ietf-idr-bgp-ls-segment- 649 routing-ext-01 (work in progress), February 2017. 651 [I-D.ietf-idr-bgpls-segment-routing-epe] 652 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 653 Dong, "BGP-LS extensions for Segment Routing BGP Egress 654 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 655 epe-12 (work in progress), April 2017. 657 [I-D.ietf-spring-segment-routing-msdc] 658 Filsfils, C., Previdi, S., Mitchell, J., Aries, E., and P. 659 Lapukhov, "BGP-Prefix Segment in large-scale data 660 centers", draft-ietf-spring-segment-routing-msdc-04 (work 661 in progress), March 2017. 663 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 664 "Multiprotocol Extensions for BGP-4", RFC 4760, 665 DOI 10.17487/RFC4760, January 2007, 666 . 668 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 669 S. Ray, "North-Bound Distribution of Link-State and 670 Traffic Engineering (TE) Information Using BGP", RFC 7752, 671 DOI 10.17487/RFC7752, March 2016, 672 . 674 Authors' Addresses 676 Stefano Previdi (editor) 677 Cisco Systems 678 IT 680 Email: stefano@previdi.net 682 Clarence Filsfils 683 Cisco Systems 684 Brussels 685 Belgium 687 Email: cfilsfils@cisco.com 689 Acee Lindem 690 Cisco Systems 691 170 W. Tasman Drive 692 San Jose, CA 95124 95134 693 USA 695 Email: acee@cisco.com 696 Arjun Sreekantiah 697 Cisco Systems 698 170 W. Tasman Drive 699 San Jose, CA 95124 95134 700 USA 702 Email: asreekan@cisco.com 704 Hannes Gredler 705 RtBrick Inc. 707 Email: hannes@rtbrick.com