]> 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 XXXX Network Slice" (where XXXX is the number assigned to when published as an RFC"). provides a clear distinction between:

• the "RFC XXXX 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 XXXX 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 XXXX 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 XXXX Network Slice Service. Such a customization can be achieved by creating a set of Network Resource Partitions (NRPs). In other deployments, RFC XXXX Network Slices can be hosted directly on the underlay network (i.e., without requiring any NRP). RFC XXXX 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 XXXX 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 XXXX 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 XXXX 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 XXXX 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 XXXX 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 XXXX 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 XXXX Network Slice Controller as well as how to use different data models being defined for RFC XXXX Network Slice Service provision.

SR-based Hierarchical Network Slices proposes a hierarchical approach for realizing RFC XXXX 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 XXXX Network Slices (that basically involve other slices). The document defines a new identifier, called Inter-domain NRP ID.

Applicability and Mapping Scenarios

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

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 draft 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 XXXX 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 XXXX Network Slice segments that is listed in .

DetNet describes the applicability of DetNet to RFC XXXX 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 XXXX 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 XXXX Network Slices services are being delivered. It can also be used to check where RFC XXXX 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 XXXX 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 XXXX 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 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.

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

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.

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 XXXX 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 Old Dog Consulting Juniper Networks Ciena NTT Futurewei Telefonica Nvidia 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 how abstract requests can be mapped 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. Juniper Networks Juniper Networks Juniper Networks Orange Telefonica 5G slicing is a feature that was introduced by the 3rd Generation Partnership Project (3GPP) in mobile networks. This feature covers slicing requirements for all mobile domains, including the Radio Access Network (RAN), Core Network (CN), and Transport Network (TN). This document describes a basic IETF Network Slice realization model in IP/MPLS networks with a focus on the Transport Network fulfilling 5G slicing connectivity requirements. This realization model reuses many building blocks currently commonly used in service provider networks. Cisco Systems Inc. Juniper Networks Huawei Technologies Comcast Cisco Systems Inc. Ericsson ZTE Corporation ZTE Corporation IBM Corporation Telefonica Ciena Verizon 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 relying on compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) on to packets that carry identifiers that indicate the slicing service that is to be applied to the packets. 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. Huawei University of Surrey China Mobile KDDI Corporation Samsung This document describes the framework for Enhanced Virtual Private Network (VPN+) to support the needs of applications with specific traffic performance requirements (e.g., low latency, bounded jitter). VPN+ leverages the VPN and Traffic Engineering (TE) technologies and adds characteristics that specific services require beyond those provided by conventional VPNs. Typically, VPN+ will be used to underpin network slicing, but 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 Ciena Telefonica Old Dog Consulting Orange This document exemplifies how the various data modules that are produced in the IETF can be combined in the context of IETF Network Slice Services delivery. Specifically, this document describes the relationship between the IETF Network Slice Service models for requesting IETF Network Slice Services and both Service (e.g., the Layer-3 Service Model, the Layer-2 Service Model) and Network (e.g., the Layer-3 Network Model, the Layer-2 Network Model) models used during their realizations. In addition, this document describes the communication between an IETF Network Slice Controller (NSC) and the network controllers for the realization of IETF Network Slices. The IETF 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 the IETF 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 Microsoft Huawei IBM Corporation Huawei Nokia This document describes a potential division in major functional components of an IETF Network Slice Controller (NSC) as well as references the data models required for supporting the requests of IETF network slice services and their realization. This document describes a potential way of 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 Network slicing can be used to meet the connectivity and performance requirement of different applications or customers in a shared network. An IETF network slice may be used for 5G or other network scenarios. 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 IETF network slices. In some scenarios, IETF network slices may span multiple network domains, and IETF network slices may be composed hierarchically, which means a network slice may itself be further sliced. This document first describes the possible use cases of composite IETF network slices, then it provides considerations about the realization of composite IETF network slices. For the interaction between IETF network slices with 5G network slices, the identifiers of the 5G network slices may be introduced into IETF networks. For the multi-domain IETF network slices, the Inter-Domain Network Resource Partition Identifier (Inter-domain NRP ID) is introduced. For the hierarchical IETF network slices, the structure of the NRP ID is discussed. 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 IETF network slices. This document also describes the management considerations of composite network slices. 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 slices have 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 management plane, control plane and data plane. 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-existed encryption of packet payload posts 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 Juniper Networks 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 Rakuten Symphony Microsoft Nokia Network slicing in 5G supports 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 services, user's data plane packets over the radio access network (RAN) and mobile core network (5GC) use IP transport in many segments of the end-to-end 5G slice. When end-to- end slices in a 5G system use IP network resources, they are mapped to corresponding IP transport network slice(s) which in turn provide the bandwidth, latency, isolation and other criteria requested by the 5G slice. This document describes mapping of 5G slices to IP or Layer 2 transport network slices when the IP transport network (slice provider) is separated from the networks in which the 5G network functions are deployed, for example, 5G functions that are distributed across data centers. The slice mapping proposed here is supported transparently when a 5G user device moves across 5G attachment points and session anchors. 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. Orange Juniper Telefonica Nokia Huawei Technologies The document specifies a common Attachment Circuits (ACs) YANG module, which is designed with the intent to be reusable by other models. 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. Orange Juniper Telefonica Nokia Huawei Technologies This document specifies a YANG service data model for Attachment Circuits (ACs). This model can be used for the provisioning of ACs before or during service provisioning (e.g., Network Slice Service). The document also specifies a module that updates other service and network modules with the required information to bind specific services to ACs that are created using the AC service model. Also, the document specifies a set of reusable groupings. Whether other service models reuse structures defined in the AC models or simply include an AC reference is a design choice of these service models. Utilizing the AC service model to manage ACs over which a service is delivered has the advantage of decoupling service management from upgrading AC components to incorporate recent AC technologies or features. Huawei Technologies Huawei Technologies Ciena Cisco Systems, Inc China Mobile Cisco Systems, Inc This document defines a YANG data model for the IETF Network Slice Service. The model can be used in the IETF Network Slice Service interface between a customer and a provider that offers IETF 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. Orange Juniper Telefonica Nokia Huawei Technologies 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., Network Slice Service). A companion service model is specified in [I-D.boro-opsawg-teas-attachment-circuit]. The module augments the Service Attachment Point (SAP) model with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs). Alef Edge Microsoft Individual Telefonica Huawei Nokia Ciena Futurewei Huawei An IETF network slice may use a customized topology to describe intended resource reservation for connectivities between slice endpoints. Customized topologies enable customers to request shared resources among connections activated on demand and to customize the service paths in a network slice with an extensive level of control. This document describes a YANG data model for managing and controlling customized topologies for IETF network slices defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-ietf-network-slices once it has been published. Samsung Electronics Huawei Cisco Individual ETRI 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. This document provides a YANG data model generally applicable to any mode of VN operations. This includes VN operations as per Abstraction and Control of TE Networks (ACTN) framework. Huawei Technologies Huawei Technologies Juniper Networks Cisco Systems ZTE Corporation A Network Resource Partition (NRP) is a collection of resources identified in the underlay network to support services (like IETF Network Slices) that need logical network structures with required Service Level Objective (SLO) and Service Level Expectation (SLE) characteristics to be created. This document defines a YANG data model for Network Resource Partitions (NRPs). The model can be used, in particular, for the realization of the IETF Network Slice Services in IP/MPLS 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 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 resource and TE/VPN models. Samsung Electronics Huawei Huawei Technologies Huawei Technologies 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 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 resource and TE models. Juniper Networks, Inc. Juniper Networks, Inc. This document specifies a mechanism, referred to as "Intent Driven Service Mapping", that uses BGP to express intent based association of overlay routes, with underlay routes having specific Traffic Engineering (TE) characteristics, that satisfy a certain Service Level Agreement (SLA). The document achieves this by defining new constructs, to group underlay routes with sufficiently similar TE characteristics into identifiable classes (called, Transport Classes), that overlay routes use as an ordered set to resolve reachability (Resolution Schemes) towards service endpoints. These constructs can be used, e.g., to realize the "IETF Network Slice" defined in TEAS Network Slices framework. 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 RFC 4364 procedures and follows RFC 8277 NLRI encoding, is defined to advertise underlay routes with its identified class. This new address family is called "BGP Classful Transport", a.k.a., BGP CT. Cisco Systems Cisco Systems This document describes a BGP based routing solution to establish end-to-end intent-aware paths across a multi-domain service provider transport network. This solution is called BGP Color-Aware Routing (BGP CAR). 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 preformed 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. 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 IETF 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 ZTE Corporation China mobile China Telecom This document defines a new TLV which enable the headed to report the configuration and the states of SR policies carrying NRP information by using 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 VPN (VPN+) aims to provide enhanced VPN service to support some existing and emerging application's needs of enhanced isolation and stringent performance requirements. VPN+ requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Virtual Transport Network (VTN) is a virtual underlay network that is associated with a network topology, and is allocated with a set of dedicated or shared resources from the underlay physical network. A VTN could be used as the underlay to support one or a group of VPN+ services. In some network scenarios, each VTN can be associated with a unique logical network topology. This document describes a mechanism to build the SR based VTNs using IS-IS Multi-Topology together with other well-defined IS-IS extensions. China Telecom China Telecom Huawei Technologies Huawei Technologies Enhanced VPN (VPN+) aims to provide enhanced VPN service to support some applications' needs of enhanced isolation and stringent performance requirements. VPN+ requires integration between the overlay VPN and the underlay network. A Virtual Transport Network (VTN) is a virtual underlay network which consists of a subset of the network topology and network resources allocated from the physical network. A VTN could be used as the underlay for one or a group of VPN+ services. When Segment Routing is used as the data plane of VTNs, each VTN can be allocated with a group of Segment Identifiers (SIDs) to identify the topology and resource attributes of network segments in the VTN. The association between the network topology, the network resource attributes and the SR SIDs may need to be distributed to a centralized network controller. In network scenarios where each VTN can be associated with a unique logical network topology, this document describes a mechanism to distribute the information of SR based VTNs using BGP-LS with Multi-Topology. 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. This document describes a method to encode network slicing identifier within SRv6 domain. 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 and evolvement 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 (VPN+). VPN+ can be used, for example, to deliver IETF network slice services. A VTN is a virtual underlay network that is associated with a network topology, and is allocated with a set of dedicated or shared resources from the underlay physical network. VPN+ services can be delivered by mapping one or a group of overlay VPNs to the appropriate VTNs as the virtual underlay. For packet forwarding in a specific VTN, some fields in the data packet are used to identify the VTN the packet belongs to, so that VTN-specific processing can be performed on each node along a VTN-specific path. This document specifies a new IPv6 Hop-by-Hop option to carry the VTN related information in data packets, which could be used to identify the VTN-specific processing to be performed on the packets by each network node along a VTN-specific path. Huawei Technologies KDDI Corporation China Telecom China Mobile China Mobile This document describes the mechanism to associate network resources to Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs in this document. The resource-aware SIDs retain their original forwarding semantics, but with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. The resource-aware SIDs can therefore be used to build SR paths or virtual networks with a set of reserved network resources. 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 Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent topological or service based instructions. A segment can further be associated with a set of network resources used for executing the instruction. Such a segment is called resource-aware segment. A Virtual Transport Network (VTN) is a virtual underlay network which is associated with a network topology, and is allocated with a set of dedicated or shared resources from the underlay physical network. Resource-aware Segment Identifiers (SIDs) may be used to build SR paths with a set of reserved network resources. In addition, a group of resource-aware SIDs may be used to build SR based virtual underlay networks, which provide customized network topology and resource attributes required by one or a group of customers and/or services. Such virtual underlay networks are the SR instantiations of VTNs. This document describes a suggested approach to build SR based VTNs using resource-aware SIDs. The SR based VTNs can be used to deliver RFC XXXX network slices 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 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. 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. Ericsson Ericsson ZTE Corp. Futurewei Futurewei Inria and University of Luxembourg This document defines a set of metrics for networking services with performance requirements expressed as Service Level Objectives (SLO). These metrics, referred to as Precision Availability Metrics (PAM), are useful for defining and monitoring SLOs. For example, PAM can be used by providers and/or customers of an RFC XXXX Network Slice Service to assess whether the service is provided in compliance with its defined SLOs. Note to the RFC Editor: Please update "RFC XXXX Network Slice" with the RFC number assigned to draft-ietf-teas-ietf-network-slices. 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. Huawei Technologies Huawei Technologies China Mobile China Telecom Verizon Inc. China Mobile 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 XXXX 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.