]> Huawei

IN dhruv.ietf@gmail.com

Huawei Technologies

101 Software Avenue, Yuhua District Nanjing 210012 CN lana.wubo@huawei.com

Routing TEAS Working Group This document provides a YANG data model to map IETF network slice service to Traffic Engineering (TE) models (e.g., the Virtual Network (VN) model or the TE Tunnel, etc). It also supports mapping to the VPN Network models and Network Resource Partition (NRP) models. These models are referred to as the IETF network slice service mapping model and are applicable generically for the seamless control and management of the IETF network slice service with underlying TE/VPN support. The models are principally used for monitoring and diagnostics of the management systems to show how the IETF network slice service requests are mapped onto underlying network resources and TE/VPN models.

Introduction Data models are a representation of objects that can be configured or monitored within a system. Within the IETF, YANG is the language of choice for documenting data models, and YANG models have been produced to allow the configuration or modeling of a variety of network devices, protocol instances, and network services. The YANG model discussed in this document augments the IETF Network Slice Service YANG model , which is used to operate IETF Network Slices during the IETF Network Slice instantiation. This provides a way to map IETF network slice service to Traffic Engineering (TE) models (e.g., the Virtual Network (VN) model or the TE Tunnel, etc). Alternatively, it also supports mapping to the VPN Network models and Network Resource Partition (NRP) models. The model supports:

• A mapping of the IETF Network Slice with the Network Resource Partition (NRP). As per , NRP is a collection of resources (bufferage, queuing, scheduling, etc.) in the underlay network. The NRP YANG model is specified in . The IETF Network Slice can be mapped to the NRP directly.
• A mapping of the IETF Network Slice with the VPN network models - LxNM. This mapping can be populated at the time of IETF network service realization. This mapping information is internal and used for monitoring and diagnostics purposes such as telemetry, auto-scaling, and closed-loop automation. Note that the LxNM may further map to other TE resources as specified in . Optionally, a mapping to the NRP can also be populated.
• A mapping of the IETF Network Slice with the underlying TE resources directly. The TE resources could be in a form of VN, set of TE tunnels, TE abstract topology, etc. This mapping can be populated by the network at the time of realization of the IETF network slice service. It is also possible to configure the mapping provided one is aware of NRP/VN/tunnels. This mapping mode is used only when there is an awareness of VN or TE by the consumer of the model. Otherwise, this mapping information is internal and used for monitoring and diagnostics purposes such as telemetry, auto-scaling, and closed-loop automation.
• Possibility to request the creation of a new VN/Tunnel to be bound to IETF network slice.
• Indication to share the VN/Tunnel sharing (with or without modification) for the IETF network slice.
• Support for configuration of underlying TE properties (as opposed to existing VN or tunnels).

Note: The RFC Editor will replace XXXX with the number assigned to the RFC once this draft becomes an RFC.

Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Tree Diagrams A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is defined in .

Prefixes in Data Node Names In this document, names of data nodes and other data model objects are often used without a prefix, as long as it is clear from the context in which the YANG module each name is defined. Otherwise, names are prefixed using the standard prefix associated with the corresponding YANG module, as shown in Table 1.

Prefix	YANG module	Reference
nw	ietf-network
tsmt	ietf-te-service-mapping-types
l3vpn-ntw	ietf-l3vpn-ntw
l2vpn-ntw	ietf-l2vpn-ntw
ietf-ns	ietf-network-slice
nrp	ietf-nrp

References in the Model The following additional documents are referenced in the model defined in this document -

Document	Reference
Framework for IETF Network Slices

Model Design The YANG model specified in this document augments the IETF network slice service YANG model . Currently, the following mapping are supported:

• L3NM: The L3 network model (L3NM) describes a L3VPN Service in the Service Provider Network. It contains information on the Service Provider network and might include allocated resources. It can be used by network controllers to manage and control the L3VPN Service configuration in the Service Provider network. This model maps an IETF network slice to a L3VPN ID.
• L2NM: The L2 network model (L2NM) describes a L2VPN Service in the Service Provider Network. It contains information on the Service Provider network and might include allocated resources. It can be used by network controllers to manage and control the L2VPN Service configuration in the Service Provider network. This model maps an IETF network slice to a L2VPN ID.
• TE: The TE mapping is specified in . The mapping can be done to the following TE resources:
  • Virtual Networks (VN)
  • TE-Tunnels
  • TE-Topology
• NRP: defines IETF network slice services that provide connectivity coupled with network resources commitment between a number of endpoints over a shared network infrastructure and, for scalability concerns, defines NRP to host one or a group of network slice services according to characteristics including SLOs and SLEs. Along with mapping to VPN, this model maps an IETF network slice to an NRP ID.

