<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.ietf-teas-yang-path-computation" target="https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-path-computation-26">
   <front>
      <title>A YANG Data Model for requesting path computation</title>
      <author initials="I." surname="Busi" fullname="Italo Busi">
         <organization>Huawei Technologies</organization>
      </author>
      <author initials="S." surname="Belotti" fullname="Sergio Belotti">
         <organization>Nokia</organization>
      </author>
      <author initials="O. G." surname="de Dios" fullname="Oscar Gonzalez de Dios">
         <organization>Telefonica</organization>
      </author>
      <author initials="A." surname="Sharma" fullname="Anurag Sharma">
         <organization>Google</organization>
      </author>
      <author initials="Y." surname="Shi" fullname="Yan Shi">
         <organization>China Unicom</organization>
      </author>
      <date month="February" day="5" year="2026" />
      <abstract>
	 <t>   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.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-teas-yang-path-computation-26" />
   
</reference>
