idnits 2.17.1 draft-zhou-idr-inter-domain-lcu-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: ---------------------------------------------------------------------------- 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 189 has weird spacing: '... prefix colo...' -- The document date (January 10, 2021) is 1200 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: 'I-D.peng-teas-network-slicing' is mentioned on line 266, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group R. Chen 3 Internet-Draft Ch. Dai 4 Intended status: Standards Track Sh. Peng 5 Expires: July 14, 2021 ZTE Corporation 6 January 10, 2021 8 Inter-domain Network Slicing via BGP-LU 9 draft-zhou-idr-inter-domain-lcu-02 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 prefix to stitch multiple network 16 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 July 14, 2021. 35 Copyright Notice 37 Copyright (c) 2021 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 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 54 3. Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 4. Advertising multiple paths . . . . . . . . . . . . . . . . . 3 56 5. Assigning Label(s) . . . . . . . . . . . . . . . . . . . . . 3 57 6. Inter-domain Network Slicing via BGP-LU . . . . . . . . . . . 4 58 7. Deploy Considerations . . . . . . . . . . . . . . . . . . . . 6 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 63 10.2. Information References . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 As described in [I-D.peng-teas-network-slicing], in the traditional 69 end to end inter-domain network slicing, BGP-LU to build inter-domain 70 MPLS LSP, and overlay service will be directly over BGP-LU LSP. 72 [RFC8277] specifies a set of procedures for using BGP to advertise 73 that a specified router has bound a specified MPLS label to a 74 specified address prefix. It's an effective way for inter-domain 75 labels, but it does not have the ability to select the underlying 76 network resources. 78 This document describes the colored BGP-LU LSP, which defines the 79 multiple paths for the same destination prefix can be advertised in 80 BGP UPDATE message, and each UPDATE message can contain the color 81 Extended Community [I-D.ietf-idr-tunnel-encaps] with different color 82 value, which helps to select the underlying resources. 84 2. Requirements notation 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 3. Color 92 [I-D.ietf-idr-tunnel-encaps] introduces the concept of color, which 93 is used as one of the KEY of SR policy 94 [I-D.ietf-spring-segment-routing-policy]. The color of SR policy 95 defines a TE purpose, which includes a set of constraints such as 96 bandwidth, delay, TE metric, etc. 98 Color is used a policy keyword to help routing decisions and can be 99 carried through Community attribute [I-D.ietf-idr-tunnel-encaps] in 100 BGP. Each UPDATE SHOULD contain a Color Extended Community with a 101 specific color value, the Color Sub-TLV is only an opaque extended 102 community. 104 4. Advertising multiple paths 106 A BGP speaker can advertise multiple paths for a particular address 107 prefix by a Path identifier in the Extended NLRI Encoding as defined 108 in [RFC7911]. 110 +--------------------------------+ 111 | Path Identifier (4 octets) | 112 +--------------------------------+ 113 | Length (1 octet) | 114 +--------------------------------+ 115 | Prefix (variable) | 116 +--------------------------------+ 118 The Path Identifier only identifies a path, not carrying any 119 particular semantics.In this document, it can be generated by the 120 tuple. The assignment to the Path Identifier for a 121 path by a BGP speaker is purely a local matter. 123 Therefore, if a BGP speaker has two colors for the prefix P, which 124 correspond to two different paths, it may advertise two UPDATE NLRIs, 125 with color1 extended community and with color2 extended community. Pathid1 and pathid2 in two 127 UPDATE NLRIs MUST be different. 129 Note that in this document, BGP speakers acting as border routers 130 that interact with external neighbors need to support advertising 131 multiple paths corresponding to the same prefix. Although multiple 132 paths have differnet path ids, they have the same next hop. As for 133 the procedures of mutual backup paths with the same prefix and the 134 differnet next hops, refer to [RFC7911]. 136 5. Assigning Label(s) 138 [RFC8277] describes how to use BGP to bind MPLS label(s) to address 139 prefixes. The specific format of the UPDATE message is detailed in 140 Section 2 of [RFC8277]. 142 [RFC8277] Section 3.2 details the process of modifying the Label 143 field during propagation. When propagating a SAFI-4 or SAFI-128 144 route, if the Network Address of Next Hop field has never changed, 145 the label field must remain unchanged. Otherwise, if the Network 146 Address of Next Hop field is changed, the label field(s) of the 147 propagating route must contain the label(s) that is (are) bound to 148 the prefix at the new next hop. What the label changes to depends on 149 the local policy. However, LSPs with different color paths need to 150 have different label(s). 152 6. Inter-domain Network Slicing via BGP-LU 154 [RFC7911] defined that multiple paths for a particular address prefix 155 by a Path identifier can be advertised in BGP UPDATE message, and 156 each UPDATE message can contain the Color Extended Community 157 [I-D.ietf-idr-tunnel-encaps] with different color value. That is a 158 simple existing way to realize BGP-LU color function, and no protocol 159 extension required. 161 Consider the following example of establishing multiple BGP-LU LSPs 162 per different colors in a cross-domain scenario. 164 <1.1.1.1, path-id1> <1.1.1.1, path-id1> <1.1.1.1, path-id1> 165 166 ------------------------------------------------------------------> 167 .----. .------. 168 ( ) ( ) 169 .-( )-. .-( )-. 170 +---+---color1----+----+ +---+----color1----+---+ 171 |PE1|\---SR-TE1---/|AS |-sub-if1 with slice1-|AS |\---SR-TE1---/|PE2| 172 | |/---SR-TE2---\|BR1|-sub-if2 with slice2-|BR2|/---SR-TE2---\| | 173 +---+---color2---- +---+ +---+--color2------+---+ 174 ( ) ( ) 175 '--( AS1 )--' '--( AS2 )--' 176 ( ) ( ) 177 '-' '-' 178 -------------------------------------------------------------------> 179 <1.1.1.1, path-id2> <1.1.1.1, path-id2> <1.1.1.1, path-id2> 180 182 Label Exchange Tables: 183 ASBR1: ASBR2: 184 inLabel outLabel nextHop inLabel outLabel nextHop 185 201 200 SR-TE1 201 201 sub-if1 186 202 200 SR-TE2 202 202 sub-if2 188 PE2: 189 prefix color outLabel nextHop 190 1.1.1.1 1 201 SR-TE1 191 1.1.1.1 2 202 SR-TE2 193 Figure 1: Example of Inter-domain Network Slicing via BGP-LU 195 In figure 1, PE1 advertises two paths: <1.1.1.1, path-id1> carries 196 the color1 attribute and <1.1.1.1, path-id2> carries the color2 197 attribute to ASBR1.PE1 advertises the binding between the prefix 198 1.1.1.1 and label 200. Because of the end node, both paths have the 199 same label value 200. 201 ASBR1 receives these two paths from PE1, and when sending to ASBR2, 202 it modifies the next hop to itself. And allocate two new labels 203 based on . As shown in Figure 1, ASBR1 sends 204 two paths to ASBR2, <1.1.1.1, path-id1> carries color1+label201, and 205 <1.1.1.1, path-id2> carries color2+label202. 207 Similarly, ASBR2 also generates two different labels based on the 208 . As shown in Figure 1, multiple end to end 209 BGP-LU LSPs are established.Different BGP-LU LSPs select the lower 210 SR-BE/TE tunnels according to their colors. 212 7. Deploy Considerations 214 All BGP routers (PE1--ASBR1, ASBR1---ASBR2, ASBR2---PE2) SHOULD be 215 BGP-LU neighbors in advance. There may be multiple border routers to 216 ensure multipath backup. All routers require the ADD-PATH Capability 217 which is described in chapter 4 of [RFC7911]. 219 This document not only supports interprovider VPNs while the customer 220 sites belong to different ASs, but also supports the Carrier-of- 221 Carriers VPNs while the customer site belong to the same AS. 222 Multiple operators are involved, so AS border routers may involve 223 color mapping, color namespaces, or color service chains. These 224 services can be delivered by the controller configurations or the 225 local configurations. 227 8. Security Considerations 229 TBD 231 9. IANA Considerations 233 TBD. 235 10. References 237 10.1. Normative References 239 [I-D.ietf-idr-tunnel-encaps] 240 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 241 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 242 encaps-22 (work in progress), January 2021. 244 [I-D.ietf-spring-segment-routing-policy] 245 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 246 P. Mattes, "Segment Routing Policy Architecture", draft- 247 ietf-spring-segment-routing-policy-09 (work in progress), 248 November 2020. 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, 252 DOI 10.17487/RFC2119, March 1997, 253 . 255 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 256 "Advertisement of Multiple Paths in BGP", RFC 7911, 257 DOI 10.17487/RFC7911, July 2016, 258 . 260 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 261 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 262 . 264 10.2. Information References 266 [I-D.peng-teas-network-slicing] 267 Peng, S., Chen, R., Mirsky, G., and F. Qin, "Packet 268 Network Slicing using Segment Routing", draft-peng-teas- 269 network-slicing-04 (work in progress), October 2020. 271 Authors' Addresses 273 Ran Chen 274 ZTE Corporation 276 Email: chen.ran@zte.com.cn 278 Chunning Dai 279 ZTE Corporation 281 Email: dai.chunning@zte.com.cn 283 Shaofu Peng 284 ZTE Corporation 286 Email: peng.shaofu@zte.com.cn