Traffic Engineering Architecture and Signaling (teas) Internet Drafts

      
 A YANG Data Model for Resource Reservation Protocol (RSVP)
 
 draft-ietf-teas-yang-rsvp-20.txt
 Date: 19/12/2025
 Authors: Vishnu Beeram, Tarek Saad, Rakesh Gandhi, Xufeng Liu, Igor Bryskin
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 This document defines a YANG data model for the configuration and management of the RSVP protocol. The YANG data model covers the building blocks that may be augmented by other RSVP extension data models such as RSVP Traffic-Engineering (RSVP-TE). It is divided into two modules that cover the basic and extended RSVP features.
 A YANG Data Model for Traffic Engineering Tunnels,Label Switched Paths,and Interfaces
 
 draft-ietf-teas-yang-te-43.txt
 Date: 28/02/2026
 Authors: Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Igor Bryskin
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 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.
 A YANG Data Model for RSVP-TE Protocol
 
 draft-ietf-teas-yang-rsvp-te-10.txt
 Date: 19/01/2026
 Authors: Vishnu Beeram, Tarek Saad, Rakesh Gandhi, Xufeng Liu, Igor Bryskin, Himanshu Shah
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 This document defines a YANG data model for the configuration and management of RSVP (Resource Reservation Protocol) to establish Traffic-Engineered (TE) Label-Switched Paths (LSPs) for MPLS (Multi- Protocol Label Switching) and other technologies. The model defines a generic RSVP-TE module for signaling LSPs that are technology agnostic. The generic RSVP-TE module is to be augmented by technology specific RSVP-TE modules that define technology specific data. This document also defines the augmentation for RSVP-TE MPLS LSPs model. This model covers data for the configuration, operational state, remote procedural calls, and event notifications.
 A YANG Data Model for requesting path computation
 
 draft-ietf-teas-yang-path-computation-26.txt
 Date: 05/02/2026
 Authors: Italo Busi, Sergio Belotti, Oscar de Dios, Anurag Sharma, Yan Shi
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 There are scenarios, typically in a hierarchical Software-Defined Networking (SDN) context, where the topology information provided by a Traffic Engineering (TE) network provider may be insufficient for its client to perform multi-domain path computation. In these cases the client would need to request the TE network provider to compute some intra-domain paths to be used by the client to choose the optimal multi-domain paths. This document provides a mechanism to request path computation by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-te once it has been published. Moreover, this document describes some use cases where the path computation request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can be needed.
 Traffic Engineering (TE) and Service Mapping YANG Data Model
 
 draft-ietf-teas-te-service-mapping-yang-18.txt
 Date: 12/10/2025
 Authors: Young Lee, Dhruv Dhody, Giuseppe Fioccola, Qin WU, Daniele Ceccarelli, Jeff Tantsura
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 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.
 YANG models for Virtual Network (VN)/TE Performance Monitoring Telemetry and Scaling Intent Autonomics
 
 draft-ietf-teas-actn-pm-telemetry-autonomics-18.txt
 Date: 02/02/2026
 Authors: Dhruv Dhody, Daniel King, Ricard Vilalta, Italo Busi, Daniele Ceccarelli
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 This document provides YANG data models that describe the performance monitoring parameters and scaling intent mechanisms for Traffic Engineering (TE) tunnels and Virtual Networks (VNs). Their performance monitoring parameters are exposed as the key telemetry data for tunnels and VNs. The models presented in this document allow customers to subscribe to and monitor the key performance data of the TE-tunnel or the VN. The models also provide customers with the ability to program autonomic scaling intent mechanisms on the level of TE-tunnel as well as VN.
 Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI)
 
 draft-ietf-teas-actn-poi-applicability-18.txt
 Date: 14/03/2026
 Authors: Fabio Peruzzini, Jean-Francois Bouquier, Italo Busi, Daniel King, Daniele Ceccarelli
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 This document explores the applicability of the Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) within the context of IP/MPLS and optical internetworking. It examines the YANG data models defined by the IETF that enable an ACTN-based deployment architecture and highlights specific scenarios pertinent to Service Providers. Existing IETF protocols and data models are identified for each multi-technology scenario (packet over optical), particularly emphasising the Multi-Domain Service Coordinator to Provisioning Network Controller Interface (MPI) within the ACTN architecture
 Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to IETF Network Slicing
 
 draft-ietf-teas-applicability-actn-slicing-10.txt
 Date: 28/08/2024
 Authors: Daniel King, John Drake, Haomian Zheng, Adrian Farrel
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 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.
 A YANG Data Model for the RFC 9543 Network Slice Service
 
 draft-ietf-teas-ietf-network-slice-nbi-yang-25.txt
 Date: 09/05/2025
 Authors: Bo Wu, Dhruv Dhody, Reza Rokui, Tarek Saad, John Mullooly
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 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.
 Realizing Network Slices in IP/MPLS Networks
 
 draft-ietf-teas-ns-ip-mpls-07.txt
 Date: 28/02/2026
 Authors: Tarek Saad, Vishnu Beeram, Jie Dong, Joel Halpern, Shaofu Peng
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by by requiring compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) based on slice identifiers.
 Common YANG Data Types for Traffic Engineering
 
 draft-ietf-teas-rfc8776-update-22.txt
 Date: 18/02/2026
 Authors: Italo Busi, Aihua Guo, Xufeng Liu, Tarek Saad, Igor Bryskin
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 This document defines a collection of common data types, identities, and groupings in YANG data modeling language. These derived common data types, identities and groupings are intended to be imported by other modules, e.g., those which model the Traffic Engineering (TE) configuration and state capabilities. This document obsoletes RFC 8776.
 Scalability Considerations for Network Resource Partition
 
 draft-ietf-teas-nrp-scalability-09.txt
 Date: 11/02/2026
 Authors: Jie Dong, Zhenbin Li, Liyan Gong, Guangming Yang, Gyan Mishra
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC 9543 describes a framework for network slices built using networks that use IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a set of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. As the demand for network slices increases, scalability becomes an important factor. Although the scalability of network slices can be improved by mapping a group of network slices to a single NRP, that design may not be suitable or possible for all deployments, thus there are concerns about the scalability of NRPs themselves. This document discusses some considerations for NRP scalability in the control and data planes. It also investigates a set of optimization mechanisms.
 IETF Network Slice Application in 3GPP 5G End-to-End Network Slice
 
 draft-ietf-teas-5g-network-slice-application-06.txt
 Date: 02/03/2026
 Authors: Xuesong Geng, Luis Contreras, Reza Rokui, Jie Dong, Ivan Bykov
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 Network Slicing is one of the core features of 5G defined in 3GPP, which provides different network service as independent logical networks. To provide 5G network slices services, an end-to-end network slice has to span three network segments: Radio Access Network (RAN), Mobile Core Network (CN) and Transport Network (TN). This document describes the application of the IETF network slice framework in providing 5G end-to-end network slices, including network slice mapping in the management, control and data planes.
 IETF Network Slice Controller and its Associated Data Models
 
 draft-ietf-teas-ns-controller-models-06.txt
 Date: 20/10/2025
 Authors: Luis Contreras, Reza Rokui, Jeff Tantsura, Bo Wu, Xufeng Liu
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 This document describes an approach for structuring the IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision (and how they are related). It is not the purpose of this document to standardize or constrain the implementation the IETF Network Slice Controller.
 YANG Data Models for Network Resource Partitions (NRPs)
 
 draft-ietf-teas-nrp-yang-05.txt
 Date: 22/01/2026
 Authors: Bo Wu, Dhruv Dhody, Vishnu Beeram, Tarek Saad, Shaofu Peng
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 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 two YANG data models for Network Resource Partitions (NRPs): a network-level model for policy configuration by a Network Slice Controller, and a device-level model for configuration of individual network elements. These models enable automated provisioning of NRPs in IP/MPLS and Segment Routing (SR) networks, supporting scalable realization of RFC 9543 Network Slice Services.
 A YANG Data Model for MPLS-TE Topology
 
 draft-ietf-teas-yang-te-mpls-topology-04.txt
 Date: 01/03/2026
 Authors: Italo Busi, Aihua Guo, Xufeng Liu, Tarek Saad, Rakesh Gandhi
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 This document defines a YANG data model for representing, retrieving, and manipulating MPLS-TE network topologies. It is based on and augments existing YANG models that describe network and traffic engineering packet network topologies. This document also defines a collection of common YANG data types and groupings specific to MPLS-TE. These common types and groupings are intended to be imported by modules that model MPLS-TE technology- specific configuration and state capabilities. The YANG models defined in this document can also be used for MPLS Transport Profile (MPLS-TP) network topologies.
 Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE-centric Use Cases
 
 draft-ietf-teas-te-topology-profiles-05.txt
 Date: 02/03/2026
 Authors: Italo Busi, Xufeng Liu, Igor Bryskin, Tarek Saad, Oscar de Dios
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 This document describes how profiles of the Topology YANG data model, defined in RFC8795, can be used to address applications in Traffic Engineering aware (TE-aware) deployments, irrespective of whether they are TE-centric or not.
 YANG Data Model for Topology Filter
 
 draft-ietf-teas-yang-topology-filter-02.txt
 Date: 19/10/2025
 Authors: Vishnu Beeram, Tarek Saad, Rakesh Gandhi, Xufeng Liu
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 This document defines a YANG data model for the management of topology filters/filter-sets on network elements and controllers.
 IETF Network Slice Topology YANG Data Model
 
 draft-ietf-teas-network-slice-topology-yang-03.txt
 Date: 23/01/2026
 Authors: Xufeng Liu, Luis Contreras, Sergio Belotti, Aihua Guo, Italo Busi
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 An RFC 9543 network slice customer may utilize intent-based topologies to express resource reservation intentions within the provider's network. These customer-defined intent topologies allow customers to request shared resources for future connections that can be flexibly allocated and customized. Additionally, they provide an extensive level of control over underlay service paths within the network slice. This document describes a YANG data model for expressing customer intent topologies which can be used to enhance the RFC 9543 Network Slice Services in specific use cases, such as Network wholesale scenarios, where both topology and connectivity intents need to be expressed.
 Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) for Packet Optical Integration (POI) service assurance
 
 draft-ietf-teas-actn-poi-assurance-04.txt
 Date: 24/02/2026
 Authors: Italo Busi, Jean-Francois Bouquier, Fabio Peruzzini, Paolo Volpato, Prasenjit Manna
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 This document extends the analysis of the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) to cover multi-layer service assurance scenarios. Specifically, the ACTN architecture enables the detection and handling of different failures that may happen either at the optical or the packet layer. It is assumed that the underlying transport optical network carries end-to-end IP services such as L2VPN or L3VPN connectivity services, with specific Service Level Agreement (SLA) requirements. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) service assurance scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface) in the ACTN architecture.
 RSVP Cryptographic Authentication,Version 2
 
 draft-ietf-teas-rsvp-auth-v2-00.txt
 Date: 19/10/2025
 Authors: Ran Atkinson, Tony Li
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 This document provides an algorithm-independent description of the format and use of RSVP's INTEGRITY object. The RSVP INTEGRITY object is widely used to provide hop-by-hop integrity and authentication of RSVP messages, particularly in MPLS deployments using RSVP-TE. This document obsoletes both RFC2747 and RFC3097.
 RSVP Cryptographic Authentication with HMAC-SHA2
 
 draft-ietf-teas-rsvp-hmac-sha2-00.txt
 Date: 19/10/2025
 Authors: Ran Atkinson, Joel Halpern
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 This document specifies the use of the US NIST Secure Hash Standard in the Hashed Message Authentication Code (HMAC) mode with RSVP Cryptographic Authentication version 2. Along with draft-ietf-teas- rsvp-auth-v2, this document obsoletes RFC2747 and RFC3097.
 Realization of Composite IETF Network Slices
 
 draft-ietf-teas-composite-network-slices-00.txt
 Date: 16/03/2026
 Authors: Zhenbin Li, Jie Dong, Ran Pang, Yongqing Zhu, Luis Contreras
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC 9543 describes a framework for network slices built in networks that use IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a collection of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. In some network scenarios, network slices using IETF technologies may span multiple network domains, and they may be composed hierarchically, which means a network slice itself may be further sliced. In the context of 5G, a 5G end-to-end network slice consists of three different types of network technology segments: Radio Access Network (RAN), Transport Network (TN) and Core Network (CN). The transport segments of the 5G end-to-end network slice can be provided using network slices described in RFC 9543. This document first describes the possible use cases of composite network slices built in networks that use IETF network technologies, then it provides considerations about the realization of composite network slices. For the multi-domain network slices, an Inter-Domain Network Resource Partition Identifier (Inter-domain NRP ID) may be introduced. For hierarchical network slices, the structure of the NRP ID is discussed. And for the interaction between IETF network slices with 5G network slices, the identifiers of the 5G network slices may be introduced into IETF networks. These network slice- related identifiers may be used in the data plane, control plane and management plane of the network for the instantiation and management of composite network slices. This document also describes the management considerations of composite network slices.
 In-Place Bandwidth Update for MPLS RSVP-TE LSPs
 
 draft-ietf-teas-rsvp-inplace-lsp-bw-update-00.txt
 Date: 18/03/2026
 Authors: Zafar Ali, Vishnu Beeram, Peter Schoenmaker
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 This document describes the procedure for updating the bandwidth of an MPLS RSVP-TE Label Switched Path (LSP) tunnel in-place without employing make-before-break (MBB).

