]> Huawei Technologies

italo.busi@huawei.com

Futurewei Technologies

aihuaguo.ietf@gmail.com

Nokia

sergio.belotti@nokia.com

CCAMP Working Group This document describes a YANG data model for a Remote Procedure Calls (RPC) to request Path Computation in an Optical Transport Network (OTN). The YANG data models defined in this document conforms to the Network Management Datastore Architecture (NMDA).

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. The YANG data model defined in this document conforms to the Network Management Datastore Architecture .

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 . Prefix YANG module Reference l1-types ietf-layer1-types [RFCYYYY] te ietf-te [RFCZZZZ] te-pc ietf-te-path-computation [RFCKKKK] otn-pc ietf-otn-path-computation RFCXXXX RFC Editor Note: Please replace XXXX with the RFC number assigned to this document. Please replace YYYY with the RFC number assigned to . Please replace ZZZZ with the RFC number assigned to . Please replace KKKK with the RFC number assigned to . Please remove this note.

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 .

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 . The YANG module ietf-otn-path-computation defined in this document conforms to the Network Management Datastore Architecture (NMDA) 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-link-bandwidth and otn-path-bandwidth groupings 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 .

OTN Path Computation Tree Diagram below shows the tree diagram of the YANG data model defined in module ietf-otn-path-computation.yang.

YANG Model for OTN Path Computation

WG List: Editor: Aihua Guo Editor: Italo Busi Editor: Sergio Belotti "; description "This module defines a model for requesting OTN Path Computation. The model fully conforms to the Network Management Datastore Architecture (NMDA). 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 "2022-07-10" { description "Initial version."; reference "RFC XXXX: YANG Model for OTN and Optical Path Computation"; // RFC Ed.: replace XXXX with actual RFC number, update date // information and remove this note } /* * 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-always/" + "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-always/" + "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 end 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; } } } ]]>

Manageability Considerations TBD.

Security Considerations <Add any security considerations>

IANA Considerations This document registers the following URIs in the "ns" subregistry within the "IETF XML registry" .

This document registers the following YANG module in the "YANG Module Names" registry .

Huawei Technologies Nokia Telefonica Google Ericsson 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. This document defines a YANG data model which contains Remote Procedure Calls (RPCs) to request path computation. This model complements the solution, defined in RFC YYYY, to configure a TE tunnel path in "compute-only" mode. [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. Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. Huawei Technologies Huawei Technologies This document defines a collection of common data types and groupings in the YANG data modeling language for use with layer 1 networks. These derived common types and groupings are intended to be imported by modules that specify OTN networks, such as topology, tunnel, client signal adaptation and service. 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. Juniper Networks Cisco Systems Inc Volta Networks Juniper Networks Individual Telefonica 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 is divided into YANG modules that classify data into generic, device-specific, technology agnostic, and technology-specific elements. This model covers data for configuration, operational state, remote procedural calls, and event notifications. 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. Huawei Technologies Huawei Technologies Volta Networks Nokia Telefonica This document describes a YANG data model to describe the topologies of an Optical Transport Network (OTN). It is independent of control plane protocols and captures topological and resource related information pertaining to OTN. This model enables clients, which interact with a transport domain controller, for OTN topology related operations such as obtaining the relevant topology resource information. TIM Vodafone Huawei Old Dog Consulting Ericsson This document considers the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI)in the context of IP/MPLS and optical internetworking. It identifies the YANG data models being defined by the IETF to support this deployment architecture and specific scenarios relevant for Service Providers. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface)in the ACTN architecture.

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