]> Huawei

IN dhruv.ietf@gmail.com

Routing TEAS Working Group This document provides a YANG data model to map traffic to Traffic Engineering (TE) paths. This model providers operator a seamless control and management of which traffic to send on the underlying TE resources.

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 configuration or modeling of a variety of network devices, protocol instances, and network services. There are various YANG models to establish paths in the network, such as:

• TE Tunnels
• Segment Routing (SR) Policy
• Service Function Chaining (SFC)
• Virtual Network (VN)
• IETF Network Slice

These models do not include an exact mechanism to describe the traffic that needs to be mapped to the paths. Thus an operator lacks a way to simply use the YANG model to tell requirements such as the traffic from source X on port Y should go on a TE path with delay less than Z. The YANG model defined in this document fills this gap. To achieve this goal, the YANG model defined in this document utilizes the concept borrowed from:

• BGP FlowSpec: Where the description of traffic flows is done by the combination of multiple Flow Specification Components and their dissemination as traffic flow specifications (Flow Specifications) is described for BGP in . In BGP, a Flow Specification is comprised of traffic filtering rules and is associated with actions to perform on the packets that match the Flow Specification. The BGP routers that receive a Flow Specification can classify received packets according to the traffic filtering rules and can direct packets based on the associated actions.
• Path Computation Element (PCE) FlowSpec: Extends the idea to PCE Communication Protocol (PCEP) .
• Access Control List (ACL): A basic elements used to configure device-forwarding behavior in form of a user-ordered set of rules that is used to filter traffic on a networking device. Each rule is represented by an Access Control Entry (ACE). Each ACE has a group of match criteria and a group of actions .
• Flow: Elements in the packet in IP/UDP/TCP header to match particular flows.

The YANG model includes two key concepts:

• Traffic Description: The various fields that needs to be matched to identify a traffic flow.
• Action: The associated action that needs to be taken. For the purpose of this YANG model the action is to simply point to the TE resource in form of the TE tunnel, SR Policy etc.

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 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
inet	ietf-inet-types
yang	ietf-yang-types
te	ietf-te
rt	ietf-routing
sr-policy	ietf-sr-policy
ietf-nss	ietf-network-slice-service
acl	ietf-access-control-list
packet-fields	ietf-packet-fields
vpn-common	ietf-vpn-common

References in the Model Following documents are referenced in the model defined in this document -

Document	Reference
YANG Data Model for Network Access Control Lists (ACLs)
A YANG Data Model for Traffic Engineering Tunnels and Interfaces
YANG Data Model for Segment Routing Policy

Discussion Items For describing the traffic, currently the YANG models uses:

• The match criteria grouping from the . If this document gets WG backing, then it might be a good idea to move the grouping to this document instead.
• The ACL Name. Should that be ACE instead?
• The match action granularity in case of IETF network slice and VN needs to be discussed.
• The match action for SFC is not handled yet.

Tree Structure /acl:acls/acl/name | +--:(flowspec) | +--:(interface) | | +--rw node? string | | +--rw if-name? string | +--:(flow) | | +--rw (l3)? | | | +--:(ipv4) | | | | +--rw ipv4 | | | | ... | | | +--:(ipv6) | | | +--rw ipv6 | | | ... | | +--rw (l4)? | | +--:(tcp) | | | +--rw tcp | | | ... | | +--:(udp) | | +--rw udp | | ... | +--:(other) +--rw action | +--rw te-tunnel* te:tunnel-ref | +--rw sr-policy* [headend policy-color-ref policy-endpoint-ref] | | +--rw headend inet:ip-address-no-zone | | +--rw policy-color-ref leafref | | +--rw policy-endpoint-ref leafref | +--rw other +--ro stats +--ro matched-packets? yang:counter64 +--ro matched-octets? yang:counter64 ]]>

