idnits 2.17.1 draft-keyupate-idr-bgp-prefix-sid-01.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 (April 21, 2015) is 3292 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 (-19) exists of draft-ietf-idr-error-handling-18 ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) == Outdated reference: A later version (-05) exists of draft-filsfils-spring-segment-routing-central-epe-03 == Outdated reference: A later version (-03) exists of draft-previdi-idr-bgpls-segment-routing-epe-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR K. Patel 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track S. Ray 5 Expires: October 23, 2015 Unaffiliated 6 S. Previdi 7 C. Filsfils 8 Cisco Systems 9 April 21, 2015 11 Segment Routing Prefix SID extensions for BGP 12 draft-keyupate-idr-bgp-prefix-sid-01 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 "segments". Each segment 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 The Segment Routing architecture can be implemented using MPLS with 24 no changes to the forwarding plane. It requires minor extensions to 25 the existing routing protocols. 27 This document describes the BGP extension for announcing BGP Prefix 28 Segment Identifier (BGP Prefix SID) information. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on October 23, 2015. 53 Copyright Notice 55 Copyright (c) 2015 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 72 3. Segment Routing Documents . . . . . . . . . . . . . . . . . . 3 73 4. BGP-Prefix-SID . . . . . . . . . . . . . . . . . . . . . . . 3 74 5. BGP-Prefix-SID Label Index Attribute . . . . . . . . . . . . 4 75 6. Receiving BGP-Prefix-SID Label Index Attribute . . . . . . . 5 76 7. Announcing BGP-Prefix-SID Label Index Attribute . . . . . . . 6 77 8. Error Handling of BGP-Prefix-SID Label Index Attribute . . . 6 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 81 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 13.1. Normative References . . . . . . . . . . . . . . . . . . 7 84 13.2. Informative References . . . . . . . . . . . . . . . . . 7 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 87 1. Introduction 89 Segment Routing (SR) architecture leverages the source routing 90 paradigm. A group of inter-connected nodes that use SR forms a SR 91 domain. The ingress node of the SR domain prepends a SR header 92 containing "segments" to an incoming packet. Each segment represents 93 a topological instruction (such as "go to prefix P following shortest 94 path") or a service instruction ("pass through deep packet 95 inspection"). By inserting the desired sequence of instructions, the 96 ingress node is able to steer a packet via any topological path and/ 97 or service chain; per-flow state is maintained only at the ingress 98 node of the SR domain. 100 Each segment is identified by a Segment Identifier (SID). By using 101 MPLS labels as SIDs, the SR architecture can be implemented using the 102 existing MPLS dataplane. 104 A BGP-Prefix Segment (aka BGP-Prefix-SID), is a BGP segment attached 105 to a BGP prefix. A BGP-Prefix-SID is always global within the SR/BGP 106 domain and identifies an instruction to forward the packet over the 107 ECMP-aware best-path computed by BGP to the related prefix. The BGP- 108 Prefix-SID is the identifier of the BGP prefix segment. 110 This document describes the BGP extension to signal the BGP-Prefix- 111 SID. Specifically, this document defines a new BGP attribute known 112 as BGP Label index attribute (carrying the BGP Prefix SID) and 113 specifies the rules to originate, receive and handle error conditions 114 of the new attribute. 116 2. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 120 be interpreted as described in [RFC2119] only when they appear in all 121 upper case. They may also appear in lower or mixed case as English 122 words, without any normative meaning. 124 3. Segment Routing Documents 126 The main reference for this document is the SR architecture defined 127 in [I-D.filsfils-spring-segment-routing]. 129 The Segment Routing Egress Peer Engineering architecture is described 130 in [I-D.filsfils-spring-segment-routing-central-epe]. 132 The Segment Routing Egress Peer Engineering BGPLS extensions are 133 described in [I-D.previdi-idr-bgpls-segment-routing-epe]. 135 A practical use case of the BGP Prefix SID is illustrated in 136 [I-D.filsfils-spring-segment-routing-msdc]. 138 4. BGP-Prefix-SID 140 The BGP-Prefix-SID attached to a BGP prefix P represents the 141 instruction "go to Prefix P" along its BGP bestpath (potentially 142 ECMP-enabled). This Segment is realized on a MPLS dataplane in the 143 following way: 145 According to [I-D.filsfils-spring-segment-routing], each BGP 146 speaker is configured with a label block called Segment Routing 147 Global Block (SRGB). The SRGB could be different on different 148 speakers. 150 The operator assigns a globally unique "index", L_I, to a locally 151 sourced prefix of a BGP speaker N which is advertised to all other 152 BGP speakers in the SR domain. 154 The index L_I is a 32 bit offset in the SRGB. Each BGP speaker 155 derives its local MPLS label, L, by adding L_I to the start value 156 of its own SRGB, and programs L in its MPLS dataplane as its 157 incoming/local label for the prefix. 159 If the BGP speakers are configured with the same SRGB start value, 160 they will all program the same MPLS label value for a given prefix 161 P. This has the effect of having a single label value for prefix 162 P across all BGP speakers despite the MPLS paradigm of "local 163 label" is preserved. 165 In order to advertise the SRGB label index of a given prefix P, a new 166 extension to BGP is needed. This extension is described in 167 subsequent sections. 169 5. BGP-Prefix-SID Label Index Attribute 171 BGP Prefix Label Index is a new optional, transitive BGP path 172 attribute. The attribute type code for BGP Label Index attribute is 173 to be assigned by IANA. The value field of the Label Index attribute 174 has following format: 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | RESERVED | Flags | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Label Index | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 where: 186 o RESERVED: 16 bit field. SHOULD be unset on transmission and MUST 187 be ignored on reception. 189 o Flags: 16 bits of flags. None are defined in this document. 190 Flags SHOULD be unset on transmission an MUST be ignored at 191 reception. 193 o Label Index: 32 bit value representing the index value in the SRGB 194 space. 196 Using the BGP protocol Label index as an offset, a label value for a 197 given prefix is computed from a BGP SRGB. The BGP SRGB protocol 198 label block is configured explicitly on each BGP Speaker enabled with 199 BGP-Prefix-SID extensions. 201 6. Receiving BGP-Prefix-SID Label Index Attribute 203 It is assumed that a BGP speaker is configured with an SRGB=[GB_S, 204 GB_E]. Given a label index L_I, we call L = L_I + GB_S as the 205 derived label. A BGP Label Index attribute is called "unacceptable" 206 for a speaker M if the derived label value L lies outside the SRGB 207 configured on M. Otherwise the Label Index attribute is called 208 "acceptable" to speaker M. 210 When a BGP speaker receives a path from a neighbor with an acceptable 211 BGP Label Index attribute, it SHOULD program the derived label as the 212 local label for the prefix in its MPLS dataplane. In case of any 213 error, a BGP speaker MUST resort to the error handling rules 214 specified in the later section of the document. A BGP speaker MAY 215 log an error for further analysis. 217 When a BGP speaker receives a path from a neighbor with an 218 unacceptable BGP Label Index attribute, for the purpose of label 219 allocation, it SHOULD treat the path as if it came without a Label 220 Index attribute. A BGP speaker MAY choose to assign a local (also 221 called dynamic) label (non-SRGB) for such a prefix. A BGP speaker 222 MAY log an error for further analysis. 224 A BGP speaker receiving a BGP Label index attribute from its EBGP 225 neighbor SHOULD discard the attribute unless it is configured to 226 accept the attribute from the EBGP neighbor. A BGP speaker MAY log 227 an error when discarding an attribute for further analysis. 229 A BGP speaker receiving a prefix with a Label index attribute and a 230 label NLRI field of implicit-null from a neighbor MUST adhere to 231 standard behavior and program its MPLS dataplane to pop the top label 232 when forwarding traffic to the prefix.The label NLRI defines the 233 outbound label that MUST be used by the receiving node. The Label 234 Index gives a hint to the receiving node on which local/incoming 235 label he SHOULD use. 237 7. Announcing BGP-Prefix-SID Label Index Attribute 239 A BGP speaker that originates a prefix attaches the Label Index 240 attribute when it advertises the prefix to its neighbors. The value 241 of the Label Index is determined by configuration. 243 A BGP speaker that advertises a path received from one of its 244 neighbors SHOULD advertise the Label Index received with the path 245 without modification regardless of whether the Label Index was 246 acceptable. If the path did not come with a Label Index attribute, 247 the speaker MAY attach a Label Index to the path if configured to do 248 so. The value of the Label Index is determined by the configuration. 250 In all cases, the label field of the NLRI ([RFC3107], [RFC4364]) MUST 251 be set to the label programmed in the MPLS dataplane for the given 252 prefix. If the prefix is that of a local interface of the speaker, 253 this label is the usual MPLS label (such as implicit or explicit NULL 254 label). 256 The BGP Label Index attribute SHOULD only be announced with BGP 257 Prefixes carried in a labeled address-family (SAFI value 4 or SAFI 258 value 128). Since the BGP Label index value must be unique within an 259 SR domain, by default an implementation SHOULD NOT advertise the BGP 260 Label Index attribute outside an Autonomous System unless it is 261 explicitly configured to do so. To contain distribution of the BGP 262 Label Index attribute beyond its intended scope of applicability, 263 attribute filtering MAY be deployed. 265 8. Error Handling of BGP-Prefix-SID Label Index Attribute 267 When a BGP Speaker receives a BGP Update message containing more than 268 one, or a malformed BGP Label Index attribute, it MUST ignore the 269 received BGP Label Index attributes and not pass it to other BGP 270 peers. (see [I-D.ietf-idr-error-handling], Section 7). This is 271 equivalent to the -attribute discard- action specified in 272 [[I-D.ietf-idr-error-handling]. A BGP speaker MAY log an error when 273 discarding an attribute for further analysis. 275 When a BGP Speaker receives a BGP Label Index attribute that is 276 attached to prefixes belonging to SAFI value other than 4 or 128, it 277 MUST quietly ignore the received attribute and not pass it to other 278 BGP peers. A BGP speaker MAY log an error for further analysis. 280 When a BGP speaker receives an unacceptable Label Index attribute, it 281 MAY log an error for further analysis. 283 9. IANA Considerations 285 This document defines a new BGP attribute known as BGP Label Index 286 attribute. This document requests IANA to assign a new attribute 287 code type for BGP Label Index attribute from the BGP Path Attributes 288 registry. 290 10. Security Considerations 292 This document introduces no new security considerations above and 293 beyond those already specified in [RFC4271] and [RFC3107]. 295 11. Acknowledgements 297 TBD 299 12. Change Log 301 Initial Version: Sep 21 2014 303 13. References 305 13.1. Normative References 307 [I-D.ietf-idr-error-handling] 308 Chen, E., Scudder, J., Mohapatra, P., and K. Patel, 309 "Revised Error Handling for BGP UPDATE Messages", draft- 310 ietf-idr-error-handling-18 (work in progress), December 311 2014. 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, March 1997. 316 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 317 BGP-4", RFC 3107, May 2001. 319 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 320 Protocol 4 (BGP-4)", RFC 4271, January 2006. 322 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 323 Networks (VPNs)", RFC 4364, February 2006. 325 13.2. Informative References 327 [I-D.filsfils-spring-segment-routing] 328 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 329 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 330 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 331 "Segment Routing Architecture", draft-filsfils-spring- 332 segment-routing-04 (work in progress), July 2014. 334 [I-D.filsfils-spring-segment-routing-central-epe] 335 Filsfils, C., Previdi, S., Patel, K., Aries, E., 336 shaw@fb.com, s., Ginsburg, D., and D. Afanasiev, "Segment 337 Routing Centralized Egress Peer Engineering", draft- 338 filsfils-spring-segment-routing-central-epe-03 (work in 339 progress), January 2015. 341 [I-D.filsfils-spring-segment-routing-msdc] 342 Filsfils, C., "BGP-Prefix Segment in large-scale data 343 centers", 2014. 345 [I-D.previdi-idr-bgpls-segment-routing-epe] 346 Previdi, S., Filsfils, C., Ray, S., Patel, K., Dong, J., 347 and M. Chen, "Segment Routing Egress Peer Engineering 348 BGPLS Extensions", draft-previdi-idr-bgpls-segment- 349 routing-epe-02 (work in progress), March 2015. 351 Authors' Addresses 353 Keyur Patel 354 Cisco Systems 355 170 W. Tasman Drive 356 San Jose, CA 95124 95134 357 USA 359 Email: keyupate@cisco.com 361 Saikat Ray 362 Unaffiliated 364 Email: raysaikat@gmail.com 366 Stefano Previdi 367 Cisco Systems 368 Via Del Serafico, 200 369 Rome 00142 370 Italy 372 Email: sprevidi@cisco.com 373 Clarence Filsfils 374 Cisco Systems 375 Brussels 376 Belgium 378 Email: cfilsfils@cisco.com