idnits 2.17.1 draft-vergara-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 (March 1, 2016) is 2978 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 (-20) exists of draft-ietf-i2rs-yang-network-topo-02 Summary: 0 errors (**), 0 flaws (~~), 2 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 V. Lopez 4 Expires: August 28, 2016 O. Gonzalez de Dios 5 Telefonica I+D/GCTO 6 D. King 7 Lancaster University 8 Y. Lee 9 Huawei 10 Z. Ali 11 Cisco Systems 12 March 1, 2016 14 YANG data model for Flexi-Grid Optical Networks 15 draft-vergara-ccamp-flexigrid-yang-02.txt 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. This document may not be modified, 21 and derivative works of it may not be created, except to publish it 22 as an RFC and to translate it into languages other than English. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on August 28, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 Abstract 59 This document defines a YANG model for managing flexi-grid optical 60 Networks. The model described in this document is composed of two 61 submodels: one to define a flexi-grid traffic engineering database, 62 and other one to describe the flexi-grid paths or media channels. 64 Table of Contents 66 1. Introduction .............................................. 2 67 2. Conventions used in this document ......................... 3 68 3. Flexi-grid network topology model overview ................ 3 69 4. Main building blocks....................................... 4 70 4.1. flexi-grid TED ....................................... 4 71 4.2. Media-channel/network-media-channel .................. 7 72 5. Example of use ............................................ 9 73 6. Formal Syntax ............................................. 11 74 7. Security Considerations ................................... 11 75 8. IANA Considerations ....................................... 11 76 9. References ................................................ 11 77 9.1. Normative References ................................. 11 78 9.2. Informative References ............................... 12 79 10. Contributors ............................................. 12 80 11. Acknowledgments .......................................... 12 81 Appendix A. YANG models....................................... 12 82 A.1. Flexi-grid TED YANG Model ............................ 13 83 A.1.1. YANG Model - Tree .................................. 13 84 A.1.2. YANG MOdel - Code .................................. 14 85 A.2. Media Channel YANG Model ............................. 23 86 A.2.1. YANG Model - Tree .................................. 23 87 A.2.2. YANG Model - Code .................................. 24 88 A.3. License .............................................. 29 89 Authors' Addresses ........................................... 30 91 1. Introduction 93 Internet-based traffic is dramatically increasing every year. 94 Moreover, such traffic is also becoming more dynamic. Thus, 95 transport networks need to evolve from current DWDM systems towards 96 elastic optical networks, based on flexi-grid transmission and 97 switching technologies. This technology aims at increasing both 98 transport network scalability and flexibility, allowing the 99 optimization of bandwidth usage. 101 This document presents a YANG model for flexi-grid objects in the 102 dynamic optical network, including the nodes, transponders and links 103 between them, as well as how such links interconnect nodes and 104 transponders. 106 The YANG model for flexi-grid [RFC7698] networks allows the 107 representation of the flexi-grid optical layer of a network, combined 108 with the underlying physical layer. The model is defined in two YANG 109 modules: 111 o Flexi-grid-TED (Traffic Engineering Database): This module defines 112 all the information needed to represent the flexi-grid optical 113 node, transponder and link. 115 o Media-channel: This module defines the whole path from a source 116 transponder to the destination through a number of intermediate 117 nodes in the flexi-grid optical network. 119 This document identifies the flexi-grid components, parameters and 120 their values, characterizes the features and the performances of the 121 flexi-grid elements. An application example is provided towards the 122 end of the document to better understand their utility. 124 2. Conventions used in this document 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 In this document, these words will appear with that interpretation 131 only when in ALL CAPS. Lower case uses of these words are not to be 132 interpreted as carrying RFC-2119 significance. 134 In this document, the characters ">>" preceding an indented line(s) 135 indicates a compliance requirement statement using the key words 136 listed above. This convention aids reviewers in quickly identifying 137 or finding the explicit compliance requirements of this RFC. 139 3. Flexi-grid network topology model overview 141 YANG is a data modeling language used to model configuration data 142 manipulated by the NETCONF protocol. Several YANG models have already 143 been specified for network configurations. For instance, the work in 144 [I-D.draft-ietf-i2rs-yang-network-topo] has proposed a YANG model of 145 a TED, but only covering the IP layer. A YANG model has also been 146 proposed in [I-D.draft-dharini-netmod-g-698-2-yang] to configure 147 flexi-grid DWDM parameters. 149 As stated before, we propose a model to describe an flexi-grid 150 topology that is split in two YANG sub-modules: 152 o Flexi-grid-TED: In order to be compatible with existing 153 proposals, we augment the definitions contained in 154 [I-D.draft-ietf-i2rs-yang-network-topo], by defining the 155 different elements we find in an flexi-grid network: a node, a 156 transponder and a link. For that, each of those elements is 157 defined as a container that includes a group of attributes. 158 References to the elements are provided to be later used in the 159 definition of a media channel. It also includes the data types for 160 the type of modulation, the flexi-grid technology, the FEC, etc. 161 o Media-channel: This module defines the whole path from a source 162 transponder to the destination through a number of intermediate 163 nodes and links. For this, it takes the information defined before 164 in the flexi-grid TED. 166 The following section provides a detailed view of each module. 168 4. Main building blocks 170 Subsections below detail each of the defined YANG modules. They are 171 listed in Appendix A. 173 4.1. Flexi-grid TED 175 The description of the three main components, flexi-grid-node, 176 flexi-grid-transponder and flexi-grid-link is provided below. 177 flexi-grid-sliceable-transponders are also defined. 179 ::= 181 : This element designates a node in the network 183 ::= 184 186 : Contains all the attributes 187 related to the node, such as its unique id, its interfaces or 188 its management addresses. 190 : An unique numeric identifier for the node. It is 191 also used as a reference in order to point to it in the 192 media-channel module. 194 ::= 195 196 [ / ] 198 : The list containing all the 199 information of the interfaces 200 : Determines the interface name. 202 : Port number of the interface. 204 : Boolean value that defines whether the 205 interface is input or not. 207 : Boolean value that defines whether the 208 interface is output or not. 210 : Description of the usage of the interface. 212 : Determines if the interface is numbered 213 or unnumbered. 215 ::= 217 : A interface with its own IP 218 address 220 : Only available if 221 is "numbered-interface". Determines the IP address 222 of the interface. 224 ::=