data-group-menu-data-url="/group/groupmenu.json">

Traffic Engineering Architecture and Signaling (teas)

WG Name Traffic Engineering Architecture and Signaling
Acronym teas
Area Routing Area (rtg)
State Active
Charter charter-ietf-teas-02 Approved
Document dependencies
Additional resources Issue tracker
Wiki
Zulip Stream
document repository
Personnel Chairs Oscar Gonzalez de Dios, Vishnu Pavan Beeram
Area Director Jim Guichard
Tech Advisors Adrian Farrel, Lou Berger
Secretary Italo Busi
Delegate Italo Busi
Mailing list Address teas@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/teas
Archive https://mailarchive.ietf.org/arch/browse/teas/
Chat Room address https://zulip.ietf.org/#narrow/stream/teas

Charter for Working Group

The Traffic Engineering Architecture and Signaling (TEAS)
Working Group is responsible for defining IP, MPLS and GMPLS
traffic engineering architecture and identifying required
related control-protocol functions, i.e., routing and path
computation element functions. The TEAS group is also
responsible for standardizing RSVP-TE signaling protocol
mechanisms that are not related to a specific switching
technology.

Traffic Engineering (TE) is the term used to refer to
techniques that enable operators to control how specific
traffic flows are treated within their networks. TE is
applied to packet networks via MPLS TE tunnels and LSPs, but
may also be provided by other mechanisms such as forwarding
rules similar to policy-based routing. The MPLS-TE control
plane was generalized to additionally support non-packet
technologies via GMPLS. RSVP-TE is the signaling protocol
used for both MPLS-TE and GMPLS. Centralized and logically
centralized control models are also supported, e.g., via
Abstraction and Control of Traffic Engineered Networks (ACTN)
and stateful-PCE.

