idnits 2.17.1 draft-chan-idr-bgp-lu2-00.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 1) being 62 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: ' 8. 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: ' 9. IANA Considerations' ) ** There are 107 instances of too long lines in the document, the longest one being 22 characters in excess of 72. ** The abstract seems to contain references ([RFC4360], [RFC7911], [RFC2119], [RFC5512], [RFC3107], [BGP-CAP], [100200], [RFC5575], [RFC8277]), 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 127 has weird spacing: '...etation only...' == Line 128 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 (Nov 4, 2019) is 1633 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? 'BGP-CAP' on line 270 looks like a reference -- Missing reference section? 'RFC2119' on line 233 looks like a reference -- Missing reference section? '100 200' on line 190 looks like a reference -- Missing reference section? 'RFC3107' on line 238 looks like a reference -- Missing reference section? 'RFC4360' on line 243 looks like a reference -- Missing reference section? 'RFC5512' on line 248 looks like a reference -- Missing reference section? 'RFC5575' on line 254 looks like a reference -- Missing reference section? 'RFC7911' on line 260 looks like a reference -- Missing reference section? 'RFC8277' on line 265 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IDR Working Group Louis Chan 2 INTERNET-DRAFT 3 Intended status: Experimental Juniper Networks 4 Expires: May 4, 2020 Nov 4, 2019 6 Color Operation with BGP Label Unicast 7 draft-chan-idr-bgp-lu2-00.txt 9 Abstract 11 This document specifies how to carry colored path advertisement via an enhancement 12 to the existing protocol BGP Label Unicast. It would allow backward compatibility 13 with RFC8277. 15 The targeted solution is to use stack of labels advertised via BGP Label Unicast 16 2.0 for end to end traffic steering across multiple IGP domains. The operation is 17 similar to Segment Routing. 19 This proposed protocol will convey the necessary reachability information to the 20 ingress PE node to construct an end to end path 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 25 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering Task Force 28 (IETF). Note that other groups may also distribute working documents as Internet- 29 Drafts. The list of current Internet-Drafts is at 30 http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months and may be 33 updated, replaced, or obsoleted by other documents at any time. It is 34 inappropriate to use Internet-Drafts as reference material or to cite them other 35 than as "work in progress." 37 This Internet-Draft will expire on May 4, 2020. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the document authors. 42 All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating 45 to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents carefully, as they 47 describe your rights and restrictions with respect to this document. Code 48 Components extracted from this document must include Simplified BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are provided without 50 warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction................................................................2 55 2. Conventions used in this document...........................................3 56 3. Carrying Label Mapping Information with Color and Label Stack...............3 57 3.1. Color extended community for BGP Labeled Unicast.......................3 58 3.2. Color extended community for service prefixes..........................4 59 4. Uniqueness of path entries..................................................4 60 5. AIGP consideration..........................................................4 61 6. Explicit Withdraw of a ......................................4 62 7. Error Handling Procedure....................................................5 63 8. Security Considerations.....................................................5 64 9. IANA Considerations.........................................................5 65 10. References.................................................................5 66 10.1. Normative References.................................................5 67 10.2. Informative References...............................................5 68 11. Acknowledgments............................................................6 70 1. Introduction 72 The proposed protocol is aimed to solve interdomain traffic steering, with 73 different transport services in mind. One application is low latency service across 74 multiple IGP domains, which could scale up to 100k routers network. 76 BGP is a flexible protocol. With additional of color attribute to BGP Label 77 Unicast, a path with specific color would be given a meaning in application - a low 78 latency path, a fully protected path, or a path for diversity. 80 The stack of labels would mean an end to end path across domains through each ABR 81 or ASBR. Each ABR or ASBR will take one label from the stack, and hence pick the 82 forwarding path to next ABR, ASBR, or the final destination. 84 And the label in the stack may be derived from any of the below 86 - Prefix SID 87 - Binding SID for RSVP LSP 88 - Binding SID for SR-TE LSP 89 - Local assigned label 91 The enhancement to the original RFC8277 is to add color extended community, with 92 multiple advertisement allowed. The result is similar to multi-topology BGP-LU with 93 different colors. 95 A new [BGP-CAP] should be required to enable such slicing. 97 On the other hand, to enable the service prefixes to be mapped according, the 98 L3VPN, L2VPN, EVPN and prefix with BGP signaling, the color extended community is 99 also added there. In the PE node, the service prefixes with color will be matched 100 to a transport tunnel with the same color. 102 The following is an example 104 PE1----ABR1-----ABR2-----PE2 106 PE1 will send the following labels with a color 100 path 108 [2001 13001 801 16], where 110 2001 - SR label to reach ABR1 112 13001 - Binding-SID label to reach ABR2. Underlying tunnel type is RSVP-TE 114 801 - Binding-SID label to reach PE2. Underlying tunnel type is SR-TE 116 16 - a VPN label 118 If PE1 wants to reach PE2 with another colored path, say color 200, the label stack 119 could be different. 121 2. Conventions used in this document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 124 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 125 interpreted as described in RFC 2119 [RFC2119]. 127 In this document, these words will appear with that interpretation only when in 128 ALL CAPS. Lower case uses of these words are not to be interpreted as carrying 129 significance described in RFC 2119. 131 3. Carrying Label Mapping Information with Color and Label Stack 133 3.1. Color extended community for BGP Labeled Unicast 135 The addition of Color Extended Community is an opaque extended community from 136 RFC4360 and RFC5512. The draft allows multiple color values advertisement. 138 0 1 2 3 139 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 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | 0x03 | 0x0b |C|O| Reserved |X|X|X| 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Color Value ~ 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 ~ 0x03 | 0x0b |C|O| Reserved |X|X|X| 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Color Value | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 Figure 1: Color value advertisement format 152 Both in BGP update and MP_UNREACH_NLRI message, multiple color extended communities 153 could be included. It means that multiple colors, indicating different kind of 154 services, could share the same label stack. 156 If only one color extended community is specified, only prefix with that color 157 value is updated or withdrawn. 159 If a MP_UNREACH_NLRI message without any color specified is received for a given 160 prefix, that prefix with any color should not be affected. 162 If color extended community is not present in a BGP update message, it would be 163 treated as normal BGP-LU without any color. 165 3 bits of XXX is reserved here for the draft. 167 Color value 0 is reserved for future interoperability purpose. 169 3.2. Color extended community for service prefixes 171 The same format of color extended community is advertised with service prefixes. 172 The order of the color extended community could be interpreted as 174 - Order of primary and fallback colors 175 - Or, ECMP of equal split between color tunnels 177 The above would be interpreted by the receiving PE upon its local configuration. 179 4. Uniqueness of path entries 181 Use of color can be considered to slice into multiple BGP Label Unicast RIB. 182 Therefore, it should be treated as unique entries for the . 184 e.g. , [labels] 186 <1, 10.1.1.1/32>, [100 200] 188 <2, 10.1.1.1/32>, [100 200] 190 , [100 200] 192 All these 3 NLRI are considered different but valid entries for different color 193 instances. 195 5. AIGP consideration 197 AIGP (RFC7311) would be also used in here to embed certain metric across. 199 6. Explicit Withdraw of a 200 According to RFC8277, MP_UNREACH_NLRI can be used to remove binding of a . 203 Compatibility is set to 0xC00000 to specify the use of color. Multiple color 204 extended communities could be applied here. 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Length | Compatibility | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Prefix ~ 212 ~ | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Figure 2: NLRI for Withdrawal 216 7. Error Handling Procedure 218 If BGP receiver could not handle the NLRI, it should silently discard with error 219 logging. 221 8. Security Considerations 223 9. IANA Considerations 225 TBD. It will require a new BGP capability code to enable such color operation. 227 New SAFI might be required as well. 229 10. References 231 10.1. Normative References 233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", 234 BCP 14, RFC 2119, March 1997. 236 10.2. Informative References 238 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 239 3107, DOI 10.17487/RFC3107, May 2001, 241 . 243 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 244 Communities Attribute", RFC 4360, February 2006 246 . 248 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address 249 Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 250 5512, April 2009. 252 . 254 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. 255 McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 256 10.17487/RFC5575, August 2009, 258 . 260 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of 261 Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, 263 . 265 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, 266 DOI 10.17487/RFC8277, October 2017, 268 . 270 [BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement 272 with BGP-4", RFC 2842, May 2000. 274 11. Acknowledgments 276 The following people have contributed to this document: 278 Jeff Haas, Juniper Networks 280 Shraddha Hedge, Juniper Networks 282 Santosh Kolenchery, Juniper Networks 284 Shihari Sangli, Juniper Networks 286 Krzysztof Szarkowicz, Juniper Networks 288 Yimin Shen, Juniper Networks 290 Authors Addresses 292 Louis Chan (editor) 293 Juniper Networks 294 2604, Cityplaza One, 1111 King's Road 295 Taikoo Shing 296 Hong Kong 298 Phone: +85225876659 299 Email: louisc@juniper.net