Attachment Circuits (ACs) are defined in as the logical constructs that connect customer edges (CEs) to provider edges (PEs) and carry customer traffic into a RFC 9543 Network Slice Service. The YANG model in already includes a mapping to AC.

Open Questions The following open questions need to be addressed in a future revision:

• Is there a need/use-case to map the IETF Network slice Connection Group and/or Connectivity Construct as well?
• Is there a need/use-case to map IETF Network slice Service Demarcation Points (SDPs)?
• Is there a need to indicate "map-type" (new, share) for NRP and VPNs?

Tree Structure /nw:networks/nrp:nrp-policies/nrp-policy/name +--:(l3vpn) | +--rw l3vpn-id? leafref | +--rw l3vpn-nrp? | -> /nw:networks/nrp:nrp-policies/nrp-policy/name +--:(l2vpn) | +--rw l2vpn-id? leafref | +--rw l2vpn-nrp? | -> /nw:networks/nrp:nrp-policies/nrp-policy/name +--:(te) +--rw type? identityref +--rw te-policy | +--rw path-affinities-values | | +--rw path-affinities-value* [usage] | | ... | +--rw path-affinity-names | | +--rw path-affinity-name* [usage] | | ... | +--rw protection-type? identityref | +--rw availability-type? identityref +--rw (te)? | +--:(vn) | | +--rw vn* | | -> /vn:virtual-network/vn/id | +--:(te-topo) | | +--rw te-topology-identifier | | | ... | | +--rw abstract-node? | | -> /nw:networks/network/node/node-id | +--:(te-tunnel) | +--rw te-tunnel* te:tunnel-ref | +--rw sr-policy* [headend color-ref endpoint-ref] | {sr-policy}? | ... +--rw template-ref? leafref {template}? ]]>

YANG Model file "ietf-network-slice-mapping@2025-10-13.yang" module ietf-network-slice-mapping { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-network-slice-mapping"; prefix ietf-nsm; import ietf-network { prefix nw; reference "RFC 8345: A YANG Data Model for Network Topologies"; } import ietf-network-slice-service { prefix ietf-nss; reference "I-D.ietf-teas-ietf-network-slice-nbi-yang: A YANG Data Model for the IETF Network Slice Service"; } import ietf-te-service-mapping-types { prefix tsmt; reference "I-D.ietf-teas-te-service-mapping-yang: Traffic Engineering (TE) and Service Mapping YANG Data Model"; } import ietf-l3vpn-ntw { prefix l3vpn-ntw; reference "RFC 9182: A YANG Network Data Model for Layer 3 VPNs"; } import ietf-l2vpn-ntw { prefix l2vpn-ntw; reference "RFC 9291: A Layer 2 VPN Network YANG Model"; } import ietf-nrp { prefix nrp; reference "I-D.ietf-teas-nrp-yang: A YANG Data Model for Network Resource Partitions (NRPs)"; } organization "IETF Traffic Engineering Architecture and Signaling (TEAS) Working Group"; contact "WG Web: WG List: Editor: Dhruv Dhody Bo Wu "; description "This module contains a YANG module to map the IETF Network Slice with Traffic Engineering (TE) or VPN Network models. Copyright (c) 2025 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2025-10-13 { description "initial version."; reference "RFC XXXX: IETF Network Slice Service Mapping YANG Model"; } identity map-to { description "Base identity from which specific map-to are derived."; } identity map-to-nrp { base map-to; description "Map to Network Resource Partition (NRP)"; } identity map-to-vpn { base map-to; description "Map to VPN"; } identity map-to-l3vpn { base map-to-vpn; description "Map to L3VPN"; } identity map-to-l2vpn { base map-to-vpn; description "Map to L2VPN"; } identity map-to-l1vpn { base map-to-vpn; description "Map to L1VPN"; } identity map-to-te { base map-to; description "Map to TE directly"; } grouping ns-mapping { description "Mapping between IETF network slice and Network Resource Partition (NRP)/VPN/TE"; container ns-mapping { description "The container for the mapping"; leaf map-to { type identityref { base map-to; } description "Mapping to NRP/VPN/TE"; } choice map { description "Mapping to NRP/VPN/TE"; case nrp { leaf nrp { type leafref { path "/nw:networks/nrp:nrp-policies" + "/nrp:nrp-policy/nrp:name"; } description "A reference to NRP name"; reference "I-D.ietf-teas-nrp-yang: A YANG Data Model for Network Resource Partitions (NRPs)"; } } case l3vpn { leaf l3vpn-id { type leafref { path "/l3vpn-ntw:l3vpn-ntw" + "/l3vpn-ntw:vpn-services" + "/l3vpn-ntw:vpn-service" + "/l3vpn-ntw:vpn-id"; } description "A reference to VPN ID"; } leaf l3vpn-nrp { type leafref { path "/nw:networks/nrp:nrp-policies" + "/nrp:nrp-policy/nrp:name"; } description "An optional reference to NRP name"; reference "RFC9543: Framework for IETF Network Slices"; } description "Mapping to L3NM"; reference "RFC9182: A YANG Network Data Model for Layer 3 VPNs"; } case l2vpn { leaf l2vpn-id { type leafref { path "/l2vpn-ntw:l2vpn-ntw" + "/l2vpn-ntw:vpn-services" + "/l2vpn-ntw:vpn-service" + "/l2vpn-ntw:vpn-id"; } description "A reference to VPN ID"; } leaf l2vpn-nrp { type leafref { path "/nw:networks/nrp:nrp-policies" + "/nrp:nrp-policy/nrp:name"; } description "An optional reference to NRP"; reference "RFC9543: Framework for IETF Network Slices"; } description "Mapping to L2NM"; reference "RFC 9291: A Layer 2 VPN Network YANG Model"; } case te { uses tsmt:te-mapping; description "Mapping to TE directly"; reference "I-D.ietf-teas-te-service-mapping-yang: Traffic Engineering (TE) and Service Mapping YANG Model"; } } } } augment "/ietf-nss:network-slice-services/ietf-nss:slice-service" { description "IETF Network Slice augmented to include the mapping information to the network slice realization"; container mapping { presence "Indicates Mapping information"; description "Container to augment IETF network slice to include NRP / VPN / TE mappings"; uses ns-mapping; } } } ]]>

