idnits 2.17.1 draft-zheng-ccamp-client-tunnel-yang-07.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 (August 17, 2020) is 1320 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 (-36) exists of draft-ietf-teas-yang-te-25 == Outdated reference: A later version (-20) exists of draft-ietf-ccamp-otn-tunnel-model-10 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-wson-tunnel-model-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group H. Zheng 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track A. Guo 5 Expires: February 18, 2021 Futurewei 6 I. Busi 7 Huawei Technologies 8 Y. Xu 9 CAICT 10 Y. Zhao 11 China Mobile 12 X. Liu 13 Volta Networks 14 August 17, 2020 16 A YANG Data Model for Client-layer Tunnel 17 draft-zheng-ccamp-client-tunnel-yang-07 19 Abstract 21 A transport network is a server-layer network to provide connectivity 22 services to its client. In this draft the tunnel of client is 23 described, with the definition of client tunnel YANG model. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 18, 2021. 42 Copyright Notice 44 Copyright (c) 2020 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 (https://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 respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology and Notations . . . . . . . . . . . . . . . . . . 3 61 3. YANG Model for Client-layer Tunnel . . . . . . . . . . . . . 3 62 3.1. YANG Tree for Ethernet Tunnel . . . . . . . . . . . . . . 3 63 3.2. YANG Tree for Tunnel of other Client Signal Model . . . . 4 64 4. YANG Code for Client-layer Tunnel . . . . . . . . . . . . . . 4 65 4.1. The ETH Tunnel YANG Code . . . . . . . . . . . . . . . . 4 66 4.2. Other Client-layer Tunnel YANG Code . . . . . . . . . . . 6 67 5. Considerations and Open Issue . . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 7. Manageability Considerations . . . . . . . . . . . . . . . . 6 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 72 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 11.2. Informative References . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 A transport network is a server-layer network designed to provide 81 connectivity services for a client-layer network to carry the client 82 traffic transparently across the server-layer network resources. The 83 tunnel model in Traffic-Engineered network has been defined in both 84 generic way and technology-specific way. The generic model, which is 85 the base TE tunnel YANG model, can be found at 86 [I-D.ietf-teas-yang-te]. Technology-specific models, such as OTN/ 87 WSON tunnel model, have also been defined in 88 [I-D.ietf-ccamp-otn-tunnel-model] and 89 [I-D.ietf-ccamp-wson-tunnel-model] respectively. Corresponding 90 tunnel on client-layer is also required, to have a complete topology 91 view from the perspective of network controllers. 93 This document defines a data model of all client-layer tunnel, using 94 YANG language defined in [RFC7950]. The model is augmenting the 95 generic TE tunnel model, and can be used by applications exposing to 96 a network controller via a REST interface. Furthermore, it can be 97 used by an application to describe the client tunnel that constructed 98 above the server-layer network. It is also worth noting that the 99 client layer network will only need the tunnel model when there is a 100 demand for switching techniques, such as Carrier Ethernet and MPLS- 101 TP. The transparent signals do not need this model. 103 2. Terminology and Notations 105 A simplified graphical representation of the data model is used in 106 this document. The meaning of the symbols in the YANG data tree 107 presented later in this document is defined in [RFC8340]. They are 108 provided below for reference. 110 o Brackets "[" and "]" enclose list keys. 112 o Abbreviations before data node names: "rw" means configuration 113 (read-write) and "ro" state data (read-only). 115 o Symbols after data node names: "?" means an optional node, "!" 116 means a presence container, and "*" denotes a list and leaf-list. 118 o Parentheses enclose choice and case nodes, and case nodes are also 119 marked with a colon (":"). 121 o Ellipsis ("...") stands for contents of subtrees that are not 122 shown. 124 3. YANG Model for Client-layer Tunnel 126 3.1. YANG Tree for Ethernet Tunnel 127 module: ietf-eth-te-tunnel 128 augment /te:te/te:tunnels/te:tunnel: 129 +--rw src-eth-tunnel-endpoint 130 | +--rw vlanid? etht-types:vlanid 131 | +--rw tag-type? etht-types:eth-tag-type 132 +--rw dst-eth-tunnel-endpoint 133 | +--rw vlanid? etht-types:vlanid 134 | +--rw tag-type? etht-types:eth-tag-type 135 +--rw bandwidth-profile 136 +--rw bandwidth-profile-name? string 137 +--rw bandwidth-profile-type? etht-types:bandwidth-profile-type 138 +--rw CIR? uint64 139 +--rw CBS? uint64 140 +--rw EIR? uint64 141 +--rw EBS? uint64 142 +--rw color-aware? boolean 143 +--rw coupling-flag? boolean 145 3.2. YANG Tree for Tunnel of other Client Signal Model 147 This section will be completed later. 149 4. YANG Code for Client-layer Tunnel 151 4.1. The ETH Tunnel YANG Code 153 file "ietf-eth-te-tunnel@2018-03-01.yang" 155 module ietf-eth-te-tunnel { 157 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-te-tunnel"; 159 prefix "eth-tunnel"; 161 import ietf-te { 162 prefix "te"; 163 } 165 import ietf-eth-tran-types { 166 prefix "etht-types"; 167 } 169 organization 170 "Internet Engineering Task Force (IETF) CCAMP WG"; 171 contact 172 " 173 WG List: 175 ID-draft editor: 176 Haomian Zheng (zhenghaomian@huawei.com); 177 Italo Busi (italo.busi@huawei.com); 178 Aihua Guo (aihuaguo.ietf@gmail.com); 179 Yunbin Xu (xuyunbin@caict.ac.cn); 180 Yang Zhao (zhaoyangyjy@chinamobile.com); 181 Xufeng Liu (xufeng.liu.ietf@gmail.com); 182 "; 184 description 185 "This module defines a model for ETH transport tunnel"; 187 revision 2018-03-01 { 188 description 189 "Initial revision"; 190 reference 191 "draft-zheng-ccamp-client-tunnel-yang"; 192 } 194 grouping eth-tunnel-endpoint { 195 description "Parameters for ETH tunnel."; 197 leaf vlanid { 198 type etht-types:vlanid; 199 description 200 "VLAN tag id."; 201 } 203 leaf tag-type { 204 type etht-types:eth-tag-type; 205 description "VLAN tag type."; 206 } 207 } 209 augment "/te:te/te:tunnels/te:tunnel" { 210 description 211 "Augment with additional parameters required for ETH 212 service."; 214 container src-eth-tunnel-endpoint { 215 description 216 "Source ETH tunnel endpoint."; 218 uses eth-tunnel-endpoint; 219 } 221 container dst-eth-tunnel-endpoint { 222 description 223 "Destination ETH tunnel endpoint."; 225 uses eth-tunnel-endpoint; 226 } 228 container bandwidth-profile { 229 description 230 "ETH tunnel bandwidth profile specification."; 232 uses etht-types:etht-bandwidth-profiles; 233 } 234 } 235 } 237 239 4.2. Other Client-layer Tunnel YANG Code 241 TBD. 243 5. Considerations and Open Issue 245 Editor Notes: This section is used to note temporary discussion/ 246 conclusion that to be fixed in the future version, and will be 247 removed before publication. This is a part of L2 work, need to 248 discuss how to go with other L2 network models. The expectation is 249 to include all potential L2 TE part in this work. 251 6. IANA Considerations 253 TBD. 255 7. Manageability Considerations 257 TBD. 259 8. Security Considerations 261 The data following the model defined in this document is exchanged 262 via, for example, the interface between an orchestrator and a 263 transport network controller. The security concerns mentioned in 264 [I-D.ietf-teas-yang-te] also applies to this document. 266 The YANG module defined in this document can be accessed via the 267 RESTCONF protocol defined in [RFC8040], or maybe via the NETCONF 268 protocol [RFC6241]. 270 9. Acknowledgements 272 We would like to thank Igor Bryskin and Daniel King for their 273 comments and discussions. 275 10. Contributors 277 Yanlei Zheng 278 China Unicom 279 Email: zhengyl@dimpt.com 281 Zhe Liu 282 Huawei Technologies, 283 Email: liuzhe123@huawei.com 285 Sergio Belotti 286 Nokia, 287 Email: sergio.belotti@nokia.com 289 Yingxi Yao 290 Shanghai Bell, 291 yingxi.yao@nokia-sbell.com 293 Giuseppe Fioccola 294 Huawei Technologies 295 giuseppe.fioccola@huawei.com 297 11. References 299 11.1. Normative References 301 [I-D.ietf-teas-yang-te] 302 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 303 "A YANG Data Model for Traffic Engineering Tunnels, Label 304 Switched Paths and Interfaces", draft-ietf-teas-yang-te-25 305 (work in progress), July 2020. 307 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 308 and A. Bierman, Ed., "Network Configuration Protocol 309 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 310 . 312 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 313 RFC 7950, DOI 10.17487/RFC7950, August 2016, 314 . 316 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 317 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 318 . 320 11.2. Informative References 322 [I-D.ietf-ccamp-otn-tunnel-model] 323 Zheng, H., Busi, I., Belotti, S., Lopezalvarez, V., and Y. 324 Xu, "OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel- 325 model-10 (work in progress), March 2020. 327 [I-D.ietf-ccamp-wson-tunnel-model] 328 Lee, Y., Zheng, H., Guo, A., Lopezalvarez, V., King, D., 329 Yoon, B., and R. Vilata, "A Yang Data Model for WSON 330 Tunnel", draft-ietf-ccamp-wson-tunnel-model-05 (work in 331 progress), March 2020. 333 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 334 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 335 . 337 Authors' Addresses 339 Haomian Zheng 340 Huawei Technologies 341 H1, XiliuBeipo Village, Songshan Lake 342 Dongguan, Guangdong 523808 343 China 345 Email: zhenghaomian@huawei.com 347 Aihua Guo 348 Futurewei 350 Email: aihuaguo.ietf@gmail.com 352 Italo Busi 353 Huawei Technologies 355 Email: Italo.Busi@huawei.com 356 Yunbin Xu 357 CAICT 359 Email: xuyunbin@caict.ca.cn 361 Yang Zhao 362 China Mobile 364 Email: zhaoyangyjy@chinamobile.com 366 Xufeng Liu 367 Volta Networks 369 Email: xufeng.liu.ietf@gmail.com