]> Orange

Rennes 35000 France mohamed.boucadair@orange.com

Traffic Engineering Architecture and Signaling slice specifications slice coordination This document lists a set of slicing-related specifications that are being development within the IETF. This document is meant to provide an overview of slicing activities in the IETF to hopefully ease coordination and ensure that specifications that are developed in many WGs are consistent. Discussion Venues Discussion of this document takes place on the Traffic Engineering Architecture and Signaling Working Group mailing list (teas@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Various slicing efforts are being conduced within various IETF WGs (e.g., teas, idr, spring, ccamp, mpls, opsawg, 6man, and ippm) and areas (e.g., rtg, int, tsv, and ops). All these efforts are referring to the IETF framework that is developed by the teas WG (), however there is a lack of a global visibility about these efforts and their interdependency. Also, there is a lack of cross-WG communications in some cases when a slicing-related specification is candidate for adoption or adopted by a WG. This lack of global view at the IETF level and lack of early cross-WG communications may induce some inconsistency. For example, some proposals argue in favor of specifying extensions to convey specific identifiers in packets. However, distinct identifiers are being proposed: slice identifier, NRP Selector, NRP identifier, VTN identifier, VTN resource identifier, etc. The need and relationship between these identifiers are worth to be discussed independent of the channels that are used to convey these identifiers. This document provides an overview of slicing activities in the IETF to hopefully ease coordination and ensure that specifications that are developed in many WGs are consistent, e.g.:

• Position the various concepts: network slice, network resource partition, virtual transport network, etc.
• Clarify the need of the various identifiers introduced so far and soften redundant/duplicate uses.
• Harmonize the definition of relevant identifiers (length, encoding, usage, etc.) rather than having the specification of the same identifier repeated in many places. For example, current specifications use distinct encoding length of the same attribute (variable, 16-bit, 32-bit).
• Clarify the relationship and co-existence of identifiers if more than one is needed.

Reference Framework and Architecture is the authoritative IETF framework for Network Slices. It provides definitions for a slice-related core terms and specifies a framework for the provision of Network Slice Services over networks that are deployed using technologies that are owned by the IETF (IP, MPLS, etc.). The document refers to such slices as IETF Network Slice or "the term "RFC 9543 Network Slice". provides a clear distinction between:

• the "RFC 9543 Network Slice Service" which is the service delivered to the customer and which is agnostic to the technologies and mechanisms used by the service provider, and
• the "RFC 9543 Network Slice" which is the realization of the service in the service provider's network achieved by partitioning network resources and by applying a set of mechanisms within the network.

The RFC 9543 Network Slice Service is specified in terms of:

• a set of Service Demarcation Point (SDP),
• a set of one or more connectivity constructs between subsets of these SDPs, and
• a set of service objectives for each SDP sending to each connectivity construct.

The service objectives can be expressed as Service Level Objectives (SLOs) or Service Level Expectations (SLEs). In some deploymenets, the underlying network can be customized to select a subset of resources that are suitable for the delivery of an RFC 9543 Network Slice Service. Such a customization can be achieved by creating a set of Network Resource Partitions (NRPs). In other deployments, RFC 9543 Network Slices can be hosted directly on the underlay network (i.e., without requiring any NRP). RFC 9543 Network Slices can be realized using existing tools (). The extensions listed in or are not required in such a case. does not provide any recommendation about the technological means to realize an RFC 9543 Network Slice Service. These considerations are deployment specific.

Models for Realizing Network Slices

Using Current IP/MPLS Technologies describes a model for the realization of RFC 9543 Network Slices for 5G networks. This realization model reuses many building blocks that are commonly used in service provider networks, specifically:

• L2VPN/L3VPN service instances for logical separation,
• Fine-grained resource control at the PE,
• Coarse resource control at the transit, and
• Capacity planning/management for efficient usage of provider network resources.

Using Network Resource Partitions (NRPs) and Slice-Flow Aggregates proposes a model that is inspired from the Diffserv model for the realization of Network Slices over IP/MPLS networks. Specifically, this model introduces the concept of Slice-Flow Aggregate which is defined as a collection of packets that are mapped to an NRP and are given the same forwarding treatment in a shared network. An aggregate can group flows from of one or more RFC 9543 Network Slice Services. also introduces the notion of NRP Policy that is used to trigger the creation of NRPs that will support a given Slice-Flow Aggregate. In some deployment schemes, packets that belong to a Slice-Flow Aggregate are forwarded by intermediate node along the appropriate NRP by processing an NRP Selector that is carried by these packets.

Optical Transport Networks (OTN) Slicing defines Optical Transport Networks (OTN) slice as an OTN virtual network topology connecting a number of OTN endpoints using a set of shared or dedicated OTN network resources to satisfy specific SLOs. OTN slices are considered as a technology-specific realization of an RFC 9543 Network Slice in the OTN domain.

VPN+ describes a framework for providing enhanced VPN services based upon VPN and Traffic Engineering (TE) technologies. Enhanced VPN (VPN+) can be used for the realization of Network Slices. This document introduces the concept of Virtual Transport Network (VTN), which is a virtual underlay network consisting of a subset of network resources allocated from the physical underlay network, and is associated with a customized network topology.

Instantiation in Service Providers Networks focuses on the instantiation of the RFC 9543 Network Slice Services in service provider networks using existing data models. In particular, this document describes the relationship between service models for managing the RFC 9543 Network Slice Services and network models (e.g., the Layer-3 Network Model (L3NPM, ), the Layer-2 Network Model (L2NM )) used for the realization of the slices.

Structuring Network Slice Controllers proposes an approach for structuring the RFC 9543 Network Slice Controller as well as how to use different data models being defined for RFC 9543 Network Slice Service provision.

SR-based Hierarchical Network Slices proposes a hierarchical approach for realizing RFC 9543 Network Slices in Segment Routing domain. The approach involves two levels:

• Level 1 Network Slices are realized using Flex-Algo.
• Level 2 forwarding paths are restricted in the Level 1 topology by using SR Policy and NRP-ID in the data plane.

Realization of Composite Network Slices investigates a set of scenarios for realizing composite RFC 9543 Network Slices (that basically involve other slices). The document defines a new identifier, called Inter-domain NRP ID.

AAA for Hierarchical Network Slices describes an authentication, authorization, and accounting process for hierarchical Network Slices. The document suggest adding NRP-ID to accounting meesages, but lacks a discussion whether any protocol extension is needed.

Applicability and Mapping Scenarios

3GPP 5G End-to-End Network Slices focuses on the application of RFC 9543 Network Slices in the context of the 3GPP 5G slices.

Enforcement of 5G End-to-End Network Slice QoS documents an example of possible mapping of 5QI values to DSCP markings with a focus on 5G Network Slices. The document groups different 5QI types in classes based on their SLOs.

Encoding 3GPP Slices for Interactive Media Services explores how IETF schemes (DSCP and UDP options) can be used to expose some QoS-related metadata for specific flows to 5GS. The document focuses on the Extended Reality & multi-modality communication (XRM) service.

Abstraction and Control of Traffic Engineered Networks (ACTN) describes the applicability of ACTN to Network Slicing.

Mobility-Aware Transport Network Slicing discusses a mapping of 5G slices to RFC 9543 Network Slices when the transport network is separated from the networks in which the 5G network functions are deployed (e.g., 5G functions distributed across data centers). This document zooms into the use of UDP source port number in GTP-U outer header and LAN to map between a 5G slice and corresponding RFC 9543 Network Slice segments that is listed in . The document specifies an ACaaS extension to support a layer 3 GTP-U (or UDP encapsulated GTP) bearer as an attachment circuit.

DetNet describes the applicability of DetNet to RFC 9543 Network Slice, particularly to provide deterministic services. The document describes how to use DetNet flow aggregation as the Slice-Flow Aggregates over an underlying NRP following the approach in .

Orchestration and Data Models provides an example of the various data models that can be invoked in the context of Network Slicing.

Overview of Data Models used for Network Slicing

Common Models specifies a set of reusable types and groupings to manage VPN services. Note that VPNs are used for the realization of Network Slices. specifies a set of reusable types and groupings to manage Attachment Circuits (ACs).

Service Models

Attachment Circuit as a Service (ACaaS) Data Model specifies YANG data models for managing 'Attachment Circuits'-as-a-Service (ACaaS) and also bearers. These ACs and bearers are used to identify where to deliver a slice service.

Network Slice Service Data Model defines a YANG data model for manaing RFC 9543 Network Slice Services.

Network Models

Service Attachment Points (SAPs) defines a YANG data model for representing an abstract view of the provider network topology that contains the points from which its services can be attached (e.g., basic connectivity, VPN, network slices). Also, the model can be used to retrieve the points where the services are actually being delivered to customers (including peer networks). A SAP network topology can be used for one or multiple service types ('service-type'). Setting this data node to 'network-slice' allows a controller to expose where RFC 9543 Network Slices services are being delivered. It can also be used to check where RFC 9543 Network Slice Services can be delivered.

AC-augmented SAPs augments the SAP model with more details for managing ACs at the network level.

Network Slice Topology specifies a YANG model for RFC 9543 Network Slice Topology with on exposing a customized topology that contains a topology intent with required SLO/SLEs to express the customer’s intent for resource reservation. The need for such a model is yet to be justified as the current scope is redundant with, e.g., what can be already achieved using . The authors should motivate why is not sufficient.

Network Resource Partitions (NRPs) specifies a YANG data model for managing NRPs.

Network Slice Mapping specifies an RFC 9543 Network Slice Service mapping YANG model. The model supports the following mappings:

• L3NM
• L2NM
• TE
• NRP

Control Plane Extensions

BGP Classful Transport Planes specifies mechanisms for classifying underlay routes into a set of classes, called Transport Classes, and mapping service-specific routes to a specific Transport Class. For example, can be used to create a customized topology for Network Slices. These topologies (Transport Classes) will be typically created to satisfy certain TE characteristics. A new Transport Class Route Target Extended Community is defined for this purpose. A Transport Class is identified by a 4-octet identifier: Transport Class ID.

BGP Color-Aware Routing (CAR) specifies a new BGP SAFI called BGP Color-Aware Routing (BGP CAR). Colors are defined to characterize an objective (e.g., low latency). To satisfy Network Slice requirements, CAR may be used to establish paths that address specific objectives. These paths will be associated with a Color. The proposal leverages the BGP Color Extended Community defined in and builds upon the Color concept defined in . In addition, a new Extended Community, called Local-Color-Mapping (LCM) Extended Community, is defined to address cases where the granularity of the exposed colors differs when crossing domains.

Network Resource Partitions (NRPs)

BGP Flowspec specifies a BGP Flowspec extension for NRP traffic steering.

BGP-LS NRP Filters in SR specifies new BGP-LS attributes, called BGP-LS Filters, for NRPs in SR networks. A BGP-LS Filter provides a description of a subset of the links and nodes in an underlay network. Ingress PE selects a path to an egress PE from the topology defined by the BGP-LS Filters it has imported for a given VPN. adds new BGP-LS attribute TLVs to encode information such as NRP-ID.

BGP NRP Extensions specifies extensions to BGP to advertise NRPs to the network nodes involved in the NRP.

BGP-LS NRP Extensions specifies extensions to BGP Link-State (BGP-LS) to advertise NRPs to network controllers.

SR Policies Extensions

BGP and define extensions to BGP in order to advertise NRP ID in an SR Policy. The NRP ID is encoded in 4 octets.

BGP-LS specifies SR Policy extensions for NRP in BGP-LS. The NRP ID is encoded in 4 octets.

PCEP Extensions specifie Path Computation Element Communication Protocol (PCEP) extensions for NRP. The NRP ID is encoded in 4 octets.

Virtual Transport Networks (VTNs)

IS-IS MT specifies how to use IS-IS Multi-Topology (MT) for SR-based VTNs.

BGP-LS describes a mechanism to distribute the information of SR-based VTNs to the network controller using BGP-LS with Multi-Topology.

Data Plane Extensions

Slice Identifier in the MPLS Entropy Label proposes an approach to encode slice identifiers in a portion of the MPLS Entropy Label (EL). The number of bits to be used for encoding the slice identifier in the EL is policy-based. Transit LSRs uses the slice identifier in the EL to apply per-slice policies.

Slice Identifier in IPv6 Flow Label proposes to encode slice identifers in a portion of the IPv6 Flow Label. Slice identifiers are used by intermediate IPv6 routers to process the packet according to a network slice policy.

Slice Identifier in the Source Address of Encapsulated SRH When an ingress SR router encapsulates a packet in an IPv6 packet with an SRH, suggests to use the least significant bits of the outer IPv6 source address to encode a slide identifier. SLID Presence Indicator (SPI) is used to indicate the presence of a slice identifier. The number of bits used to encode slice identifiers is local to an SR domain.

VTN Resource ID in an IPv6 Extension Header describes a mechanism to carry an identifier, called VTN resource ID, in the IPv6 Hop-by-Hop extension header. The document claims that "VTN resource ID" is equivalent to NRP-ID, but does motivate why another yet ID is thus needed rather than using "NRP-ID". The length of the VTN ID depends on the context type. When CT=0, the VTN ID is a 4-octet ID.

Network Resource Partitions (NRPs)

Resource-aware Segments An NRP can be represented in SR networks using a set of NRP-specific resource-aware segments .

NRP ID in SRv6 specifies an approach to encode the NRP ID in the SRH. This ID is used by intermediate IPv6 routers to identify the NRP to be used for forwarding. The encoding of the NRP ID in an IPv6 address is variable; an instruction is thus needed to help identifyint the NRP-ID position (e.g., low 16 bits).

NRP Selector in MPLS Network Actions As mentioned in , packets that are associated with a Slice-Flow Aggregate may carry an NRP Selector (NRPS). This selector is intended to be conveyed in the packet's network layer header to identify the flow aggregate to which a packet belongs. investigates a set of options to use MPLS Network Actions (MNA) to carry the NRPS:

• 13-bit NRP Selector (NRPS13) Action
• 20-bit NRP Selector (NRPS20) Action
• 20-bit Entropy and NRP Selector (ENRPS20) Action

SRv6 Resource Programming defines a new SRv6 Endpoint behavior to associate a SID with a set of NRPs.

OAM

LSP Ping/Traceroute Extensions specifies extenstions to the LSP Ping/Traceroute to convey NRP-ID in SR domains. The NRP-ID is a encoded as a 4-octet field.

Precision Availability Metrics (PAM) introduces a new set of metrics, called Precision Availability Metrics (PAM). These metrics are used to assess whether a service (e.g., Network Slice Service) is provided in compliance with its specified SLOs. specifies a set of new IP Flow Information Export (IPFIX) Information Elements to export precision availability data associated with Flows. These Information Elements are specifically designed to indicate compliance of a Flow with an SLO.

IPFIX Information Elements for NRP explores how to use IPFIX to export NRP IDs. However, there is currently no one single stable/authoritative specification of NRP-ID. This identifier is being proposed as data plane and control plane extensions. These proposals do not share the same ID format. The initial version of does explain which plan is used, in which layer the ID was exported, etc. Defining an IPFIX IE is useful for network observability, however there is no stable specification yet of the ID to be exported.

PAM-based Path Computation specifies a new PCEP object (PRECISION METRIC) for path calculation with performance requirements expressed as SLOs. The new PCEP object uses the attributes defined in .

Misc

Scalability Considerations for NRP discusses a set of scenarios for the deployment of NRP with a focus on scalability implications. The document reasons about the increase of requested RFC 9543 Network Slice Services that would require NRPs. Such an increase of slices is speculative at this stage.

Deployment Considerations reports a set of "deployments" from various network operators and identifies some considerations for operating Network Slices (e.g., scalability and automation). Most of these reported cases rely upon SRv6. The document does not provide enough details whether these "deployments" are for testing purposes or reflect setups to carry customers' traffic.

Security Considerations Security considerations of the mechanisms listed in the document are discussed in the relevant documents that specify these mechanisms.

IANA Considerations This document does not make any request to IANA.

Informative References This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context. The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security. This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices. Network slicing is a feature that was introduced by the 3rd Generation Partnership Project (3GPP) in Mobile Networks. Realization of 5G slicing implies requirements for all mobile domains, including the Radio Access Network (RAN), Core Network (CN), and Transport Network (TN). This document describes a network slice realization model for IP/MPLS networks with a focus on the Transport Network fulfilling the service objectives for 5G slicing connectivity. The realization model reuses many building blocks commonly used in service provider networks at the current time. Cisco Systems Inc. Juniper Networks Huawei Technologies Ericsson ZTE Corporation Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by by requiring compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) based on slice identifiers. Futurewei Technologies Telefonica Nokia Ciena CAICT China Mobile Alef Edge The requirement of slicing network resources with desired quality of service is emerging at every network technology, including the Optical Transport Networks (OTN). As a part of the transport network, OTN can provide hard pipes with guaranteed data isolation and deterministic low latency, which are highly demanded in the Service Level Agreement (SLA). This document describes a framework for OTN network slicing and defines YANG data models with OTN technology-specific augments deployed at both the north and south bound of the OTN network slice controller. Additional YANG data model augmentations will be defined in a future version of this draft. This document describes a framework for Enhanced Virtual Private Networks (VPNs) based on Network Resource Partitions (NRPs) in order to support the needs of applications with specific traffic performance requirements (e.g., low latency, bounded jitter). NRP-based enhanced VPNs leverage the VPN and Traffic Engineering (TE) technologies and add characteristics that specific services require beyond those provided by conventional VPNs. Typically, an NRP-based enhanced VPN will be used to underpin network slicing, but it could also be of use in its own right providing enhanced connectivity services between customer sites. This document also provides an overview of relevant technologies in different network layers and identifies some areas for potential new work. Nokia Telefonica Nokia Telefonica Orange This document exemplifies how the various data models that are produced in the IETF can be combined in the context of Network Slice Services delivery. Specifically, this document describes the relationship between the Network Slice Service models for requesting Network Slice Services and both Service (e.g., the L3VPN Service Model, the L2VPN Service Model) and Network (e.g., the L3VPN Network Model, the L2VPN Network Model) models used during their realizations. In addition, this document describes the communication between a Network Slice Controller (NSC) and the network controllers for the realization of Network Slices. The Network Slice Service YANG model provides a customer-oriented view of the intended Network slice Service. Thus, once an NSC receives a request for a Slice Service request, the NSC has to map it to accomplish the specific objectives expected by the network controllers. Existing YANG network models are analyzed against Network Slice requirements, and the gaps in existing models are identified. As a complement to the Layer 3 Virtual Private Network Service Model (L3SM), which is used for communication between customers and service providers, this document defines an L3VPN Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a service provider network. The model provides a network-centric view of L3VPN services. The L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate communication between a service orchestrator and a network controller/orchestrator. This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). The L2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types. Telefonica Ciena Nvidia Huawei This document describes an approach for structuring the IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision (and how they are related). It is not the purpose of this document to standardize or constrain the implementation the IETF Network Slice Controller. China Mobile China Mobile New H3C Technologies New H3C Technologies Huawei Technologies ZTE Corporation Ruijie Networks Co., Ltd. This document describes a Segment Routing based solution for two- level hierarchical IETF network slices. Level-1 network slice is realized by associating Flex-Algo with dedicated sub-interfaces, and level-2 network slice is realized by using SR Policy with additional NRP-ID on data plane. Huawei Technologies Huawei Technologies China Unicom China Telecom Telefonica A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC 9543 describes a framework for network slices built in networks that use IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a collection of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. In some network scenarios, network slices using IETF technologies may span multiple network domains, and they may be composed hierarchically, which means a network slice itself may be further sliced. In the context of 5G, a 5G end-to-end network slice consists of three different types of network technology segments: Radio Access Network (RAN), Transport Network (TN) and Core Network (CN). The transport segments of the 5G end-to-end network slice can be provided using network slices described in RFC 9543. This document first describes the possible use cases of composite network slices built in networks that use IETF network technologies, then it provides considerations about the realization of composite network slices. For the multi-domain network slices, an Inter-Domain Network Resource Partition Identifier (Inter-domain NRP ID) may be introduced. For hierarchical network slices, the structure of the NRP ID is discussed. And for the interaction between IETF network slices with 5G network slices, the identifiers of the 5G network slices may be introduced into IETF networks. These network slice- related identifiers may be used in the data plane, control plane and management plane of the network for the instantiation and management of composite network slices. This document also describes the management considerations of composite network slices. China Mobile New H3C Technologies New H3C Technologies This document describes an enhanced AAA mechanism for hierarchical network slice service when users access to the network and use the network slice resources of different SLA levels. Huawei Technologies Telefonica Ciena Huawei Technologies Ribbon Communications Network Slicing is one of the core features of 5G defined in 3GPP, which provides different network service as independent logical networks. To provide 5G network slices services, an end-to-end network slice has to span three network segments: Radio Access Network (RAN), Mobile Core Network (CN) and Transport Network (TN). This document describes the application of the IETF network slice framework in providing 5G end-to-end network slices, including network slice mapping in the management, control and data planes. Telefonica Ribbon Communications Juniper Networks 5G End-to-End Network Slice QoS is an essential aspect of network slicing, as described in both IETF drafts and the 3GPP specifications. Network slicing allows for the creation of multiple logical networks on top of a shared physical infrastructure, tailored to support specific use cases or services. The primary goal of QoS in network slicing is to ensure that the specific performance requirements of each slice are met, including latency, reliability, and throughput. China Mobile China Mobile Extended Reality & multi-modality communication, or XRM, is a type of advanced service that has been studied and standardized in the 3GPP SA2 working group. It targets at achieving high data rate, ultra-low latency, and high reliability. The streams of an XRM service might be comprised of data from multiple modalities, namely, video, audio, ambient-sensor and haptic detection, etc. XRM service faces challenges on various aspects, e.g. accurate multi-modality data synchronization, QoS differentiation, large volume of packets, and etc. While a new 3GPP network slice type, HDLLC, has been recently introduced to handle the QoS requirements of XRM streams, the ubiquitously-existential encryption of packet header and/or payload post additional challenges to the transport of encoded video packets via 5GS. We have then discussed two potential IETF schemes, e.g., IP-DSCP based or UDP-option extension, that could be applied to 'expose' XRM QoS 'metadata' to 5GS. Old Dog Consulting Independent Huawei Technologies Old Dog Consulting Network abstraction is a technique that can be applied to a network domain to obtain a view of potential connectivity across the network by utilizing a set of policies to select network resources. Network slicing is an approach to network operations that builds on the concept of network abstraction to provide programmability, flexibility, and modularity. It may use techniques such as Software Defined Networking (SDN) and Network Function Virtualization (NFV) to create multiple logical or virtual networks, each tailored for a set of services that share the same set of requirements. Abstraction and Control of Traffic Engineered Networks (ACTN) is described in RFC 8453. It defines an SDN-based architecture that relies on the concept of network and service abstraction to detach network and service control from the underlying data plane. This document outlines the applicability of ACTN to network slicing in a Traffic Engineered (TE) network that utilizes IETF technologies. It also identifies the features of network slicing not currently within the scope of ACTN and indicates where ACTN might be extended. Intel Corporation Futurewei Starten Systems Nvidia Telefonica Network slicing in 5G enables logical networks for communication services of multiple 5G customers to be multiplexed over the same infrastructure. While 5G slicing covers logical separation of various aspects of 5G infrastructure and services, user's data plane packets over the Radio Access Network (RAN) and Core Network (5GC) use IP in many segments of an end-to-end 5G slice. When end-to-end slices in a 5G System use network resources, they are mapped to corresponding Transport Network (TN) slice(s) which in turn provide the bandwidth, latency, isolation, and other criteria required for the realization of a 5G slice. This document describes mapping of 5G slices to TN slices using UDP source port number of the GTP-U bearer when the TN slice provider is separated by an "attachment circuit" from the networks in which the 5G network functions are deployed, for example, 5G functions that are distributed across data centers. The slice mapping defined here is supported transparently when a 5G user device moves across 5G attachment points and session anchors. Delivery of network services assumes that appropriate setup is provisioned over the links that connect customer termination points and a provider network. The required setup to allow successful data exchange over these links is referred to as an attachment circuit (AC), while the underlying link is referred to as a "bearer". This document specifies a YANG service data model for ACs. This model can be used for the provisioning of ACs before or during service provisioning (e.g., RFC 9543 Network Slice Service). The document also specifies a YANG service data model for managing bearers over which ACs are established. ZTE Corp. ZTE Corp. The convergence of IETF Network Slicing with DetNet achieves adequate network resource allocation and reservation to each node along the way of DetNet flows for latency-sensitive services. This document introduces the applicability of DetNet to network slice , DetNet mapping with Network Slice requirements and YANG data models extensions in the context of IP/ MPLS network. This document defines a common YANG module that is meant to be reused by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN network models. The document specifies a common attachment circuits (ACs) YANG data model, which is designed to be reusable by other models. This design is meant to ensure consistent AC structures among models that manipulate ACs. For example, this common model can be reused by service models to expose ACs as a service, service models that require binding a service to a set of ACs, network and device models to provision ACs, etc. Huawei Technologies Huawei Technologies Ciena Cisco Systems, Inc Cisco Systems, Inc This document defines a YANG data model for RFC 9543 Network Slice Service. The model can be used in the Network Slice Service interface between a customer and a provider that offers RFC 9543 Network Slice Services. This document defines a YANG data model for representing an abstract view of the provider network topology that contains the points from which its services can be attached (e.g., basic connectivity, VPN, network slices). Also, the model can be used to retrieve the points where the services are actually being delivered to customers (including peer networks). This document augments the 'ietf-network' data model defined in RFC 8345 by adding the concept of Service Attachment Points (SAPs). The SAPs are the network reference points to which network services, such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be attached. One or multiple services can be bound to the same SAP. Both User-to-Network Interface (UNI) and Network-to-Network Interface (NNI) are supported in the SAP data model. This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior or during service provisioning (e.g., VPN, Network Slice Service). A companion service model is specified in the YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (I-D.ietf- opsawg-teas-attachment-circuit). The module augments the base network ('ietf-network') and the Service Attachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs). Alef Edge Telefonica Nokia Futurewei Huawei An RFC 9543 network slice customer may utilize intent-based topologies to express resource reservation intentions within the provider's network. These customer-defined intent topologies allow customers to request shared resources for future connections that can be flexibly allocated and customized. Additionally, they provide an extensive level of control over underlay service paths within the network slice. This document describes a YANG data model for expressing customer intent topologies which can be used to enhance the RFC 9543 Network Slice Services in specific use cases, such as Network wholesale scenarios, where both topology and connectivity intents need to be expressed. A Virtual Network (VN) is a network provided by a service provider to a customer for the customer to use in any way it wants as though it were a physical network. This document provides a YANG data model generally applicable to any mode of VN operations. This includes VN operations as per the Abstraction and Control of TE Networks (ACTN) framework (RFC 8453). Huawei Technologies Huawei Technologies Juniper Networks Cisco Systems ZTE Corporation RFC 9543 describes a framework for Network Slices in networks built from IETF technologies. In this framework, the network resource partition (NRP) is introduced as a collection of network resources allocated from the underlay network to carry a specific set of Network Slice Service traffic and meet specific Service Level Objective (SLO) and Service Level Expectation (SLE) characteristics. This document defines YANG data models for Network Resource Partitions (NRPs), applicable to devices and network controllers. The models can be used, in particular, for the realization of the RFC9543 Network Slice Services in IP/MPLS and Segment Routing (SR) networks. Huawei Huawei Technologies This document provides a YANG data model to map IETF network slice service to Traffic Engineering (TE) models (e.g., the Virtual Network (VN) model or the TE Tunnel, etc). It also supports mapping to the VPN Network models and Network Resource Partition (NRP) models. These models are referred to as the IETF network slice service mapping model and are applicable generically for the seamless control and management of the IETF network slice service with underlying TE/ VPN support. The models are principally used for monitoring and diagnostics of the management systems to show how the IETF network slice service requests are mapped onto underlying network resources and TE/VPN models. Samsung Electronics Huawei Huawei Huawei Cisco Nvidia This document provides a YANG data model to map customer service models (e.g., L3VPN Service Delivery model) to Traffic Engineering (TE) models (e.g., the TE Tunnel or the Virtual Network (VN) model). These models are referred to as the TE Service Mapping Model and are applicable generically to the operator's need for seamless control and management of their VPN services with underlying TE support. The models are principally used for monitoring and diagnostics of the management systems to show how the service requests are mapped onto underlying network resources and TE models. This document specifies a mechanism referred to as "Intent-Driven Service Mapping". The mechanism uses BGP to express Intent-based association of overlay routes with underlay routes having specific Traffic Engineering (TE) characteristics satisfying a certain Service Level Agreement (SLA). This is achieved by defining new constructs to group underlay routes with sufficiently similar TE characteristics into identifiable classes (called "Transport Classes" or "TCs"), that overlay routes use as an ordered set to resolve reachability (Resolution Schemes) towards service endpoints. These constructs can be used, for example, to realize the "IETF Network Slice" defined in the TEAS Network Slices framework (RFC 9543). Additionally, this document specifies protocol procedures for BGP that enable dissemination of service mapping information in a network that may span multiple cooperating administrative domains. These domains may be administered either by the same provider or by closely coordinating providers. A new BGP address family that leverages the procedures described in RFC 4364 ("BGP/MPLS IP Virtual Private Networks (VPNs)") and follows the NLRI encoding described in RFC 8277 ("Using BGP to Bind MPLS Labels to Address Prefixes") is defined to enable each advertised underlay route to be identified by its class. This new address family is called "BGP Classful Transport" (or "BGP CT"). This document describes a BGP-based routing solution to establish end-to-end intent-aware paths across a multi-domain transport network. The transport network can span multiple service provider and customer network domains. The BGP intent-aware paths can be used to steer traffic flows for service routes that need a specific intent. This solution is called BGP Color-Aware Routing (BGP CAR). This document describes the routing framework and BGP extensions to enable intent-aware routing using the BGP CAR solution. The solution defines two new BGP SAFIs (BGP CAR SAFI and BGP VPN CAR SAFI) for IPv4 and IPv6. It also defines an extensible Network Layer Reachability Information (NLRI) model for both SAFIs that allows multiple NLRI types to be defined for different use cases. Each type of NLRI contains key and TLV-based non-key fields for efficient encoding of different per-prefix information. This specification defines two NLRI types: Color-Aware Route NLRI and IP Prefix NLRI. It defines non-key TLV types for the MPLS label stack, SR-MPLS label index, and Segment Routing over IPv6 (SRv6) Segment Identifiers (SIDs). This solution also defines a new Local Color Mapping (LCM) Extended Community. This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels. This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired. Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. Huawei Technologies ZTE Corporation China Telecom China Mobile BGP Flow Specification (Flowspec) provides a mechanism to distribute traffic Flow Specifications and the forwarding actions to be performed to the specific traffic flows. A set of Flowspec components are defined to specify the matching criteria that can be applied to the packet, and a set of BGP extended communities are defined to encode the actions a routing system can take on a packet which matches the flow specification. An IETF Network Slice enables connectivity between a set of Service Demarcation Points (SDPs) with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. To meet the connectivity and performance requirements of network slice services, network slice service traffic may need to be mapped to a corresponding Network Resource Partition (NRP). The edge nodes of the NRP needs to identify the traffic flows of specific connectivity constructs of network slices, and steer the matched traffic into the corresponding NRP, or a specific path within the corresponding NRP. BGP Flowspec can be used to distribute the matching criteria and the forwarding actions to be performed on network slice service traffic. The existing Flowspec components can be reused for the matching of network slice services flows at the edge of an NRP. New components and traffic action may need to be defined for steering network slice service flows into the corresponding NRP. This document defines the extensions to BGP Flowspec for IETF network slice traffic steering (NS-TS). Juniper Networks Old Dog Consulting Verizon AT&T Future networks that support advanced services, such as those enabled by 5G mobile networks, envision a set of overlay networks each with different performance and scaling properties. These overlays are known as network slices and are realized over a common underlay network. In the context of IETF technologies, they are known as IETF network slices. In order to support IETF network slicing, as well as to offer enhanced VPN services in general, it is necessary to define a mechanism by which specific resources (buffers, queues, scheduling policies, etc.) of specific network topology components (links and/or nodes) of an underlay network can be used by a specific network slice, VPN, or set of VPNs. These collections of resources are known as Network Resource Partitions (NRPs). This document sets out such a mechanism for use of BGP-LS to construct and operate NRPs in Segment Routing networks. ZTE Corporation ZTE Corporation Juniper Networks Juniper Networks This document specifies extensions to the BGP Link-state address- family in order to advertise the information of Network Resource Partition SIDs. An external component (e.g., a controller) then can collect Network Resource Partition SIDs in the "northbound" direction. The draft is applicable to both SR-MPLS and SRv6 dataplanes. Huawei Technologies Huawei Technologies China Mobile A Network Resource Partition (NRP) is a subset of the network resources and the associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services or RFC 9543 network slice services. For the instantiation of an NRP, NRP- specific information and policy need to be advertised to the network nodes involved in the NRP, so that the NRP-specific state can be created and NRP-specific behavior can be enabled. The mechanism for instantiating NRPs on the involved network elements is called NRP Policy. This document specifies the BGP extensions for advertising NRP Policy information to the set of network nodes involved in the NRP. The NRP Policy is advertised using a separate BGP Subsequent Address Family Identifier (SAFI) of the BGP Link-State (BGP-LS) Address Family, which allows to reuse the TLVs defined in BGP-LS without impacting the base BGP and BGP-LS functionality. Huawei Technologies China Telecom China Telecom China Mobile Huawei Technologies Huawei Technologies Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements on connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. The NRP-specific resource information and status needs to be collected from network nodes and reported to the network controller for NRP-specific management and path computation. This document specifies the BGP Link-State (BGP-LS) mechanisms with necessary extensions to advertise the information of NRPs to network controller in a scalable way. The NRP information is advertised using a separate type of BGP-LS NLRI, which allows flexible update of NRP information without impacting the based link state information. Huawei Technologies Huawei Technologies China Unicom Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. A Network Resource Partition (NRP) is a subset of network resources allocated in the underlay network which can be used to support one or a group of RFC 9543 network slice services. In networks where there are multiple NRPs, an SR Policy may be associated with a particular NRP. The association between SR Policy and NRP needs to be specified, so that for service traffic which is steered into the SR Policy, the header of the packets can be augmented with the information associated with the NRP. An SR Policy candidate path can be distributed using BGP SR Policy. This document defines the extensions to BGP SR policy to specify the NRP which the SR Policy candidate path is associated with. ZTE ZTE This document defines extensions to BGP in order to advertise Network Resource Partition (NRP) in SR policy. ZTE Corporation Huawei ZTE Corporation China mobile China Telecom China Unicom A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP ID is an important network resource attribute associated with the Segment Routing (SR) policy and needs to be reported to the external components. This document defines a new TLV which enables the headend to report the NRP which the SR Policy Candidate Path (CP) is associated with using Border Gateway Protocol Link-State (BGP-LS). Huawei Technologies Huawei Technologies ZTE Corporation ZTE Corporation China Mobile China Mobile Juniper Networks Cisco Systems This document specifies the extensions to Path Computation Element Communication Protocol (PCEP) to carry Network Resource Partition (NRP) related information in the PCEP messages. The extensions in this document can be used to indicate the NRP-specific constraints and information needed in path computation, path status report and path initialization. China Telecom China Telecom Huawei Technologies Huawei Technologies Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements for connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. In some network scenarios, each NRP can be associated with a unique logical network topology. This document describes a mechanism to build the SR-based NRPs using IS-IS Multi-Topology together with other well-defined IS-IS extensions. China Telecom China Telecom Huawei Technologies Huawei Technologies When Segment Routing (SR) is used for building Network Resource Partitions (NRPs), each NRP can be allocated with a group of Segment Identifiers (SIDs) to identify the topology and resource attributes of network segments in the NRP. This document describes how BGP-Link State (BGP-LS) with Multi-Topology (MT) can be used to distribute the information of SR-based NRPs to a network controller in a specific context where each NRP is associated with a separate logical topology identified by a Multi-Topology ID (MT-ID). This document sets out the targeted scenarios for the approach suggested, and presents the scalability limitations that arise. Orange Cisco Systems, Inc. Nokia Juniper Networks Juniper Networks Verizon This document updates [RFC6790] to extend the use of the TTL field of the Entropy Label in order to provide a flexible set of flags called the Entropy Label Control field. This document also defines a solution to encode a slice identifier in MPLS in order to distinguish packets that belong to different slices, to allow enforcing per network slice policies (.e.g, Qos). The slice identification is independent of the topology. It allows for QoS/DiffServ policy on a per slice basis in addition to the per packet QoS/DiffServ policy provided by the MPLS Traffic Class field. In order to minimize the size of the MPLS stack and to ease incremental deployment the slice identifier is encoded as part of the Entropy Label. Cisco Systems, Inc. Cisco Systems, Inc. Cisco Systems, Inc. Cisco Systems, Inc. Bell Canada Ciena This document defines a stateless and scalable solution to achieve network slicing with SRv6. China Mobile China Telecom China Unicom New H3C Technologies China Mobile Broadcom CentecNetworks Ruijie Networks Co., Ltd. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding in a specific NRP, some fields in the data packet are used to identify the NRP the packet belongs to, so that NRP-specific processing can be performed on each node along a path in the NRP. This document describes a novel method to encode NRP-ID in the outer IPv6 header of an SRv6 domain, which could be used to identify the NRP-specific processing to be performed on the packets by each network node along a network path in the NRP. Huawei Technologies Huawei Technologies China Telecom China Telecom Verizon Inc. Virtual Private Networks (VPNs) provide different customers with logically separated connectivity over a common network infrastructure. With the introduction of 5G and also in some existing network scenarios, some customers may require network connectivity services with advanced features comparing to conventional VPN services. Such kind of network service is called enhanced VPNs. Enhanced VPNs can be used, for example, to deliver network slice services. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP may be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding within a specific NRP, some fields in the data packet (which is called NRP Selector) need to be used to identify the NRP to which the packet belongs. In doing so, NRP-specific processing can be performed on each node along the forwarding path in the NRP. This document specifies a new IPv6 Hop-by-Hop option to carry Network Resource related information (e.g., identifier) in data packets. The NR Option can be used to carry NRP Selector ID and related information, while it is designed to make the NR option generalized for other network resource semantics and functions. Huawei Technologies KDDI Corporation China Telecom China Mobile China Mobile This document describes a mechanism to allocate network resources to one or a set of Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs. The resource-aware SIDs retain their original forwarding semantics, with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). Huawei Technologies KDDI Corporation China Telecom China Mobile China Mobile Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements on connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment is referred to by its Segment Identifier (SID). SIDs can represent topological or service based instructions. SIDs can further be associated with a set of network resources used for executing the instruction. Such SIDs are called resource-aware SIDs. A group of resource-aware SIDs may be used to build SR based NRPs, which provide customized network topology and resource attributes required by one or a group of enhanced VPN services. This document describes an approach to build SR based NRPs using resource-aware SIDs. The SR based NRP can be used to deliver enhanced VPN services in SR networks. China Mobile New H3C Technologies New H3C Technologies China Mobile This document proposes a method to carry the NRP-ID with the packet in the SRv6 segment. Juniper Networks Juniper Networks Cisco Systems Broadcom An IETF Network Slice service provides connectivity coupled with a set of network resource commitments and is expressed in terms of one or more connectivity constructs. A Network Resource Partition (NRP) is a collection of resources identified in the underlay network to support IETF Network Slice services. A Slice-Flow Aggregate refers to the set of traffic streams from one or more connectivity constructs belonging to one or more IETF Network Slices that are mapped to a specific NRP and provided the same forwarding treatment. The packets associated with a Slice-Flow Aggregate may carry a marking in the packet's network layer header to identify this association and this marking is referred to as NRP Selector. The NRP Selector is used to map the packet to the associated NRP and provide the corresponding forwarding treatment to the packet. MPLS Network Actions (MNA) technologies are used to indicate actions for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for these actions. This document discusses options for using MPLS Network Actions (MNAs) to carry the NRP Selector in MPLS packets. China Mobile New H3C Technologies This document introduces a new flavor type for SRv6 called "Flavor NRP". It associates the SRv6 End.X SID with a set of network resource partitions (referred to as NRP resources). By using the End.X SID with the NRP flavor type, SRv6 policies can provide programmability for network resources. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. ZTE ZTE [RFC8287] defines the extensions to MPLS LSP ping and traceroute for Segment Routing IGP-Prefix and IGP-Adjacency SIDs with an MPLS data plane. To correctly identify and validate an SR NRP SID, the validating device also requires NRP-ID to be supplied in the FEC Stack sub-TLV. This document introduces new Target FEC Stack sub- TLVs to perform MPLS LSP ping and traceroute for NRP SIDs. This document defines a set of metrics for networking services with performance requirements expressed as Service Level Objectives (SLOs). These metrics, referred to as "Precision Availability Metrics (PAMs)", are useful for defining and monitoring SLOs. For example, PAMs can be used by providers and/or customers of an RFC 9543 Network Slice Service to assess whether the service is provided in compliance with its defined SLOs. Futurewei Orange Ericsson This document defines a set of IP Flow Information Export (IPFIX) Information Elements to export precision availability data associated with Flows, specifically Flows that are associated with stringent Service Level Objectives (SLOs) such as latency or packet delay variation. ZTE This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify the Network Resource Partition (NRP) that the network slice traffic is related with. Telefonica Universitat Politecnica de Catalunya Universitat Politecnica de Catalunya ZTE Corporation The Path Computation Element (PCE) is able of determining paths according to constraints expressed in the form of metrics. The value of the metric can be signaled as a bound or maximum, meaning that path metric must be less than or equal such value. While this can be sufficient for certain services, some others can require the utilization of Precision Availability Metrics (PAM). This document defines a new object, namely the PRECISION METRIC object, to be used for path calculation or selection for networking services with performance requirements expressed as Service Level Objectives (SLO) using PAM. Huawei Technologies Huawei Technologies China Mobile China Telecom Verizon Inc. A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC 9543 describes a framework for network slices built using networks that use IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a set of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. As the demand for network slices increases, scalability becomes an important factor. Although the scalability of network slices can be improved by mapping a group of network slices to a single NRP, that design may not be suitable or possible for all deployments, thus there are concerns about the scalability of NRPs themselves. This document discusses some considerations for NRP scalability in the control and data planes. It also investigates a set of optimization mechanisms. China Telecom China Telecom China Mobile Hong Kong China Mobile Hong Kong Huawei Technologies China Unicom Algeria Telecom Network Slicing is considered as an important approach to provide different services and customers with the required network connectivity, network resources and performance characteristics over a shared network. Operators have started the deployment of network slices in their networks for different purposes. This document introduces several deployment cases of IETF network slices in operator networks. Some considerations collected from these IETF network slice deployments are also provided.

Acknowledgments Thanks to Kaliraj Vairavakkalai for the comments.