Security Considerations The "ietf-network-slice-mapping" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF and RESTCONF . These YANG-based management protocols (1) have to use a secure transport layer (e.g., SSH , TLS , and QUIC ) and (2) have to use mutual authentication. The Network Configuration Access Control Model (NACM) provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., "config true", which is the default). All writable data nodes are likely to be sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. The following subtrees and data nodes have particular sensitivities/vulnerabilities:

• /ietf-nss:network-slice-services/ietf-nss:slice-service/mapping/ns-mapping/ - can configure Network Slice Service mapping.

There are no particularly sensitive readable data nodes. There are no particularly sensitive RPC or action operations. This YANG module uses groupings from other YANG modules that define nodes that may be considered sensitive or vulnerable in network environments. Refer to the Security Considerations of for information as to which nodes may be considered sensitive or vulnerable in network environments.

IANA Considerations IANA is requested to make the following allocation for the URIs in the "ns" subregistry within the "IETF XML Registry" : IANA is requested to make the following allocation for the YANG module in the "YANG Module Names" registry :

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models. 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. Huawei Technologies Huawei Technologies Ciena Cisco Systems, Inc Cisco Systems, Inc This document defines a YANG data model for RFC 9543 Network Slice Service. The model can be used in the Network Slice Service interface between a customer and a provider that offers RFC 9543 Network Slice Services. Samsung Electronics Huawei Huawei Huawei Cisco Nvidia This document provides a YANG data model to map customer service models (e.g., L3VPN Service Delivery model) to Traffic Engineering (TE) models (e.g., the TE Tunnel or the Virtual Network (VN) model). These models are referred to as the TE Service Mapping Model and are applicable generically to the operator's need for seamless control and management of their VPN services with underlying TE support. The models are principally used for monitoring and diagnostics of the management systems to show how the service requests are mapped onto underlying network resources and TE models. Huawei Technologies Huawei Technologies Juniper Networks Cisco Systems ZTE Corporation RFC 9543 describes a framework for Network Slices in networks built from IETF technologies. In this framework, the network resource partition (NRP) is introduced as a collection of network resources allocated from the underlay network to carry a specific set of Network Slice Service traffic and meet specific Service Level Objective (SLO) and Service Level Expectation (SLE) characteristics. This document defines YANG data models for Network Resource Partitions (NRPs), applicable to devices and network controllers. The models can be used, in particular, for the realization of the RFC9543 Network Slice Services in IP/MPLS and Segment Routing (SR) networks. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK] The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity. Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources. This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior or during service provisioning (e.g., VPN, Network Slice Service). A companion service model is specified in the YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (I-D.ietf- opsawg-teas-attachment-circuit). The module augments the base network ('ietf-network') and the Service Attachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs). This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context. The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security. This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices. Cisco Systems Inc. Juniper Networks Huawei Technologies Ericsson ZTE Corporation Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by 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.

Acknowledgments Thanks to Jie Dong and Adrian Farrel for the initial discussion behind this document.

Examples To be added in future revisions.