idnits 2.17.1 draft-ietf-ccamp-otn-topo-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 189: '...oding attributes MUST be filled as OTN...' RFC 2119 keyword, line 203: '...otential ODU type SHALL be advertised....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 164 has weird spacing: '...riority uin...' -- The document date (October 30, 2017) is 2370 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-ccamp-otn-tunnel-model-00 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-13 == Outdated reference: A later version (-28) exists of draft-ietf-ccamp-wson-yang-08 == Outdated reference: A later version (-06) exists of draft-ietf-netmod-yang-tree-diagrams-02 == Outdated reference: A later version (-06) exists of draft-vergara-ccamp-flexigrid-yang-05 Summary: 1 error (**), 0 flaws (~~), 7 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 Z. Fan 4 Intended status: Standards Track Huawei Technologies 5 Expires: May 3, 2018 A. Sharma 6 Google 7 X. Liu 8 Jabil 9 S. Belotti 10 Nokia 11 Y. Xu 12 CAICT 13 L. Wang 14 China Mobile 15 O. Gonzalez de Dios 16 Telefonica 17 October 30, 2017 19 A YANG Data Model for Optical Transport Network Topology 20 draft-ietf-ccamp-otn-topo-yang-02 22 Abstract 24 A transport network is a server-layer network designed to provide 25 connectivity services for a client-layer network to carry the client 26 traffic transparently across the server-layer network resources. A 27 transport network can be constructed from equipments utilizing any of 28 a number of different transport technologies such as the evolving 29 Optical Transport Networks (OTN) or packet transport as provided by 30 the MPLS-Transport Profile (MPLS-TP). 32 This document describes a YANG data model to describe the topologies 33 of an Optical Transport Network (OTN). It is independent of control 34 plane protocols and captures topological and resource related 35 information pertaining to OTN. This model enables clients, which 36 interact with a transport domain controller via a REST interface, for 37 OTN topology related operations such as obtaining the relevant 38 topology resource information. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on May 3, 2018. 57 Copyright Notice 59 Copyright (c) 2017 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 75 2. Terminology and Notations . . . . . . . . . . . . . . . . . . 3 76 3. YANG Data Model for OTN Topology . . . . . . . . . . . . . . 4 77 3.1. the YANG Tree . . . . . . . . . . . . . . . . . . . . . . 4 78 3.2. Explanation of the OTN Topology Data Model . . . . . . . 4 79 3.3. The YANG Code . . . . . . . . . . . . . . . . . . . . . . 5 80 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 5. Manageability Considerations . . . . . . . . . . . . . . . . 9 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 84 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 87 9.2. Informative References . . . . . . . . . . . . . . . . . 11 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 90 1. Introduction 92 A transport network is a server-layer network designed to provide 93 connectivity services for a client-layer network to carry the client 94 traffic transparently across the server-layer network resources. A 95 transport network can be constructed of equipments utilizing any of a 96 number of different transport technologies such as the Optical 97 Transport Networks (OTN) or packet transport as provided by the MPLS- 98 Transport Profile (MPLS-TP). 100 This document defines a data model of an OTN network topology, using 101 YANG [RFC7950]. The model can be used by an application exposing to 102 a transport controller via a REST interface. Furthermore, it can be 103 used by an application for the following purposes (but not limited 104 to): 106 o To obtain a whole view of the network topology information of its 107 interest; 109 o To receive notifications with regard to the information change of 110 the OTN topology; 112 o To enforce the establishment and update of a network topology with 113 the characteristic specified in the data model, e.g., by a client 114 controller; 116 The YANG model defined in this document is independent of control 117 plane protocols and captures topology related information pertaining 118 to an Optical Transport Networks (OTN)-electrical layer, as the scope 119 specified by [RFC7062] and [RFC7138]. Furthermore, it is not a 120 stand-alone model, but augmenting from the TE topology YANG model 121 defined in [I-D.ietf-teas-yang-te-topo]. Following TE topology YANG 122 model, the YANG model defined in this document is interface 123 independent. The applicability of models to interfaces is described 124 in [I-D.zhang-teas-actn-yang]. 126 Optical network technologies, including fixed Dense Wavelength 127 Switched Optical Network (WSON) and flexible optical networks 128 (a.k.a., flexi-grid networks), are covered in 129 [I-D.ietf-ccamp-wson-yang] and [I-D.vergara-ccamp-flexigrid-yang], 130 respectively. 132 2. Terminology and Notations 134 A simplified graphical representation of the data model is used in 135 this document. The meaning of the symbols in the YANG data tree 136 presented later in this document is defined in 137 [I-D.ietf-netmod-yang-tree-diagrams]. They are provided below for 138 reference. 140 o Brackets "[" and "]" enclose list keys. 142 o Abbreviations before data node names: "rw" means configuration 143 (read-write) and "ro" state data (read-only). 145 o Symbols after data node names: "?" means an optional node, "!" 146 means a presence container, and "*" denotes a list and leaf-list. 148 o Parentheses enclose choice and case nodes, and case nodes are also 149 marked with a colon (":"). 151 o Ellipsis ("...") stands for contents of subtrees that are not 152 shown. 154 3. YANG Data Model for OTN Topology 156 3.1. the YANG Tree 158 module: ietf-otn-topology 159 augment /nw:networks/nw:network/nw:network-types/tet:te-topology: 160 +--rw otn-topology! 161 augment /nw:networks/nw:network/nt:link/tet:te 162 /tet:te-link-attributes: 163 +--rw available-odu-info* [priority] 164 | +--rw priority uint8 165 | +--rw odulist* [odu-type] 166 | | +--rw odu-type identityref 167 | | +--rw number? uint16 168 | | +--rw tpn-range? string 169 | +--rw ts-range? string 170 +--rw tsg? identityref 171 +--rw distance? uint32 172 augment /nw:networks/nw:network/nw:node/nt:termination-point 173 /tet:te: 174 +--rw supported-payload-types* [index] 175 +--rw index uint16 176 +--rw payload-type? string 178 3.2. Explanation of the OTN Topology Data Model 180 As can be seen, from the data tree shown in Section 3.1, the YANG 181 module presented in this document augments from a more generic 182 Traffic Engineered (TE) network topology data model, i.e., the ietf- 183 te-topology.yang as specified in [I-D.ietf-teas-yang-te-topo]. The 184 entities and their attributes, such as node, termination points and 185 links, are still applicable for describing an OTN topology and the 186 model presented in this document only specifies with technology- 187 specific attributes/information. For example, if the data plane 188 complies with ITU-T G.709 (2012) standards, the switching-capability 189 and encoding attributes MUST be filled as OTN-TDM and G.709 190 ODUk(Digital Path) respectively. 192 Note the model in this document re-uses some attributes defined in 193 ietf-transport-types.yang, which is specified in 194 [I-D.ietf-ccamp-otn-tunnel-model]. 196 One of the main augmentations in this model is that it allows to 197 specify the type of ODU container and the number a link can support 198 per priority level. For example, for a ODU3 link, it may advertise 199 32*ODU0, 16*ODU1, 4*ODU2 available, assuming only a single priority 200 level is supported. If one of ODU2 resource is taken to establish a 201 ODU path, then the availability of this ODU link is updated as 202 24*ODU0, 12*ODU1, 3*ODU2 available. If there are equipment hardware 203 limitations, then a subset of potential ODU type SHALL be advertised. 204 For instance, an ODU3 link may only support 4*ODU2. 206 3.3. The YANG Code 208 file "ietf-otn-topology@2017-10-30.yang" 210 module ietf-otn-topology { 211 yang-version 1.1; 213 namespace "urn:ietf:params:xml:ns:yang:ietf-otn-topology"; 214 prefix "otntopo"; 216 import ietf-network { 217 prefix "nw"; 218 } 220 import ietf-network-topology { 221 prefix "nt"; 222 } 224 import ietf-te-topology { 225 prefix "tet"; 226 } 228 import ietf-otn-types { 229 prefix "otn-types"; 230 } 232 organization 233 "IETF CCAMP Working Group"; 234 contact 235 "WG Web: 236 WG List: 238 Editor: Haomian Zheng 239 241 Editor: Zheyu Fan 242 244 Editor: Anurag Sharma 245 247 Editor: Xufeng Liu 248 250 Editor: Sergio Belotti 251 253 Editor: Yunbin Xu 254 256 Editor: Lei Wang 257 259 Editor: Oscar Gonzalez de Dios 260 "; 262 description 263 "This module defines a protocol independent Layer 1/ODU topology 264 data model."; 266 revision 2017-10-30 { 267 description 268 "Revision 0.5"; 269 reference 270 "draft-ietf-ccamp-otn-topo-yang-02.txt"; 271 } 273 /* 274 * Groupings 275 */ 276 grouping otn-link-attributes { 277 description "link attributes for OTN"; 279 list available-odu-info { 280 key "priority"; 281 max-elements "8"; 282 description "List of ODU type and number on this link"; 283 leaf priority { 284 type uint8 { 285 range "0..7"; 286 } 287 description "priority"; 288 } 289 list odulist { 290 key "odu-type"; 291 description 292 "the list of available ODUs per priority level"; 293 leaf odu-type { 294 type identityref { 295 base otn-types:tributary-protocol-type; 296 } 297 description "the type of ODU"; 298 } 299 leaf number { 300 type uint16; 301 description "the number of odu type supported"; 302 } 303 leaf tpn-range { 304 type string { 305 pattern "([1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?" 306 + "(,[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?)*)"; 307 } 308 description 309 "A list of available tributary port number range 310 between 1 and 9999. 311 For example 1-20,25,50-1000"; 312 reference "RFC 7139: GMPLS Signaling Extensions for Control 313 of Evolving G.709 Optical Transport Networks"; 314 } 315 } 316 leaf ts-range { 317 type string { 318 pattern "([1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?" 319 + "(,[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?)*)"; 320 } 321 description 322 "A list of available tributary slot range 323 between 1 and 9999. 324 For example 1-20,25,50-1000"; 325 reference "RFC 7139: GMPLS Signaling Extensions for Control 326 of Evolving G.709 Optical Transport Networks"; 327 } 328 } 329 leaf tsg { 330 type identityref { 331 base otn-types:tributary-slot-granularity; 333 } 334 description "Tributary slot granularity."; 335 reference 336 "G.709/Y.1331, February 2016: Interfaces for the 337 Optical Transport Network (OTN)"; 338 } 339 leaf distance { 340 type uint32; 341 description "distance in the unit of kilometers"; 342 } 343 } 345 grouping otn-tp-attributes { 346 description "tp attributes for OTN"; 347 list supported-payload-types { 348 key "index"; 349 description 350 "Supported payload types of a TP. The payload type is defined 351 as the generalized PIDs in GMPLS."; 352 leaf index { 353 type uint16; 354 description "payload type index"; 355 } 356 leaf payload-type { 357 type string; 358 description "the payload type supported by this client tp"; 359 reference 360 "http://www.iana.org/assignments/gmpls-sig-parameters 361 /gmpls-sig-parameters.xhtml"; 362 } 363 } 364 } 366 /* 367 * Data nodes 368 */ 369 augment "/nw:networks/nw:network/nw:network-types/" 370 + "tet:te-topology" { 371 container otn-topology { 372 presence "indicates a topology type of Optical Transport 373 Network (OTN)-electrical layer."; 374 description "otn topology type"; 375 } 376 description "augment network types to include otn newtork"; 377 } 379 augment "/nw:networks/nw:network/nt:link/tet:te/" 380 + "tet:te-link-attributes" { 382 when "../../../nw:network-types/tet:te-topology/" 383 + "otntopo:otn-topology" { 384 description "Augment only for otn network."; 385 } 386 description "Augment link configuration"; 387 uses otn-link-attributes; 388 } 390 augment "/nw:networks/nw:network/nw:node/nt:termination-point/" 391 + "tet:te" { 392 when "../../../nw:network-types/tet:te-topology/" 393 + "otntopo:otn-topology" { 394 description "Augment only for otn network"; 395 } 396 description "OTN TP attributes config in ODU topology."; 397 uses otn-tp-attributes; 398 } 399 } 401 403 4. IANA Considerations 405 TBD. 407 5. Manageability Considerations 409 TBD. 411 6. Security Considerations 413 The data following the model defined in this document is exchanged 414 via, for example, the interface between an orchestrator and a 415 transport network controller. The security concerns mentioned in 416 [I-D.ietf-teas-yang-te-topo] for using ietf-te-topology.yang model 417 also applies to this document. 419 The YANG module defined in this document can be accessed via the 420 RESTCONF protocol defined in [RFC8040], or maybe via the NETCONF 421 protocol [RFC6241]. 423 There are a number of data nodes defined in the YANG module which are 424 writable/creatable/deletable (i.e., config true, which is the 425 default). These data nodes may be considered sensitive or vulnerable 426 in some network environments. Write operations (e.g., POST) to these 427 data nodes without proper protection can have a negative effect on 428 network operations. 430 Editors note: to list specific subtrees and data nodes and their 431 sensitivity/vulnerability. 433 7. Acknowledgements 435 We would like to thank Igor Bryskin, Zhe Liu, and Daniele Ceccarelli 436 for their comments and discussions. 438 8. Contributors 440 Baoquan Rao 441 Huawei Technologies 442 Email: raobaoquan@huawei.com 444 Xian Zhang 445 Huawei Technologies 446 Email: zhang.xian@huawei.com 448 Huub van Helvoort 449 Hai Gaoming BV 450 the Netherlands 451 Email: huubatwork@gmail.com 453 Victor Lopez 454 Telefonica 455 Email: victor.lopezalvarez@telefonica.com 457 Yunbo Li 458 China Mobile 459 Email: liyunbo@chinamobile.com 461 Dieter Beller 462 Nokia 463 Email: dieter.beller@nokia.com 465 Yanlei Zheng 466 China Unicom 467 Email: zhengyl@dimpt.com 469 9. References 471 9.1. Normative References 473 [I-D.ietf-ccamp-otn-tunnel-model] 474 zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., Rao, R., 475 Belotti, S., Lopezalvarez, V., and Y. Li, "OTN Tunnel YANG 476 Model", draft-ietf-ccamp-otn-tunnel-model-00 (work in 477 progress), July 2017. 479 [I-D.ietf-teas-yang-te-topo] 480 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 481 O. Dios, "YANG Data Model for Traffic Engineering (TE) 482 Topologies", draft-ietf-teas-yang-te-topo-13 (work in 483 progress), October 2017. 485 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 486 and A. Bierman, Ed., "Network Configuration Protocol 487 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 488 . 490 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 491 J. Drake, "Traffic Engineering Extensions to OSPF for 492 GMPLS Control of Evolving G.709 Optical Transport 493 Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014, 494 . 496 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 497 RFC 7950, DOI 10.17487/RFC7950, August 2016, 498 . 500 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 501 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 502 . 504 9.2. Informative References 506 [I-D.ietf-ccamp-wson-yang] 507 Lee, Y., Dhody, D., Zhang, X., Guo, A., Lopezalvarez, V., 508 King, D., Yoon, B., and R. Vilata, "A Yang Data Model for 509 WSON Optical Networks", draft-ietf-ccamp-wson-yang-08 510 (work in progress), October 2017. 512 [I-D.ietf-netmod-yang-tree-diagrams] 513 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 514 ietf-netmod-yang-tree-diagrams-02 (work in progress), 515 October 2017. 517 [I-D.vergara-ccamp-flexigrid-yang] 518 Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., 519 King, D., Lee, Y., and G. Galimberti, "YANG data model for 520 Flexi-Grid Optical Networks", draft-vergara-ccamp- 521 flexigrid-yang-05 (work in progress), July 2017. 523 [I-D.zhang-teas-actn-yang] 524 Lee, Y., zhenghaomian@huawei.com, z., Yoon, B., Dios, O., 525 Shin, J., and S. Belotti, "Applicability of YANG models 526 for Abstraction and Control of Traffic Engineered 527 Networks", draft-zhang-teas-actn-yang-05 (work in 528 progress), June 2017. 530 [RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D. 531 Ceccarelli, "Framework for GMPLS and PCE Control of G.709 532 Optical Transport Networks", RFC 7062, 533 DOI 10.17487/RFC7062, November 2013, 534 . 536 Authors' Addresses 538 Haomian Zheng 539 Huawei Technologies 540 F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District 541 Shenzhen, Guangdong 518129 542 P.R.China 544 Email: zhenghaomian@huawei.com 546 Zheyu Fan 547 Huawei Technologies 548 F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District 549 Shenzhen, Guangdong 518129 550 P.R.China 552 Email: fanzheyu2@huawei.com 554 Anurag Sharma 555 Google 556 1600 Amphitheatre Parkway 557 Mountain View, CA 94043 559 Email: ansha@google.com 561 Xufeng Liu 562 Jabil 564 Email: Xufeng_Liu@jabil.com 565 Sergio Belotti 566 Nokia 568 Email: sergio.belotti@nokia.com 570 Yunbin Xu 571 CAICT 573 Email: xuyunbin@ritt.cn 575 Lei Wang 576 China Mobile 578 Email: wangleiyj@chinamobile.com 580 Oscar Gonzalez de Dios 581 Telefonica 583 Email: oscar.gonzalezdedios@telefonica.com