]> 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.

Future versions of this document many include recommendations.

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. provides a clear distinction between:

• the "IETF 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 "IETF 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 IETF 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 IETF Network Slice service. Such a customization can be achieved by creating a set of Network Resource Partitions (NRPs). In other deployments, IETF Network Slices can be hosted directly on the underlay network (i.e., without requiring any NRP). IETF 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 IETF 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 IETF 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 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 IETF 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 IETF 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 IETF 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 IETF Network Slice services in service provider networks using available data models. In particular, this document describes the relationship between service models for managing the IETF 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 IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision.

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

Applicability and Mapping Scenarios

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

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

DetNet describes the applicability of DetNet to IETF 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 IETF 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 IETF Network Slices services are being delivered. It can also be used to check where IETF 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 IETF Network Slice Topology. The need for such a model is yet to be justified as the current scope is redundant with what can be already achieved using the SAP model ().

NRP specifies a YANG data model for managing NRPs.

Network Slice Mapping specifies an IETF 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.

NRP

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.

NRP

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 for SLO-Governed End-to-End Services 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.

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 IETF Network Slice services that would require NRPs. Such an increase of slices is speculative at this stage.

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" 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 IBM Corporation 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 Network Slicing (NS) is an integral part of Service Provider networks. The IETF has produced several YANG data models to support the Software-Defined Networking and network slice architecture and YANG- based service models for network slice (NS) instantiation. This document describes the relationship between IETF Network Slice models for requesting the IETF Network Slices and (e.g., Layer-3 Service Model, Layer-2 Service Model) and Network Models (e.g., Layer-3 Network Model, Layer-2 Network Model) used during their realizations. In addition, this document describes the communication between the IETF Network Slice Controller and the network controllers for the realization of IETF network slices. The IETF Network Slice YANG model provides the customer-oriented view of the network slice. Thus, once the IETF Network Slice controller (NSC) receives a request, it needs to map it to accomplish the specific parameters expected by the network controllers. The network models are analyzed to satisfy the IETF Network Slice requirements, and the gaps in existing models are reported. The document also provides operational and security considerations when deploying network slices in Service Provider networks. 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 slice 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 defined. 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 in 5G, which provides different network service as independent logical networks. To provide 5G network slices service, an end-to-end network slice needs to consists of 3 major types of network segments: Radio Access Network (RAN), Mobile Core Network (CN) and Transport Network (TN). This document describes the application of IETF network slice in providing 5G end-to-end network slices, including the network slice identification mapping, network slice parameter mapping and 5G IETF Network Slice NBI. 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 prior or during service provisioning (e.g., Network Slice Service). The document specifies also 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 a service model reuses structures defined in the AC models or simply include an AC reference is a design choice of these service models. Relying upon the AC service model to manage ACs over which a service is delivered has the merit to decorrelate the management of a service vs. upgrade the AC components to reflect 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 Slices. Orange Telefonica Nokia Huawei Nokia 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). IBM Corporation Microsoft Individual Telefonica Huawei Nokia Ciena Futurewei Huawei An IETF network slice may use an abstract topology to describe intended underlay for connectivities between slice endpoints. Abstract topologies help the customer to request network slices with shared resources amongst connections, and connections can be activated within the slice as needed. This document describes a YANG data model for managing and controlling abstract 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. Huawei Technologies Huawei Technologies Juniper Networks Cisco Systems ZTE Corporation 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. Huawei Technologies 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 Technologies Huawei Technologies Huawei Technologies Ericsson Microsoft 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 sufficienty similar TE characteristics into identifiable classes (Transport Class), that overlay routes use as an ordered set to resolve reachability (Resolution Scheme) towards service endpoints. These constructs can be used to realize the "IETF Network Slice" defined in TEAS Network Slices framework. This document specifies protocol procedures for BGP that enable dissemination of such 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). In certain situations, transporting a packet from one Border Gateway Protocol (BGP) speaker to another (the BGP next hop) requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the "encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header. The encapsulation information need not be signaled for all encapsulation types. In cases where signaling is required (such as Layer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic Routing Encapsulation (GRE) with key), this document specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using the Encapsulation Subsequent Address Family Identifier (SAFI) and the IPv4 or IPv6 Address Family Identifier (AFI). In cases where no encapsulation information needs to be signaled (such as GRE without key), this document specifies a BGP extended community that can be attached to BGP UPDATE messages that carry payload prefixes in order to indicate the encapsulation protocol type to be used. [STANDARDS-TRACK] 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 needs to be mapped to a corresponding Network Resource Partition (NRP). The edge nodes of the NRP needs to identify the traffic flows which belong to a network slice 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 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 which consists of a subset of network resources allocated on network nodes and links in a customized topology of the 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 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 other network scenarios, some existing or new customers may require connectivity services with advanced characteristics comparing to traditional VPNs. Such kind of network service is called enhanced VPNs (VPN+). VPN+ can be used to deliver IETF network slices, and could also be used for other application scenarios. A Virtual Transport Network (VTN) is a virtual underlay network which consists of a set of dedicated or shared network resources allocated from the physical underlay network, and is associated with a customized logical network topology. VPN+ services can be delivered by mapping one or a group of overlay VPNs to the appropriate VTNs as the virtual underlay. In packet forwarding, some fields in the data packet needs to be used to identify the VTN the packet belongs to, so that VTN-specific processing can be performed on each node the packet traverses. This document proposes a new Hop-by-Hop option of IPv6 extension header to carry the VTN related information in data packets, which could used to identify the VTN specific processing to be performed on the packets. The procedure of processing the VTN option is also specified. Huawei Technologies University of Surrey KDDI Corporation China Telecom China Mobile China Mobile Cisco Systems 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 University of Surrey KDDI Corporation China Telecom China Mobile China Mobile Cisco Systems 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. 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 users of a Network Slice service to assess whether the service is provided in compliance with its defined SLOs. 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 Futurewei Technologies Verizon Inc. China Mobile Juniper Networks Juniper Networks The IETF Network Slice aims to offer connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. A Network Resource Partition (NRP) is 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 IETF Network Slice increases, scalability would become an important factor for the deployment of IETF Network Slices. Although the scalability of IETF Network Slices can be improved by mapping a group of IETF Network Slices to one NRP, that design may not be suitable or possible for all deployments, thus there are concerns about the scalability of NRPs. This document discusses some scalability considerations about NRPs in the network control and data plane. It also investigates a set of optimization mechanisms.

Acknowledgments Thanks to Kaliraj Vairavakkalai for the comments.