]> Huawei Technologies

italo.busi@huawei.com

Futurewei Technologies

aihuaguo.ietf@gmail.com

Nokia

sergio.belotti@nokia.com

Routing CCAMP Working Group next generation unicorn sparkling distributed ledger This document provides a mechanism to request path computation in an Optical Transport Network (OTN) by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Common Control and Measurement Plane Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction describes key use cases, where a client needs to request underlying SDN controllers for path computation. In some of these use cases, the underlying SDN controller can control an Optical Transport Network (OTN). This document defines a YANG data model, which augment the generic Path Computation RPC defined in , with OTN technology-specific augmentations required to request path computation to an underlying OTN SDN controller. These models allow a client to delegate path computation tasks to the underlying SDN controller without having to obtain OTN detailed information from the controller and performing feasible path computation itself.

Editorial Note (To be removed by RFC Editor)

• Note to the RFC Editor: This section is to be removed prior to publication.

This document contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. Please apply the following replacements:

• XXXX --> the assigned RFC number for this I-D
• YYYY --> the assigned RFC number for
• ZZZZ --> the assigned RFC number for
• KKKK --> the assigned RFC number for
• 2026-05-19 --> the actual date of the publication of this document

Terminology and Notations Refer to and for the OTN specific terms used in this document. The following terms are defined in and are not redefined here:

• client
• server
• augment
• data model
• data node

The following terms are defined in and are not redefined here:

• configuration data
• state data

The terminology for describing YANG data models is found in .

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

Prefix in Data Node Names In this document, names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules, as shown in . Prefixes and corresponding YANG modules

Prefix	YANG module	Reference
l1-types	ietf-layer1-types	[RFCZZZZ]
te	ietf-te	[RFCKKKK]
te-pc	ietf-te-path-computation	[RFCYYYY]
otn-pc	ietf-otn-path-computation	RFCXXXX

YANG Data Model for OTN Path Computation

YANG Model Overview The YANG data model for requesting OTN path computation is defined as an augmentation of the generic Path Computation RPC defined in , as shown in .

Relationship between OTN and TE path computation models

The entities and Traffic Engineering (TE) attributes, such as requested path and tunnel attributes, defined in , are still applicable when requesting OTN path computation and the models defined in this document only specifies the additional OTN technology-specific attributes/information, using the attributes defined in .

Bandwidth Augmentation The OTN path computation model augments all the occurrences of the te-bandwidth container with the OTN technology-specific attributes using the otn-path-bandwidth grouping defined in .

Label Augmentations The OTN path computation model augments all the occurrences of the label-restriction list with OTN technology-specific attributes using the otn-label-range-info grouping defined in . Moreover, the model augments all the occurrences of the te-label container with the OTN technology-specific attributes using the otn-label-start-end, otn-label-hop and otn-label-step groupings defined in .

YANG Model for OTN Path Computation

