idnits 2.17.1 draft-chan-idr-bgp-lu2-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 9. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 10. IANA Considerations' ) ** There are 119 instances of too long lines in the document, the longest one being 17 characters in excess of 72. ** The abstract seems to contain references ([RFC4360], [RFC7911], [RFC2119], [RFC5512], [101300], [RFC3107], [BGP-CAP], [100200], [RFC7311], [RFC5575], [RFC8277], [102400]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 138 has weird spacing: '...etation only...' == Line 139 has weird spacing: '...t to be int...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (Apr 16, 2020) is 1468 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? 'BGP-CAP' on line 329 looks like a reference -- Missing reference section? 'RFC2119' on line 287 looks like a reference -- Missing reference section? '100 200' on line 229 looks like a reference -- Missing reference section? '101 300' on line 231 looks like a reference -- Missing reference section? '102 400' on line 233 looks like a reference -- Missing reference section? 'RFC3107' on line 292 looks like a reference -- Missing reference section? 'RFC4360' on line 297 looks like a reference -- Missing reference section? 'RFC5512' on line 302 looks like a reference -- Missing reference section? 'RFC5575' on line 308 looks like a reference -- Missing reference section? 'RFC7311' on line 313 looks like a reference -- Missing reference section? 'RFC7911' on line 319 looks like a reference -- Missing reference section? 'RFC8277' on line 324 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group Louis Chan 3 INTERNET-DRAFT 4 Intended status: Experimental Juniper Networks 5 Expires: Oct 15, 2020 Apr 16, 2020 7 Color Operation with BGP Label Unicast 8 draft-chan-idr-bgp-lu2-01.txt 10 Abstract 12 This document specifies how to carry colored path advertisement via an enhancement 13 to the existing protocol BGP Label Unicast. It would allow backward compatibility 14 with RFC8277. 16 The targeted solution is to use stack of labels advertised via BGP Label Unicast 17 2.0 for end to end traffic steering across multiple IGP domains. The operation is 18 similar to Segment Routing. 20 This proposed protocol will convey the necessary reachability information to the 21 ingress PE node to construct an end to end path 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 26 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering Task Force 29 (IETF). Note that other groups may also distribute working documents as Internet- 30 Drafts. The list of current Internet-Drafts is at 31 http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months and may be 34 updated, replaced, or obsoleted by other documents at any time. It is 35 inappropriate to use Internet-Drafts as reference material or to cite them other 36 than as "work in progress." 38 This Internet-Draft will expire on Oct 15, 2020. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the document authors. 43 All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating 46 to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents carefully, as they 48 describe your rights and restrictions with respect to this document. Code 49 Components extracted from this document must include Simplified BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction...................................................2 56 2. Conventions used in this document..............................3 57 3. Carrying Label Mapping Information with Color and Label Stack..4 58 3.1. Color extended community for BGP Labeled Unicast..........4 59 3.2. Color extended community for service prefixes.............5 60 4. Uniqueness of path entries.....................................5 61 5. AIGP consideration.............................................5 62 6. Explicit Withdraw of a .........................6 63 7. Error Handling Procedure.......................................6 64 8. Controller Compatibility.......................................6 65 9. Security Considerations........................................6 66 10. IANA Considerations...........................................6 67 11. References....................................................7 68 11.1. Normative References.....................................7 69 11.2. Informative References...................................7 70 12. Acknowledgments...............................................8 72 1. Introduction 74 The proposed protocol is aimed to solve interdomain traffic steering, with 75 different transport services in mind. One application is low latency service across 76 multiple IGP domains, which could scale up to 100k routers network. 78 BGP is a flexible protocol. With additional of color attribute to BGP Label 79 Unicast, a path with specific color would be given a meaning in application - a low 80 latency path, a fully protected path, or a path for diversity. 82 The stack of labels would mean an end to end path across domains through each ABR 83 or ASBR. Each ABR or ASBR will take one label from the stack, and hence pick the 84 forwarding path to next ABR, ASBR, or the final destination. 86 And the label in the stack may be derived from any of the below 88 - Prefix SID 89 - Binding SID for RSVP LSP 90 - Binding SID for SR-TE LSP 91 - Local assigned label 93 The enhancement to the original RFC8277 is to add color extended community, with 94 multiple advertisement allowed. The result is similar to multi-topology BGP-LU with 95 different colors. 97 A new [BGP-CAP] should be required to enable such slicing. 99 On the other hand, to enable the service prefixes to be mapped accordingly, the 100 L3VPN, L2VPN, EVPN and prefix with BGP signaling, the color extended community is 101 also added there. In the PE node, the service prefixes with color will be matched 102 to a transport tunnel with the same color. 104 The following is an example. Between PE1 and PE2, there is a VPN service running 105 with label 16, which is associated with color 100. 107 PE1----ABR1-----ABR2-----PE2 109 PE1 will send the following labels with a color 100 path plus VPN label 111 [2001 13001 801 16], where 113 2001 - SR label to reach ABR1 115 13001 - a Binding-SID label for ABR1-ABR2 tunnel. Underlying tunnel type is RSVP-TE 117 801 - a Binding-SID label for ABR2-PE2 tunnel. Underlying tunnel type is SR-TE 119 16 - a VPN label, which is signaled via other means 121 [2001 13001 801] denotes the label stack for this color 100 path to reach PE2 123 The document here is going to describe how PE1 gains enough information to build 124 this label stack across routing domains. 126 If PE1 wants to reach PE2 with another colored path, say color 200, the label stack 127 could be different. 129 At the same time, this architecture is also controller friendly, since all the 130 notation is Segment Routing compatible, like use of Binding-SID. 132 2. Conventions used in this document 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 135 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 136 interpreted as described in RFC 2119 [RFC2119]. 138 In this document, these words will appear with that interpretation only when in 139 ALL CAPS. Lower case uses of these words are not to be interpreted as carrying 140 significance described in RFC 2119. 142 3. Carrying Label Mapping Information with Color and Label Stack 144 3.1. Color extended community for BGP Labeled Unicast 146 The addition of Color Extended Community is an opaque extended community from 147 RFC4360 and RFC5512. The draft allows multiple color values advertisement. 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | 0x03 | 0x0b |C|O| Reserved |X|X|X| 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Color Value ~ 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 ~ 0x03 | 0x0b |C|O| Reserved |X|X|X| 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Color Value | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 1: Color value advertisement format 162 Both in BGP update and MP_UNREACH_NLRI message, multiple color extended communities 163 could be included. It means that multiple colors, indicating different kind of 164 services, could share the same label stack. 166 If only one color extended community is specified, only prefix with that color 167 value is updated or withdrawn. 169 If a MP_UNREACH_NLRI message without any color specified is received for a given 170 prefix, that prefix with color(s) should not be affected. 172 If color extended community is not present in a BGP update message, it would be 173 treated as normal BGP-LU without any color. 175 3 bits of XXX is reserved here for the draft. 177 The meaning for XXX is interpreted as sub-slice of color, with 0 to 7 in decimal, 178 or 000b and 111b in binary. These sub-slice could be used in either of the 179 following case. 181 a) Primary path and fallback paths in order of preference 182 0 primary path 183 1 first and most preferred backup path 185 7 least preferred backup path 187 b) ECMP paths up to 8, since all paths should be active in forwarding plane. 189 Color value 0 is reserved for future interoperability purpose. 191 Color value 1 - 31 are not recommended to use, and this range is reserved for 192 future use. 194 3.2. Color extended community for service prefixes 196 The same format of color extended community is advertised with service prefixes. 197 The order of the color extended community could be interpreted as 199 - Order of primary and fallback colors 200 - Or, ECMP of equal split between color paths 202 The above would be interpreted by the receiving PE upon its local configuration. 204 It is optional to enable sub-slice notation. 206 But if sub-slice bits are used, it will be used to map directly to each of the sub- 207 slice path. If sub-slice path is not available for mapping, it should just fallback 208 to resolving by color. 210 4. Uniqueness of path entries 212 a) Use of color can be considered to slice into multiple BGP Label Unicast RIB. 213 Therefore, it should be treated as unique entries for the . 215 e.g. , [labels] 217 <1, 10.1.1.1/32>, [100 200] 219 <2, 10.1.1.1/32>, [100 200] 221 , [100 200] 223 All these 3 NLRI are considered different but valid entries for different color 224 instances. 226 b) With sub-slice notation 227 , [labels] 229 <1-0, 10.1.1.1/32>, [100 200] 231 <1-1, 10.1.1.1/32>, [101 300] 233 <1-7, 10.1.1.1/32>, [102 400] 235 These 3 NLRI are distinct, and the second and third NLRI could be used for 236 backup or ECMP purpose. 238 5. AIGP consideration 240 AIGP (RFC7311) would be also used in here to embed certain metric across. 242 6. Explicit Withdraw of a 243 According to RFC8277, MP_UNREACH_NLRI can be used to remove binding of a . 246 Compatibility is set to 0xC00000 to specify the use of color. Multiple color 247 extended communities could be applied here. 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Length | Compatibility | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Prefix ~ 255 ~ | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 2: NLRI for Withdrawal 259 7. Error Handling Procedure 261 If BGP receiver could not handle the NLRI, it should silently discard with error 262 logging. 264 8. Controller Compatibility 266 The proposed architecture is compatible with controller for end to end 267 provisioning. Persistent label, like Binding-SIS is recommended to be used. Hence, 268 controller could learn these labels from the network, and program specific end to 269 end path. 271 Controller could also be deployed based on domain by domain perspective. e.g. 272 Optimizing latency of a RSVP LSP, or maintain the bandwidth and loading between SR- 273 TE LSPs. 275 9. Security Considerations 277 10. IANA Considerations 279 TBD. It will require a new BGP capability code to enable such color operation. 281 New SAFI might be required as well. 283 11. References 285 11.1. Normative References 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", 288 BCP 14, RFC 2119, March 1997. 290 11.2. Informative References 292 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 293 3107, DOI 10.17487/RFC3107, May 2001, 295 . 297 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 298 Communities Attribute", RFC 4360, February 2006 300 . 302 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address 303 Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 304 5512, April 2009. 306 . 308 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. 309 McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 310 10.17487/RFC5575, August 2009, 312 . 313 [RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro, 314 "The Accumulated IGP Metric Attribute for BGP", RFC 7311, 315 DOI 10.17487/RFC7311, August 2014, 317 . 319 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of 320 Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, 322 . 324 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, 325 DOI 10.17487/RFC8277, October 2017, 327 . 329 [BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement 331 with BGP-4", RFC 2842, May 2000. 333 12. Acknowledgments 335 The following people have contributed to this document: 337 Jeff Haas, Juniper Networks 339 Shraddha Hedge, Juniper Networks 341 Santosh Kolenchery, Juniper Networks 343 Shihari Sangli, Juniper Networks 345 Krzysztof Szarkowicz, Juniper Networks 347 Yimin Shen, Juniper Networks 349 Authors Addresses 351 Louis Chan (editor) 352 Juniper Networks 353 2604, Cityplaza One, 1111 King's Road 354 Taikoo Shing 355 Hong Kong 357 Phone: +85225876659 358 Email: louisc@juniper.net