idnits 2.17.1 draft-zhou-idr-inter-domain-lcu-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) == There are 5 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 191 has weird spacing: '... prefix colo...' -- The document date (Feb 18, 2020) is 1521 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) == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-15 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-06 == Outdated reference: A later version (-04) exists of draft-peng-teas-network-slicing-02 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 Working Group J. Zhou 3 Internet-Draft Chunning. Dai 4 Intended status: Standards Track Shaofu. Peng 5 Expires: August 21, 2020 ZTE Corp. 6 Feb 18, 2020 8 Inter-domain Network Slicing via BGP-LU 9 draft-zhou-idr-inter-domain-lcu-01 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 August 21, 2020. 35 Copyright Notice 37 Copyright (c) 2020 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) . . . . . . . . . . . . . . . . . . . . . 4 57 6. Establishing BGP-LU LSPs . . . . . . . . . . . . . . . . . . 4 58 7. Deploy Considerations . . . . . . . . . . . . . . . . . . . . 6 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 62 9.2. Informative References . . . . . . . . . . . . . . . . . 7 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 As described in [I-D.peng-teas-network-slicing], in the traditional 68 end to end inter-domain network slicing, BGP-LU is used as a 69 distributed slicing scheme. [RFC8277] specifies a set of procedures 70 for using BGP to advertise that a specified router has bound a 71 specified MPLS label to a specified address prefix. It's an 72 effective way for inter-domain labels, but it does not have the 73 ability to select the underlying network resources. 75 This document describes the colored BGP-LU LSP, in which the routing 76 prefix not only carries a label(or a sequence of labels), but also 77 carries an unique color attribute which helps to select the 78 underlying logic slice. 80 [RFC7911] defines a BGP extension that allows the advertisement of 81 multiple paths of the same address prefix. It can help with optimal 82 routing and in a network by providing potential alternate or backup 83 paths. In this document, it is not used for the link backup. It is 84 only used to advertise multiple paths, whether intra-domain or inter- 85 domain. 87 2. Requirements notation 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 3. Color 95 [I-D.ietf-idr-tunnel-encaps] introduces the concept of color, which 96 is used as one of the KEY of SR policy 97 [I-D.ietf-spring-segment-routing-policy]. The color of SR policy 98 defines a TE purpose, which includes a set of constraints such as 99 bandwidth, delay, TE metric, etc. 101 Color is used a policy keyword to help routing decisions and can be 102 carried through Community attribute [I-D.ietf-idr-tunnel-encaps] in 103 BGP. Each UPDATE SHOULD contain a Color Extended Community with a 104 specific color value, the Color Sub-TLV is only an opaque extended 105 community. 107 4. Advertising multiple paths 109 A BGP speaker can advertise multiple paths for a particular address 110 prefix by a Path identifier in the Extended NLRI Encoding as defined 111 in [RFC7911]. 113 +--------------------------------+ 114 | Path Identifier (4 octets) | 115 +--------------------------------+ 116 | Length (1 octet) | 117 +--------------------------------+ 118 | Prefix (variable) | 119 +--------------------------------+ 121 The Path Identifier only identifies a path, not carrying any 122 particular semantics. It MAY be generated by the 123 tuple. It MAY be generated from the information containing Prefix 124 and Color. It MIGHT be generated by the prefix without color. The 125 assignment to the Path Identifier for a path by a BGP speaker is 126 purely a local matter. However, The Path Identifier MUST be assigned 127 in a way that the BGP speaker is able to use the (Prefix, Path 128 Identifier) to uniquely identify a path. 130 Therefore, if a BGP speaker has two colors for the prefix P, which 131 correspond to two different paths, it may advertise two UPDATE NLRIs, 132 with color1 extended community and with color2 extended community. Pathid1 and pathid2 in two 134 UPDATE NLRIs MUST be different. 136 Note that in this document, BGP speakers acting as border routers 137 that interact with external neighbors need to support advertising 138 multiple paths corresponding to the same prefix. Although multiple 139 paths have differnet path ids, they have the same next hop. As for 140 the procedures of mutual backup paths with the same prefix and the 141 differnet next hops, refer to [RFC7911]. 143 5. Assigning Label(s) 145 [RFC8277] describes how to use BGP to bind MPLS label(s) to address 146 prefixes. The specific format of the UPDATE message is detailed in 147 Section 2 of [RFC8277]. 149 [RFC8277] Section 3.2 details the process of modifying the Label 150 field during propagation. When propagating a SAFI-4 or SAFI-128 151 route, if the Network Address of Next Hop field has never changed, 152 the label field must remain unchanged. Otherwise, if the Network 153 Address of Next Hop field is changed, the label field(s) of the 154 propagating route must contain the label(s) that is (are) bound to 155 the prefix at the new next hop. What the label changes to depends on 156 the local policy. However, LSPs with different color paths need to 157 have different label(s). 159 6. Establishing BGP-LU LSPs 161 Consider the following LSR topology in Figure 1: PE1---ASBR1---ASBR2 162 ---PE2. Packet transfers from PE2 to PE1. PE1, as one of the tail 163 routers, has a loopback IP 1.1.1.1. The overlay service of PE1 to 164 PE2 for prefix 1.1.1.1 has two colors, color1 and color2. 166 <1.1.1.1, path-id1> <1.1.1.1, path-id1> <1.1.1.1, path-id1> 167 168 ------------------------------------------------------------------> 169 .----. .------. 170 ( ) ( ) 171 .-( )-. .-( )-. 172 +---+---color1----+----+ +---+----color1----+---+ 173 |PE1|\---SR-TE1---/|AS |-sub-if1 with slice1-|AS |\---SR-TE1---/|PE2| 174 | |/---SR-TE2---\|BR1|-sub-if2 with slice2-|BR2|/---SR-TE2---\| | 175 +---+---color2---- +---+ +---+--color2------+---+ 176 ( ) ( ) 177 '--( AS1 )--' '--( AS2 )--' 178 ( ) ( ) 179 '-' '-' 180 -------------------------------------------------------------------> 181 <1.1.1.1, path-id2> <1.1.1.1, path-id2> <1.1.1.1, path-id2> 182 184 Label Exchange Tables: 185 ASBR1: ASBR2: 186 inLabel outLabel nextHop inLabel outLabel nextHop 187 201 200 SR-TE1 201 201 sub-if1 188 202 200 SR-TE2 202 202 sub-if2 190 PE2: 191 prefix color outLabel nextHop 192 1.1.1.1 1 201 SR-TE1 193 1.1.1.1 2 202 SR-TE2 195 Figure 1: Details of Network Slicing Example 197 As we can see, PE1 advertises two paths <1.1.1.1, path-id1> and 198 <1.1.1.1, path-id2> to ASBR1. PE1 advertises the binding between the 199 prefix 1.1.1.1 and label 200. Because of the end node, both paths 200 have the same label value 200. 202 When ASBR1 receives these two paths from PE1, ASBR1 automatically 203 performs the next hop address to self, and allocate two new labels 204 based on these two paths. As shown in Figure 1, ASBR1 generates a 205 label 201 by replacing the label 200 with <1.1.1.1, color1>, and 206 generates a label 202 by replacing the label 200 with <1.1.1.1, 207 color2>. Both of them are the local label exchange entries. 209 Similarly, ASBR2 also generates two different labels based on the two 210 paths. As shown in Figure 1, multiple end to end BGP-LU LSPs are 211 established. 213 So, at the entry node of per domain, BGP-LU LSP generated for 214 specific color is over intra-domain SR-TE or SR Best-effort path 215 generated for the color again. At exit node of per domain, BGP-LU 216 LSP generated for specific color selects inter-domain forwarding 217 resource per color. 219 7. Deploy Considerations 221 All BGP routers (PE1--ASBR1, ASBR1---ASBR2, ASBR2---PE2) SHOULD be 222 BGP-LU neighbors in advance. There may be multiple border routers to 223 ensure multipath backup. All routers require the ADD-PATH Capability 224 which is described in chapter 4 of [RFC7911]. 226 This document not only supports interprovider VPNs while the customer 227 sites belong to different ASs, but also supports the Carrier-of- 228 Carriers VPNs while the customer site belong to the same AS. 229 Multiple operators are involved, so AS border routers may involve 230 color mapping, color namespaces, or color service chains. These 231 services can be delivered by the controller configurations or the 232 local configurations. 234 8. Security Considerations 236 TBD 238 9. References 240 9.1. Normative References 242 [I-D.ietf-idr-tunnel-encaps] 243 Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel 244 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15 245 (work in progress), December 2019. 247 [I-D.ietf-spring-segment-routing-policy] 248 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 249 P. Mattes, "Segment Routing Policy Architecture", draft- 250 ietf-spring-segment-routing-policy-06 (work in progress), 251 December 2019. 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, 255 DOI 10.17487/RFC2119, March 1997, 256 . 258 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 259 "Advertisement of Multiple Paths in BGP", RFC 7911, 260 DOI 10.17487/RFC7911, July 2016, 261 . 263 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 264 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 265 . 267 9.2. Informative References 269 [I-D.peng-teas-network-slicing] 270 Peng, S., Chen, R., Mirsky, G., and F. Qin, "Packet 271 Network Slicing using Segment Routing", draft-peng-teas- 272 network-slicing-02 (work in progress), December 2019. 274 Authors' Addresses 276 Jin Zhou 277 ZTE Corp. 279 Email: zhou.jin6@zte.com.cn 281 Chunning Dai 282 ZTE Corp. 284 Email: dai.chunning@zte.com.cn 286 Shaofu Peng 287 ZTE Corp. 289 Email: peng.shaofu@zte.com.cn