idnits 2.17.1 draft-chan-idr-bgp-lu2-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 6) being 63 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 133 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], [10013000], [RFC5492], [RFC2119], [RFC5512], [RFC3107], [BGP-CAP], [RFC7311], [RFC5575], [10024000], [RFC8277], [10002000], [RFC4760]), 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. == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (Sep 1, 2020) is 1334 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? 'RFC7911' on line 400 looks like a reference -- Missing reference section? 'BGP-CAP' on line 410 looks like a reference -- Missing reference section? 'RFC2119' on line 368 looks like a reference -- Missing reference section? 'RFC5492' on line 236 looks like a reference -- Missing reference section? 'RFC4760' on line 258 looks like a reference -- Missing reference section? '1000 2000' on line 313 looks like a reference -- Missing reference section? '1001 3000' on line 315 looks like a reference -- Missing reference section? '1002 4000' on line 317 looks like a reference -- Missing reference section? 'RFC3107' on line 373 looks like a reference -- Missing reference section? 'RFC4360' on line 378 looks like a reference -- Missing reference section? 'RFC5512' on line 383 looks like a reference -- Missing reference section? 'RFC5575' on line 389 looks like a reference -- Missing reference section? 'RFC7311' on line 394 looks like a reference -- Missing reference section? 'RFC8277' on line 405 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 15 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: Mar 31, 2021 Sep 1, 2020 7 Color Operation with BGP Label Unicast 8 draft-chan-idr-bgp-lu2-02.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 There is a major change of protocol format starting from this updated draft. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 28 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering Task Force 31 (IETF). Note that other groups may also distribute working documents as Internet- 32 Drafts. The list of current Internet-Drafts is at 33 http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months and may be 36 updated, replaced, or obsoleted by other documents at any time. It is 37 inappropriate to use Internet-Drafts as reference material or to cite them other 38 than as "work in progress." 40 This Internet-Draft will expire on Oct 15, 2020. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the document authors. 45 All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating 48 to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents carefully, as they 50 describe your rights and restrictions with respect to this document. Code 51 Components extracted from this document must include Simplified BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are provided without 53 warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction ...............................................................2 58 2. Conventions used in this document ..........................................3 59 3. Carrying Label Mapping Information with Color and Label Stack ..............4 60 3.1. Use of Add-path to advertise multiple color paths .....................4 61 3.2. Color extended community for BGP Labeled Unicast ......................4 62 3.3. Color extended community for service prefixes .........................5 63 3.4. Color Slicing Capability ..............................................6 64 4. Uniqueness of path entries .................................................7 65 5. AIGP consideration .........................................................7 66 6. Explicit Withdraw of a .........................7 67 7. Error Handling Procedure ...................................................8 68 8. Controller Compatibility ...................................................8 69 9. Security Considerations ....................................................8 70 10. IANA Considerations .......................................................8 71 11. References ................................................................8 72 11.1. Normative References .................................................8 73 11.2. Informative References ...............................................8 74 12. Acknowledgments ...........................................................9 76 1. Introduction 78 The proposed protocol is aimed to solve interdomain traffic steering, with 79 different transport services in mind. One application is low latency service across 80 multiple IGP domains, which could scale up to 100k or more routers network. 82 BGP is a flexible protocol. With additional of color attribute to BGP Label 83 Unicast, a path with specific color would be given a meaning in application - a low 84 latency path, a fully protected path, or a path for diversity. 86 The stack of labels would mean an end to end path across domains through each ABR 87 or ASBR. Each ABR or ASBR will take one label from the stack, and hence pick the 88 forwarding path to next ABR, ASBR, or the final destination. 90 And the label in the stack may be derived from any of the below 92 - Prefix SID 93 - Binding SID for RSVP LSP 94 - Binding SID for SR-TE LSP 95 - Local assigned label 97 The enhancement to the original RFC8277 is to add color extended community, with 98 multiple advertisement allowed. The result is similar to multi-topology BGP-LU with 99 different colors. 101 With Add-path [RFC7911] feature, non color RIB and colored RIB could be advertised 102 to the BGP neighbors without new additional attributes. Add-path capability is 103 required advertise multiple paths with same prefix but different colors. 105 A new [BGP-CAP] should be required to enforce such slicing operation during 106 negotiation. 108 On the other hand, to enable the service prefixes to be mapped accordingly, the 109 L3VPN, L2VPN, EVPN and IP prefix with BGP signaling, the color extended community 110 is also added there. In the PE node, the service prefixes with color will be 111 matched to a transport tunnel with the same color. 113 The following is an example. Between PE1 and PE2, there is a VPN service running 114 with label 16, which is associated with color 100. 116 PE1----ABR1-----ABR2-----PE2 118 PE1 will send the following labels with a color 100 path plus VPN label 120 [2001 13001 801 16], where 122 2001 - SR label to reach ABR1 124 13001 - a Binding-SID label for ABR1-ABR2 tunnel. Underlying tunnel type is RSVP-TE 126 801 - a Binding-SID label for ABR2-PE2 tunnel. Underlying tunnel type is SR-TE 128 16 - a VPN label, which is signaled via other means 130 [2001 13001 801] - denotes the label stack for this color 100 path to reach PE2 132 The document here is going to describe how PE1 gains enough information to build 133 this label stack across routing domains. 135 If PE1 wants to reach PE2 with another colored path, say color 200, the label stack 136 could be different. 138 At the same time, this architecture is also controller friendly, since all the 139 notation is Segment Routing compatible, like use of Binding-SID. 141 2. Conventions used in this document 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 144 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 145 interpreted as described in RFC 2119 [RFC2119]. 147 In this document, these words will appear with that interpretation only when in ALL 148 CAPS. Lower case uses of these words are not to be interpreted as carrying 149 significance described in RFC 2119. 151 3. Carrying Label Mapping Information with Color and Label Stack 153 3.1. Use of Add-path to advertise multiple color paths 155 The use of Path Identifier is to allow multiple advertisement of the same prefix 156 but with different colors or null color. 157 The extended NLRI format would be like this 159 +--------------------------------+ 160 | Path Identifier (4 octets) | 161 +--------------------------------+ 162 | Length (1 octet) | 163 +--------------------------------+ 164 | Label (3 octets) ~ 165 +--------------------------------+ 166 ~ Label (3 octets) | 167 +--------------------------------+ 168 | Prefix (variable) | 169 +--------------------------------+ 171 3.2. Color extended community for BGP Labeled Unicast 173 The addition of Color Extended Community is an opaque extended community from 174 RFC4360 and RFC5512. The draft allows multiple color values advertisement. 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 | 0x03 | 0x0b |C|O| Reserved |X|X|X| 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Color Value ~ 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 ~ 0x03 | 0x0b |C|O| Reserved |X|X|X| 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Color Value | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Figure 1: Color value advertisement format 189 Both in BGP update and MP_UNREACH_NLRI message, multiple color extended communities 190 could be included. It means that multiple colors, indicating different kind of 191 services, could share the same label stack. With the use of Path-ID, the multiple 192 colors are considered as one bundled update. Any subsequent update is based on 193 Path-ID. 195 If color extended community is not present in a BGP update message, it would be 196 treated as normal BGP-LU without any color. 198 3 bits of XXX is reserved here for the draft. 200 The meaning for XXX is interpreted as sub-slice of color, with 0 to 7 in decimal, 201 or 000b and 111b in binary. These sub-slice could be used in either of the 202 following case. 204 a) Primary path and fallback paths in order of preference 205 0 - primary path 206 1 - first and most preferred backup path 207 ... 208 7 - least preferred backup path 210 b) ECMP paths up to 8, since all paths should be active in forwarding plane. 212 Color value 0 is reserved for future interoperability purpose. 214 Color value 1 - 31 are not recommended to use, and this range is reserved for 215 future use. 217 3.3. Color extended community for service prefixes 219 The same format of color extended community is advertised with service prefixes, 220 which could be VPN prefixes or IP prefixes. The order of the color extended 221 community could be interpreted as 223 - Order of primary and fallback colors 224 - Or, ECMP of equal split between color paths 226 The above would be interpreted by the receiving PE upon its local configuration. 228 It is optional to enable sub-slice notation. 230 But if sub-slice bits are used, it will be used to map directly to each of the sub- 231 slice path. If sub-slice path is not available for mapping, it should just fallback 232 to resolving by color. 234 3.4. Color Slicing Capability 236 The Color Slicing Capability is a BGP capability [RFC5492], with Capability Code 237 xx. The Capability Length field of this capability is variable. The Capability 238 Value field consists of one or more of the following tuples: 240 +------------------------------------------------+ 241 | Address Family Identifier (2 octets) | 242 +------------------------------------------------+ 243 | Subsequent Address Family Identifier (1 octet) | 244 +------------------------------------------------+ 245 | version (1 octet) | 246 +------------------------------------------------+ 247 | Reserved (3 octet) | 248 +------------------------------------------------+ 250 The meaning and use of the fields are as follows: 252 Address Family Identifier (AFI): 254 This field is the same as the one used in [RFC4760]. 256 Subsequent Address Family Identifier (SAFI): 258 This field is the same as the one used in [RFC4760]. 260 Version: 262 This field is for capability negotiation. 264 0 1 2 3 4 5 6 7 265 +-+-+-+-+-+-+-+-+ 266 |v v v v| |s| 267 +-+-+-+-+-+-+-+-+ 269 Each of 4 bits of v represents a flag of version from 0 to 4, where LSB 270 denotes support of version 1, and MSB denotes version 4. Version 0 is the default 271 mode of operation, which is described in this document. To determine the common 272 capability between the two BGP PEER, logical AND function to use determine the 273 highest denominator of protocol version. 275 For example, if BGP receive 0b0110 from its peer and perform AND function with its 276 own capability 0b0010, the result is 0b0010. Version 2 is selected. 278 The other examples are 279 - 0b0110 AND 0b0110, version 3 is selected 280 - 0b0100 AND 0b0010, version 0 is selected 282 Version 1 (0b0001) is reserved. 284 S-flag is the indication of use of sub-slice. Set to 1 if sub-slice notation is 285 enforced. If either side is set to 0 for S-flag, sub-slice is not in use. 287 Reserved: 289 This field is reserved for future use. 291 4. Uniqueness of path entries 293 a) Use of color can be considered to slice into multiple BGP Label Unicast RIB. 294 Therefore, it should be treated as unique entries for the . 297 e.g. , [labels] 299 <123, 100, 10.1.1.1/32>, [1000 2000] 301 <124, 200, 10.1.1.1/32>, [1000 2000] 303 <222, {300,400}, 10.1.1.1/32>, [1000 2000] 305 <223, null, 10.1.1.1/32>, [1000 2000] 307 All these 4 NLRI are considered different but valid entries for different color 308 instances. 310 b) With sub-slice notation 311 , [labels] 313 <901, 100-0, 10.1.1.1/32>, [1000 2000] 315 <902, 100-1, 10.1.1.1/32>, [1001 3000] 317 <903, 100-7, 10.1.1.1/32>, [1002 4000] 319 These 3 NLRI are distinct, and the second and third NLRI could be used for 320 backup or ECMP purpose. 322 5. AIGP consideration 324 AIGP (RFC7311) would be also used in here to embed certain metric across. 326 6. Explicit Withdraw of a 327 According to RFC8277, MP_UNREACH_NLRI can be used to remove binding of a . 330 If a path-id is associated with a prefix with multiple colors, the withdrawal would 331 be applied to all associated colors. 333 To withdraw color(s) partially from the same path-id advertisement, BGP update 334 should be used instead. 336 7. Error Handling Procedure 338 If BGP receiver could not handle the NLRI, it should silently discard with error 339 logging. 341 8. Controller Compatibility 343 The proposed architecture is compatible with controller for end to end 344 provisioning. Persistent label, like Binding-SID is recommended to be used. Hence, 345 controller could learn these labels from the network, and program specific end to 346 end path. 348 In this case, BGP-LU2 will provide a second best path to an ingress PE node, while 349 a controller, with more external information, could provide a best path from 350 overall perspective. 352 Controller could also be deployed based on domain by domain perspective. e.g. 353 Optimizing latency of a RSVP LSP, or maintain the bandwidth and loading between SR- 354 TE LSPs. 356 9. Security Considerations 358 10. IANA Considerations 360 TBD. It will require a new BGP capability code to enable such color operation. 362 New SAFI might be required as well. 364 11. References 366 11.1. Normative References 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", 369 BCP 14, RFC 2119, March 1997. 371 11.2. Informative References 373 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 374 3107, DOI 10.17487/RFC3107, May 2001, 376 . 378 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 379 Communities Attribute", RFC 4360, February 2006 381 . 383 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address 384 Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 385 5512, April 2009. 387 . 389 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. 390 McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 391 10.17487/RFC5575, August 2009, 393 . 394 [RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro, 395 "The Accumulated IGP Metric Attribute for BGP", RFC 7311, 396 DOI 10.17487/RFC7311, August 2014, 398 . 400 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of 401 Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, 403 . 405 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, 406 DOI 10.17487/RFC8277, October 2017, 408 . 410 [BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement 412 with BGP-4", RFC 2842, May 2000. 414 12. Acknowledgments 416 The following people have contributed to this document: 418 Jeff Haas, Juniper Networks 420 Shraddha Hedge, Juniper Networks 422 Santosh Kolenchery, Juniper Networks 424 Shihari Sangli, Juniper Networks 426 Krzysztof Szarkowicz, Juniper Networks 428 Yimin Shen, Juniper Networks 430 Author Addresses 432 Louis Chan (editor) 433 Juniper Networks 434 2604, Cityplaza One, 1111 King's Road 435 Taikoo Shing 436 Hong Kong 438 Phone: +85225876659 439 Email: louisc@juniper.net