idnits 2.17.1 draft-ietf-ccamp-flexigrid-yang-04.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 7, 2019) is 1748 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) == Missing Reference: 'RFCXXXX' is mentioned on line 166, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-layer0-types-01 == Outdated reference: A later version (-28) exists of draft-ietf-ccamp-wson-yang-22 == Outdated reference: A later version (-04) exists of draft-ietf-ccamp-flexigrid-media-channel-yang-02 Summary: 0 errors (**), 0 flaws (~~), 6 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: January 8, 2020 Naudit HPCN 5 V. Lopez 6 Telefonica I+D/GCTO 7 D. King 8 Lancaster University 9 Y. Lee 10 Futurewei 11 July 7, 2019 13 YANG data model for Flexi-Grid Optical Networks 14 draft-ietf-ccamp-flexigrid-yang-04.txt 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. This document may not be modified, 20 and derivative works of it may not be created, except to publish it 21 as an RFC and to translate it into languages other than English. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on January 8, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with 51 respect to this document. Code Components extracted from this 52 document must include Simplified BSD License text as described in 53 Section 4.e of the Trust Legal Provisions and are provided without 54 warranty as described in the Simplified BSD License. 56 Abstract 58 This document defines a YANG model for managing flexi-grid optical 59 Networks. The model described in this document defines a flexi-grid 60 traffic engineering database. A complementary module is referenced 61 to detail the flexi-grid media channels. 63 This module is grounded on other defined YANG abstract models. 65 Table of Contents 67 1. Introduction .............................................. 2 68 2. Conventions used in this document ......................... 3 69 2.1. Terminology .......................................... 3 70 2.2. Tree diagram ......................................... 71 2.3. Prefixes in Data Node Names .......................... 72 3. Flexi-grid network topology model overview ................ 73 4. Main building blocks of the Flexi-grid TED................. 74 4.1 Formal Syntax ......................................... 75 5. Example of use ............................................ 76 6. Flexi-grid TED YANG Model.................................. 77 6.1. YANG Model - Tree .................................... 78 6.2. YANG Model - Code .................................... 79 6.3. License .............................................. 80 7. Security Considerations ................................... 81 8. IANA Considerations ....................................... 82 9. References ................................................ 83 9.1. Normative References ................................. 84 9.2. Informative References ............................... 85 10. Contributors ............................................. 86 11. Acknowledgments .......................................... 87 Authors' Addresses ........................................... 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 [RFC7950] model for flexi-grid objects 100 in the dynamic optical network, including the nodes, transponders 101 and links between them, as well as how such links interconnect nodes 102 and 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 2.1. Terminology 130 Refer to [RFC7446] and [RFC7581] for the key terms used in this 131 document. 133 The following terms are defined in [RFC7950] and are not redefined 134 here: 136 o client 137 o server 138 o augment 139 o data model 140 o data node 142 The following terms are defined in [RFC6241] and are not redefined 143 here: 145 o configuration data 146 o state data 147 The terminology for describing YANG data models is found in 148 [RFC7950]. 150 2.2. Tree diagram 152 A simplified graphical representation of the data model is used in 153 chapter 6 of this this document. The meaning of the symbols in 154 these diagrams is defined in [RFC8340]. 156 2.3. Prefixes in Data Node Names 158 In this document, names of data nodes and other data model objects 159 are prefixed using the standard prefix associated with the 160 corresponding YANG imported modules, as shown in Table 1. 162 +-------------+-------------------------+-----------------+ 163 | Prefix | YANG module | Reference | 164 +-------------+-------------------------+-----------------+ 165 | layer0-type | ietf-layer0-types | [Layer0-Types] | 166 | flexi-grid | ietf-flexi-grid-topology| [RFCXXXX] | 167 | nw | ietf-network | [RFC8345] | 168 | nt | ietf-network-topology | [RFC8345] | 169 | tet | ietf-te-topology | [TE-TOPO] | 170 +-------------+-------------------------+-----------------+ 172 Table 1: Prefixes and corresponding YANG modules 174 Note: The RFC Editor will replace XXXX with the number assigned to 175 the RFC once this draft becomes an RFC. 177 3. Flexi-grid network topology model overview 179 YANG is a data modeling language used to model configuration data 180 manipulated by the NETCONF protocol. Several YANG models have already 181 been specified for network configurations. For instance, the work in 182 [RFC8345] has proposed a generic YANG model for network/service 183 topologies and inventories. The work in [TE-TOPO] presents a data 184 model to represent, retrieve and manipulate Traffic Engineering (TE) 185 Topologies. These models serve as base models that other technology 186 specific models can augment. A YANG model has also been proposed in 187 [I-D.draft-dharini-ccamp-dwdm-if-yang] to manage single channel 188 optical interface parameters of DWDM applications, and in 189 [I-D.draft-ietf-ccamp-wson-yang] another model has been specified for 190 the routing and wavelength assignment TE topology in wavelength 191 switched optical networks (WSONs). None of them are specific for 192 flexi-grid technology. 194 Then, as stated before, we propose a model to describe a flexi-grid 195 topology that is split in two YANG sub-modules: 197 o Flexi-grid-topology: In order to be compatible with existing 198 proposals, we augment the definitions contained in 199 [RFC8345] and [TE-TOPO], by defining the different elements we 200 can find in a flexi-grid network: a node, a transponder and a 201 link. For that, each of those elements is defined as a container 202 that includes a group of attributes. References to the elements 203 are provided to be later used in the definition of a media 204 channel. Data types for the type of modulation, the flexi-grid 205 technology, the FEC, etc. are defined in [Layer0-Types]. 206 o Media-channel: This module defines the whole path from a source 207 transponder to the destination through a number of intermediate 208 nodes and links. For this, it takes the information defined before 209 in the flexi-grid topology. This module is described in 210 [I-D.draft-ietf-ccamp-flexigrid-media-channel-yang]. 212 The following section provides a detailed view of the first module. 214 4. Main building blocks of the Flexi-grid topology 216 This section details the defined YANG module. It is listed below in 217 section 6. 219 The description of the three main components, flexi-grid-node, 220 flexi-grid-transponder and flexi-grid-link is provided below. 221 flexi-grid-sliceable-transponders are also defined. 223 ::= 225 : This element designates a node in the 226 network. 228 ::= 230 : Contains the configuration of a node. 231 ::= 232 234 : Contains all the 235 attributes related to the node configuration, such as 236 its interfaces or its management addresses. 237 ::= 238 239 240 [ / ] 241 : The list containing all the 242 information of the interfaces. 244 : Determines the interface name. 246 : Port number of the interface. 248 : Boolean value that defines 249 whether the interface is input or not. 251 : Boolean value that defines 252 whether the interface is output or not. 254 : Description of the usage of 255 the interface. 257 : Determines if the interface 258 is numbered or unnumbered. 260 ::= 261 : An interface with 262 its own IP address. 264 : Only available if 265 is "numbered-interface". 266 Determines the IP address of the interface. 268 ::= 269