idnits 2.17.1 draft-zhang-ccamp-l1-topo-yang-05.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 == Line 160 has weird spacing: '...riority uin...' == Line 162 has weird spacing: '...du-type ide...' == Line 167 has weird spacing: '...riority uin...' == Line 169 has weird spacing: '...du-type ide...' -- The document date (October 26, 2016) is 2739 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 (-18) exists of draft-ietf-netconf-restconf-17 == Outdated reference: A later version (-20) exists of draft-ietf-netmod-rfc6087bis-09 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-05 ** Downref: Normative reference to an Informational RFC: RFC 7062 == Outdated reference: A later version (-28) exists of draft-ietf-ccamp-wson-yang-03 == Outdated reference: A later version (-06) exists of draft-vergara-ccamp-flexigrid-yang-03 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group X. Zhang 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track A. Sharma 5 Expires: April 29, 2017 Infinera 6 X. Liu 7 Ericsson 8 October 26, 2016 10 A YANG Data Model for Optical Transport Network Topology 11 draft-zhang-ccamp-l1-topo-yang-05 13 Abstract 15 A transport network is a server-layer network designed to provide 16 connectivity services for a client-layer network to carry the client 17 traffic transparently across the server-layer network resources. A 18 transport network can be constructed from equipments utilizing any of 19 a number of different transport technologies such as the evolving 20 Optical Transport Networks (OTN) or packet transport as provided by 21 the MPLS-Transport Profile (MPLS-TP). 23 This draft describes a YANG data model to describe the topologies of 24 an Optical Transport Network (OTN). It is independent of control 25 plane protocols and captures topological and resource related 26 information pertaining to OTN. This model enables clients, which 27 interact with a transport domain controller via a REST interface, for 28 OTN topology related operations such as obtaining the relevant 29 topology resource information. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 29, 2017. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Terminology and Notations . . . . . . . . . . . . . . . . . . 3 73 3. YANG Data Model for OTN Topology . . . . . . . . . . . . . . 4 74 3.1. the YANG Tree . . . . . . . . . . . . . . . . . . . . . . 4 75 3.2. Explanation of the OTN Topology Data Model . . . . . . . 5 76 3.3. The YANG Code . . . . . . . . . . . . . . . . . . . . . . 5 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 5. Manageability Considerations . . . . . . . . . . . . . . . . 13 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 81 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 84 9.2. Informative References . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 A transport network is a server-layer network designed to provide 90 connectivity services for a client-layer network to carry the client 91 traffic transparently across the server-layer network resources. A 92 transport network can be constructed of equipments utilizing any of a 93 number of different transport technologies such as the Optical 94 Transport Networks (OTN) or packet transport as provided by the MPLS- 95 Transport Profile (MPLS-TP). 97 This document defines a data model of an OTN network topology, using 98 YANG [RFC6020]. The model can be used by an application exposing to 99 a transport controller via a REST interface. Furthermore, it can be 100 used by an application for the following purposes (but not limited 101 to): 103 o To obtain a whole view of the network topology information of its 104 interest; 106 o To receive notifications with regard to the information change of 107 the OTN topology; 109 o To enforce the establishment and update of a network topology with 110 the characteristic specified in the data model, e.g., by a client 111 controller; 113 The YANG model defined in this draft is independent of control plane 114 protocols and captures topology related information pertaining to an 115 Optical Transport Networks (OTN)-electrical layer, as the scope 116 specified by [RFC7062] and [RFC7138]. Furthermore, it is not a 117 stand-alone model, but augmenting from the TE topology YANG model 118 defined in [I-D.ietf-teas-yang-te-topo]. 120 Optical network technologies, including fixed Dense Wavelength 121 Switched Optical Network (WSON) and flexible optical networks 122 (a.k.a., flexi-grid networks), are covered in 123 [I-D.ietf-ccamp-wson-yang] and [I-D.vergara-ccamp-flexigrid-yang], 124 respectively. 126 2. Terminology and Notations 128 A simplified graphical representation of the data model is used in 129 this document. The meaning of the symbols in the YANG data tree 130 presented later in this draft is defined in 131 [I-D.ietf-netmod-rfc6087bis]. They are provided below for reference. 133 o Brackets "[" and "]" enclose list keys. 135 o Abbreviations before data node names: "rw" means configuration 136 (read-write) and "ro" state data (read-only). 138 o Symbols after data node names: "?" means an optional node, "!" 139 means a presence container, and "*" denotes a list and leaf-list. 141 o Parentheses enclose choice and case nodes, and case nodes are also 142 marked with a colon (":"). 144 o Ellipsis ("...") stands for contents of subtrees that are not 145 shown. 147 3. YANG Data Model for OTN Topology 149 3.1. the YANG Tree 151 module: ietf-otn-topology 152 augment /nd:networks/nd:network/nd:network-types/tet:te-topology: 153 +--rw otn-topology! 154 augment /nd:networks/nd:network: 155 +--rw name? string 156 augment /nd:networks/nd:network/nd:node: 157 +--rw name? string 158 augment /nd:networks/nd:network/lnk:link/tet:te/tet:config: 159 +--rw available-odu-info* [priority] 160 | +--rw priority uint8 161 | +--rw odulist* [odu-type] 162 | +--rw odu-type identityref 163 | +--rw number? uint16 164 +--rw distance? uint32 165 augment /nd:networks/nd:network/lnk:link/tet:te/tet:state: 166 +--ro available-odu-info* [priority] 167 | +--ro priority uint8 168 | +--ro odulist* [odu-type] 169 | +--ro odu-type identityref 170 | +--ro number? uint16 171 +--ro distance? uint32 172 augment /nd:networks/nd:network/nd:node/lnk:termination-point 173 /tet:te/tet:config: 174 +--rw client-facing? empty 175 +--rw tpn? uint16 176 +--rw tsg? identityref 177 +--rw protocol-type? identityref 178 +--rw adaptation-type? adaptation-type 179 +--rw sink-adapt-active? boolean 180 +--rw source-adapt-active? boolean 181 +--rw tributaryslots 182 | +--rw values* uint8 183 +--rw supported-payload-types* [index] 184 +--rw index uint16 185 +--rw payload-type? string 186 augment /nd:networks/nd:network/nd:node/lnk:termination-point/ 187 tet:te/tet:state: 188 +--ro client-facing? empty 189 +--ro tpn? uint16 190 +--ro tsg? identityref 191 +--ro protocol-type? identityref 192 +--ro adaptation-type? adaptation-type 193 +--ro sink-adapt-active? boolean 194 +--ro source-adapt-active? boolean 195 +--ro tributaryslots 196 | +--ro values* uint8 197 +--ro supported-payload-types* [index] 198 +--ro index uint16 199 +--ro payload-type? string 201 3.2. Explanation of the OTN Topology Data Model 203 As can be seen, from the data tree shown in Section 3.1, the YANG 204 module presented in this draft augments from a more generic Traffic 205 Engineered (TE) network topology data model, i.e., the ietf-te- 206 topology.yang as specified in [I-D.ietf-teas-yang-te-topo]. The 207 entities and their attributes, such as node, termination points and 208 links, are still applicable for describing an OTN topology and the 209 model presented in this draft only specifies with technology-specific 210 attributes/information. For example, if the data plane complies with 211 ITU-T G.709 (2012) standards, the switching-capability and encoding 212 attributes MUST be filled as OTN-TDM and G.709 ODUk(Digital Path) 213 respectively. 215 Note the model in this draft re-uses some attributes defined in ietf- 216 transport-types.yang, which is specified in 217 [I-D.sharma-ccamp-otn-service-model]. 219 One of the main augmentations in this model is that it allows to 220 specify the type of ODU container and the number a link can support 221 per priority level. For example, for a ODU3 link, it may advertise 222 32*ODU0, 16*ODU1, 4*ODU2 available, assuming only a single priority 223 level is supported. If one of ODU2 resource is taken to establish a 224 ODU path, then the availability of this ODU link is updated as 225 24*ODU0, 12*ODU1, 3*ODU2 available. If there are equipment hardware 226 limitations, then a subset of potential ODU type SHALL be advertised. 227 For instance, an ODU3 link may only support 4*ODU2. 229 3.3. The YANG Code 231 file " ietf-otn-topology@2016-10-26.yang" 233 module ietf-otn-topology { 234 yang-version 1; 236 namespace "urn:ietf:params:xml:ns:yang:ietf-otn-topology"; 237 prefix "otntopo"; 239 import ietf-network { 240 prefix "nd"; 241 } 243 import ietf-network-topology { 244 prefix "lnk"; 245 } 247 import ietf-te-topology { 248 prefix "tet"; 249 } 251 import ietf-transport-types { 252 prefix "tran-types"; 253 } 255 organization 256 "Internet Engineering Task Force (IETF) CCAMP WG"; 257 contact 258 " 259 WG List: 261 ID-draft editor: 262 Xian ZHANG (zhang.xian@huawei.com); 263 Anurag Sharma (AnSharma@infinera.com); 264 "; 266 description 267 "This module defines a protocol independent Layer 1/ODU 268 topology data model."; 270 revision 2016-10-26 { 271 description 272 "Initial version."; 273 reference 274 "draft-zhang-ccamp-l1-topo-yang-04.txt"; 275 } 277 /* 278 typedef 279 */ 281 typedef adaptation-type { 282 type enumeration { 283 enum CBR { 284 description "Constant Bit Rate."; 285 } 286 enum ATMvp { 287 description "ATM VP."; 288 } 289 enum GFP { 290 description "Generic Framing Procedure."; 291 } 292 enum NULL { 293 description "NULL"; 294 } 295 enum PRBS { 296 description "Pseudo Random Binary Sequence"; 297 } 298 enum RSn { 299 description "SDH/SONET section"; 300 } 301 enum ODUj-21 { 302 description "ODU payload type 21"; 303 } 304 enum ETHERNET_PP-OS { 305 description "ETHERNET_PP-OS, for ODU 2 only"; 306 } 307 enum CBRx { 308 description "CBRx(0.. 1.25G), for ODU0 only"; 309 } 310 enum ODU { 311 description "Optical Data Unit"; 312 } 313 } 315 description 316 "Defines a type representing the adaptation type 317 on the termination point."; 318 } 320 /* 321 Groupings 322 */ 324 grouping otn-topology-type { 325 container otn-topology { 326 presence "indicates a topology type of Optical 327 Transport Network (OTN)-electrical layer."; 328 description "otn topology type"; 330 } 331 description "otn-topology-type"; 332 } 334 grouping otn-topology-attributes { 335 leaf name { 336 type string; 337 description "the topology name"; 338 } 339 description "name attribute for otn topology"; 340 } 342 grouping otn-node-attributes { 343 description "otn-node-attributes"; 344 leaf name { 345 type string; 346 description "a name for this node."; 347 } 348 } 350 grouping otn-link-attributes { 351 description "otn link attributes"; 353 list available-odu-info{ 354 key "priority"; 355 max-elements "8"; 357 description 358 "List of ODU type and number on this link"; 359 leaf priority { 360 type uint8 { 361 range "0..7"; 362 } 363 description "priority"; 364 } 366 list odulist { 367 key "odu-type"; 369 description 370 "the list of available ODUs per priority level"; 372 leaf odu-type { 373 type identityref{ 374 base tran-types:tributary-protocol-type; 375 } 376 description "the type of ODU"; 377 } 378 leaf number { 379 type uint16; 380 description "the number of odu type supported"; 381 } 382 } 383 } 385 leaf distance { 386 type uint32; 387 description "distance in the unit of kilometers"; 388 } 389 } 391 grouping otn-tp-attributes { 392 description "otn-tp-attributes"; 394 leaf client-facing { 395 type empty; 396 description 397 "if present, it means this tp is a client-facing tp. 398 adding/dropping client signal flow."; 399 } 401 leaf tpn { 402 type uint16 { 403 range "0..4095"; 404 } 405 description 406 "Tributary Port Number. Applicable in case of mux services."; 407 reference 408 "RFC7139: GMPLS Signaling Extensions for Control of Evolving 409 G.709 Optical Transport Networks."; 410 } 412 leaf tsg { 413 type identityref { 414 base tran-types:tributary-slot-granularity; 415 } 416 description "Tributary slot granularity."; 417 reference 418 "G.709/Y.1331, February 2012: Interfaces for the Optical 419 Transport Network (OTN)"; 420 } 422 leaf protocol-type { 423 type identityref { 424 base tran-types:tributary-protocol-type; 425 } 426 description "Protocol type for the Termination Point."; 427 } 429 leaf adaptation-type { 430 type adaptation-type; 431 description 432 "This attribute indicates the type of the supported 433 adaptation function at the termination point."; 434 reference 435 "G.874.1, January 2002: Optical transport network (OTN): 436 Protocol-neutral management information model for the 437 network element view."; 438 } 440 leaf sink-adapt-active { 441 type boolean; 442 description 443 "This attribute allows for activation or deactivation of 444 the sink adaptation function. The value of TRUE means active."; 446 reference 447 "G.874.1, January 2002: Optical transport network (OTN): 448 Protocol-neutral management information model for the 449 network element view "; 450 } 452 leaf source-adapt-active { 453 type boolean; 454 description 455 "This attribute allows for activation or deactivation of 456 the sink adaptation function. The value of TRUE 457 means active."; 458 reference 459 "G.874.1, January 2002: Optical transport network (OTN): 460 Protocol-neutral management information model for 461 the network element view "; 462 } 464 container tributaryslots { 465 description 466 "A list of tributary slots used by the ODU 467 Termination Point."; 468 leaf-list values { 469 type uint8; 470 description 471 "Tributary slot value."; 472 reference 473 "G.709/Y.1331, February 2012: Interfaces for the 474 Optical Transport Network (OTN)"; 475 } 476 } 478 list supported-payload-types{ 479 key "index"; 481 description "supported payload types of a TP"; 483 leaf index { 484 type uint16; 485 description "payload type index"; 486 } 488 leaf payload-type { 489 type string; 490 description "the payload type supported by this client 491 tp"; 492 reference 493 "http://www.iana.org/assignments/gmpls-sig-parameters 494 /gmpls-sig-parameters.xhtml 495 not: the payload type is defined as the generalized PIDs 496 in GMPLS."; 497 } 498 } 499 } 501 /* 502 * Data nodes 503 */ 504 augment "/nd:networks/nd:network/nd:network-types/tet:te-topology" { 505 uses otn-topology-type; 506 description "augment network types to include otn newtork"; 507 } 509 augment "/nd:networks/nd:network" { 510 when "nd:network-types/tet:te-topology/otn-topology" { 511 description "Augment only for otn network"; 512 } 513 uses otn-topology-attributes; 514 description "Augment network configuration"; 515 } 517 augment "/nd:networks/nd:network/nd:node" { 518 when "../nd:network-types/tet:te-topology/otn-topology" { 519 description "Augment only for otn network"; 520 } 521 description "Augment node configuration"; 522 uses otn-node-attributes; 523 } 525 augment "/nd:networks/nd:network/lnk:link/tet:te/tet:config" { 526 when "../../../nd:network-types/tet:te-topology/otn-topology" { 527 description "Augment only for otn network."; 528 } 529 description "Augment link configuration"; 531 uses otn-link-attributes; 532 } 534 augment "/nd:networks/nd:network/lnk:link/tet:te/tet:state" { 535 when "../../../nd:network-types/tet:te-topology/otn-topology" { 536 description "Augment only for otn network."; 537 } 538 description "Augment link state"; 540 uses otn-link-attributes; 541 } 543 augment "/nd:networks/nd:network/nd:node/" 544 +"lnk:termination-point/tet:te/tet:config" { 545 when "../../../../nd:network-types/tet:te-topology/otn-topology" { 546 description "Augment only for otn network"; 547 } 548 description "OTN TP attributes config in a ODU topology."; 549 uses otn-tp-attributes; 550 } 552 augment "/nd:networks/nd:network/nd:node/" 553 +"lnk:termination-point/tet:te/tet:state" { 554 when "../../../../nd:network-types/tet:te-topology/otn-topology" { 555 description "Augment only for otn network"; 556 } 557 description "OTN TP attributes state in a ODU topology."; 558 uses otn-tp-attributes; 559 } 560 } 562 564 4. IANA Considerations 566 TBD. 568 5. Manageability Considerations 570 TBD. 572 6. Security Considerations 574 The data following the model defined in this draft is exchanged via, 575 for example, the interface between an orchestrator and a transport 576 network controller. The security concerns mentioned in 577 [I-D.ietf-teas-yang-te-topo] for using ietf-te-topology.yang model 578 also applies to this draft. 580 The YANG module defined in this document can be accessed via the 581 RESTCONF protocol defined in [I-D.ietf-netconf-restconf], or maybe 582 via the NETCONF protocol [RFC6241]. 584 There are a number of data nodes defined in the YANG module which are 585 writable/creatable/deletable (i.e., config true, which is the 586 default). These data nodes may be considered sensitive or vulnerable 587 in some network environments. Write operations (e.g., POST) to these 588 data nodes without proper protection can have a negative effect on 589 network operations. 591 Editors note: to list specific subtrees and data nodes and their 592 sensitivity/vulnerability. 594 7. Acknowledgements 596 We would like to thank Igor Bryskin, Zhe Liu, Dieter Beller and 597 Daniele Ceccarelli for their comments and discussions. 599 8. Contributors 601 Baoquan Rao 602 Huawei Technologies 603 Email: raobaoquan@huawei.com 605 Sergio Belotti 606 Alcatel Lucent 607 Email: Sergio.belotti@alcatel-lucent.com 609 Huub van Helvoort 610 Hai Gaoming BV 611 the Netherlands 612 Email: huubatwork@gmail.com 614 9. References 616 9.1. Normative References 618 [I-D.ietf-netconf-restconf] 619 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 620 Protocol", draft-ietf-netconf-restconf-17 (work in 621 progress), September 2016. 623 [I-D.ietf-netmod-rfc6087bis] 624 Bierman, A., "Guidelines for Authors and Reviewers of YANG 625 Data Model Documents", draft-ietf-netmod-rfc6087bis-09 626 (work in progress), October 2016. 628 [I-D.ietf-teas-yang-te-topo] 629 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 630 O. Dios, "YANG Data Model for TE Topologies", draft-ietf- 631 teas-yang-te-topo-05 (work in progress), July 2016. 633 [I-D.sharma-ccamp-otn-service-model] 634 ansharma@infinera.com, a., Rao, R., and X. Zhang, "OTN 635 Service YANG Model", draft-sharma-ccamp-otn-service- 636 model-00 (work in progress), July 2016. 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, 640 DOI 10.17487/RFC2119, March 1997, 641 . 643 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 644 the Network Configuration Protocol (NETCONF)", RFC 6020, 645 DOI 10.17487/RFC6020, October 2010, 646 . 648 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 649 and A. Bierman, Ed., "Network Configuration Protocol 650 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 651 . 653 [RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D. 654 Ceccarelli, "Framework for GMPLS and PCE Control of G.709 655 Optical Transport Networks", RFC 7062, 656 DOI 10.17487/RFC7062, November 2013, 657 . 659 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 660 J. Drake, "Traffic Engineering Extensions to OSPF for 661 GMPLS Control of Evolving G.709 Optical Transport 662 Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014, 663 . 665 9.2. Informative References 667 [I-D.ietf-ccamp-wson-yang] 668 Lee, Y., Dhody, D., Zhang, X., Guo, A., Lopezalvarez, V., 669 King, D., and B. Yoon, "A Yang Data Model for WSON Optical 670 Networks", draft-ietf-ccamp-wson-yang-03 (work in 671 progress), July 2016. 673 [I-D.vergara-ccamp-flexigrid-yang] 674 Madrid, U., Lopezalvarez, V., Dios, O., King, D., Lee, Y., 675 and Z. Ali, "YANG data model for Flexi-Grid Optical 676 Networks", draft-vergara-ccamp-flexigrid-yang-03 (work in 677 progress), July 2016. 679 Authors' Addresses 681 Xian Zhang 682 Huawei Technologies 683 F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District 684 Shenzhen, Guangdong 518129 685 P.R.China 687 Email: zhang.xian@huawei.com 689 Anurag Sharma 690 Infinera 692 Email: ansharma@infinera.com 694 Xufeng Liu 695 Ericsson 697 Email: xufeng.liu@ericsson.com