idnits 2.17.1 draft-ietf-ccamp-flexigrid-yang-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2006 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-18 == Outdated reference: A later version (-28) exists of draft-ietf-ccamp-wson-yang-14 == Outdated reference: A later version (-04) exists of draft-ietf-ccamp-flexigrid-media-channel-yang-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group J.E. Lopez de Vergara 2 Internet Draft Universidad Autonoma de Madrid 3 Intended status: Standards Track D. Perdices 4 Expires: April 25, 2019 Naudit HPCN 5 V. Lopez 6 O. Gonzalez de Dios 7 Telefonica I+D/GCTO 8 D. King 9 Lancaster University 10 Y. Lee 11 Huawei 12 G. Galimberti 13 Cisco Photonics Srl 14 October 22, 2018 16 YANG data model for Flexi-Grid Optical Networks 17 draft-ietf-ccamp-flexigrid-yang-02.txt 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. This document may not be modified, 23 and derivative works of it may not be created, except to publish it 24 as an RFC and to translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on April 25, 2019. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described in 56 Section 4.e of the Trust Legal Provisions and are provided without 57 warranty as described in the Simplified BSD License. 59 Abstract 61 This document defines a YANG model for managing flexi-grid optical 62 Networks. The model described in this document defines a flexi-grid 63 traffic engineering database. A complementary module is referenced 64 to detail the flexi-grid media channels. 66 This module is grounded on other defined YANG abstract models. 68 Table of Contents 70 1. Introduction .............................................. 2 71 2. Conventions used in this document ......................... 3 72 3. Flexi-grid network topology model overview ................ 3 73 4. Main building blocks of the Flexi-grid TED................. 4 74 4.1 Formal Syntax ......................................... 7 75 5. Example of use ............................................ 8 76 6. Flexi-grid TED YANG Model.................................. 9 77 6.1. YANG Model - Tree .................................... 9 78 6.2. YANG Model - Code .................................... 27 79 6.3. License .............................................. 64 80 7. Security Considerations ................................... 65 81 8. IANA Considerations ....................................... 65 82 9. References ................................................ 65 83 9.1. Normative References ................................. 65 84 9.2. Informative References ............................... 66 85 10. Contributors ............................................. 66 86 11. Acknowledgments .......................................... 67 87 Authors' Addresses ........................................... 67 89 1. Introduction 91 Internet-based traffic is dramatically increasing every year. 92 Moreover, such traffic is also becoming more dynamic. Thus, 93 transport networks need to evolve from current DWDM systems towards 94 elastic optical networks, based on flexi-grid transmission and 95 switching technologies [RFC7698]. This technology aims at increasing 96 both transport network scalability and flexibility, allowing the 97 optimization of bandwidth usage. 99 This document presents a YANG model for flexi-grid objects in the 100 dynamic optical network, including the nodes, transponders and links 101 between them, as well as how such links interconnect nodes and 102 transponders. 104 The YANG model for flexi-grid networks allows the representation of 105 the flexi-grid optical layer of a network, combined with the 106 underlying physical layer. 108 This document identifies the flexi-grid components, parameters and 109 their values, characterizes the features and the performances of the 110 flexi-grid elements. An application example is provided towards the 111 end of the document to better understand their utility. 113 2. Conventions used in this document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 In this document, these words will appear with that interpretation 120 only when in ALL CAPS. Lower case uses of these words are not to be 121 interpreted as carrying RFC-2119 significance. 123 In this document, the characters ">>" preceding an indented line(s) 124 indicates a compliance requirement statement using the key words 125 listed above. This convention aids reviewers in quickly identifying 126 or finding the explicit compliance requirements of this RFC. 128 3. Flexi-grid network topology model overview 130 YANG is a data modeling language used to model configuration data 131 manipulated by the NETCONF protocol. Several YANG models have already 132 been specified for network configurations. For instance, the work in 133 [RFC8345] has proposed a generic YANG model for network/service 134 topologies and inventories. The work in 135 [I-D.draft-ietf-teas-yang-te-topo] presents a data model to 136 represent, retrieve and manipulate Traffic Engineering (TE) 137 Topologies. These models serve as base models that other technology 138 specific models can augment. A YANG model has also been proposed in 139 [I-D.draft-dharini-ccamp-dwdm-if-yang] to manage single channel 140 optical interface parameters of DWDM applications, and in 142 [I-D.draft-ietf-ccamp-wson-yang] another model has been specified for 143 the routing and wavelength assignment TE topology in wavelength 144 switched optical networks (WSONs). None of them are specific for 145 flexi-grid technology. 147 Then, as stated before, we propose a model to describe a flexi-grid 148 topology that is split in two YANG sub-modules: 150 o Flexi-grid-TED: In order to be compatible with existing 151 proposals, we augment the definitions contained in 152 [RFC8345] and [I-D.draft-ietf-teas-yang-te-topo], by defining 153 the different elements we can find in a flexi-grid network: 154 a node, a transponder and a link. For that, each of those elements 155 is defined as a container that includes a group of attributes. 156 References to the elements are provided to be later used in 157 the definition of a media channel. It also includes the data 158 types for the type of modulation, the flexi-grid technology, 159 the FEC, etc. 160 o Media-channel: This module defines the whole path from a source 161 transponder to the destination through a number of intermediate 162 nodes and links. For this, it takes the information defined before 163 in the flexi-grid TED. This module is described in 164 [I-D.draft-ietf-ccamp-flexigrid-media-channel-yang] 166 The following section provides a detailed view of the first module. 168 4. Main building blocks of the Flexi-grid TED 170 This section details the defined YANG module. It is listed below in 171 section 6. 173 The description of the three main components, flexi-grid-node, 174 flexi-grid-transponder and flexi-grid-link is provided below. 175 flexi-grid-sliceable-transponders are also defined. 177 ::= 179 : This element designates a node in the 180 network. 182 ::= 184 : Contains the configuration of a node. 185 ::= 186 188 : Contains all the 189 attributes related to the node configuration, such as 190 its interfaces or its management addresses. 192 ::= 193 194 195 [ / ] 197 : The list containing all the 198 information of the interfaces. 200 : Determines the interface name. 202 : Port number of the interface. 204 : Boolean value that defines 205 whether the interface is input or not. 207 : Boolean value that defines 208 whether the interface is output or not. 210 : Description of the usage of 211 the interface. 213 : Determines if the interface 214 is numbered or unnumbered. 216 ::= 217 : An interface with 218 its own IP address. 220 : Only available if 221 is "numbered-interface". 222 Determines the IP address of the interface. 224 ::= 225