The TEAS WG is responsible for:

    a) Traffic-engineering architectures for generic
       applicability across packet and non-packet
       networks. This includes, for example, networks that
       perform centralized computation and control, distributed
       computation and control, or even a hybrid approach.

    b) Definition of protocol-independent metrics and
       parameters (measurement and/or service attributes) for
       describing links and tunnels/paths required for traffic
       engineering (and related routing, signaling and path
       computation). These will be developed in conjunction
       with requests and requirements from other WGs to ensure
       overall usefulness.

    c) Functional specification of extensions for routing
       (OSPF, ISIS) and for path computation (PCEP), including
       those that provide general enablers of
       traffic-engineering systems that may also use
       RSVP-TE. Protocol formats and procedures that embody
       these extensions will be done in coordination with the
       WGs supervising those protocols.

    d) Functional specification of generic (i.e., not data
       plane technology-specific) extensions for RSVP-TE, and
       the associated protocol formats and procedures that
       embody these extensions.

    e) Definition of control plane mechanisms and extensions to
       allow the setup and maintenance of TE paths and TE
       tunnels that span multiple domains and/or switching
       technologies, where a domain may be an IGP area, an
       Autonomous System, or any other region of topological
       visibility.

    f) Definition and extension of management and security
       techniques for TE path and tunnel control. This
       includes configuring and monitoring RSVP-TE as well as
       mechanisms used to configure, control, and report OAM
       within TE networks. YANG and MIB modules may be
       considered.

