TEAS Shaofu. Peng Internet-Draft Ran. Chen Intended status: Standards Track Gregory. Mirsky Expires: April 23, 2021 ZTE Corporation Fengwei. Qin China Mobile October 20, 2020 Packet Network Slicing using Segment Routing draft-peng-teas-network-slicing-04 Abstract This document presents a mechanism aimed at providing a solution for network slicing in the transport network for 5G services. The proposed mechanism uses a unified administrative instance identifier to distinguish different virtual network resources for both intra- domain and inter-domain network slicing scenarios. Combined with the segment routing technology, the mechanism could be used for both best-effort and traffic engineered services for tenants. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 23, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Peng, et al. Expires April 23, 2021 [Page 1] Internet-Draft Packet Network Slicing using SR October 2020 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Architecture of TN Slicing . . . . . . . . . . . . . . . . . 4 2.1. Key Technologies of Transport slice . . . . . . . . . . . 5 3. Slicing Requirements . . . . . . . . . . . . . . . . . . . . 6 3.1. Dedicated Virtual Networks . . . . . . . . . . . . . . . 6 3.2. End-to-End Slicing . . . . . . . . . . . . . . . . . . . 6 3.3. Unified NSI . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Traffic Engineering . . . . . . . . . . . . . . . . . . . 7 3.5. Summarized Requirements . . . . . . . . . . . . . . . . . 7 4. Conventions Used in This Document . . . . . . . . . . . . . . 8 5. Overview of Existing Identifiers . . . . . . . . . . . . . . 8 5.1. AG and EAG Bit . . . . . . . . . . . . . . . . . . . . . 8 5.2. Multi-Topology Identifier . . . . . . . . . . . . . . . . 9 5.3. SR Policy Color . . . . . . . . . . . . . . . . . . . . . 9 5.4. Flex-algorithm Identifier . . . . . . . . . . . . . . . . 9 5.5. New Slice-based Identifier Introduced . . . . . . . . . . 10 6. Overview of AII-based Mechanism . . . . . . . . . . . . . . . 10 6.1. Physical Network Partition by AII . . . . . . . . . . . . 11 6.2. Path within AII specific Slice . . . . . . . . . . . . . 11 6.2.1. SR-BE Path within AII specific Slice . . . . . . . . 12 6.2.2. SR-TE Path within AII specific Slice . . . . . . . . 13 6.3. Traffic Steering to SR policy within Slice . . . . . . . 13 6.4. Simple Variant of AII-based Slicing Scheme . . . . . . . 13 7. Resource Allocation per AII . . . . . . . . . . . . . . . . . 14 7.1. L3 Link Resource AII Configuration . . . . . . . . . . . 14 7.2. L2 Link Resource AII Configuration . . . . . . . . . . . 15 7.3. Node Resource AII Configuration . . . . . . . . . . . . . 15 7.4. Service Function Resource AII Configuration . . . . . . . 16 8. E2E Slicing with Centralized Mode . . . . . . . . . . . . . . 16 9. E2E Slicing with Distributed Mode . . . . . . . . . . . . . . 17 10. Combined with SR Flex-algorithm for Stack Depth Optimization 17 10.1. Flex-algo Using AII Criteria . . . . . . . . . . . . . . 18 10.2. Best-effort Color Template Mapping to Flex-algo . . . . 18 10.3. Traffic Engineering Color Template Mapping to Flex-algo 18 11. Network Slicing Examples . . . . . . . . . . . . . . . . . . 18 11.1. Intra-domain Network Slicing Example . . . . . . . . . . 19 11.1.1. Best-effort Service over Network Slice Example . . . 19 11.1.2. TE Service over Network Slice Example . . . . . . . 19 11.1.3. TE Service over Network Slice with Flex-algo Example 20 11.2. Inter-domain Network Slicing via BGP-LS Example . . . . 20 Peng, et al. Expires April 23, 2021 [Page 2] Internet-Draft Packet Network Slicing using SR October 2020 11.2.1. Best-effort Service Example . . . . . . . . . . . . 20 11.2.2. TE Service Example . . . . . . . . . . . . . . . . . 21 11.2.3. TE Service Using Flex-algo Example . . . . . . . . . 21 11.3. Inter-domain Network Slicing via BGP-LU Example . . . . 22 12. Implementation Suggestions . . . . . . . . . . . . . . . . . 22 12.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . 22 12.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 23 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 14. Security Considerations . . . . . . . . . . . . . . . . . . . 25 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 16. Normative references . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction According to 5G context, network slicing is the collection of a set of technologies to create specialized, dedicated logical networks as a service (NaaS) in support of network service differentiation and meeting the diversified requirements from vertical industries. Through the flexible and customized design of functions, isolation mechanisms, and operation and management (O&M) tools, network slicing is capable of providing dedicated virtual networks over a shared infrastructure. A Network Slice Instance (NSI) is the realization of network slicing concept. It is an E2E logical network, which comprises of a group of network functions, resources, and connection relationships. An NSI typically covers multiple technical domains, which include a terminal, access network (AN), transport network (TN) and a core network (CN), as well as a DC domain that hosts third- party applications from vertical industries. Different NSIs may have different network functions and resources. They may also share some of the network functions and resources. For a transport network, network slicing requires the underlying network to support partitioning of the network resources to provide the client with dedicated (private) networking, computing, and storage resources drawn from a shared pool. The slices may be seen as virtual networks. This document describes how to realize TN-slice in the underlay network, and analyze the necessity and usage of a new slice-based identifier to represent specific virtual network that is requested by the user of 5G service who have the specific resources and connection requirements. This new slice-based identifier is expected to be not only used for management system, but also for control and data plane in the underlay network. Peng, et al. Expires April 23, 2021 [Page 3] Internet-Draft Packet Network Slicing using SR October 2020 2. Architecture of TN Slicing Relationship with NS Design Team: The current scope of NS design team will focus on the framework of the TN Slice.We would like to make some contributions of it, and we will sent this section to the NS Design Team for dicussion. +-----------+ +-----------+ +-----------+ |Tenant VPN | | eMBB | | uRLLC | ...... Client/Tenant +-----------+ +-----------+ +-----------+ Layer ----------------------------------------------------------------------------------------------------- L2VPN L3VPN EVPN Service Layer o o--o---o / o--o---o /| \ o--o---o / o o o /| \ o o o o ------------------------------------------------------------------------------------------------------ Virtual-Network-1 Virtual-Network-2 __________________________________ ________________________________ / / / / / ++++ ++++ ++++ / / ++++ ++++ / / + +---+ +---+ + / / + +--------+ + / / ++++ ++++ ++++ / / ++++ ++++ / / | | / / | | / Transport-Slice / ++++ ++++ / / ++++ ++++ / Layer / + +----+ + / / +--+------- +--+ / / ++++ ++++ / / ++++ ++++ / /__ ______________________________/ /_____________________________ / ------------------------------------------------------------------------------------------------------ ++++ ++++ ++++ +--+------------+--+-----------+--+ ++++ ++++ ++++ Physical Network | | | Layer | | | ++++ ++++ ++++ +--+-----------+--+----------+--+ ++++ ++++ ++++ Figure 1 Architecture of TN Slicing Peng, et al. Expires April 23, 2021 [Page 4] Internet-Draft Packet Network Slicing using SR October 2020 Based on the concept and architecture of Transport slice, the basic requirements and features of Transport slice are as following: o On-Demand network reconstitution: The slice network can be reconstituted in network topology and node capability to meet service needs. Each slice network has its own specific bandwidth, latency and lifecycle. Different Transport Slice networks are isolated from each other, and have independent topology and network resources. o Decoupling of Service Slice Layer and Physical Network Layer: The Service Slice Layer and the Physical Network Layer are decoupled, and unaware of the details of each other, which simplifies the deployment of services. o Similarity of Transport Slice Network and Physical Network for Service Layer: A Transport Slice Network Layer provides network resources to the upper layer (Service Layer) which is the same as the resources provided directly by a physical network from the point view of the upper layer. Services such as VPN service etc. can be deployed directly on the Transport slice network just as they are deployed on the physical network. One Transport slice network can support the deployment of more than one services or VPNs. o Data Plane Isolation of Transport Slice Network: The TN provides two types of traffic isolation between different TN slices: hard isolation and soft isolation. Hard isolation is implemented by providing independent circuit switched connections for the exclusive use of one slice, such as MTN (Metro Transport Network, see ITU-T G.mtn), and ODUk. Soft isolation is implemented by using a packet technology (e.g., Ethernet VLAN, MPLS tunnel, and VPN). Services of different slices are isolated from each other. o Transport Slice Network: There may be multiple Sub-TN-slices in a Transport Slice Network, and those Sub-Transport slices may be nested. Different sub-TN-slices can be also combined together for an end-to-end TN slice service. 2.1. Key Technologies of Transport slice For the transport network forwarding plane slicing, there are basically two kinds of isolation technology: soft isolation technology and hard isolation technology. The soft isolation is a Layer 2 or Layer 3 technology, such as SR/IP/MPLS based tunnel technology and VPN/VLAN based virtualization technology. The hard isolation is a Layer 1 or optical-layer slicing technology based on physically rigid pipelines, such as MTN, OTN and Wavelength Division Peng, et al. Expires April 23, 2021 [Page 5] Internet-Draft Packet Network Slicing using SR October 2020 Multiplexing (WDM) technologies. In applications, the hybrid hard and soft isolation solution is always used. The hard isolation ensures service isolation, and the soft isolation supports service bandwidth reuse. So, The Key Technologies of Transport slice should include: Layer-one Data Plane, Layer-Two Data Plane, and Layer-Three Data Plane. 3. Slicing Requirements 3.1. Dedicated Virtual Networks An end-to-end virtual network with dedicated resources is the advantage of network slicing than traditional DiffServ QoS and VPN. For example, DiffServ QoS can distinguish VoIP traffic and other type of traffic (such as high-definition video, web browsing), but can not distinguish the same type of traffic from different tenants, nor isolation of these traffic at all. Another example is the IoT traffic of health monitoring network which connected hospital and outpatient, it always has strict privacy and safety requirements, including where the data can be stored and who can access the data, all this can not be satisfied by DiffServ QoS as it has not any function of network computing and storage. Dedicated VN is a distinct object purchased by a customer, and it provides specific function with predictable performance, guaranteed level of isolation and safety. It is not just as QoS. 3.2. End-to-End Slicing Only an end-to-end slice and fine-grained network can match ultra delay and safety requirements of special service. End-to-end means that it is constructed with AN-slice, TN-slice, and CN-slice part. Although 3GPP technical specifications mainly focus on the operation and management of AN-slice and CN-slice, which include some NF (network function) components, TN-slice is also created and destroyed according to the related NSI lifecycle. In fact, the 3GPP management system will request expected link requirements related to the network slice (e.g., topology, QOS parameters) with the help of the management system that handles the TN part related to the slice. For TN part, the link requirements are independent of the existing domain partition of the network, i.e., any intra- or inter-domain link is the candidate resource for the slice. It is also independent of the existing underlay frame or routing technologies (IGP, BGP, Peng, et al. Expires April 23, 2021 [Page 6] Internet-Draft Packet Network Slicing using SR October 2020 Segment Routing, Flex-E, etc.), i.e., any L2 or L3 link is the candidate resource. From the end-to-end slicing requirement, the inter domain resource guarantee needs to be paid more attention to. 3.3. Unified NSI An NSI is indentified by S-NSSAI (Single Network Slice Selection Assistance Information), which is allocated per PDU session and has semantic global within the AN and CN. For the purpose of operation and management simplicity, it is also better to have a unified identifier with semantic global to distinguish different TN-slice within the whole TN. TN-slice identifier has a mapping relation with S-NSSAI, perhaps 1:1 or 1:n. Instead, using different slice identifier across multi-domain of TN for the specific TN-slice will introduce much and unnecessary complexity, especially for case two devices belongs to different domain try to exchange slice-based information directly through the protocol mechanism in control plane, without the help of SDN controller to translate the unified TN-slice identifier to an individual domain-wide indentifier. 3.4. Traffic Engineering 5G system is expected to be able to provide optimized support for a variety of different communication services, different traffic loads, and different end-user communities. For example, the communication services using network slicing may include: vehicle-to-everything (V2X) services, 5G seamless enhanced Mobile BroadBand (eMBB) service with FMC (fixed-mobile convergence), massive IoT connections. Among these service types, high data rates, high traffic densities, low- latency, high-reliability are highlighted requirements. Traffic engineering mechanism in TN must support the above requirements, bandwidth and delay are two primary TE constraints. 3.5. Summarized Requirements In summary, the following requirements would be satisfied for the realization of TN-slice: REQ1: Provide a distinct virtual network, including dedicated topology, computation, and storage resource, not only traditional QoS; Peng, et al. Expires April 23, 2021 [Page 7] Internet-Draft Packet Network Slicing using SR October 2020 REQ2: Unified NSI for easy operation and maintenance; REQ3: E2E network slicing, including both intra-domain and inter- domain case; REQ4: Customization resource for QoS purpose, bandwidth and delay are basic constraints; REQ5: Layer 2 as well as Layer 3 link resource partition; 4. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. 5. Overview of Existing Identifiers Currently there are multiple existing mature identifiers that could be used to identify all or part of the virtual network's resources in the transport network, such as: o Administrative Group (AG) described in [RFC3630], [RFC5329], [RFC5305] and Extended Administrative Groups (EAGs) described in [RFC7308] o Multi-Topology Routing (MTR) described in [RFC5120], [RFC4915], [RFC5340] o SR policy color described in [I-D.ietf-spring-segment-routing-policy] o FA-id described in [I-D.ietf-lsr-flex-algo] However, all these identifiers are not sufficient to meet the above requirements of TN-slice. Note that all these identifiers have use case of their own, besides the network slicing use case. Next, we will discuss each of them to determine their matching of slicing requirements. 5.1. AG and EAG Bit AG and EAG are limited to serve as a link color scheme used in TE path computation to meet the requirements of TE service for a tenant. It is difficult to use them for an NSI allocation mapping (assuming that each bit position of AG/EAG represents an NSI), and also difficult to use them to represent non-link resources. Hence, they do not meet REQ1, 2. Additionally, AG or EAG cannot be as an Peng, et al. Expires April 23, 2021 [Page 8] Internet-Draft Packet Network Slicing using SR October 2020 identifier to organize specific forwarding tables or policys for different virtual networks. AG and EAG can be used as the attribute of both L3 interface and L2-bundles member, to meet REQ5. Although AG and EAG have semantic global, they don't fully meet REQ3. For example, for an E2E path, inter domain links can also be selected by their AG/EAG attributes, but they can't be adhered to intra domain links through AG/EAG to let a complete view of virtual network be presented. 5.2. Multi-Topology Identifier MTR is limited to serve as an IGP logical topology scheme only used in the intra-domain scenario. Thus it is challenging to select inter-area link resources based on MT-ID when E2E inter-domain TE path needs to be created for a tenant. And, by definition, MTR is only used to represent topology resources and cannot be used for various other types of resources. That is, it does not meet REQ1, 3. Different IGP domain within the same TN-slice may be configured with different MT-ID. Thus MT-ID does not meet REQ2. MT-ID is only as L3 link attribute, not appropriate for L2-bundles member, so it does not meet REQ5. 5.3. SR Policy Color The color of SR policy defines a TE purpose, which includes a set of constraints such as bandwidth, delay, TE metric, etc. Therefore color is an abstract target, and it is difficult to get a distinct virtual network according to a specific color value. In most cases, only the headend and some other border nodes need to maintain the color template, and a color-based virtual network is hard to present because of too few participants and lack of interaction scheme. That is, the color does not meet REQ1, 2. We can continue to define TE affinity information in color-template, to select L3 link or L2-bundles member,to meet REQ5. Note that the color has global semantic, so it meets REQ3. 5.4. Flex-algorithm Identifier Indeed, FA-id is a short mapping of SR policy color, and it may inherit the matched-degree of the Policy Color. However, FA-id has its own characteristics. A specific FA-id can have more distributed Peng, et al. Expires April 23, 2021 [Page 9] Internet-Draft Packet Network Slicing using SR October 2020 participants and define explicit link resource so that an explicit FA plane can be created. Unfortunately, different service of the same tenant-slice will define different constraints, resulting in the need to occupy more FA-id resources for single tenant-slice. The relationship between FA-id and slice is not clear. That is, FA-id does not meet REQ1. On the other hand, FA-id, like MT-ID, is limited to serve as an IGP algorithm scheme used in the intra-domain scenario. It is challenging to select inter-area (especially inter-AS) link resources according to FA-id when the E2E inter-domain TE path needs to be created for the tenant. So, FA-id does not meet REQ3. Different IGP domain within the same TN-slice may configure different FA-ids, so it does not meet REQ2. What is more important, the path in FA plane identified by FA-id is MP2P LSP, so it is hard to define bandwidth reservation for service. So, FA-id does not meet REQ4. Unless each link is totally dedicated to a single FA plane, i.e., link resources are not shared among multiple FA plane. It is possible to let the link include/exclude rules defined by FA-id be appropriate for both L3 link and L2-bundles member, to meet REQ5. 5.5. New Slice-based Identifier Introduced Thus, there needs to introduce a new characteristic of NSI that meets the above-listed requirements to isolate underlay resources, and it is a slice-based identifier. Firstly, it could serve as TE criteria for TE service, this aspect is like AG/EAG; and secondly, as an identifier to orgnize specific forwarding tables or policys for different virtual networks, this aspect is like MT-ID or FA-id. This document introduces a new property of NSI called "Administrative Instance Identifier" (AII) and corresponding method of how to instantiate it in the underlay network to match the above-listed requirements. 6. Overview of AII-based Mechanism SR policy [I-D.ietf-spring-segment-routing-policy], just like traditional RSVP-TE LSP, can be used to realize IETF network slice in underlay network. This document introduce AII-based mechanism to enhance SR policy to support tenant-slice as well as service-slice. It will signal the association of AII and shared resources required Peng, et al. Expires April 23, 2021 [Page 10] Internet-Draft Packet Network Slicing using SR October 2020 to create and manage an NSI, and steer the packets to the path within the specific NSI according to SR policy color. SR policy color has semantic global in order to be conveniently exchanged between two endpoints within TN-slice. These two endpoints can configure the same color template information for the same color value. AII, also with global semantic, can be contained in color template to enhance SR policy to create a TE path within global TN- slice identified by AII. Besides TE service served by explicit SR policy instance, best-effort service can be served by AII-specific forwarding tables or policys that are created by default once AII configured. The following is how AII-based mechanism works. 6.1. Physical Network Partition by AII Each node and link in the physical network can be colored dynamically, with shared or dedicated resources, to conform with network slicing requirements. As previously mentioned, AII can be used to color nodes and links to partition underlay resources. Also, we may continue to use AG or EAG to color links for traditional TE within a virtual network specified by an AII. A single or multiple AIIs could be configured on each intra-domain or inter-domain link regardless of IGP instance configuration. At the minimum, a link always belongs to default AII (the value is 0). The extension of the existing IGP-TE mechanisms [RFC3630] and [RFC5305] to distribute AII information as a new TE parameter of a link in the underlay network will be defined in another document. Using BGP-LS [RFC7752], an SDN controller,can collect topology information of each virtual network specified by AII with related resources, and have a distinct view of each virtual network. Extension of BGP-LS will also be defined in another document. 6.2. Path within AII specific Slice Using the CSPF algorithm, a TE path for any best-effort (BE) or traffic-engineered (TE) service can be calculated within a virtual network specified by the AII. The computation criteria could be or for the BE and TE respectively. Combined with segment routing, the TE path could be represented as: o A single node-SID of the destination node, for the best-effort service intra-domain; Peng, et al. Expires April 23, 2021 [Page 11] Internet-Draft Packet Network Slicing using SR October 2020 o Several node-SIDs of the border node and the destination node, adjacency-SID of inter-domain link, for the inter-domain best- effort service; o An explicit adjacency-SID list or compressed with several loose node-SIDs, for traffic engineered service. To distinguish forwarding behavior of different virtual networks, Prefix-SID and Adjacency-SID need to be allocated per AII with related resources, and advertised in the IGP domain. 6.2.1. SR-BE Path within AII specific Slice Because packets of the best-effort service could be transported over an MP2P LSP without congestion control, SR-BE path for each virtual network specified by AII to forward best-effort packets may be created in the IGP domain. This document will register some standard AII value (see section "IANA Considerations") to represent different type of slice. For example, a slice type "normal" represent any slices that have endogenous "min IGP metric" criteria to compute SPF path within the slice. Thus, for a virtual network with slice type "normal", CSPF computation with criteria is distributed on each node within the virtual network. Similarly, a slice type "uRLLC" represent any slices that have endogenous "min delay metric" (Min Unidirectional Link Delay as defined in [RFC7810]) criteria to compute SPF path within the slice. For a virtual network with slice type "uRLLC", CSPF computation with criteria is distributed on each node within the virtual network. Similarly, a slice type "TE" represent any slices that have endogenous "TE metric" (TE default metric as defined in [RFC5305]) criteria to compute SPF path within the slice. For a virtual network with slice type "TE metric", CSPF computation with criteria is distributed on each node within the virtual network. That is similar to the behavior in [I-D.ietf-lsr-flex-algo], but the distributed CSPF computation is triggered by AII, using determined criteria without negotiation among noeds. Besides the best-effort service, SR-BE path for specific AII also provide an escape way for traffic engineering service within the same virtual network when the expected TE purpose can not be meet. Peng, et al. Expires April 23, 2021 [Page 12] Internet-Draft Packet Network Slicing using SR October 2020 6.2.2. SR-TE Path within AII specific Slice Other different constraints sets can also be defined to calculate TE paths for different overlay services within the same slice, regardless of the endogenous criteria of the slice. It is suggested that the set of constraints defined should contain the endogenous constraint of the slice. For some traffic engineering services that have strict requirements, 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 should consist of pure adjacency-SIDs and other service funciton SIDs per AII, with guaranteed resources. The segment list could be computed by headend or SDN controller. However, stack depth of the segment list MAY be optimized at a later time based on local policies. 6.3. Traffic Steering to SR policy within Slice The traffic of overlay service can be steerred to the above SR-BE path or SR-TE tunnel/policy instance for the specific virtual network. The overlay service could specify a color for TE purpose. For example, color 1000 means to say "I need best-effort forwarding within AII 10 resource", color 1001 means to say "I need traffic engineering forwarding within AII 10 resource, and only use links with AG 0x1 to reach guarantee of not exceeding 10ms delay upper bound". Service with color 1000 will be steered to an SR-BE entry of the table identified by AII, or an SR-TE tunnel/policy in case of inter- domain. Service with color 1001 will be steered to an SR-TE tunnel/policy. 6.4. Simple Variant of AII-based Slicing Scheme There is a simple variant of AII-based slicing scheme for initial slicing requirement of service, where the SDN controller in management partition the whole E2E network topology to multiple strictly isolated VNs identified by AII in local, but let the forwarding equipments of the underlay network be totally unware of that. The overlay service is steered to the SR policy whose path is limited within specific VN using a pure adjacency-segment list. Peng, et al. Expires April 23, 2021 [Page 13] Internet-Draft Packet Network Slicing using SR October 2020 This variant need not introduce any complex protocol mechanism of control plane in the underlay network, however only for limited scenes. There are no states per AII, except that QoS policy per AII need to be configured in the underlay network. 7. Resource Allocation per AII 7.1. L3 Link Resource AII Configuration In IGP domain, each numbered or unnumbered L3 link could be configured with AII information and synchronized among IGP neighbors. The IGP link-state database will contain L3 links with AII information to support TE path computation taking account of AII criteria. For a numbered L3 link, it could be represented as a tuple , for unnumbered it could be . Each L3 link could be configured to belong to a single AII or multiple AIIs. Note that an L3 link always belongs to default AII(0). For different tuple it would allocate a different adjacency-SID, as well as advertising with different resource portion such as bandwidth occupied. Note that AII is independent of IGP instance. An L3 link that is not part of the IGP domain, such as the special purpose for a static route, or an inter-domain link, can also be configured with AII information and allocate adjacency-SID per AII as the same as IGP links. BGP-LS could be used to collect link state data with AII information to the controller, BGP-LS has already provided a mechanism to collect link state data from many source protocols, such as IGP, Direct, Static configuration, etc., to cover network slicing requirements. When an L3 link joins to to multiple VNs, as traditional ways that these VNs can share the total bandwidth resouce of the link with preemption mode based on packet priority, this is what we know as soft slicing. However, In some other scenarios, a hard slicing scheme can be used to establish a hardened pipe to meet the slicing business requirements, at this time each VN need dedicated bandwidth resouce reserved from the same link, and at each node QoS policy per AII (e.g, traffic shaper per slice) should be used to ensure that the traffic between different slices is isolated and does not affect each other. Peng, et al. Expires April 23, 2021 [Page 14] Internet-Draft Packet Network Slicing using SR October 2020 7.2. L2 Link Resource AII Configuration [RFC8668] described how to encode adjacency-SID for each L2 member link of an L3 parent link. In the network slicing scenario, it is beneficial to deploy LAG or another virtual aggregation interface between two nodes. If that, the dedicated link resources belong to different virtual networks could be added or removed on demand, they are treated as L2 member links of a single L3 virtual interface. It is the single L3 virtual interface which needs to occupy IP resource and join the IGP instance. Creating a new slice-specific link on demand or removing the old one is likely to affect little configurations. For network slicing purpose, [RFC8668] need to be extended to advertise the AII attribute for each L2 member link. In practice, for hard isolation purpose, different L2 member link of the same L3 parent link is SUGGESTED to be configured to belong to different single AII, with different adjacency-SID. Note that in this case, the L3 parent link belongs to default AII(0) (i.e, for this L3 link it is not necessary to allocate adjacency-SID per AII any more), but each L2 member link belongs to the specific non-default AII as well as the shared default AII. An L2 member link maybe a Flex-E channel or ODUK tunnel created/destroyed on demand. In practice, for hard isolation purpose, different L2 member link of the same L3 parent link SUGGESTED to be configured to belong to different AII, with different adjacency-SID. Note that in this case, the L3 parent link belongs to default AII(0), but each L2 member link belongs to the specific non-default AII. An L2 member link maybe a Flex-E channel or ODUK tunnel created/destroyed on demand. In the control plane, routing protocol packets following the L3 parent link will select the L2 member link with the highest priority. In the forwarding plane, data packets that belong to the specific virtual network will pass along the L2 member link with the specific AII value. TE path computation based on link-state database need inspect the detailed L2 members of an L3 adjacency to select the expected L2 link resource. 7.3. Node Resource AII Configuration For topology resource, each node needs to allocate node-SID per AII when it joins the related virtual network. All nodes in the IGP domain can run the CSPF algorithm with criteria to compute SR-BE path to any other destination nodes for an Peng, et al. Expires April 23, 2021 [Page 15] Internet-Draft Packet Network Slicing using SR October 2020 AII-specific virtual network based on the link-state database that containing AII information, so that SR-BE FIB can be constructed for each AII. Static routes could also be added to the AII-specific FIB. An intra-domain overlay best-effort service belongs to an AII specific virtual network could be directly over the SR-BE path within that VN. An inter-domain overlay best-effort service belongs to an AII specific virtual network could be over a path containing a single destination node-SID or a segment list containing domain border node- SID and destination node-SID within that VN. 7.4. Service Function Resource AII Configuration [I-D.ietf-spring-sr-service-programming] introduces the notion of service segments, and describes how to implement service segments and achieve stateless service programming in SR-MPLS and SRv6 networks. The ability of encoding the service segments along with the topological segment enables service providers to forward packets along a specific network path and through VNFs or physical service appliances available in the network. Typically, a Service Function may be any purposeful execution for the packet, such as DPI, firewall, NAT, etc. The Service Function is independent of topology, it can also be instantiated per AII, each with different priority to be executed or scheduled. For example, a docker container including specific Service Funciton process can be generated or destroyed on demand according to the life-cycle of a particular slice. It will have a particular CPU scheduling priority. At a node, multiple instance of the same type of Service Function for different slice will allocate different Service SID and advertise to other nodes. 8. E2E Slicing with Centralized Mode [RFC7752] BGP-LS describes the methodology that using BGP protocol to transfer the Link-State information that maybe originated from IGP instance (for intra-domain topology information) or from local direct interface or static configuration(for inter-domain topology information). [I-D.ietf-idr-bgpls-inter-as-topology-ext] also describes a method to firstly put inter-domain interconnections to IGP instance, then always import data from IGP protocol source to BGP-LS. In any case BGP-LS need extend to transfer the Link-State data with AII information. Peng, et al. Expires April 23, 2021 [Page 16] Internet-Draft Packet Network Slicing using SR October 2020 An E2E inner-AS SR-TE instance with particular color template could be initiated on PE1, PE1 is head-end and PE2 is destination node. BGP-LS could be used to inform the SDN controller about the underlay network topology information including AII attribute. Thus the controller could calculate E2E TE path within the particular virtual network. Especially an AII specific Adacency-SID of inter-domain link can be included in the E2E SID list. 9. E2E Slicing with Distributed Mode In some deployments, especially the network evolution from seamless MPLS in practice, operators adopt BGP-LU to build inter-domain MPLS LSP, and overlay service will be directly over BGP-LU LSP. In this case, the network is divided into some domains and each domain will run its own IGP process. These IGP process are isolated to each other to be simple. That means it is inconvenient to realize network slicing depending on IGP itself with inter-area route leak or redistribution. For an E2E BGP-LU LSP, if overlay service has TE requirements that defined by a color, the BGP-LU LSP need also have a sense of color, i.e., BGP-LU label could be allocated per color. At entry node of each domain, BGP-LU LSP generated for specific color will be over intra-domain SR-TE or SR-BE path generated for that color again. At exit node of each domain, BGP-LU LSP generated for specific color will select inter-domain forwarding resource per color. Especially, an ASBR will select slice-specfic inter-AS link according to AII information of color template. [RFC7911] defined that multiple paths UPDATE message for the same destination prefix can be advertised in BGP, each UPDATE can contain the Color Extended Community ([I-D.ietf-idr-tunnel-encaps]) with different color value. That is a simple existing way to realize BGP- LU color function, with needless new BGP extensions. 10. Combined with SR Flex-algorithm for Stack Depth Optimization [I-D.ietf-lsr-flex-algo] introduced a mechanism to do segment stack depth optimization for an SR policy in IGP domain part. As the color of SR policy defined a TE purpose, traditionally the headend or SDN controller will compute an expected TE path to meet that purpose. It is necessary to map a color (32 bits) to an FA-id (8 bits) when SR flex-algorithm enabled for an SR policy. Besides that, it is necessary to enable the FA-id on each node that wants to join the Peng, et al. Expires April 23, 2021 [Page 17] Internet-Draft Packet Network Slicing using SR October 2020 same FA plane manually. The FAD could copy the TE constraints (not including bandwidth case) contained in the color template. We need to consider the cost of losing the flexibility of color when executing the flex-algo optimization, and also consider the gap between P2P TE requirements and MP2P SR FA LSP capability, to reach the right balance when deciding which SR policy need optimization. 10.1. Flex-algo Using AII Criteria Because the first feature of AII is a TE criteria of link and node, it could be served as a parameter of Flex-algo Definition. [I-D.peng-lsr-flex-algo-opt-slicing] described how to extend IGP Flex-algo to compute constraint based paths over the AII specific network slice. 10.2. Best-effort Color Template Mapping to Flex-algo As described above, for best-effort service within an AII specific virtual network, we have already constructed SR-BE FIB tables per AII, that is mostly like Flex-algo. Thus, it is not necessary to map to FA-id again for a color template which has defined a best-effort behavior within an AII specific virtual network. Of course, if someone forced to remap it, there is no downside for the operation, the overlay best-effort service (with a color which defined specific AII, best-effort requirement, and mapping FA-id) in IGP domain will try to recurse over or FIB entry. 10.3. Traffic Engineering Color Template Mapping to Flex-algo An SR-TE tunnel/policy that served for traffic engineering service of an AII speficif virtual network was generated and computed according to the relevant color template, which contained specific AII and some other traditional TE constraints. If we config mapping FA-id under the color template, the SR-TE tunnel/policy instance will inherit forwarding information from corresponding SR Flex-Algo FIB entry. If we config merging FA-id under the color template, the SR-TE tunnel/ policy instance will have a TE path within Flex-algo plane. 11. Network Slicing Examples In this section, we will further illustrate the point through some examples. All examples share the same figure below. Peng, et al. Expires April 23, 2021 [Page 18] Internet-Draft Packet Network Slicing using SR October 2020 .-----. .-----. ( ) ( ) .--( )--. .--( )--. +---+----link A1----+---+ +---+----link A1----+---+ |PE1|----link A2----|PE2|---link A1---|PE3|----link A2----|PE2| | |----link B1----| |---link B1---| |----link B1----| | +---+----link B2----+---+ +---+----link B2----+---+ ( ) ( ) '--( AS1 )--' '--( AS2 )--' ( ) ( ) '-----' '-----' Figure 2 Network Slicing via AII Suppose that each link belongs to separate virtual network, e.g., link Ax belongs to the virtual network colored by AII A, link Bx belongs to the virtual network colored by AII B. link x1 has an IGP metric smaller than link x2, but TE metric lager. To simplify the use case, each AS just contained a single IGP area. 11.1. Intra-domain Network Slicing Example 11.1.1. Best-effort Service over Network Slice Example From the perspective of node PE1 in AS1, it will calculate best- effort forwarding entry for each AII instance (including default AII) to destinations in the same IGP area. For example: For entry, forwarding information could be ECMP during link A1 and link B1, with destination node-SID 100 for . For entry, forwarding information could be link A1, with destination node-SID 200 for . For entry, forwarding information could be link B1, with destination node-SID 300 for . 11.1.2. TE Service over Network Slice Example It could also initiate an SR-TE instance (SR tunnel or SR policy) with the particular color template on PE1, PE1 is headend and ASBR1 is destination node. For example: Peng, et al. Expires April 23, 2021 [Page 19] Internet-Draft Packet Network Slicing using SR October 2020 For SR-TE instance 1 with color template which defined criteria including {default AII, min TE metric}, forwarding information could be ECMP during two segment list {adjacency-SID 1002 for @PE1} and {adjacency-SID 1004 for @PE1}. For SR-TE instance 2 with the color template which defined criteria including {AII=A, min TE metric}, forwarding information could be presented as the segment list {adjacency-SID 2002 for @PE1}. For SR-TE instance 3 with the color template which defined criteria including {AII=B, min TE metric}, forwarding information could be presented as the segment list {adjacency-SID 3004 for @PE1}. 11.1.3. TE Service over Network Slice with Flex-algo Example Furthermore, we can use SR Flex-algo to optimize the above SR-TE instance. For example, for SR-TE instance 1, we can define FA-ID 201 with FAD that contains the same information as the color template, in turn, FA-ID 202 for SR-TE instance 2, FA-ID 203 for SR-TE instance 3. Note that each FA-ID also needs to be enabled on ASBR1. So that the corresponding SR FA entry could be: For entry, forwarding information could be ECMP during link A2 and link B2, with destination node-SID 600 for . For entry, forwarding information could be link A2, with destination node-SID 700 for . For entry, forwarding information could be link B2, with destination node-SID 800 for . 11.2. Inter-domain Network Slicing via BGP-LS Example 11.2.1. Best-effort Service Example For SR-TE instance 4 with color template which defined criteria including {default AII, min IGP metric}, forwarding information could be segment list {node-SID 100 for , adjacency-SID 1001 for @ASBR1, node-SID 400 for }. For SR-TE instance 5 with color template which defined criteria including {AII=A, min IGP metric}, forwarding information could be Peng, et al. Expires April 23, 2021 [Page 20] Internet-Draft Packet Network Slicing using SR October 2020 segment list {node-SID 200 for , adjacency-SID 1001 for @ASBR1, node-SID 500 for }. For SR-TE instance 6 with color template which defined criteria including {AII=B, min IGP metric}, forwarding information could be segment list {node-SID 300 for , adjacency-SID 1003 for @ASBR1, node-SID 600 for }. 11.2.2. TE Service Example For SR-TE instance 7 with color template which defined criteria including {default AII, min TE metric}, forwarding information could be ECMP during two segment list {adjacency-SID 1002 for @PE1, adjacency-SID 1001 for @ASBR1, adjacency- SID 1002 for @ASBR2} and {adjacency-SID 1004 for @PE1, adjacency-SID 1003 for @ASBR1, adjacency-SID 1004 for @ASBR2}. For SR-TE instance 8 with color template which defined criteria including {AII=A, min TE metric}, forwarding information could be segment list {adjacency-SID 2002 for @PE1, adjacency-SID 2001 for @ASBR1, adjacency-SID 2002 for @ASBR2}. For SR-TE instance 9 with color template which defined criteria including {AII=B, min TE metric}, forwarding information could be segment list {adjacency-SID 3004 for @PE1, adjacency-SID 3003 for @ASBR1, adjacency-SID 3004 for @ASBR2}. 11.2.3. TE Service Using Flex-algo Example For TE service, if we use SR Flex-algo to do optimizaztion, the above forwarding information of each TE instance could inherit the corresponding SR FA entry, it would look like this: For SR-TE instance 7, forwarding information could be ECMP during two segment list {node-SID 600 for , adjacency-SID 1001 for @ASBR1, node-SID 600 for } and {adjacency-SID 1004 for @PE1, adjacency-SID 1003 for @ASBR1, adjacency- SID 1004 for @ASBR2}. For SR-TE instance 8 with color template which defined criteria including {AII=A, min TE metric}, forwarding information could be segment list {node-SID 700 for , Peng, et al. Expires April 23, 2021 [Page 21] Internet-Draft Packet Network Slicing using SR October 2020 adjacency-SID 2001 for @ASBR1, node-SID 700 for }. For SR-TE instance 9 with color template which defined criteria including {AII=B, min TE metric}, forwarding information could be segment list {node-SID 800 for , adjacency-SID 3003 for @ASBR1, node-SID 800 for }. 11.3. Inter-domain Network Slicing via BGP-LU Example In figure 1, PE2 can allocate and advertise six labels for its loopback plus color 1, 2, 3, 4, 5, 6 respectively. Suppose color 1 defines {default AII, min IGP metric}, color 2 defines {AII=A, min IGP metric}, color 3 defines {AII=B, min IGP metric}, and color 4 defines {default AII, min TE metric}, color 5 defines {AII=A, min TE metric}, color 6 defines {AII=B, min TE metric}. PE2 will advertise these labels to ASBR2 and ASBR2 then continues to allocate six labels each for prefix PE2 plus different color. Other nodes will have the same operation. Ultimately PE1 will maintain six BGP-LU LSP. For example, the BGP-LU LSP for color 1 will be over SR best-effort FIB entry node-SID 100 for to pass through AS1, over adjacency-SID 1001 for @ASBR1 to pass inter-AS, over SR best-effort FIB entry node-SID 400 for to pass through AS2. For example, The BGP-LU LSP for color 4 will over SR-TE instance 1 (see section 10.1.2), or SR best-effort FIB entry node-SID 600 for (see section 10.1.3) to pass through AS1, over adjacency-SID 1001 for @ASBR1 to pass inter-AS, over SR-TE instance 1' or corresponding SR FA entry to pass through AS2. Note that ASBR1 need also understand the meaning of a specific color and select forwarding resource between two AS. 12. Implementation Suggestions The implementation cost is low by means of existing segment routing infrastructure. 12.1. SR-MPLS As a node often contains control plane and forwarding plane, a suggestion is that only default AII specific FTN table, i.e, traditional FTN table, need be installed on forwarding plane, so that there are not any modification and upgrade requirement for hardware and existing MPLS forwarding mechanism. FTN entry for non-default AII instance will only be maintained on the control plane and be used Peng, et al. Expires April 23, 2021 [Page 22] Internet-Draft Packet Network Slicing using SR October 2020 for overlay service iteration according to next-hop plus color (color will give AII information and mapping FA-id information). Note that ILM entry for all AII need be installed on forwarding plane, that does not bring any confusion because of prefix-SID allocation per AII. SR NHLFE entry and other iteration entry such as can contain AII information for expected packet scheduling. It is recommended that QoS policy per AII should be maintained in the underlay network. The Slice Type value of AII can distinguish flows by coarse-grained classification, while the Instance value of AII can be used for more scheduling policy. 12.2. SRv6 For SRv6 case, IPv6 address resource is directly used to represent SID, so that different IPv6 block could be allocated to different slice. There are two possible ways to advertise slice specfic IPv6 block: o Traditional prefix reachability, but only for default AII (0) specific IPv6 block. o New SRv6 Locator advertisement, for nonzero AII specific IPv6 block. Forwarding entries for the default AII specific locators advertised in prefix reachability MUST be installed in the forwarding plane of receiving routers. Forwarding entries for the nonzero AII specific locators advertised in the SRv6 Locator MUST be also installed in the forwarding plane of receiving SRv6 capable routers when the associated AII is supported by the receiving node. The entries of both the above two cases SHOULD be installed in the unified FIB table, i.e., a single FIB table for default AII, because different IPv6 block is allocated to different slice. Instead, more FIB tables created for each VN in dataplane will bring comlexity for overlay service iteration, that is why MTR has no practical deployment. The forwarding information of FIB entry can contain AII information for expected packet scheduling. Peng, et al. Expires April 23, 2021 [Page 23] Internet-Draft Packet Network Slicing using SR October 2020 13. IANA Considerations This document requests IANA to create a new top-level registry called "Network Slicing Parameters". This registry is being defined to serve as a top-level registry for keeping all other Network Slicing sub-registries. Additionally, a new sub-registry "AII (TN-slice Identifier) codepoint" is to be created under top-level "Network Slicing Parameters" registry. This sub-registry maintains 32-bit identifiers and has the following registrations: Peng, et al. Expires April 23, 2021 [Page 24] Internet-Draft Packet Network Slicing using SR October 2020 +============+======================================================+ | Slice Type | Instance | Description | |(High 8bits)| (Low 24bits) | | +============+==============+=======================================+ | | 0 | Reservered for Default Slice: the | | 0(Normal) | | original physical network. | |endogenous: +--------------+---------------------------------------+ | IGP-metric | nonzero | Normal Slice, for user defined. | +------------+--------------+---------------------------------------+ | | 0 | Resevered. | | 1(uRLLC) +--------------+---------------------------------------+ |endogenous: | | Slice suitable for the handling of | | delay | nonzero | ultra- reliable low latency | | | | communications, for user defined. | +------------+--------------+---------------------------------------+ | 2(TE) | 0 | Resevered. | |endogenous: +--------------+---------------------------------------+ | TE-metric | nonzero | General TE Slice, for user defined. | +------------+--------------+---------------------------------------+ | | 0 | Resevered. | | 3(eMBB) +--------------+---------------------------------------+ |endogenous: | | Slice suitable for the handling of 5G | | TBD | nonzero | enhanced Mobile Broadband, for user | | | | defined. | +------------+--------------+---------------------------------------+ | | 0 | Resevered. | | 4(MIoT) +--------------+---------------------------------------+ |endogenous: | nonzero | Slice suitable for the handling of | | TBD | | massive IoT, for user defined. | +------------+--------------+---------------------------------------+ | | 0 | Resevered. | | 5(V2X) +--------------+---------------------------------------+ |endogenous: | nonzero | Slice suitable for the handling of | | TBD | | V2X services, for user defined. | +------------+--------------+---------------------------------------+ | 6-255 | any | Unassigned. | +------------+--------------+---------------------------------------+ Table 1. AII Codepoint 14. Security Considerations TBD. Peng, et al. Expires April 23, 2021 [Page 25] Internet-Draft Packet Network Slicing using SR October 2020 15. Acknowledgements TBD. 16. Normative references [I-D.ali-spring-network-slicing-building-blocks] Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer, "Building blocks for Slicing in Segment Routing Network", draft-ali-spring-network-slicing-building-blocks-02 (work in progress), November 2019. [I-D.ietf-idr-bgpls-inter-as-topology-ext] Wang, A., Chen, H., Talaulikar, K., and S. Zhuang, "BGP-LS Extension for Inter-AS Topology Retrieval", draft-ietf- idr-bgpls-inter-as-topology-ext-09 (work in progress), September 2020. [I-D.ietf-idr-tunnel-encaps] Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- encaps-19 (work in progress), September 2020. [I-D.ietf-lsr-flex-algo] Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- algo-12 (work in progress), October 2020. [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", draft- ietf-spring-segment-routing-policy-08 (work in progress), July 2020. [I-D.ietf-spring-sr-service-programming] Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and S. Salsano, "Service Programming with Segment Routing", draft-ietf-spring-sr-service- programming-03 (work in progress), September 2020. [I-D.nsdt-teas-transport-slice-definition] Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "IETF Definition of Transport Slice", draft- nsdt-teas-transport-slice-definition-04 (work in progress), September 2020. Peng, et al. Expires April 23, 2021 [Page 26] Internet-Draft Packet Network Slicing using SR October 2020 [I-D.peng-lsr-flex-algo-opt-slicing] Peng, S., Chen, R., and G. Mirsky, "IGP Flexible Algorithm Optimazition for Netwrok Slicing", draft-peng-lsr-flex- algo-opt-slicing-02 (work in progress), September 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, . [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, . [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, DOI 10.17487/RFC5329, September 2008, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)", RFC 7308, DOI 10.17487/RFC7308, July 2014, . Peng, et al. Expires April 23, 2021 [Page 27] Internet-Draft Packet Network Slicing using SR October 2020 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 7810, DOI 10.17487/RFC7810, May 2016, . [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, . [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, M., and E. Aries, "Advertising Layer 2 Bundle Member Link Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, December 2019, . Authors' Addresses Shaofu Peng ZTE Corporation Email: peng.shaofu@zte.com.cn Ran Chen ZTE Corporation Email: chen.ran@zte.com.cn Gregory Mirsky ZTE Corporation Email: gregimirsky@gmail.com Fengwei Qin China Mobile Email: qinfengwei@chinamobile.com Peng, et al. Expires April 23, 2021 [Page 28]