]> Huawei Technologies

italo.busi@huawei.com

Futurewei Technologies

aihuaguo.ietf@gmail.com

Nokia

sergio.belotti@nokia.com

CCAMP Working Group 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. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-path-computation once it has been published.

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.

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 [RFCZZZZ] te ietf-te [RFCKKKK] te-pc ietf-te-path-computation [RFCYYYY] 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-09-12" { description "Initial version."; reference "RFC XXXX: A YANG Data Model for requesting Path Computation in an Optical Transport Network (OTN)"; // 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 This document provides a method for requesting path computations for OTN tunnels. Consideration of mechanisms to gather and collate information required for the path computations will be necessary. Furthermore, storing path computation requests and responses and triggering actions will also need to be carefully managed and secured. Future versions of this document will contain additional information.

Security Considerations The YANG module defined in this document will be accessed via the NETCONF protocol or RESTCONF protocol . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS and the mandatory-to-implement secure transport is TLS . The Network Configuration Access Control Model (NACM) provides the means to restrict access to particular NETCONF or RESTCONF users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content. Some of the RPC operations defined in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus essential to control access to these operations. Operations defined in this document, and their sensitivities and possible vulnerabilities, will be discussed further in future versions of this document.

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. 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 IBM Corporation 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 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. 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. 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). This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [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. 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. 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 IBM Corporation 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