The TEAS working group is chartered to deliver the following:

    1. Definition of additional abstract service, link, and
       path properties such as jitter, delay, and
       diversity. Extensions to IGPs to advertise these
       properties, and extensions to RSVP-TE to request and to
       accumulate these properties. Work with PCE WG to include
       these properties in computation requests.

    2. Specification of terminology, architecture, and protocol
       requirements for abstraction and distribution of TE
       information between interconnected TE domains/layers.

    3. Specification and protocol extensions for a GMPLS
       External Network-to-Network Interface (E-NNI), i.e.,
       multi-domain GMPLS support.

    4. Protocol mechanisms to signal associated LSPs in
       particular with different source nodes.

    5. Requirements and protocol extensions for additional
       protection mechanisms including, for example, end-point
       protection, protection of P2MP LSPs, and inter-domain
       protection.

    6. YANG models in support of Traffic Engineering, in
       coordination with working groups working on YANG models
       for network topology and for technology-specific network
       attributes.

Requirements may be documented in stand-alone RFCs, may be
folded into architecture or solutions RFCs, may be recorded
on a wiki, or may be documented in an Internet-Draft that is
not progressed to RFC.

The TEAS WG will coordinate with the following working
groups:

    - With the MPLS WG to maintain and extend MPLS-TE protocol
      mechanisms and to determine whether they should be
      generalized.

    - With the CCAMP WG to maintain and extend non-packet, data
      plane technology-specific TE protocol mechanisms and to
      determine whether they should be generalized.

    - With the LSR (OSPF and ISIS) WG to maintain or extend TE
      routing mechanisms.

    - With the PCE WG on uses of a PCE in the
      traffic-engineering architecture, on PCE extensions per
      the above, and on RSVP-TE extensions to support PCE WG
      identified requirements.

    - With the IDR WG on the use of BGP-LS in TE environments.

    - With the DetNet WG on mechanisms (YANG models and
      protocols) to support DetNets.

    - With the SPRING WG on TE architecture and, where
      appropriate, TE-related protocol extensions.

    - With the SFC WG on mechanisms (YANG models and protocols) to
      support SFCs

