Internet-Draft | YANG for OTN Path Computation | October 2023 |
Busi, et al. | Expires 22 April 2024 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 April 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[I-D.ietf-teas-yang-path-computation] 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 [I-D.ietf-teas-yang-path-computation], 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.¶
Refer to [I-D.ietf-ccamp-otn-topo-yang] and [I-D.ietf-ccamp-layer1-types] for the OTN specific terms used in this document.¶
The following terms are defined in [RFC7950] and are not redefined here:¶
The following terms are defined in [RFC6241] and are not redefined here:¶
The terminology for describing YANG data models is found in [RFC7950].¶
A simplified graphical representation of the data model is used in Section 3 of this document. The meaning of the symbols in these diagrams is defined in [RFC8340].¶
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 Table 1.¶
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 [I-D.ietf-teas-yang-path-computation]. Please replace ZZZZ with the RFC number assigned to [I-D.ietf-ccamp-layer1-types]. Please replace KKKK with the RFC number assigned to [I-D.ietf-teas-yang-te]. Please remove this note.¶
The YANG data model for requesting OTN path computation is defined as an augmentation of the generic Path Computation RPC defined in [I-D.ietf-teas-yang-path-computation], as shown in Figure 1.¶
The entities and Traffic Engineering (TE) attributes, such as requested path and tunnel attributes, defined in [I-D.ietf-teas-yang-path-computation], 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 [I-D.ietf-ccamp-layer1-types].¶
The YANG module ietf-otn-path-computation defined in this document conforms to the Network Management Datastore Architecture (NMDA) defined in [RFC8342].¶
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 [I-D.ietf-ccamp-layer1-types].¶
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 [I-D.ietf-ccamp-layer1-types].¶
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 [I-D.ietf-ccamp-layer1-types].¶
Figure 2 below shows the tree diagram of the YANG data model defined in module ietf-otn-path-computation.yang.¶
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.¶
The YANG module defined in this document will be accessed via the NETCONF protocol [RFC6241] or RESTCONF protocol [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS and the mandatory-to-implement secure transport is TLS [RFC8446].¶
The Network Configuration Access Control Model (NACM) [RFC8341] 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.¶
This document registers the following URIs in the "ns" subregistry within the "IETF XML registry" [RFC3688].¶
URI: urn:ietf:params:xml:ns:yang:ietf-otn-path-computation Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.¶
This document registers the following YANG module in the "YANG Module Names" registry [RFC7950].¶
name: ietf-otn-path-computation namespace: urn:ietf:params:xml:ns:yang:ietf-otn-path-computation prefix: otn-pc reference: this document¶
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 [I-D.draft-gbb-ccamp-optical-path-computation-yang], and the OTN capabilities were moved into this document.¶
Editors note, please remove this appendix before publication.¶
The authors of this document would like to thank the authors of [I-D.ietf-teas-actn-poi-applicability] for having identified the gap and requirements to trigger this work.¶
This document was prepared using kramdown.¶