YANG Model file "ietf-traffic-map@2024-03-04.yang" module ietf-traffic-map { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-traffic-map"; prefix tm; import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types"; } import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG Data Types"; } import ietf-te { prefix te; reference "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic Engineering Tunnels and Interfaces"; } import ietf-routing { prefix rt; reference "RFC8349: A YANG Data Model for Routing Management"; } import ietf-sr-policy { prefix sr-policy; reference "I-D.ietf-spring-sr-policy-yang: YANG Data Model for Segment Routing Policy"; } import ietf-network-slice-service { prefix ietf-nss; reference "I-D.ietf-teas-ietf-network-slice-nbi-yang: IETF Network Slice Service YANG Model"; } import ietf-packet-fields { prefix packet-fields; reference "RFC 8519: YANG Data Model for Network Access Control Lists (ACLs)"; } import ietf-access-control-list { prefix acl; reference "RFC 8519: YANG Data Model for Network Access Control Lists (ACLs)"; } import ietf-vpn-common { prefix vpn-common; reference "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3 VPNs"; } organization "IETF Traffic Engineering Architecture and Signaling (TEAS) Working Group"; contact "WG Web: WG List: Editor: Dhruv Dhody "; description "This module contains a YANG module to map traffic to Traffic Engineering (TE) paths. Copyright (c) 2022 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 2024-03-04 { description "initial version."; reference "RFC XXXX: Traffic Mapping YANG model for Traffic Engineering (TE)"; } grouping traffic-description { description "The traffic description"; leaf id { type string; description "The identifier for Traffic Description"; } choice type { description "The various ways the traffic can be described"; case match-criteria { description "Use the match criteria"; list match-criterion { key "index"; description "List of traffic match criteria."; leaf index { type uint32; description "The entry index."; } leaf match-type { type identityref { base ietf-nss:service-match-type; } mandatory true; description "Identifies an entry in the list of the match criteria."; } leaf-list value { type string; description "Describes the slice service match criteria, e.g. IP address, VLAN, etc."; } } } case acl { description "Reference to ACL"; leaf acl { type leafref { path "/acl:acls/acl:acl/acl:name"; } description "The ACL Name. The action part of the ACL is not used."; reference "RFC8519: YANG Data Model for Network Access Control Lists (ACLs)"; } } case flowspec { description "Based on FlowSpec component type - TODO"; } case interface { description "All traffic received on an interface"; leaf node { type string; description "The node identifier"; } leaf if-name { type string; description "The interface name on the node"; } } case flow { description "Match particular flows"; choice l3 { description "Either IPv4 or IPv6."; container ipv4 { description "Rule set that matches the IPv4 header."; uses packet-fields:acl-ip-header-fields; uses packet-fields:acl-ipv4-header-fields; } container ipv6 { description "Rule set that matches the IPv6 header."; uses packet-fields:acl-ip-header-fields; uses packet-fields:acl-ipv6-header-fields; } } choice l4 { description "Includes Layer-4-specific information. This version focuses on TCP and UDP."; container tcp { description "Rule set that matches the TCP header."; uses packet-fields:acl-tcp-header-fields; uses vpn-common:ports; } container udp { description "Rule set that matches the UDP header."; uses packet-fields:acl-udp-header-fields; uses vpn-common:ports; } } } case other { description "TODO"; } } } grouping te-ref { description "Reference to TE paths"; leaf-list te-tunnel { type te:tunnel-ref; description "Reference to TE Tunnels"; reference "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic Engineering Tunnels and Interfaces"; } list sr-policy { key "headend policy-color-ref policy-endpoint-ref"; description "SR Policy"; reference "I-D.ietf-spring-sr-policy-yang: YANG Data Model for Segment Routing Policy"; /*Headend needs to be added*/ leaf headend { type inet:ip-address-no-zone; description "SR Policy headend"; } leaf policy-color-ref { type leafref { path "/rt:routing/sr-policy:segment-routing" + "/sr-policy:traffic-engineering/sr-policy:policies" + "/sr-policy:policy/sr-policy:color"; } description "Reference to sr-policy color"; } leaf policy-endpoint-ref { type leafref { path "/rt:routing/sr-policy:segment-routing" + "/sr-policy:traffic-engineering/sr-policy:policies" + "/sr-policy:policy/sr-policy:endpoint"; } description "Reference to sr-policy endpoint"; } } container other { description "To dp - VN, IETF Network Slice, SFC etc"; } } /* Configuration data nodes */ container traffic-map { description "AP configurations"; list maps { key "id"; description "traffic map identifier"; leaf id { type string; description "The identifier for Traffic Maps"; } container traffic { description "The traffic description"; uses traffic-description; } container action { description "The action is limited to identifying the TE resource"; uses te-ref; } container stats { config false; description "Statistics"; leaf matched-packets { type yang:counter64; description "The number of packets that matched the traffic description"; } leaf matched-octets { type yang:counter64; description "The number of octets (byte) that matched the traffic description"; } } } } } ]]>

Security Considerations TBD

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] This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. 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). 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. 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. This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022. This document defines a data model for Access Control Lists (ACLs). An ACL is a user-ordered set of rules used to configure the forwarding behavior in a device. Each rule is used to find a match on a packet and define actions that will be performed on the packet. 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. Cisco Systems Inc Cisco Systems Inc Alef Edge Juniper Networks Individual This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data that is independent of any technology or dataplane encapsulation and is divided into two YANG modules that cover device-specific, and device independent data. This model covers data for configuration, operational state, remote procedural calls, and event notifications. Cisco Systems Cisco Systems Huawei Technologies Bell Canada Equinix SoftBank Juniper Networks This document defines a YANG data model for Segment Routing (SR) Policy that can be used for configuring, instantiating, and managing SR policies. The model is generic and apply equally to the MPLS and SRv6 instantiations of SR policies. Huawei Technologies Huawei Technologies Ciena Cisco Systems, Inc Cisco Systems, Inc This document defines a YANG data model for RFC AAAA Network Slice Service. The model can be used in the Network Slice Service interface between a customer and a provider that offers RFC AAAA Network Slice Services. Informative References This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. This document obsoletes both RFC 5575 and RFC 7674. The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering (TE) network. These paths may be supplied in response to requests for computation or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path. Traffic flows may be categorized and described using "Flow Specifications". RFC 8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC 8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. This document specifies a set of extensions to PCEP to support dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. The extensions defined in this document include the creation, update, and withdrawal of Flow Specifications via PCEP and can be applied to tunnels initiated by the PCE or to tunnels where control is delegated to the PCE by the Path Computation Client (PCC). Furthermore, a PCC requesting a new path can include Flow Specifications in the request to indicate the purpose of the tunnel allowing the PCE to factor this into the path computation.

Acknowledgments Thanks to Adrian Farrel for the motivation behind this document.

Examples TO be added in future revisions.