In doing this work, the WG will cooperate with external SDOs
(such as the ITU-T and the IEEE 802.1) as necessary.

Milestones

Date Milestone Associated documents
Mar 2026 Submit SF Aware TE Topology YANG Model to IESG for publication draft-ietf-teas-sf-aware-topo-model
Nov 2025 Submit ACTN YANG Models to IESG for publication draft-ietf-teas-actn-yang
draft-ietf-teas-actn-pm-telemetry-autonomics
Nov 2025 Submit SR&L3 TE Topology Yang Models to IESG for publication draft-ietf-teas-yang-sr-te-topo
draft-ietf-teas-yang-l3-te-topo
Nov 2025 Submit RSVP(-TE) Yang Models to (base and MPLS) IESG for publication draft-ietf-teas-yang-rsvp-te
draft-ietf-teas-yang-rsvp
Jul 2025 Submit TE LSP Yang Models to IESG for publication draft-ietf-teas-rfc8776-update
draft-ietf-teas-yang-te
draft-ietf-teas-yang-path-computation

Done milestones

Date Milestone Associated documents
Done Submit PCECC and Native IP documents to IESG for publication rfc8821 (was draft-ietf-teas-pce-native-ip)
rfc9689 (was draft-ietf-teas-pcecc-use-cases)
Done Revisit WG status (close if no milestones/deliverables)

1 new milestone currently in Area Director review.