idnits 2.17.1 draft-vergara-ccamp-flexigrid-yang-01.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 (July 6, 2015) is 3216 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 (-07) exists of draft-ietf-ccamp-flexi-grid-fwk-05 == Outdated reference: A later version (-20) exists of draft-ietf-i2rs-yang-network-topo-01 Summary: 0 errors (**), 0 flaws (~~), 3 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: January 7, 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 July 6, 2015 14 YANG data model for Flexi-Grid Optical Networks 15 draft-vergara-ccamp-flexigrid-yang-01.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 January 7, 2016. 42 Copyright Notice 44 Copyright (c) 2015 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 DWDM 60 Networks. The model described in this document is composed of two 61 submodels: one to define an flex-grid traffic engineering database, 62 and other one to describe the flex-grid paths or media channels. 64 Table of Contents 66 1. Introduction ...............................................2 67 2. Conventions used in this document ..........................3 68 3. Flex-grid network topology model overview ..................3 69 4. Main building blocks........................................5 70 4.1. Flex-grid TED .........................................5 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. Flex-grid TED YANG Model ..............................13 83 A.2. Media Channel YANG Model ..............................28 84 A.3. License ...............................................35 85 Authors' Addresses ............................................36 87 1. Introduction 89 Internet-based traffic is dramatically increasing every year. 90 Moreover, such traffic is also becoming more dynamic. Thus, 91 transport networks need to evolve from current DWDM systems towards 92 elastic optical networks, based on flexi-grid transmission and 93 switching technologies. This technology aims at increasing both 94 transport network scalability and flexibility, allowing the 95 optimization of bandwidth usage. 97 This document presents a YANG model for flex-grid objects in the 98 dynamic optical network, including the nodes, transponders and links 99 between them, as well as how such links interconnect nodes and 100 transponders. 102 The YANG model for flexi-grid [I-D.draft-ietf-ccamp-flexi-grid-fwk] 103 networks allows the representation of the flex-grid optical layer of 104 a network, combined with the underlying physical layer. The model is 105 defined in two YANG modules: 107 o Optical-TED (Traffic Engineering Database): This module defines 108 all the information needed to represent the flex-grid optical 109 node, an transponder and link. 111 o Media-channel: This module defines the whole path from a source 112 transponder to the destination through a number of intermediate 113 nodes. 115 This document identifies the flexi-grid components, parameters and 116 their values, characterizes the features and the performances of the 117 flex-grid elements. An application example is provided towards the 118 end of the document to better understand their utility. 120 2. Conventions used in this document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 In this document, these words will appear with that interpretation 127 only when in ALL CAPS. Lower case uses of these words are not to be 128 interpreted as carrying RFC-2119 significance. 130 In this document, the characters ">>" preceding an indented line(s) 131 indicates a compliance requirement statement using the key words 132 listed above. This convention aids reviewers in quickly identifying 133 or finding the explicit compliance requirements of this RFC. 135 3. Flex-grid network topology model overview 137 YANG is a data modeling language used to model configuration data 138 manipulated by the NETCONF protocol. Several YANG models have already 139 been specified for network configurations. For instance, the work in 140 [I-D.draft-ietf-i2rs-yang-network-topo] has proposed a YANG model of 141 a TED, but only covering the IP layer. A YANG model has also been 142 proposed in [I-D.draft-dharini-netmod-g-698-2-yang] to configure 143 flex-grid DWDM parameters. 145 As stated before, we propose a model to describe an flex-grid 146 topology that is split in two YANG sub-modules: 148 o flexgrid-TED: In order to be compatible with existing proposals, 149 we augment the definitions contained in [RFC6020], by defining the 150 different elements we find in an flex-grid network: a node, a 151 transponder and a link. For that, each of those elements is 152 defined as a container that includes a group of attributes. 153 References to the elements are provided to be later used in the 154 definition of a media channel. It also includes the data types for 155 the type of modulation, the flex-grid technology, the FEC, etc. 156 o Media-channel: This module defines the whole path from a source 157 transponder to the destination through a number of intermediate 158 nodes and links. For this, it takes the information defined before 159 in the flex-grid TED. 161 The following section provides a detailed view of each module. 163 4. Main building blocks 165 Subsections below detail each of the defined YANG modules. They are 166 listed in Appendix A. 168 4.1. Flex-grid TED 170 The description of the three main components, flex-grid-node, 171 flex-grid-transponder and flex-grid-link is provided below. 172 flex-grid-sliceable-transponders are also defined. 174 ::= 176 : This element designates a node in the network 178 ::= 179 181 : Contains all the attributes 182 related to the node, such as its unique id, its interfaces or 183 its management addresses. 185 : An unique numeric identifier for the node. It is 186 also used as a reference in order to point to it in the 187 media-channel module. 189 ::= 190 191 [ / ] 193 : The list containing all the 194 information of the interfaces 195 : Determines the interface name. 197 : Port number of the interface. 199 : Boolean value that defines whether the 200 interface is input or not. 202 : Boolean value that defines whether the 203 interface is output or not. 205 : Description of the usage of the interface. 207 : Determines if the interface is numbered 208 or unnumbered. 210 ::= 212 : A interface with its own IP 213 address 215 : Only available if 216 is "numbered-interface". Determines the IP address 217 of the interface. 219 ::=