idnits 2.17.1 draft-peng-teas-network-slicing-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 : ---------------------------------------------------------------------------- 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 the ulra-reliable low-latency communication 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 SR policy. -- The document date (November 4, 2019) is 1634 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) == Unused Reference: 'RFC2119' is defined on line 847, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ali-spring-network-slicing-building-blocks-01 == Outdated reference: A later version (-15) exists of draft-ietf-idr-bgpls-inter-as-topology-ext-07 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-14 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-04 == 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-03 ** 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: May 7, 2020 ZTE Corporation 6 Fengwei. Qin 7 China Mobile 8 November 4, 2019 10 Packet Network Slicing using Segment Routing 11 draft-peng-teas-network-slicing-01 13 Abstract 15 This document presents a mechanism aimed at providing a solution for 16 network slicing in the transport network for 5G services. The 17 proposed mechanism uses a unified administrative instance identifier 18 to distinguish different virtual network resources for both intra- 19 domain and inter-domain network slicing scenarios. Combined with the 20 segment routing technology, the mechanism could be used for both 21 best-effort and traffic engineered services for tenants. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 7, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Network Slicing Requirements . . . . . . . . . . . . . . . . 3 59 2.1. Dedicated Virtual Networks . . . . . . . . . . . . . . . 3 60 2.2. End-to-End Slicing . . . . . . . . . . . . . . . . . . . 3 61 2.3. Unified NSI . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.4. Traffic Engineering . . . . . . . . . . . . . . . . . . . 4 63 2.5. Summarized Requirements . . . . . . . . . . . . . . . . . 5 64 3. Conventions used in this document . . . . . . . . . . . . . . 5 65 4. Overview of Existing Identifiers . . . . . . . . . . . . . . 5 66 4.1. AG and EAG Bit . . . . . . . . . . . . . . . . . . . . . 6 67 4.2. Multi-Topology Identifier . . . . . . . . . . . . . . . . 6 68 4.3. SR Policy Color . . . . . . . . . . . . . . . . . . . . . 6 69 4.4. Flex-algorithm Identifier . . . . . . . . . . . . . . . . 7 70 4.5. New Slice-based Identifier Introduced . . . . . . . . . . 7 71 5. Overview of AII-based Mechanism . . . . . . . . . . . . . . . 8 72 6. Resource Allocation per AII . . . . . . . . . . . . . . . . . 10 73 6.1. L3 Link Resource AII Configuration . . . . . . . . . . . 10 74 6.2. L2 Link Resource AII Configuration . . . . . . . . . . . 11 75 6.3. Node Resource AII Configuration . . . . . . . . . . . . . 11 76 7. Combined with SR Flex-algorithm for Stack Depth Optimization 12 77 7.1. Best-effort Service AII-specific . . . . . . . . . . . . 12 78 7.2. Traffic Engineering service AII-specific . . . . . . . . 12 79 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 8.1. intra-domain network slicing . . . . . . . . . . . . . . 13 81 8.2. inter-domain network slicing via BGP-LS . . . . . . . . . 14 82 8.3. inter-domain network slicing via BGP-LU . . . . . . . . . 16 83 9. Implementation suggestions . . . . . . . . . . . . . . . . . 17 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 87 13. Normative references . . . . . . . . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 90 1. Introduction 92 According to 5G context, network slicing is the collection of a set 93 of technologies to create specialized, dedicated logical networks as 94 a service (NaaS) in support of network service differentiation and 95 meeting the diversified requirements from vertical industries. 96 Through the flexible and customized design of functions, isolation 97 mechanisms, and operation and management (O&M) tools, network slicing 98 is capable of providing dedicated virtual networks over a shared 99 infrastructure. A Network Slice Instance (NSI) is the realization of 100 network slicing concept. It is an E2E logical network, which 101 comprises of a group of network functions, resources, and connection 102 relationships. An NSI typically covers multiple technical domains, 103 which include a terminal, access network (AN), transport network (TN) 104 and a core network (CN), as well as a DC domain that hosts third- 105 party applications from vertical industries. Different NSIs may have 106 different network functions and resources. They may also share some 107 of the network functions and resources. 109 For a transport network, network slicing requires the underlying 110 network to support partitioning of the network resources to provide 111 the client with dedicated (private) networking, computing, and 112 storage resources drawn from a shared pool. The slices may be seen 113 as virtual networks. 115 2. Network Slicing Requirements 117 2.1. Dedicated Virtual Networks 119 An end-to-end virtual network with dedicated resources is the 120 advantage of network slicing than traditional DiffServ QoS and VPN. 121 For example, DiffServ QoS can distinguish VoIP traffic and other type 122 of traffic (such as high-definition video, web browsing), but can not 123 distinguish the same type of traffic from different tenants, nor 124 isolation of these traffic at all. 126 Another example is the IoT traffic of health monitoring network which 127 connected hospital and outpatient, it always has strict privacy and 128 safety requirements, including where the data can be stored and who 129 can access the data, all this can not be satisfied by DiffServ QoS as 130 it has not any function of network computing and storage. 132 Dedicated VN is a distinct object purchased by a customer, and it 133 provides specific function with predictable performance, guaranteed 134 level of isolation and safety. It is not just as QoS. 136 2.2. End-to-End Slicing 138 Only an end-to-end slice and fine-grained network can match ultra 139 delay and safety requirements of special service. End-to-end means 140 that it is constructed with AN-slice, TN-slice, and CN-slice part. 142 Although 3GPP technical specifications mainly focus on the operation 143 and management of AN-slice and CN-slice, which include some NF 144 (network function) components, TN-slice is also created and destroyed 145 according to the related NSI lifecycle. In fact, the 3GPP management 146 system will request expected link requirements related to the network 147 slice (e.g., topology, QOS parameters) with the help of the 148 management system that handles the TN part related to the slice. 150 For TN part, the link requirements are independent of the existing 151 domain partition of the network, i.e., any intra- or inter-domain 152 link is the candidate resource for the slice. It is also independent 153 of the existing underlay frame or routing technologies (IGP, BGP, 154 Segment Routing, Flex-E, etc.), i.e., any L2 or L3 link is the 155 candidate resource. 157 2.3. Unified NSI 159 An NSI is indentified by S-NSSAI (Single Network Slice Selection 160 Assistance Information), which is allocated per PDU session and has 161 semantic global within the AN and CN. 163 For the purpose of operation and management simplicity, it is also 164 better to have a unified identifier with semantic global to 165 distinguish different TN-slice during the whole TN. TN-slice 166 identifier has a mapping relation with S-NSSAI, perhaps 1:1 or 1:n. 168 Instead, using different slice identifier across multi-domain of TN 169 for the specific TN-slice will introduce much and unnecessary 170 complexity, especially for case two devices belongs to different 171 domain try to exchange slice-based information directly, without the 172 help of SDN controller to translate the unified TN-slice identifier 173 to an individual domain-wide indentifier. 175 2.4. Traffic Engineering 177 5G system is expected to be able to provide optimized support for a 178 variety of different communication services, different traffic loads, 179 and different end-user communities. For example, the communication 180 services using network slicing may include: vehicle-to-everything 181 (V2X) services, 5G seamless enhanced Mobile BroadBand (eMBB) service 182 with FMC (fixed-mobile convergence), massive IoT connections. Among 183 these service types, high data rates, high traffic densities, low- 184 latency, high-reliability are highlighted requirements. 186 Traffic engineering mechanism in TN must support the above 187 requirements, bandwidth and delay are two primary TE constraints. 189 2.5. Summarized Requirements 191 In summary, the following requirements would be satisfied: 193 REQ1: Provide a distinct virtual network, including dedicated 194 topology, computation, and storage resource, not only traditional 195 QoS; 197 REQ2: Unified NSI for easy operation and maintenance; 199 REQ3: E2E network slicing, including both intra-domain and inter- 200 domain case; 202 REQ4: Customization resource for QoS purpose, bandwidth and delay are 203 basic constraints; 205 REQ5: Layer 2 as well as Layer 3 link resource partition; 207 3. Conventions used in this document 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in RFC2119. 213 4. Overview of Existing Identifiers 215 Currently there are multiple existing mature identifiers that could 216 be used to identify the virtual network resource in the transport 217 network, such as: 219 o Administrative Group (AG) described in [RFC3630], [RFC5329], 220 [RFC5305] and Extended Administrative Groups (EAGs) described in 221 [RFC7308] 223 o Multi-Topology Routing (MTR) described in [RFC5120], [RFC4915], 224 [RFC5340] 226 o SR policy color described in 227 [I-D.ietf-spring-segment-routing-policy] 229 o FA-id described in [I-D.ietf-lsr-flex-algo] 231 However, all these identifiers are not sufficient to meet the above 232 requirements of TN-slice. Note that all these identifiers have use 233 case of their own, besides the network slicing use case. Next, we 234 will discuss each of them to determine their matching of slicing 235 requirements. 237 4.1. AG and EAG Bit 239 AG and EAG are limited to serve as a link color scheme used in TE 240 path computation to meet the requirements of TE service for a tenant. 241 It is difficult to use them for an NSI allocation mapping (assuming 242 that each bit position of AG/EAG represents an NSI). Hence, they do 243 not meet REQ1. At the same time, AG or EAG cannot be a FIB 244 identifier for best-effort service for the same tenant. 246 AG and EAG are only as L3 link attribute, not appropriate for 247 L2-bundles member, i.e., not meeting REQ5. 249 Note that AG and EAG have semantic global, so they meet REQ2,3. 251 4.2. Multi-Topology Identifier 253 MTR is limited to serve as an IGP logical topology scheme only used 254 in the intra-domain scenario. Thus it is challenging to select 255 inter-area link resources based on MT-ID when E2E inter-domain TE 256 path needs to be created for a tenant. That is, it does not meet 257 REQ3. 259 Different IGP domain within the same TN-slice may be configured with 260 different MT-ID. Thus MT-ID does not meet REQ2. 262 MT-ID is only as L3 link attribute, not appropriate for L2-bundles 263 member, so it does not meet REQ5. 265 4.3. SR Policy Color 267 The color of SR policy defines a TE purpose, which includes a set of 268 constraints such as bandwidth, delay, TE metric, etc. Therefore 269 color is an abstract target, and it is difficult to get a distinct 270 virtual network according to a specific color value. In most cases, 271 only the headend and some other border nodes need to maintain the 272 color template, and a color-based virtual network is hard to present 273 because of too few participants and lack of interaction scheme. That 274 is, the color does not meet REQ1. 276 We can continue to define TE affinity information in color-template, 277 but that is only appropriate for L3 link, not for L2-bundles member, 278 so the color does not meet REQ5. 280 Note that the color has global semantic, so it meets REQ3. 282 4.4. Flex-algorithm Identifier 284 Indeed, FA-id is a short mapping of SR policy color, and it may 285 inherit the matched-degree of the Policy Color. However, FA-id has 286 its own characteristics. A specific FA-id can have more distributed 287 participants and define explicit link resource so that an explicit FA 288 plane can be created. Unfortunately, different best-effort and TE 289 service of the same slice-tenant will define different constraints, 290 resulting in the need to occupy more FA-id resources for one slice- 291 tenant. The relationship between FA-id and slice is not clear. That 292 is, FA-id does not meet REQ1. 294 On the other hand, FA-id, like MT-ID, is limited to serve as an IGP 295 algorithm scheme used in the intra-domain scenario. It is 296 challenging to select inter-area (especially inter-AS) link resources 297 according to FA-id when the E2E inter-domain TE path needs to be 298 created for the tenant. So, FA-id does not meet REQ3. 300 Different IGP domain within the same TN-slice may configure different 301 FA-ids, so it does not meet REQ2. 303 What is more important, tha the path in FA plane identified by FA-id 304 is MP2P LSP, so it is hard to define bandwidth reservation for 305 service. So, FA-id does not meet REQ4. 307 The link include/exclude rules defined by FA-id is only appropriate 308 for the L3 link, not for L2-bundles member, so FA-id does not meet 309 REQ5. 311 4.5. New Slice-based Identifier Introduced 313 Thus, there needs to introduce a new characteristic of NSI that meets 314 the above-listed requirements to isolate underlay resources, and it 315 is a slice-based identifier. 317 Firstly, it could serve as TE criteria for TE service, this aspect is 318 like AG/EAG; and secondly, as a FIB table identifier for best-effort 319 service, this aspect is like MT-ID or FA-id. 321 This document introduces a new property of NSI called "Administrative 322 Instance Identifier" (AII) and corresponding method of how to 323 instantiate it in the underlay network to match the above-listed 324 requirements. 326 5. Overview of AII-based Mechanism 328 [I-D.ietf-teas-enhanced-vpn] described a framework to create virtual 329 networks in a packet network. 330 [I-D.ali-spring-network-slicing-building-blocks] described how SR 331 policy [I-D.ietf-spring-segment-routing-policy] is competent for 332 network slicing. This document continues to specify the detailed 333 mechanism, according to 3GPP network slicing requirements, based on 334 SR policy with necessary enhancement to signal association of shared 335 resources required to create and manage an NSI and steer the packets 336 to the path within the specific NSI. 338 SR policy color has semantic global in order to be conveniently 339 exchanged between two PE routers. They configure the same color 340 template information for the same color value. AII also with global 341 semantic can be contained in color template to enhance SR policy to 342 create a TE path within global TN-slice identified by AII. Besides 343 TE service served by explicit SR policy instance, best-effort service 344 is served by AII-specific FIB that is created by default once AII 345 configured. 347 The following is how AII-based mechanism works: 349 At the initial stage, each link in a physical network can be colored 350 to conform with network slicing requirements. As previously 351 mentioned, AII can be used to color links to partition underlay 352 resources. Also, we may continue to use AG or EAG to color links for 353 traditional TE within a virtual network specified by an AII. A 354 single or multiple AIIs could be configured on each intra-domain or 355 inter-domain link regardless of IGP instance configuration. At the 356 minimum, a link always belongs to default AII (the value is 0). The 357 number of AIIs configured on a node's links determines the number of 358 virtual networks the node belongs to. 360 The extension of the existing IGP-TE mechanisms [RFC3630] and 361 [RFC5305] to distribute AII information in an AS as a new TE 362 parameter of a link will be defined in another document. 364 An SDN controller, using BGP-LS [RFC7752] or another interface, will 365 have a distinct view of each virtual network specified by AII. The 366 extension of BGP-LS will also be defined in another document. 368 Using the CSPF algorithm, a TE path for any best-effort (BE) or 369 traffic-engineered (TE) service can be calculated within a virtual 370 network specified by the AII. The computation criteria could be 371 or for the BE 372 and TE respectively. Combined with segment routing, the TE path 373 could be represented as: 375 o a single node-SID of the destination node, for the best-effort 376 service in the domain; 378 o node-SIDs of the border node and the destination node, adjacency- 379 SID of inter-domain link, for the inter-domain best-effort 380 service; 382 o an explicit adjacency-SID list or compressed with several loose 383 node-SID, for P2P traffic engineered service. 385 Because packets of the best-effort service could be transported over 386 an MP2P LSP without congestion control, SR best-effort FIB for each 387 virtual network specified by AII to forward best-effort packets may 388 be created in the IGP domain. Thus, CSPF computation with criteria 389 is distributed on each node in the IGP domain. 390 That is similar to the behavior in [I-D.ietf-lsr-flex-algo], but the 391 distributed CSPF computation is triggered by AII. 393 To distinguish forwarding behavior of different virtual networks, 394 prefix-SID need to be allocated per AII and advertised in the IGP 395 domain. 397 For inter-domain case, in addition to the destination node-SID, 398 several node-SIDs of the domain border node and adjacency-SID of 399 inter-domain link are also needed to construct the E2E segment list. 400 The segment list could be computed with the help of the SDN 401 controller, which needs to take account of AII information during the 402 computation. The head-end of the segment list maintains the 403 corresponding SR-TE tunnel or SR policy. 405 As same as the prefix-SID, adjacency-SID needs to be allocated per 406 AII to distinguish the forwarding behavior of different virtual 407 networks. 409 For P2P traffic engineering service, especially such as the ulra- 410 reliable low-latency communication service, it SHOULD not transfer 411 over an MP2P LSP to avoid the risk of traffic congestion. The 412 segment list could consist of pure adjacency-SID per AII specific. 413 The head-end of the segment list maintains the corresponding SR-TE 414 tunnel or SR policy. 416 However, label stack depth of the segment list MAY be optimized at a 417 later time based on local policies. 419 At this moment, we can steer traffic of overlay service to the above 420 SR best-effort FIB, SR-TE tunnel, or SR policy instance for the 421 specific virtual network. The overlay service could specify a color 422 for TE purposes. For example, color 1000 means to say "I need best-effort forwarding within AII 10 424 resource", color 1001 means to say "I 425 need traffic engineering forwarding within AII 10 resource, and only 426 using link with AG equal to 0x1 to reach guarantee of not exceeding 427 10ms delay time". Service with color 1000 will be steered to an SR 428 best-effort FIB entry, or an SR-TE tunnel/policy in case of inter- 429 domain. Service with color 1001 will be steered to an SR-TE tunnel/ 430 policy. 432 Note that there is a simple variants of AII-based slicing scheme for 433 initial slicing requirement of service, where the SDN controller in 434 management partition the whole E2E network topology to multiple 435 strictly isolated VNs identified by AII in local, but let the 436 forwarding equipments be totally unware of that. The overlay service 437 is steered to the SR policy whose adjacency-segment list is limited 438 within specific VN. This variants need not introduce any complex 439 virtual network technologies to forwarding equipments, however only 440 for limited scenes. 442 6. Resource Allocation per AII 444 6.1. L3 Link Resource AII Configuration 446 In IGP domain, each numbered or unnumbered L3 link could be 447 configured with AII information and synchronized among IGP neighbors. 448 The IGP link-state database will contain L3 links with AII 449 information to support TE path computation taking account of AII 450 criteria. For a numbered L3 link, it could be represented as a tuple 451 452 , for unnumbered it could be . Each L3 link could be configured 454 to belong to a single AII or multiple AIIs. Note that an L3 link 455 always belongs to default AII(0). 457 For different tuple it would allocate a different 458 adjacency-SID, as well as advertising with different resource portion 459 such as bandwidth occupied. 461 Note that AII is independent of IGP instance. An L3 link that is not 462 part of the IGP domain, such as the special purpose for a static 463 route, or an inter-domain link, can also be configured with AII 464 information and allocate adjacency-SID per AII as the same as IGP 465 links. BGP-LS could be used to collect link state data with AII 466 information to the controller, BGP-LS has already provided a 467 mechanism to collect link state data from many source protocols, such 468 as IGP, Direct, Static configuration, etc., to cover network slicing 469 requirements. 471 6.2. L2 Link Resource AII Configuration 473 [I-D.ietf-isis-l2bundles] described how to encode adjacency-SID for 474 each L2 member link of an L3 parent link. In the network slicing 475 scenario, it is beneficial to deploy LAG or another virtual 476 aggregation interface between two nodes. If that, the dedicated link 477 resources belong to different virtual networks could be added or 478 removed on demand, they are treated as L2 member links of a single L3 479 virtual interface. It is the single L3 virtual interface which needs 480 to occupy IP resource and join the IGP instance. Creating a new 481 slice-specific link on demand or removing the old one is likely to 482 affect little configurations. 484 For network slicing purpose, [I-D.ietf-isis-l2bundles] need to be 485 extended to advertise the AII attribute for each L2 member link. For 486 different tuple it would allocate a different 487 adjacency-SID, as well as advertising with different resource portion 488 such as bandwidth occupied. 490 In practice, each L2 member link of an L3 parent link SUGGESTED to be 491 configured to belong to a single AII, and different L2 member link 492 will have different single AII configuration, with different 493 adjacency-SID. Note that in this case, the L3 parent link belongs to 494 default AII(0), but each L2 member link belongs to the specific non- 495 default AII. An L2 member link maybe a Flex-E channel or UDUK tunnel 496 created/destroyed on demand. 498 In the control plane, routing protocol packets following the L3 499 parent link will select the L2 member link with the highest priority. 500 At the same time, in the forwarding plane, data packets that belong 501 to the specific virtual network will pass along the L2 member link 502 with the specific AII value. 504 TE path computation based on link-state database need inspect the 505 detailed L2 members of an L3 adjacency to select the expected L2 link 506 resource. 508 6.3. Node Resource AII Configuration 510 For topology resource, each node needs to allocate node-SID per AII 511 when it joins the related virtual network. All nodes in the IGP 512 domain can run the CSPF algorithm with criteria 513 to compute best-effort next-hop to any other destination nodes for a 514 virtual network AII-specific based on the link-state database that 515 containing AII information, so that SR best-effort FIB can be 516 constructed for each AII. Static routes could also be added to the 517 AII-specific FIB. 519 An intra-domain overlay best-effort service belongs to a virtual 520 network could be directly matched in the SR best-effort FIB for the 521 specific AII. At the same time, an inter-domain overlay best-effort 522 service belongs to a virtual network could be over a segment list 523 containing domain border node-SID and destination node-SID which 524 could be matched in the SR best-effort FIB for the specific AII. 526 7. Combined with SR Flex-algorithm for Stack Depth Optimization 528 [I-D.ietf-lsr-flex-algo] introduced a mechanism to do label stack 529 depth optimization for an SR policy in IGP domain part. As the color 530 of SR policy defined a TE purpose, traditionally the headend or SDN 531 controller will compute an expected TE path to meet that purpose. It 532 is necessary to map a color (32 bits) to an FA-id (8 bits) when SR 533 flex-algorithm enabled for an SR policy. Besides that, it is 534 necessary to enable the FA-id on each node that wants to join the 535 same FA plane manually. The FAD could copy the TE constraints (not 536 including bandwidth case) contained in the color template. We need 537 to consider the cost of losing the flexibility of color when 538 executing the flex-algo optimization, and also consider the gap 539 between P2P TE requirements and MP2P SR FA LSP capability, to reach 540 the right balance when deciding which SR policy need optimization. 542 7.1. Best-effort Service AII-specific 544 As described above, for best-effort service we have already 545 constructed SR best-effort FIB per AII, that is mostly like Flex- 546 algo. Thus, it is not necessary to map to FA-id again for a color 547 template which has defined a best-effort behavior within the 548 dedicated AII. Of course, if someone forced to remap it, there is no 549 downside for the operation, the overlay best-effort service (with a 550 color which defined specific AII, best-effort requirement, and 551 mapping FA-id) in IGP domain will try to recurse over 552 or FIB entry. 554 7.2. Traffic Engineering service AII-specific 556 An SR-TE tunnel/policy that served for traffic engineering service of 557 a virtual network specified by an AII was generated and computed 558 according to the relevant color template, which contained specific 559 AII and some other traditional TE constraints. If we config mapping 560 FA-id under the color template, the SR-TE tunnel/policy instance 561 could inherit forwarding information from corresponding SR Flex-Algo 562 FIB entry. 564 8. Examples 566 In this section, we will further illustrate the point through some 567 examples. All examples share the same figure below. 569 .-----. .-----. 570 ( ) ( ) 571 .--( )--. .--( )--. 572 +---+----link A1----+---+ +---+----link A1----+---+ 573 |PE1|----link A2----|PE2|---link A1---|PE3|----link A2----|PE2| 574 | |----link B1----| |---link B1---| |----link B1----| | 575 +---+----link B2----+---+ +---+----link B2----+---+ 576 ( ) ( ) 577 '--( AS1 )--' '--( AS2 )--' 578 ( ) ( ) 579 '-----' '-----' 581 Figure 1 Network Slicing via AII 583 Suppose that each link belongs to separate virtual network, e.g., 584 link Ax belongs to the virtual network colored by AII A, link Bx 585 belongs to the virtual network colored by AII B. link x1 has an IGP 586 metric smaller than link x2, but TE metric lager. 588 To simplify the use case, each AS just contained a single IGP area. 590 8.1. intra-domain network slicing 592 From the perspective of node PE1 in AS1, it will calculate best- 593 effort forwarding entry for each AII instance (including default AII) 594 to destinations in the same IGP area. For example: 596 For entry, forwarding information could be 597 ECMP during link A1 and link B1, with destination node-SID 100 for 598 . 600 For entry, forwarding information could be 601 link A1, with destination node-SID 200 for . 604 For entry, forwarding information could be 605 link B1, with destination node-SID 300 for . 608 It could also initiate an SR-TE instance (SR tunnel or SR policy) 609 with the particular color template on PE1, PE1 is headend and ASBR1 610 is destination node. For example: 612 For SR-TE instance 1 with color template which defined criteria 613 including {default AII, min TE metric}, forwarding information could 614 be ECMP during two segment list {adjacency-SID 1002 for @PE1} and {adjacency-SID 1004 for @PE1}. 617 For SR-TE instance 2 with the color template which defined criteria 618 including {AII=A, min TE metric}, forwarding information could be 619 presented as the segment list {adjacency-SID 2002 for @PE1}. 622 For SR-TE instance 3 with the color template which defined criteria 623 including {AII=B, min TE metric}, forwarding information could be 624 presented as the segment list {adjacency-SID 3004 for @PE1}. 627 Furthermore, we can use SR Flex-algo to optimize the above SR-TE 628 instance. For example, for SR-TE instance 1, we can define FA-ID 201 629 with FAD that contains the same information as the color template, in 630 turn, FA-ID 202 for SR-TE instance 2, FA-ID 203 for SR-TE instance 3. 631 Note that each FA-ID also needs to be enabled on ASBR1. So that the 632 corresponding SR FA entry could be: 634 For entry, forwarding information 635 could be ECMP during link A2 and link B2, with destination node-SID 636 600 for . 638 For entry, forwarding information 639 could be link A2, with destination node-SID 700 for . 642 For entry, forwarding information 643 could be link B2, with destination node-SID 800 for . 646 8.2. inter-domain network slicing via BGP-LS 648 [RFC7752] BGP-LS describes the methodology that using BGP protocol to 649 transfer the Link-State information that maybe originated from IGP 650 instance (for intra-domain topology information) or from local direct 651 interface or static configuration(for inter-domain topology 652 information). [I-D.ietf-idr-bgpls-inter-as-topology-ext] also 653 describes a method to firstly put inter-domain interconnections to 654 IGP instance, then always import data from IGP protocol source to 655 BGP-LS. In any case BGP-LS need extend to transfer the Link-State 656 data with AII information. 658 An E2E inner-AS SR-TE instance with particular color template could 659 be initiated on PE1, PE1 is head-end and PE2 is destination node. 660 BGP-LS could be used to inform the SDN controller about the underlay 661 network topology information including AII attribute. Thus the 662 controller could calculate E2E TE path within the particular virtual 663 network. 665 o For best-effort service, for example: 667 For SR-TE instance 4 with color template which defined criteria 668 including {default AII, min IGP metric}, forwarding information could 669 be segment list {node-SID 100 for , 670 adjacency-SID 1001 for @ASBR1, node-SID 400 for 671 }. 673 For SR-TE instance 5 with color template which defined criteria 674 including {AII=A, min IGP metric}, forwarding information could be 675 segment list {node-SID 200 for , 676 adjacency-SID 1001 for @ASBR1, node-SID 500 for 677 }. 679 For SR-TE instance 6 with color template which defined criteria 680 including {AII=B, min IGP metric}, forwarding information could be 681 segment list {node-SID 300 for , 682 adjacency-SID 1003 for @ASBR1, node-SID 600 for 683 }. 685 o For TE service, for example: 687 For SR-TE instance 7 with color template which defined criteria 688 including {default AII, min TE metric}, forwarding information could 689 be ECMP during two segment list {adjacency-SID 1002 for @PE1, adjacency-SID 1001 for @ASBR1, adjacency- 691 SID 1002 for @ASBR2} and {adjacency-SID 1004 for 692 @PE1, adjacency-SID 1003 for 693 @ASBR1, adjacency-SID 1004 for @ASBR2}. 695 For SR-TE instance 8 with color template which defined criteria 696 including {AII=A, min TE metric}, forwarding information could be 697 segment list {adjacency-SID 2002 for @PE1, 698 adjacency-SID 2001 for @ASBR1, adjacency-SID 2002 699 for @ASBR2}. 701 For SR-TE instance 9 with color template which defined criteria 702 including {AII=B, min TE metric}, forwarding information could be 703 segment list {adjacency-SID 3004 for @PE1, 704 adjacency-SID 3003 for @ASBR1, adjacency-SID 3004 705 for @ASBR2}. 707 For TE service, if we use SR Flex-algo to do optimizaztion, the above 708 forwarding information of each TE instance could inherit the 709 corresponding SR FA entry, it would look like this: 711 For SR-TE instance 7, forwarding information could be ECMP during two 712 segment list {node-SID 600 for , 713 adjacency-SID 1001 for @ASBR1, node-SID 600 for } and {adjacency-SID 1004 for @PE1, adjacency-SID 1003 for @ASBR1, adjacency- 716 SID 1004 for @ASBR2}. 718 For SR-TE instance 8 with color template which defined criteria 719 including {AII=A, min TE metric}, forwarding information could be 720 segment list {node-SID 700 for , 721 adjacency-SID 2001 for @ASBR1, node-SID 700 for }. 724 For SR-TE instance 9 with color template which defined criteria 725 including {AII=B, min TE metric}, forwarding information could be 726 segment list {node-SID 800 for , 727 adjacency-SID 3003 for @ASBR1, node-SID 800 for }. 730 8.3. inter-domain network slicing via BGP-LU 732 In some deployments, operators adopt BGP-LU to build inter-domain 733 MPLS LSP, overlay service will be directly over BGP-LU LSP. If 734 overlay service has TE requirements that defined by a color, that 735 means that BGP-LU LSP needs to have a sense of color too, i.e., BGP- 736 LU label could be allocated per color. At entry node of each domain, 737 BGP-LU LSP generated for specific color will be over intra-domain SR- 738 TE or SR Best-effort path generated for that color again. At exit 739 node of each domain, BGP-LU LSP generated for specific color will 740 select inter-domain forwarding resource per color. Especially, an 741 ASBR will select slice-specfic inter-AS link according to AII 742 information of color template. 744 [RFC7911] defined that multiple paths UPDATE message for the same 745 destination prefix can be advertised in BGP, each UPDATE can contain 746 the Color Extended Community ([I-D.ietf-idr-tunnel-encaps]) with 747 different color value. 749 In figure 1, PE2 can allocate and advertise six labels for its 750 loopback plus color 1, 2, 3, 4, 5, 6 respectively. Suppose color 1 751 defines {default AII, min IGP metric}, color 2 defines {AII=A, min 752 IGP metric}, color 3 defines {AII=B, min IGP metric}, and color 4 753 defines {default AII, min TE metric}, color 5 defines {AII=A, min TE 754 metric}, color 6 defines {AII=B, min TE metric}. PE2 will advertise 755 these labels to ASBR2 and ASBR2 then continues to allocate six labels 756 each for prefix PE2 plus different color. Other nodes will have the 757 same operation. Ultimately PE1 will maintain six BGP-LU LSP. 759 For example, the BGP-LU LSP for color 1 will be over SR best-effort 760 FIB entry node-SID 100 for to pass through 761 AS1, over adjacency-SID 1001 for @ASBR1 to pass 762 inter-AS, over SR best-effort FIB entry node-SID 400 for to pass through AS2. 765 For example, The BGP-LU LSP for color 4 will over SR-TE instance 1 766 (see section 6.1), or SR best-effort FIB entry node-SID 600 for (see section 6.1) to pass through AS1, 768 over adjacency-SID 1001 for @ASBR1 to pass inter-AS, 769 over SR-TE instance 1' or corresponding SR FA entry to pass through 770 AS2. Note that ASBR1 need also understand the meaning of a specific 771 color and select forwarding resource between two AS. 773 9. Implementation suggestions 775 As a node often contains control plane and forwarding plane, a 776 suggestion is that only default AII specific FTN table, i.e, 777 traditional FTN table, need be installed on forwarding plane, so that 778 there are not any modification and upgrade requirement for hardware 779 and existing MPLS forwarding mechanism. FTN entry for non-default 780 AII instance will only be maintained on the control plane and be used 781 for overlay service iteration according to next-hop plus color (color 782 will give AII information and mapping FA-id information). Note that 783 ILM entry for all AII need be installed on forwarding plane, that 784 does not bring any confusion because of prefix-SID allocation per 785 AII. 787 SR NHLFE entry and other iteration entry such as 788 can contain AII information for expected packet scheduling. 790 The implementation cost is low by means of existing segment routing 791 infrastructure. 793 10. IANA Considerations 795 TBD. 797 11. Security Considerations 799 TBD. 801 12. Acknowledgements 803 TBD. 805 13. Normative references 807 [I-D.ali-spring-network-slicing-building-blocks] 808 Ali, Z., Filsfils, C., Camarillo, P., and d. 809 daniel.voyer@bell.ca, "Building blocks for Slicing in 810 Segment Routing Network", draft-ali-spring-network- 811 slicing-building-blocks-01 (work in progress), March 2019. 813 [I-D.ietf-idr-bgpls-inter-as-topology-ext] 814 Wang, A., Chen, H., Talaulikar, K., Zhuang, S., and S. Ma, 815 "BGP-LS Extension for Inter-AS Topology Retrieval", draft- 816 ietf-idr-bgpls-inter-as-topology-ext-07 (work in 817 progress), September 2019. 819 [I-D.ietf-idr-tunnel-encaps] 820 Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel 821 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-14 822 (work in progress), September 2019. 824 [I-D.ietf-isis-l2bundles] 825 Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and 826 E. Aries, "Advertising L2 Bundle Member Link Attributes in 827 IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), 828 May 2017. 830 [I-D.ietf-lsr-flex-algo] 831 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 832 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 833 algo-04 (work in progress), September 2019. 835 [I-D.ietf-spring-segment-routing-policy] 836 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 837 P. Mattes, "Segment Routing Policy Architecture", draft- 838 ietf-spring-segment-routing-policy-03 (work in progress), 839 May 2019. 841 [I-D.ietf-teas-enhanced-vpn] 842 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 843 Framework for Enhanced Virtual Private Networks (VPN+) 844 Service", draft-ietf-teas-enhanced-vpn-03 (work in 845 progress), September 2019. 847 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 848 Requirement Levels", BCP 14, RFC 2119, 849 DOI 10.17487/RFC2119, March 1997, 850 . 852 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 853 (TE) Extensions to OSPF Version 2", RFC 3630, 854 DOI 10.17487/RFC3630, September 2003, 855 . 857 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 858 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 859 RFC 4915, DOI 10.17487/RFC4915, June 2007, 860 . 862 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 863 Topology (MT) Routing in Intermediate System to 864 Intermediate Systems (IS-ISs)", RFC 5120, 865 DOI 10.17487/RFC5120, February 2008, 866 . 868 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 869 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 870 2008, . 872 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 873 "Traffic Engineering Extensions to OSPF Version 3", 874 RFC 5329, DOI 10.17487/RFC5329, September 2008, 875 . 877 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 878 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 879 . 881 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 882 Traffic Engineering (MPLS-TE)", RFC 7308, 883 DOI 10.17487/RFC7308, July 2014, 884 . 886 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 887 S. Ray, "North-Bound Distribution of Link-State and 888 Traffic Engineering (TE) Information Using BGP", RFC 7752, 889 DOI 10.17487/RFC7752, March 2016, 890 . 892 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 893 "Advertisement of Multiple Paths in BGP", RFC 7911, 894 DOI 10.17487/RFC7911, July 2016, 895 . 897 Authors' Addresses 899 Shaofu Peng 900 ZTE Corporation 902 Email: peng.shaofu@zte.com.cn 904 Ran Chen 905 ZTE Corporation 907 Email: chen.ran@zte.com.cn 909 Gregory Mirsky 910 ZTE Corporation 912 Email: gregimirsky@gmail.com 914 Fengwei Qin 915 China Mobile 917 Email: qinfengwei@chinamobile.com