idnits 2.17.1 draft-peng-teas-network-slicing-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: For P2P traffic engineering service, especially such as uRLLC service, it SHOULD not transfer over an MP2P LSP to avoid the risk of traffic congestion. The segment list could consist of pure adjacency-SID per AII specific. The head-end of the segment list maintains the corresponding SR-TE tunnel or [I-D.ietf-spring-segment-routing-policy]. -- The document date (August 20, 2019) is 1705 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: 'Flex-algo' is mentioned on line 185, but not defined == Unused Reference: 'RFC2119' is defined on line 603, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-inter-as-topology-ext-03 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-13 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-03 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-02 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-enhanced-vpn (ref. 'I-D.ietf-teas-enhanced-vpn') ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Shaofu. Peng 3 Internet-Draft Ran. Chen 4 Intended status: Standards Track Gregory. Mirsky 5 Expires: February 21, 2020 ZTE Corporation 6 August 20, 2019 8 Packet Network Slicing using Segment Routing 9 draft-peng-teas-network-slicing-00 11 Abstract 13 This document presents a mechanism aimed at providing a solution for 14 network slicing in the transport network for 5G services. The 15 proposed mechanism uses a unified administrative instance identifier 16 to distinguish different virtual network resources for both intra- 17 domain and inter-domain network slicing scenarios. Combined with the 18 segment routing technology, the mechanism could be used for both 19 best-effort and traffic engineered services for tenants. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 21, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions used in this document . . . . . . . . . . . . . . 4 57 3. Overview of Mechanism . . . . . . . . . . . . . . . . . . . . 4 58 4. Resource Allocation per AII . . . . . . . . . . . . . . . . . 5 59 4.1. L3 Link Resource AII Configuration . . . . . . . . . . . 5 60 4.2. L2 Link Resource AII Configuration . . . . . . . . . . . 6 61 4.3. Node Resource AII Configuration . . . . . . . . . . . . . 6 62 5. Interworking with SR Flex-algorithm . . . . . . . . . . . . . 7 63 5.1. Best-effort Service AII-specific . . . . . . . . . . . . 7 64 5.2. Traffic Engineering service AII-specific . . . . . . . . 7 65 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.1. intra-domain network slicing . . . . . . . . . . . . . . 8 67 6.2. inter-domain network slicing via BGP-LS . . . . . . . . . 9 68 6.3. inter-domain network slicing via BGP-LU . . . . . . . . . 11 69 7. Implementation suggestions . . . . . . . . . . . . . . . . . 12 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 73 11. Normative references . . . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 76 1. Introduction 78 According to 5G context, network slicing is the collection of a set 79 of technologies to create specialized, dedicated logical networks as 80 a service (NaaS) in support of network service differentiation and 81 meeting the diversified requirements from vertical industries. 82 Through the flexible and customized design of functions, isolation 83 mechanisms, and operation and management (O&M) tools, network slicing 84 is capable of providing dedicated virtual networks over a shared 85 infrastructure. A Network slice instance (NSI) is the realization of 86 network slicing concept. It is an E2E logical network, which 87 comprises of a group of network functions, resources, and connection 88 relationships. An NSI typically covers multiple technical domains, 89 which includes a terminal, access network (AN), transport network 90 (TN) and a core network (CN), as well as DC domain that hosts third- 91 party applications from vertical industries. Different NSIs may have 92 different network functions and resources. They may also share some 93 of the network functions and resources. 95 For a packet network, network slicing requires the underlying network 96 to support partitioning of the network resources to provide the 97 client with dedicated (private) networking, computing, and storage 98 resources drawn from a shared pool. The slices may be seen as 99 virtual networks. [I-D.ietf-teas-enhanced-vpn] described a framework 100 to create virtual networks in a packet network. This document 101 specifies a detailed mechanism to signal association of shared 102 resources required to create and manage an NSI. 104 Currently there are multiple methods that could be used to identify 105 the virtual network resource, such as Administrative Group (AG) 106 described in [RFC3630], [RFC5329] and [RFC5305], Extended 107 Administrative Groups (EAGs) described in [RFC7308], and Multi- 108 Topology Routing (MTR) described in [RFC5120], [RFC4915] and 109 [RFC5340]. However, all these methods are not sufficient to meet the 110 requirements of network slicing service. For example, AG or EAG are 111 limited to serve as a link color scheme used in TE path computation 112 to meet the requirements of TE service for a tenant. But it is 113 difficult to use them for an NSI allocation mapping (assuming that 114 each bit position of AG/EAG represents an NSI) and, at the same time, 115 as an IGP FIB identifier for best-effort service for the same tenant. 116 MTR is limited to serve as an IGP logical topology scheme only used 117 in the intra-domain scenario, and it is challenging to select inter- 118 area link resource according to MT-ID when E2E inter-domain TE path 119 needs to be created for a tenant. 121 In summary, the following requirements would be satisfied: 123 1) Uniform NSI for easy operation and maintenance; 125 2) E2E network slicing, including both intra-domain and inter-domain 126 case; 128 3) Customization resource for QoS purpose, bandwidth and delay are 129 basic constraints; 131 4) Layer 2 as well as Layer 3 link resource partition; 133 Thus, there needs to be a new characteristic of NSI to isolate 134 underlay resources. Firstly it could serve as TE criteria for TE 135 service, and secondly, as an IGP FIB table identifier for best-effort 136 service. This document introduces a new property of NSI called 137 "Administrative Instance Identifier" (AII) and corresponding method 138 how to instantiate it in underlay network to match above 139 requirements. 141 2. Conventions used in this document 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC2119. 147 3. Overview of Mechanism 149 At the initial stage, each link in a physical network can be colored 150 to conform with network slicing requirements. As previously 151 mentioned, AII can be used to color links to partition underlay 152 resource. Also, we may continue to use AG or EAG to color links for 153 traditional TE purpose within a virtual network specified by an AII. 154 A single or multiple AIIs could be configured on each intra-domain or 155 inter-domain link regardless of IGP instance configuration. At the 156 minimum, a link always belongs to default AII (the value is 0). The 157 number of AIIs configured on a node's links determines the number of 158 virtual networks the node is part of. This document defines a new 159 extension of the existing IGP-TE mechanisms [RFC3630] and [RFC5305] 160 to distribute AII information in an AS as a new TE parameter of a 161 link. An SDN controller, using BGP-LS or another interface, will 162 have a distinct view of each virtual network specified by AII. 164 Using the CSPF algorithm, a TE path for any best-effort (BE) or 165 traffic engineered (TE) service can be calculated within a virtual 166 network specified by the AII. The computation criteria could be 167 or for the BE 168 and TE respectively. Combined with segment routing, the TE path 169 could be represented as: 171 o a single node-SID of the destination node, for the best-effort 172 service in the domain; 174 o node-SIDs of the border node and the destination node, adjacency- 175 SID of inter-domain link, for the inter-domain best-effort 176 service; 178 o an adjacency-SID list, for P2P traffic engineered service. 180 Because packets of the best-effort service could be transported over 181 an MP2P LSP without congestion control, SR best-effort FIB for each 182 virtual network specified by AII to forward best-effort packets may 183 be created in the IGP domain. Thus, CSPF computation with criteria 184 is distributed on each node in the IGP domain. 185 That is similar to the behavior in [Flex-algo], but the distributed 186 CSPF computation is triggered by AII. 188 To distinguish forwarding behavior of different virtual networks, 189 prefix-SID need to be allocated per AII and advertised in the IGP 190 domain. 192 For inter-domain case, in addition to the destination node-SID, 193 several node-SIDs of the domain border node and adjacency-SID of 194 inter-domain link are also needed to construct the E2E segment list. 195 The segment list could be computed with the help of the SDN 196 controller which needs to consider AII information during the 197 computation. The head-end of the segment list maintains the 198 corresponding SR-TE tunnel or 199 [I-D.ietf-spring-segment-routing-policy]. 201 As for the prefix-SID, adjacency-SID needs to be allocated per AII to 202 distinguish the forwarding behavior of different virtual networks. 204 For P2P traffic engineering service, especially such as uRLLC 205 service, it SHOULD not transfer over an MP2P LSP to avoid the risk of 206 traffic congestion. The segment list could consist of pure 207 adjacency-SID per AII specific. The head-end of the segment list 208 maintains the corresponding SR-TE tunnel or 209 [I-D.ietf-spring-segment-routing-policy]. 211 However, label stack depth of the segment list MAY be optimized at a 212 later time based on local policies. 214 At this moment we can steer traffic of overlay service to the above 215 SR best-effort FIB, SR-TE tunnel or SR policy instance, for the 216 specific virtual network. The overlay service could specify a color 217 for TE purpose, for example, color 1000 means to say that I need best-effort forwarding within AII 10 219 resource, color 1001 means to say that I 220 need traffic engineering forwarding within AII 10 resource, 221 especially using link with AG equal to 0x1 to reach guarantee of not 222 exceeding 10ms delay time. Service with color 1000 will be steered 223 to an SR best-effort FIB entry, or an SR-TE tunnel/policy in case of 224 inter-domain. Service with color 1001 will be steered to an SR-TE 225 tunnel/policy. 227 4. Resource Allocation per AII 229 4.1. L3 Link Resource AII Configuration 231 In IGP domain, each numbered or unnumbered L3 link could be 232 configured with AII information and synchronized among IGP neighbors. 233 The IGP link-state database will contain L3 links with AII 234 information to support TE path computation considering AII criteria. 235 For a numbered L3 link, it could be represented as a tuple , for 237 unnumbered it could be . Each L3 link could be configured 239 to belong to a single AII or multiple AIIs, for each 240 tuple it would allocate a different adjacency-SID. Note that an L3 241 link always belongs to default AII(0). 243 AII is independent of IGP instance. An L3 link that is not part of 244 the IGP domain, such as the special purpose for a static route, or an 245 inter-domain link, can also be configured with AII information and 246 allocate adjacency-SID per AII as the same as IGP links. BGP-LS 247 could be used to collect link state data with AII information to the 248 controller. 250 4.2. L2 Link Resource AII Configuration 252 [I-D.ietf-isis-l2bundles] described how to encode adjacency-SID for 253 each L2 member link of an L3 parent link. It is beneficial to deploy 254 LAG or another virtual aggregation interface in network slicing 255 scenario. Between two nodes, the dedicated link resources belong to 256 different virtual networks could be added or removed on demand, they 257 are treated as L2 member links of a single L3 virtual interface. It 258 is the single L3 virtual interface that needs to occupy IP resource 259 and join to an IGP instance. Creating a new slice-specific link on 260 demand or removing the old one, is likely to affect some 261 configurations. 263 Each L2 member link of an L3 parent link SUGGESTED to be configured 264 to belong to a single AII, and different L2 member link will have 265 different single AII configuration, with different adjacency-SID. 266 Note that in this case, the L3 parent link belongs to default AII(0), 267 but each L2 member link belongs to the specific non-default AII. 268 Routing protocol control packets follow the L3 parent link of the L2 269 member link with the highest priority. At the same time, data 270 packets that belong to the specific virtual network will pass along 271 the L2 member link with the specific AII value. 273 TE path computation based on link-state database need view the 274 detailed L2 members of an L3 adjacency to select the expected L2 link 275 resource. 277 4.3. Node Resource AII Configuration 279 For topology resource, each node needs to allocate node-SID per AII 280 when it joins the related virtual network. All nodes in the IGP 281 domain can run CSPF algorithm with criteria to 282 compute best-effort next-hop to any other destination nodes for a 283 virtual network AII-specific, based on the link-state database that 284 containing AII information so that SR best-effort FIB can be 285 constructed for each AII. 287 An intra-domain overlay best-effort service belongs to a virtual 288 network could directly match in the above SR best-effort FIB for the 289 specific AII, while an inter-domain overlay best-effort service 290 belongs to a virtual network could be over a segment list containing 291 domain border node-SID and destination node-SID which could match in 292 the above SR best-effort FIB for the specific AII. 294 5. Interworking with SR Flex-algorithm 296 [I-D.ietf-lsr-flex-algo] introduced a mechanism to do label stack 297 depth optimization for an SR policy in IGP domain part. As the color 298 of SR policy defined a TE purpose, traditionally the headend or SDN 299 controller will compute an expected TE path to meet that purpose. It 300 is necessary to map a color (32 bits) to an FA-ID (8 bits) when SR 301 flex-algorithm enabled for an SR policy, besides that, it is 302 necessary to enable the FA-ID on each node that will join the same FA 303 plane manually. However, the FAD could copy the TE constraints 304 contained in the color template. We need to consider the cost of 305 losing the flexibility of color when executing the flex-algo 306 optimization, and also consider the gap between P2P TE requirements 307 and MP2P SR FA LSP capability, to reach the right balance when 308 deciding which SR policy need optimization. 310 5.1. Best-effort Service AII-specific 312 As described above, for best-effort service we have already 313 constructed SR best-effort FIB per AII, that is mostly like [Flex- 314 algo]. Thus, it is not necessary to map to FA-ID again for a color 315 template which has defined a best-effort behavior within the 316 dedicated AII. Of course, if someone forced to remap it, there is no 317 downside for the operation, the overlay best-effort service (with a 318 color which defined specific AII, best-effort requirement, and 319 mapping FA-ID) in IGP domain will try to recurse over 320 or FIB entry. 322 5.2. Traffic Engineering service AII-specific 324 An SR-TE tunnel/policy that served for traffic engineering service of 325 a virtual network specified by an AII was generated and computed 326 according to the relevant color template, which contained specific 327 AII and some other traditional TE constraints. If we config mapping 328 FA-ID under the color template, the SR-TE tunnel/policy instance 329 could inherit forwarding information from corresponding SR Flex-Algo 330 FIB entry. 332 6. Examples 334 In this section, we will further illustrate the point through some 335 examples. All examples share the same figure below. 337 .-----. .-----. 338 ( ) ( ) 339 .--( )--. .--( )--. 340 +---+----link A1----+---+ +---+----link A1----+---+ 341 |PE1|----link A2----|PE2|---link A1---|PE3|----link A2----|PE2| 342 | |----link B1----| |---link B1---| |----link B1----| | 343 +---+----link B2----+---+ +---+----link B2----+---+ 344 ( ) ( ) 345 '--( AS1 )--' '--( AS2 )--' 346 ( ) ( ) 347 '-----' '-----' 349 Figure 1 Network Slicing via AII 351 Suppose that each link belongs to separate virtual network, e.g., 352 link Ax belongs to the virtual network colored by AII A, link Bx 353 belongs to the virtual network colored by AII B. link x1 has an IGP 354 metric smaller than link x2, but TE metric lager. 356 To simplify the use case, each AS just contained a single IGP area. 358 6.1. intra-domain network slicing 360 From the perspective of node PE1 in AS1, it will calculate best- 361 effort forwarding entry for each AII instance (including default AII) 362 to destinations in the same IGP area. For example: 364 For entry, forwarding information could be 365 ECMP during link A1 and link B1, with destination node-SID 100 for 366 . 368 For entry, forwarding information could be 369 link A1, with destination node-SID 200 for . 372 For entry, forwarding information could be 373 link B1, with destination node-SID 300 for . 376 It could also initiate an SR-TE instance (SR tunnel or SR policy) 377 with the particular color template on PE1, PE1 is headend and ASBR1 378 is destination node. For example: 380 For SR-TE instance 1 with color template which defined criteria 381 including {default AII, min TE metric}, forwarding information could 382 be ECMP during two segment list {adjacency-SID 1002 for @PE1} and {adjacency-SID 1004 for @PE1}. 385 For SR-TE instance 2 with the color template which defined criteria 386 including {AII=A, min TE metric}, forwarding information could be 387 presented as the segment list {adjacency-SID 2002 for @PE1}. 390 For SR-TE instance 3 with the color template which defined criteria 391 including {AII=B, min TE metric}, forwarding information could be 392 presented as the segment list {adjacency-SID 3004 for @PE1}. 395 Furthermore, we can use SR Flex-algo to optimize the above SR-TE 396 instance. For example, for SR-TE instance 1, we can define FA-ID 201 397 with FAD that contains the same information as the color template, in 398 turn, FA-ID 202 for SR-TE instance 2, FA-ID 203 for SR-TE instance 3. 399 Note that each FA-ID also needs to be enabled on ASBR1. So that the 400 corresponding SR FA entry could be: 402 For entry, forwarding information 403 could be ECMP during link A2 and link B2, with destination node-SID 404 600 for . 406 For entry, forwarding information 407 could be link A2, with destination node-SID 700 for . 410 For entry, forwarding information 411 could be link B2, with destination node-SID 800 for . 414 6.2. inter-domain network slicing via BGP-LS 416 [RFC7752] BGP-LS describes the methodology that using BGP protocol to 417 transfer the Link-State information that maybe originated from IGP 418 instance (for intra-domain topology information) or from local direct 419 interface or static configuration(for inter-domain topology 420 information). [I-D.ietf-idr-bgpls-inter-as-topology-ext] also 421 describes a method to firstly put inter-domain interconnections to 422 IGP instance, then always import data from IGP protocol source to 423 BGP-LS. In any case BGP-LS need extend to transfer the Link-State 424 data with AII information. 426 An E2E inner-AS SR-TE instance with particular color template could 427 be initiated on PE1, PE1 is head-end and PE2 is destination node. 428 BGP-LS could be used to inform the SDN controller about the underlay 429 network topology information including AII attribute. Thus the 430 controller could calculate E2E TE path within the particular virtual 431 network. 433 o For best-effort service, for example: 435 For SR-TE instance 4 with color template which defined criteria 436 including {default AII, min IGP metric}, forwarding information could 437 be segment list {node-SID 100 for , 438 adjacency-SID 1001 for @ASBR1, node-SID 400 for < 439 AII=0, destination=PE2>}. 441 For SR-TE instance 5 with color template which defined criteria 442 including {AII=A, min IGP metric}, forwarding information could be 443 segment list {node-SID 200 for , adjacency- 444 SID 1001 for @ASBR1, node-SID 500 for }. 447 For SR-TE instance 6 with color template which defined criteria 448 including {AII=B, min IGP metric}, forwarding information could be 449 segment list {node-SID 300 for , adjacency- 450 SID 1003 for @ASBR1, node-SID 600 for }. 453 o For TE service, for example: 455 For SR-TE instance 7 with color template which defined criteria 456 including {default AII, min TE metric}, forwarding information could 457 be ECMP during two segment list {adjacency-SID 1002 for @PE1, adjacency-SID 1001 for @ASBR1, adjacency-SID 459 1002 for @ASBR2} and {adjacency-SID 1004 for @PE1, adjacency-SID 1003 for @ASBR1, 461 adjacency-SID 1004 for @ASBR2}. 463 For SR-TE instance 8 with color template which defined criteria 464 including {AII=A, min TE metric}, forwarding information could be 465 segment list {adjacency-SID 2002 for @PE1, adjacency- 466 SID 2001 for @ASBR1, adjacency-SID 2002 for @ASBR2}. 469 For SR-TE instance 9 with color template which defined criteria 470 including {AII=B, min TE metric}, forwarding information could be 471 segment list {adjacency-SID 3004 for @PE1, adjacency- 472 SID 3003 for @ASBR1, adjacency-SID 3004 for @ASBR2}. 475 For TE service, if we use SR Flex-algo to do optimizaztion, the above 476 forwarding information of each TE instance could inherit the 477 corresponding SR FA entry, it would look like this: 479 For SR-TE instance 7, forwarding information could be ECMP during two 480 segment list {node-SID 600 for , 481 adjacency-SID 1001 for @ASBR1, node-SID 600 for < FA- 482 ID=201, destination=PE2>} and {adjacency-SID 1004 for @PE1, adjacency-SID 1003 for @ASBR1, adjacency-SID 484 1004 for @ASBR2}. 486 For SR-TE instance 8 with color template which defined criteria 487 including {AII=A, min TE metric}, forwarding information could be 488 segment list {node-SID 700 for , 489 adjacency-SID 2001 for @ASBR1, node-SID 700 for }. 492 For SR-TE instance 9 with color template which defined criteria 493 including {AII=B, min TE metric}, forwarding information could be 494 segment list {node-SID 800 for , 495 adjacency-SID 3003 for @ASBR1, node-SID 800 for }. 498 6.3. inter-domain network slicing via BGP-LU 500 In some deployments, operators adopt BGP-LU to build inter-domain 501 MPLS LSP, overlay service will be directly over BGP-LU LSP. If 502 overlay service has TE requirements that defined by a color, that 503 means that BGP-LU LSP needs to have a sense of color too, i.e., BGP- 504 LU label could be allocated per color. At entry node of each domain, 505 BGP-LU LSP generated for specific color will be over intra-domain SR- 506 TE or SR Best-effort path generated for that color again. At exit 507 node of each domain, BGP-LU LSP generated for specific color will 508 select inter-domain forwarding resource per color. 510 [RFC7911] defined that multiple paths UPDATE message for the same 511 destination prefix can be advertised in BGP, each UPDATE can contain 512 the Color Extended Community ([I-D.ietf-idr-tunnel-encaps]) with 513 different color value. 515 In figure 1, PE2 can allocate and advertise six labels for its 516 loopback plus color 1, 2, 3, 4, 5, 6 respectively. Suppose color 1 517 defines {default AII, min IGP metric}, color 2 defines {AII=A, min 518 IGP metric}, color 3 defines {AII=B, min IGP metric}, and color 4 519 defines {default AII, min TE metric}, color 5 defines {AII=A, min TE 520 metric}, color 6 defines {AII=B, min TE metric}. PE2 will advertise 521 these labels to ASBR2 and ASBR2 then continues to allocate six labels 522 each for prefix PE2 plus different color. Other nodes will have the 523 same operation. Ultimately PE1 will maintain six BGP-LU LSP. 525 For example, the BGP-LU LSP for color 1 will be over SR best-effort 526 FIB entry node-SID 100 for to pass through 527 AS1, over adjacency-SID 1001 for @ASBR1 to pass 528 inter-AS, over SR best-effort FIB entry node-SID 400 for to pass through AS2. 531 For example, The BGP-LU LSP for color 4 will over SR-TE instance 1 532 (see section 6.1), or SR best-effort FIB entry node-SID 600 for (see section 6.1) to pass through AS1, 534 over adjacency-SID 1001 for @ASBR1 to pass inter-AS, 535 over SR-TE instance 1' or corresponding SR FA entry to pass through 536 AS2. Note that ASBR1 need also understand the meaning of a specific 537 color and select forwarding resource between two AS. 539 7. Implementation suggestions 541 As a node often contains control plane and forwarding plane, a 542 suggestion is that only default AII specific FTN entry need be 543 installed on forwarding plane, so that there are not any modification 544 and upgrade requirement for hardware and existing MPLS forwarding 545 mechanism. FTN entry for non-default AII instance will only be 546 maintained on the control plane and be used for overlay service 547 iteration according to next-hop plus color (color will give AII 548 information and mapping FA-ID information). Note that ILM entry for 549 all AII need be installed on forwarding plane. 551 The same suggestion is also appropriate for SR Flex-algo. 553 SR NHLFE need contain AII information for expected packet scheduling. 555 8. IANA Considerations 557 TBD. 559 9. Security Considerations 561 TBD. 563 10. Acknowledgements 565 TBD. 567 11. Normative references 569 [I-D.ietf-idr-bgpls-inter-as-topology-ext] 570 Wang, A., Chen, H., Talaulikar, K., and S. Ma, "BGP-LS 571 Extension for Inter-AS Topology Retrieval", draft-ietf- 572 idr-bgpls-inter-as-topology-ext-03 (work in progress), 573 July 2019. 575 [I-D.ietf-idr-tunnel-encaps] 576 Patel, K., Velde, G., Ramachandra, S., and E. Rosen, "The 577 BGP Tunnel Encapsulation Attribute", draft-ietf-idr- 578 tunnel-encaps-13 (work in progress), July 2019. 580 [I-D.ietf-isis-l2bundles] 581 Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and 582 E. Aries, "Advertising L2 Bundle Member Link Attributes in 583 IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), 584 May 2017. 586 [I-D.ietf-lsr-flex-algo] 587 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 588 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 589 algo-03 (work in progress), July 2019. 591 [I-D.ietf-spring-segment-routing-policy] 592 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 593 bogdanov@google.com, b., and P. Mattes, "Segment Routing 594 Policy Architecture", draft-ietf-spring-segment-routing- 595 policy-03 (work in progress), May 2019. 597 [I-D.ietf-teas-enhanced-vpn] 598 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 599 Framework for Enhanced Virtual Private Networks (VPN+) 600 Service", draft-ietf-teas-enhanced-vpn-02 (work in 601 progress), July 2019. 603 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 604 Requirement Levels", BCP 14, RFC 2119, 605 DOI 10.17487/RFC2119, March 1997, 606 . 608 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 609 (TE) Extensions to OSPF Version 2", RFC 3630, 610 DOI 10.17487/RFC3630, September 2003, 611 . 613 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 614 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 615 RFC 4915, DOI 10.17487/RFC4915, June 2007, 616 . 618 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 619 Topology (MT) Routing in Intermediate System to 620 Intermediate Systems (IS-ISs)", RFC 5120, 621 DOI 10.17487/RFC5120, February 2008, 622 . 624 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 625 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 626 2008, . 628 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 629 "Traffic Engineering Extensions to OSPF Version 3", 630 RFC 5329, DOI 10.17487/RFC5329, September 2008, 631 . 633 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 634 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 635 . 637 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 638 Traffic Engineering (MPLS-TE)", RFC 7308, 639 DOI 10.17487/RFC7308, July 2014, 640 . 642 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 643 S. Ray, "North-Bound Distribution of Link-State and 644 Traffic Engineering (TE) Information Using BGP", RFC 7752, 645 DOI 10.17487/RFC7752, March 2016, 646 . 648 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 649 "Advertisement of Multiple Paths in BGP", RFC 7911, 650 DOI 10.17487/RFC7911, July 2016, 651 . 653 Authors' Addresses 655 Shaofu Peng 656 ZTE Corporation 658 Email: peng.shaofu@zte.com.cn 660 Ran Chen 661 ZTE Corporation 663 Email: chen.ran@zte.com.cn 665 Gregory Mirsky 666 ZTE Corporation 668 Email: gregimirsky@gmail.com