idnits 2.17.1 draft-zhou-idr-inter-domain-lcu-04.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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 243 has weird spacing: '... prefix colo...' -- The document date (7 March 2022) is 781 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) == Missing Reference: 'RFC3392' is mentioned on line 168, but not defined ** Obsolete undefined reference: RFC 3392 (Obsoleted by RFC 5492) == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-12 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-19 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR R. Chen 3 Internet-Draft Ch. Dai 4 Intended status: Standards Track Sh. Peng 5 Expires: 8 September 2022 ZTE Corporation 6 7 March 2022 8 Inter-domain Network Slicing via BGP-LU 9 draft-zhou-idr-inter-domain-lcu-04 11 Abstract 13 This document aims to solve inter-domain network slicing problems 14 using existing technologies. It attempts to establish multiple BGP- 15 LU LSPs of different colors for a/multiple prefix to stitch multiple 16 network segments. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 8 September 2022. 35 Copyright Notice 37 Copyright (c) 2022 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Revised BSD License text as 46 described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Revised BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 53 2. Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Advertising multiple paths . . . . . . . . . . . . . . . . . 3 55 4. Assigning Label(s) . . . . . . . . . . . . . . . . . . . . . 4 56 5. Inter-domain Network Slicing via BGP-LU . . . . . . . . . . . 4 57 5.1. Colored BGP-LU Capability Advertisement . . . . . . . . . 4 58 5.2. Colored BGP-LU realized . . . . . . . . . . . . . . . . . 5 59 6. SRv6 support . . . . . . . . . . . . . . . . . . . . . . . . 7 60 7. Deploy Considerations . . . . . . . . . . . . . . . . . . . . 7 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 11. Normative References . . . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 In the traditional end to end inter-domain network slicing, BGP-LU is 70 used to build inter-domain MPLS LSP, and overlay service will be 71 directly over BGP-LU LSP. For an E2E BGP-LU LSP, if overlay service 72 has TE requirements that defined by a color, the BGP-LU LSP need also 73 have a sense of color, i.e., BGP-LU label could be allocated per 74 color. 76 [RFC8277] specifies a set of procedures for using BGP to advertise 77 that a specified router has bound a specified MPLS label to a 78 specified address prefix. It's an effective way for inter-domain 79 labels, but it does not have the ability to select the underlying 80 network resources. 82 This document describes the colored BGP-LU LSP, which contains two 83 options: 85 * One is to define the multiple paths for the same destination 86 prefix and advertise in BGP UPDATE message, and each UPDATE 87 message can contain the color Extended Community [RFC9012] with 88 different color value, which helps to select the underlying 89 resources.This mode require additional path function defined in 90 [RFC7911]. 92 * The other is that multiple prefixes and multiple colors are 93 configured on PE. One prefixes corresponds to one color. This 94 mode does not require to additional path function. 96 1.1. Requirements Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 2. Color 104 [RFC9012] introduces the concept of color, which is used as one of 105 the KEY of SR policy [I-D.ietf-spring-segment-routing-policy]. The 106 color of SR policy defines a TE purpose, which includes a set of 107 constraints such as bandwidth, delay, TE metric, etc. 109 TO help routing decisions , each UPDATE may contain a Color Extended 110 Community with a specific color value, the Color Sub-TLV is only an 111 opaque extended community. 113 3. Advertising multiple paths 115 A BGP speaker can advertise multiple paths for a particular address 116 prefix by a Path identifier in the Extended NLRI Encoding as defined 117 in [RFC7911]. 119 +--------------------------------+ 120 | Path Identifier (4 octets) | 121 +--------------------------------+ 122 | Length (1 octet) | 123 +--------------------------------+ 124 | Prefix (variable) | 125 +--------------------------------+ 127 Figure 1 129 The Path Identifier only identifies a path, not carrying any 130 particular semantics.In this document, it can be generated by the 131 tuple. The assignment to the Path Identifier for a 132 path by a BGP speaker is purely a local matter. 134 Therefore, if a BGP speaker has two colors for the prefix P, which 135 correspond to two different paths, it may advertise two UPDATE NLRIs, 136 with color1 extended community and with color2 extended community. Pathid1 and pathid2 in two 138 UPDATE NLRIs MUST be different. 140 Note that in this document, BGP speakers acting as border routers 141 that interact with external neighbors need to support advertising 142 multiple paths corresponding to the same prefix. Although multiple 143 paths have differnet path ids, they have the same next hop. As for 144 the procedures of mutual backup paths with the same prefix and the 145 differnet next hops, refer to [RFC7911]. 147 4. Assigning Label(s) 149 [RFC8277] describes how to use BGP to bind MPLS label(s) to the 150 address prefixes. The specific format of the UPDATE message is 151 detailed in Section 2 of [RFC8277]. 153 [RFC8277] Section 3.2 details the process of modifying the Label 154 field during propagation. When propagating a SAFI-4 or SAFI-128 155 route, if the Network Address of Next Hop field has never changed, 156 the label field must remain unchanged. Otherwise, if the Network 157 Address of Next Hop field is changed, the label field(s) of the 158 propagating route must contain the label(s) that is (are) bound to 159 the prefix at the new next hop. What the label changes to depends on 160 the local policy. However, LSPs with different color paths need to 161 have different label(s). 163 5. Inter-domain Network Slicing via BGP-LU 165 5.1. Colored BGP-LU Capability Advertisement 167 A BGP speaker that uses Colored BGP-LU Extensions SHOULD use the 168 Capability Advertisement procedures [RFC3392] to determine whether 169 the speaker could use Colored BGP-LU Extensions with a particular 170 peer. 172 The fields in the Capabilities Optional Parameter are set as 173 follows： 175 * The Capability Code field TBD1 (which indicates Colored BGP-LU 176 Extensions capabilities). 178 * The Capability Length field is set to 4. 180 * The Capability Value field is defined as: 182 +------------------------------------------------+ 183 | Address Family Identifier (2 octets) | 184 +------------------------------------------------+ 185 | Subsequent Address Family Identifier (1 octet) | 186 +------------------------------------------------+ 187 | reseve (1 octet) | 188 +------------------------------------------------+ 189 Figure 2 191 where: 193 AFI-Address Family Identifier (16 bit), The values is 1 "IPV4"or 2 194 "IPV6". 196 SAFI-Subsequent Address Family Identifier (8 bit), The values is 1 197 "Unicast"or 4(BGP LU). 199 Res.-Reserved (8 bit) field. SHOULD be set to 0 by the sender and 200 ignored by the receiver. 202 Note that not setting the field value to 0 may create issues for a 203 receiver not ignoring the field. In addition, this definition is 204 problematic if it is ever attempted to redefine the field. 206 5.2. Colored BGP-LU realized 208 [RFC7911] defined that multiple paths for a particular address prefix 209 by a Path identifier can be advertised in BGP UPDATE message, and 210 each UPDATE message can contain the Color Extended Community 211 [RFC9012] with different color value. That is a simple existing way 212 to realize BGP-LU color function, and only an extension of Colored 213 BGP-LU capability advertisement is required. 215 Consider the following example of establishing multiple BGP-LU LSPs 216 per different colors in a cross-domain scenario. 218 <1.1.1.1, path-id1> <1.1.1.1, path-id1> <1.1.1.1, path-id1> 219 220 ------------------------------------------------------------------> 221 .----. .------. 222 ( ) ( ) 223 .-( )-. .-( )-. 224 +---+---color1----+----+ +---+----color1----+---+ 225 |PE1|\---SR-TE1---/|AS |-sub-if1 with slice1-|AS |\---SR-TE1---/|PE2| 226 | |/---SR-TE2---\|BR1|-sub-if2 with slice2-|BR2|/---SR-TE2---\| | 227 +---+---color2---- +---+ +---+--color2------+---+ 228 ( ) ( ) 229 '--( AS1 )--' '--( AS2 )--' 230 ( ) ( ) 231 '-' '-' 232 -------------------------------------------------------------------> 233 <1.1.1.1, path-id2> <1.1.1.1, path-id2> <1.1.1.1, path-id2> 234 236 Label Exchange Tables: 237 ASBR1: ASBR2: 238 inLabel outLabel nextHop inLabel outLabel nextHop 239 201 200 SR-TE1 201 201 sub-if1 240 202 200 SR-TE2 202 202 sub-if2 242 PE2: 243 prefix color outLabel nextHop 244 1.1.1.1 1 201 SR-TE1 245 1.1.1.1 2 202 SR-TE2 247 Figure 3 249 In figure 1, PE1 advertises two paths: <1.1.1.1, path-id1> carries 250 the color1 attribute and <1.1.1.1, path-id2> carries the color2 251 attribute to ASBR1.PE1 advertises the binding between the prefix 252 1.1.1.1 and label 200. Because of the end node, both paths have the 253 same label value 200. 255 ASBR1 receives these two paths from PE1, and when sending to ASBR2, 256 it modifies the next hop to itself. And allocate two new labels 257 based on . As shown in Figure 1, ASBR1 sends 258 two paths to ASBR2, <1.1.1.1, path-id1> carries color1+label201, and 259 <1.1.1.1, path-id2> carries color2+label202. 261 Similarly, ASBR2 also generates two different labels based on the 262 . As shown in Figure 1, multiple end to end 263 BGP-LU LSPs are established.Different BGP-LU LSPs select the underlay 264 SR-BE/TE tunnels according to their colors. 266 6. SRv6 support 268 Colored BGP-LU can be also used to setup end-to-end color-aware 269 connectivity using Segment Routing over IPv6 (SRv6) [RFC8402]. 271 As defined in [I-D.ietf-bess-srv6-services],to provide SRv6 service 272 with underlay SRv6 policy connectivity, the egress PE signals the BGP 273 overlay service route with SRv6 Service SID and color extended 274 community . The ingress PE encapsulates the payload in an outer IPv6 275 header which contains the underlay SRv6 policy segment list and the 276 overlay Service SID. 278 In addition, another solution is to provide SRv6 servcie with 279 underlay SRv6 best-effort connectivity that is created by global IPv6 280 (AFI/SAFI 2/1) with color extended community. The underlay SRv6 SID 281 is allocated based on . The ingress PE 282 encapsulates the payload in an outer IPv6 header which contains the 283 underlay SRv6 SID and the Service SID. 285 7. Deploy Considerations 287 All BGP routers (PE1--ASBR1, ASBR1---ASBR2, ASBR2---PE2) SHOULD be 288 Colored BGP-LU neighbors in advance. There may be multiple border 289 routers to ensure multipath backup. All routers require the Colored 290 BGP-LU Capability Advertisement.If transit network domains that do 291 not support Colored BGP-LU，Processed as follows： 293 * When the Colored BGP-LU neighbor receives the BGP-LU routes, if it 294 continues to advertise the BGP-LU routes to the upstream neighbor 295 that supports the Colored BGP-LU, the BGP-LU routes shouldn't be 296 changed to the Colored BGP-LU routes. 298 * When receiving the Colored BGP-LU advertisement from the neighbor 299 that supports Colored BGP-LU, if the advertisement continues to be 300 advertised to the upstream neighbor that does not support Colored 301 BGP-LU, the advertisement should be changed to BGP-LU 302 advertisement, that is, advertise one out of multiple path. 304 This document not only supports interprovider VPNs while the customer 305 sites belong to different ASs, but also supports the Carrier-of- 306 Carriers VPNs while the customer site belong to the same AS. 307 Multiple operators are involved, so AS border routers may involve 308 color mapping, color namespaces, or color service chains. These 309 services can be delivered by the controller configurations or the 310 local configurations. 312 8. Acknowledgements 314 TBD. 316 9. IANA Considerations 318 TBD. 320 10. Security Considerations 322 TBD. 324 11. Normative References 326 [I-D.ietf-bess-srv6-services] 327 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 328 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 329 Overlay Services", Work in Progress, Internet-Draft, 330 draft-ietf-bess-srv6-services-12, 5 March 2022, 331 . 334 [I-D.ietf-spring-segment-routing-policy] 335 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 336 P. Mattes, "Segment Routing Policy Architecture", Work in 337 Progress, Internet-Draft, draft-ietf-spring-segment- 338 routing-policy-19, 5 March 2022, 339 . 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, 344 DOI 10.17487/RFC2119, March 1997, 345 . 347 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 348 "Advertisement of Multiple Paths in BGP", RFC 7911, 349 DOI 10.17487/RFC7911, July 2016, 350 . 352 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 353 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 354 . 356 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 357 Decraene, B., Litkowski, S., and R. Shakir, "Segment 358 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 359 July 2018, . 361 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 362 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 363 DOI 10.17487/RFC9012, April 2021, 364 . 366 Authors' Addresses 368 Ran Chen 369 ZTE Corporation 370 Nanjing 371 China 372 Email: chen.ran@zte.com.cn 374 Chunning Dai 375 ZTE Corporation 376 Nanjing 377 China 378 Email: dai.chunning@zte.com.cn 380 Shaofu Peng 381 ZTE Corporation 382 Nanjing 383 China 384 Email: peng.shaofu@zte.com.cn