OTN path computation YANG module WG List: Editor: Aihua Guo Editor: Italo Busi Editor: Sergio Belotti "; description "This module defines a model for requesting OTN Path Computation. Copyright (c) 2026 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). All revisions of IETF and IANA published modules can be found at the YANG Parameters registry group (https://www.iana.org/assignments/yang-parameters). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2026-07-29 { description "Initial version."; reference "RFC XXXX: A YANG Data Model for requesting Path Computation in an Optical Transport Network (OTN)"; } /* * Data nodes */ /* * Augment TE bandwidth */ augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "te-pc:path-request/te-pc:te-bandwidth/te-pc:technology" { description "Augment TE bandwidth of the requested path."; case otn { uses l1-types:otn-path-bandwidth; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "te-pc:tunnel-attributes/te-pc:te-bandwidth/" + "te-pc:technology" { description "Augment TE bandwidth of the requested tunnel attributes."; case otn { uses l1-types:otn-path-bandwidth; } } augment "/te:tunnels-path-compute/te:output/" + "te:path-compute-result/te-pc:response/" + "te-pc:computed-paths-properties/" + "te-pc:computed-path-properties/te-pc:path-properties/" + "te-pc:te-bandwidth/te-pc:technology" { description "Augment TE bandwidth of the computed path properties."; case otn { uses l1-types:otn-path-bandwidth; } } /* * Augment TE label range information */ augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "te-pc:path-request/te-pc:path-in-segment/" + "te-pc:label-restrictions/te-pc:label-restriction" { description "Augment TE label range information for the ingress segment of the requested path."; uses l1-types:otn-label-range-info; } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "te-pc:path-request/te-pc:path-out-segment/" + "te-pc:label-restrictions/te-pc:label-restriction" { description "Augment TE label range information for the egress segment of the requested path."; uses l1-types:otn-label-range-info; } /* * Augment TE label. */ augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "te-pc:path-request/te-pc:optimizations/te-pc:algorithm/" + "te-pc:metric/te-pc:optimization-metric/" + "te-pc:explicit-route-exclude-objects/" + "te-pc:route-object-exclude-object/te-pc:type/" + "te-pc:label/te-pc:label-hop/te-pc:te-label/" + "te-pc:technology" { description "Augment TE label hop for the optimization of the explicit route objects excluded by the path computation of the requested path."; case otn { uses l1-types:otn-label-hop; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "te-pc:path-request/te-pc:optimizations/te-pc:algorithm/" + "te-pc:metric/te-pc:optimization-metric/" + "te-pc:explicit-route-include-objects/" + "te-pc:route-object-include-object/te-pc:type/" + "te-pc:label/te-pc:label-hop/te-pc:te-label/" + "te-pc:technology" { description "Augment TE label hop for the optimization of the explicit route objects included by the path computation of the requested path."; case otn { uses l1-types:otn-label-hop; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "te-pc:path-request/te-pc:explicit-route-objects/" + "te-pc:route-object-exclude-always/" + "te-pc:type/te-pc:label/te-pc:label-hop/te-pc:te-label/" + "te-pc:technology" { description "Augment TE label hop for the explicit route objects always excluded by the path computation of the requested path."; case otn { uses l1-types:otn-label-hop; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "te-pc:path-request/te-pc:explicit-route-objects/" + "te-pc:route-object-include-exclude/te-pc:type/" + "te-pc:label/te-pc:label-hop/te-pc:te-label/" + "te-pc:technology" { description "Augment TE label hop for the explicit route objects included or excluded by the path computation of the requested path."; case otn { uses l1-types:otn-label-hop; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "te-pc:path-request/te-pc:path-in-segment/" + "te-pc:label-restrictions/te-pc:label-restriction/" + "te-pc:label-start/te-pc:te-label/te-pc:technology" { description "Augment TE label range start for the ingress segment of the requested path."; case otn { uses l1-types:otn-label-start-end; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "te-pc:path-request/te-pc:path-in-segment/" + "te-pc:label-restrictions/te-pc:label-restriction/" + "te-pc:label-end/te-pc:te-label/te-pc:technology" { description "Augment TE label range end for the ingress segment of the requested path."; case otn { uses l1-types:otn-label-start-end; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "te-pc:path-request/te-pc:path-in-segment/" + "te-pc:label-restrictions/te-pc:label-restriction/" + "te-pc:label-step/te-pc:technology" { description "Augment TE label range step for the ingress segment of the requested path."; case otn { uses l1-types:otn-label-step; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "te-pc:path-request/te-pc:path-out-segment/" + "te-pc:label-restrictions/te-pc:label-restriction/" + "te-pc:label-start/te-pc:te-label/te-pc:technology" { description "Augment TE label range start for the egress segment of the requested path."; case otn { uses l1-types:otn-label-start-end; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "te-pc:path-request/te-pc:path-out-segment/" + "te-pc:label-restrictions/te-pc:label-restriction/" + "te-pc:label-end/te-pc:te-label/te-pc:technology" { description "Augment TE label range end for the egress segment of the requested path."; case otn { uses l1-types:otn-label-start-end; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "te-pc:path-request/te-pc:path-out-segment/" + "te-pc:label-restrictions/te-pc:label-restriction/" + "te-pc:label-step/te-pc:technology" { description "Augment TE label range step for the egress segment of the requested path."; case otn { uses l1-types:otn-label-step; } } augment "/te:tunnels-path-compute/te:input/te:path-compute-info/" + "te-pc:synchronization/te-pc:exclude-objects/" + "te-pc:excludes/te-pc:type/te-pc:label/te-pc:label-hop/" + "te-pc:te-label/te-pc:technology" { description "Augment TE label hop for the explicit route objects to always exclude from synchronized path computation."; case otn { uses l1-types:otn-label-hop; } } augment "/te:tunnels-path-compute/te:output/" + "te:path-compute-result/te-pc:response/" + "te-pc:computed-paths-properties/" + "te-pc:computed-path-properties/te-pc:path-properties/" + "te-pc:path-route-objects/te-pc:path-route-object/" + "te-pc:type/te-pc:label/" + "te-pc:label-hop/te-pc:te-label/te-pc:technology" { description "Augment TE label hop for the route object of the computed path."; case otn { uses l1-types:otn-label-hop; } } } ]]>

Security Considerations This section is modeled after the template described in . The "ietf-otn-path-computation" 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 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. The YANG module defined in this document augments the "tunnels-path-compute" RPC, defined in and in , with OTN technology-specific attributes. The security considerations provided in and in are also applicable to the YANG module defined in this document.

IANA Considerations IANA is requested to register the following URI in the "ns" registry within the "IETF XML Registry" group : IANA is requested to register the following YANG module in the "YANG Module Names" registry within the "YANG Parameters" registry group.

References Normative References Huawei Technologies Nokia Telefonica Google China Unicom In certain scenarios — particularly within hierarchical Software- Defined Networking (SDN) environments—the topology information provided by a Traffic Engineering (TE) network provider may be insufficient for a client to perform end-to-end multi-domain path computation. In such cases, the client may need to delegate the computation of specific intra-domain paths to the TE provider, leveraging the resulting path segments to construct optimal multi- domain end-to-end paths. This document defines a mechanism to enable path computation requests by augmenting the Remote Procedure Calls (RPCs) specified in RFC YYYY. The augmented RPCs support path computation on demand, allowing clients to request intra-domain TE path computations from the provider while maintaining control over inter-domain path selection. Additionally, this document outlines several use cases in which such path computation requests are beneficial, particularly in environments where YANG-based management protocols—such as NETCONF or RESTCONF—are used for network automation and control. Huawei Technologies Huawei Technologies This document defines a collection of common data types, identities, and groupings in the YANG data modeling language. These derived common data types, identities, and groupings are intended to be imported by modules that model Layer 1 configuration and state capabilities. The Layer 1 types are representative of Layer 1 client signals applicable to transport networks, such as Optical Transport Networks (OTN). The Optical Transport Network (OTN) data structures are included in this document as Layer 1 types. 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 pertinent to TE tunnels, TE LSPs, and TE interfaces that are independent of any technology or dataplane encapsulation. The model is divided into two YANG modules that address both device-specific and device-independent data, supporting configuration, operational state, Remote Procedure Calls (RPCs), and event notifications. 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). 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 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. 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] Informative References Huawei Technologies Huawei Technologies Individual Nokia Telefonica This document defines a YANG data model for representing, retrieving, and manipulating Optical Transport Network (OTN) topologies. It is independent of control plane protocols and captures topological and resource-related information pertaining to OTN. This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407; it also updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained YANG modules. 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). 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] 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. 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 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. This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text. Huawei Technologies Huawei Technologies Nokia Nokia CAICT This document describes the YANG data model for tunnels in OTN TE networks. The model can be used to do the configuration in order to establish the tunnel in OTN network. This work is independent with the control plane protocols. Huawei Technologies Futurewei Technologies Nokia This document provides a mechanism to request path computation in Optical Networks (WSON and Flexi-grid) 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-path-computation once it has been published. FiberCop Vodafone Huawei Old Dog Consulting Cisco 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

OTN Path Computation Tree Diagram below shows the tree diagram of the YANG data model defined in module ietf-otn-path-computation.yang. See for an explanation of the symbols used. The data type of every leaf node is shown near the right end of the corresponding line.

OTN path computation tree diagram

JSON Examples This appendix contains an example of an instance data tree in JSON encoding . The example instantiates the "ietf-otn-path-computation" model to request the computation of the primary and secondary paths described in .

Change Log The initial YANG data model requesting path computation in optical networks was draft-gbb-ccamp-optical-path-computation-yang-00. This document included path computation request capabilities for WSON, Flexi-Grid and OTN technologies. However, it was proposed at IETF 113 (March 25, 2022) to split the initial document into separate documents for WDM (WSON and Flexi-Grid) and OTN technologies, as each technology may be developed and implemented separately. The WDM technology capabilities were kept in , and the OTN capabilities were moved into this document. Editors note, please remove this appendix before publication.

Acknowledgments The authors of this document would like to thank the authors of for having identified the gap and requirements to trigger this work. This document was prepared using kramdown.

Contributors Old Dog Consulting

daniel@olddog.co.uk