idnits 2.17.1 draft-zhou-idr-inter-domain-lcu-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: ---------------------------------------------------------------------------- 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 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 181 has weird spacing: '... prefix colo...' -- The document date (Dec 31, 2019) is 1549 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: July 3, 2020 ZTE Corp. 6 Dec 31, 2019 8 Inter-domain Network Slicing via BGP-LU 9 draft-zhou-idr-inter-domain-lcu-00 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 3, 2020. 35 Copyright Notice 37 Copyright (c) 2019 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. Generating Labels by Path . . . . . . . . . . . . . . . . . . 4 57 6. Deploy Considerations . . . . . . . . . . . . . . . . . . . . 5 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 61 8.2. Informative References . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 As described in [I-D.peng-teas-network-slicing], in the traditional 67 end to end inter-domain network slicing, BGP-LU is used as a 68 distributed slicing scheme. [RFC8277] specifies a set of procedures 69 for using BGP to advertise that a specified router has bound a 70 specified MPLS label to a specified address prefix. It's an 71 effective way for inter-domain labels, but it does not have the 72 ability to select the underlying network resources. 74 This document describes the colored BGP-LU LSP, in which the routing 75 prefix not only carries a label(or a sequence of labels), but also 76 carries an unique color attribute which helps to select the 77 underlying logic slice. 79 [RFC7911] defines a BGP extension that allows the advertisement of 80 multiple paths of the same address prefix. It can help with optimal 81 routing and in a network by providing potential alternate or backup 82 paths. In this document, it is not used for the link backup. It is 83 only used to advertise multiple paths, whether intra-domain or inter- 84 domain. 86 2. Requirements notation 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 3. Color 94 [I-D.ietf-idr-tunnel-encaps] introduces the concept of color, which 95 is used as one of the KEY of SR policy 96 [I-D.ietf-spring-segment-routing-policy]. The color of SR policy 97 defines a TE purpose, which includes a set of constraints such as 98 bandwidth, delay, TE metric, etc. 100 Color is used a policy keyword to help routing decisions and can be 101 carried through Community attribute [I-D.ietf-idr-tunnel-encaps] in 102 BGP. Each UPDATE SHOULD contain a Color Extended Community with a 103 specific color value, the Color Sub-TLV is only an opaque extended 104 community. 106 4. Advertising multiple paths 108 Consider the following LSR topology in Figure 1: PE1---ASBR1---ASBR2 109 ---PE2. Packet transfers from PE2 to PE1. The overlay service of 110 PE1 to PE2 has two colors, color1 and color2. 112 .----. .------. 113 ( ) ( ) 114 .-( )-. .-( )-. 115 +---+---color1----+----+ +---+----color1----+---+ 116 |PE1|\---SR-TE1---/|AS |-sub-if1 with slice1-|AS |\---SR-TE1---/|PE2| 117 | |/---SR-TE2---\|BR1|-sub-if2 with slice2-|BR2|/---SR-TE2---\| | 118 +---+---color2---- +---+ +---+--color2------+---+ 119 ( ) ( ) 120 '--( AS1 )--' '--( AS2 )--' 121 ( ) ( ) 122 '-' '-' 124 Figure 1: Network Slicing Example 126 According to the extended NLRI Encodings in [RFC7911], in order to 127 advertise multiple paths for the same address prefix, PE1 MUST encode 128 two different NLRIs to advertise the two paths. Every NLRI has a 129 unique Path Identifier. 131 +--------------------------------+ 132 | Path Identifier (4 octets) | 133 +--------------------------------+ 134 | Length (1 octet) | 135 +--------------------------------+ 136 | Prefix (variable) | 137 +--------------------------------+ 139 The Path Identifier only identifies a path, not carrying any 140 particular semantics. It MAY be generated from the two-tuple 141 . Also, it MAY be generated from the information 142 containing Prefix and Color. 144 Finally, There are two BGP UPDATE NLRIs from PE1 to ASBR1, with color1 extended community and with 146 color2 extended community. Pathid1 and pathid2 in two UPDATE NLRI 147 MUST be different. As described in [RFC8277], they have the same 148 label value, however, different label value is also possible. 150 5. Generating Labels by Path 152 To realize the inter-domain multiple paths, the border routers of per 153 domain SHOULD consider the diversity of paths when generating the 154 labels. 156 <1.1.1.1, path-id1> <1.1.1.1, path-id1> <1.1.1.1, path-id1> 157 158 ------------------------------------------------------------------> 159 .----. .------. 160 ( ) ( ) 161 .-( )-. .-( )-. 162 +---+---color1----+----+ +---+----color1----+---+ 163 |PE1|\---SR-TE1---/|AS |-sub-if1 with slice1-|AS |\---SR-TE1---/|PE2| 164 | |/---SR-TE2---\|BR1|-sub-if2 with slice2-|BR2|/---SR-TE2---\| | 165 +---+---color2---- +---+ +---+--color2------+---+ 166 ( ) ( ) 167 '--( AS1 )--' '--( AS2 )--' 168 ( ) ( ) 169 '-' '-' 170 -------------------------------------------------------------------> 171 <1.1.1.1, path-id2> <1.1.1.1, path-id2> <1.1.1.1, path-id2> 172 174 Label Exchange Tables: 175 ASBR1: ASBR2: 176 inLabel outLabel nextHop inLabel outLabel nextHop 177 201 200 SR-TE1 201 201 sub-if1 178 202 200 SR-TE2 202 202 sub-if2 180 PE2: 181 prefix color outLabel nextHop 182 1.1.1.1 1 201 SR-TE1 183 1.1.1.1 2 202 SR-TE2 185 Figure 2: Details of Network Slicing Example 187 Suppose ASBR1 receives two paths from PE1, with next hop 1.1.1.1, 188 path identifier 1 and 2, ASBR1 MUST modify the next hop to itself, 189 and generate two new labels based on two paths. As depicted in 190 Figure 2, <1.1.1.1, color1> generates label 201, <1.1.1.1, color2> 191 generates label 202. Both of them are the local label exchange table 192 items. Similarly, ASBR2 also generates two different labels based on 193 the two paths. As shown in Figure 2, multiple end to end BGP-LU LSP 194 are established. 196 So, at the entry node of per domain, BGP-LU LSP generated for 197 specific color is over intra-domain SR-TE or SR Best-effort path 198 generated for the color again. At exit node of per domain, BGP-LU 199 LSP generated for specific color selects inter-domain forwarding 200 resource per color. 202 6. Deploy Considerations 204 o The premise of this document is that all border routers SHOULD 205 have the same understanding of a color value. For example, PE1 206 understands color1 representing a low packet loss rate, and ASBR1 207 must think so and apply it to the local forwarding policy. 209 o All BGP routers(PE1--ASBR1, ASBR1---ASBR2, ASBR2---PE2) SHOULD be 210 BGP-LU neighbors in advance. 212 o All routers require the ADD-PATH Capability which is described in 213 chapter 4 of [RFC7911]. 215 o If any Router Reflector existed in the network, it SHOULD support 216 this function. Later will discuss Confederation. 218 7. Security Considerations 220 TBD 222 8. References 224 8.1. Normative References 226 [I-D.ietf-idr-tunnel-encaps] 227 Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel 228 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15 229 (work in progress), December 2019. 231 [I-D.ietf-spring-segment-routing-policy] 232 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 233 P. Mattes, "Segment Routing Policy Architecture", draft- 234 ietf-spring-segment-routing-policy-06 (work in progress), 235 December 2019. 237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 238 Requirement Levels", BCP 14, RFC 2119, 239 DOI 10.17487/RFC2119, March 1997, 240 . 242 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 243 "Advertisement of Multiple Paths in BGP", RFC 7911, 244 DOI 10.17487/RFC7911, July 2016, 245 . 247 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 248 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 249 . 251 8.2. Informative References 253 [I-D.peng-teas-network-slicing] 254 Peng, S., Chen, R., Mirsky, G., and F. Qin, "Packet 255 Network Slicing using Segment Routing", draft-peng-teas- 256 network-slicing-02 (work in progress), December 2019. 258 Authors' Addresses 260 Jin Zhou 261 ZTE Corp. 263 Email: zhou.jin6@zte.com.cn 265 Chunning Dai 266 ZTE Corp. 268 Email: dai.chunning@zte.com.cn 270 Shaofu Peng 271 ZTE Corp. 273 Email: peng.shaofu@zte.com.cn