idnits 2.17.1 draft-zhang-ccamp-l1-topo-yang-04.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 : ---------------------------------------------------------------------------- ** There are 290 instances of lines with control characters in the document. 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 14, 2016) is 2745 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-08 == 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: 2 errors (**), 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 17, 2017 Infinera 6 X. Liu 7 Ericsson 8 October 14, 2016 10 A YANG Data Model for Optical Transport Network Topology 11 draft-zhang-ccamp-l1-topo-yang-04 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 17, 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-14.yang" 233 module ietf-otn-topology { 234 yang-version 1; 235 namespace "urn:ietf:params:xml:ns:yang:ietf-otn-topology"; 236 prefix "otntopo"; 238 import ietf-network { 239 prefix "nd"; 240 } 242 import ietf-network-topology { 243 prefix "lnk"; 244 } 246 import ietf-te-topology { 247 prefix "tet"; 248 } 250 import ietf-transport-types { 251 prefix "tran-types"; 252 } 254 organization 255 "Internet Engineering Task Force (IETF) CCAMP WG"; 256 contact 257 " 258 WG List: 260 ID-draft editor: 261 Xian ZHANG (zhang.xian@huawei.com); 262 Anurag Sharma (AnSharma@infinera.com); 263 "; 265 description 266 "This module defines a protocol independent Layer 1/ODU 267 topology data model."; 269 revision 2016-10-14 { 270 description 271 "Initial version."; 272 reference 273 "draft-zhang-ccamp-l1-topo-yang-04.txt"; 274 } 276 /* 277 typedef 278 */ 280 typedef adaptation-type { 281 type enumeration { 282 enum CBR { 283 description 284 "Constant Bit Rate."; 285 } 286 enum ATMvp { 287 description 288 "ATM VP."; 289 } 290 enum GFP { 291 description 292 "Generic Framing Procedure."; 293 } 294 enum NULL { 295 description 296 "NULL"; 297 } 298 enum PRBS { 299 description 300 "Pseudo Random Binary Sequence"; 301 } 302 enum RSn { 303 description 304 "SDH/SONET section"; 305 } 306 enum ODUj-21 { 307 description 308 "ODU payload type 21"; 309 } 310 enum ETHERNET_PP-OS { 311 description 312 "ETHERNET_PP-OS, for ODU 2 only"; 313 } 314 enum CBRx { 315 description 316 "CBRx(0.. 1.25G), for ODU0 only"; 317 } 318 enum ODU { 319 description 320 "Optical Data Unit"; 321 } 322 } 324 description 325 "Defines a type representing the adaptation type 326 on the termination point."; 327 } 329 /* 330 Groupings 331 */ 333 grouping otn-topology-type { 334 container otn-topology { 335 presence "indicates a topology type of Optical 336 Transport Network (OTN)-electrical layer."; 337 description "otn topology type"; 338 } 339 description "otn-topology-type"; 340 } 342 grouping otn-topology-attributes { 343 leaf name { 344 type string; 345 description "the topology name"; 346 } 347 description "name attribute for otn topology"; 348 } 350 grouping otn-node-attributes { 351 description "otn-node-attributes"; 352 leaf name { 353 type string; 354 description "a name for this node."; 355 } 356 } 358 grouping otn-link-attributes { 359 description "otn link attributes"; 361 list available-odu-info{ 362 key "priority"; 363 max-elements "8"; 365 description 366 "List of ODU type and number on this link"; 368 leaf priority { 369 type uint8 { 370 range "0..7"; 371 } 372 description "priority"; 373 } 375 list odulist { 376 key "odu-type"; 377 description 378 "the list of available ODUs per priority level"; 379 leaf odu-type { 380 type identityref{ 381 base tran-types:tributary-protocol-type; 382 } 383 description "the type of ODU"; 384 } 386 leaf number { 387 type uint16; 388 description "the number of odu type supported"; 389 } 390 } 391 } 393 leaf distance { 394 type uint32; 395 description "distance in the unit of kilometers"; 396 } 397 } 399 grouping otn-tp-attributes { 400 description "otn-tp-attributes"; 402 leaf client-facing { 403 type empty; 404 description 405 "if present, it means this tp is a client-facing tp. 406 adding/dropping client signal flow."; 407 } 409 leaf tpn { 410 type uint16 { 411 range "0..4095"; 412 } 413 description 414 "Tributary Port Number. Applicable in case of mux services."; 415 reference 416 "RFC7139: GMPLS Signaling Extensions for Control of Evolving 417 G.709 Optical Transport Networks."; 418 } 420 leaf tsg { 421 type identityref { 422 base tran-types:tributary-slot-granularity; 423 } 424 description "Tributary slot granularity."; 425 reference 426 "G.709/Y.1331, February 2012: Interfaces for the Optical 427 Transport Network (OTN)"; 428 } 430 leaf protocol-type { 431 type identityref { 432 base tran-types:tributary-protocol-type; 433 } 434 description "Protocol type for the Termination Point."; 435 } 437 leaf adaptation-type { 438 type adaptation-type; 439 description 440 "This attribute indicates the type of the supported 441 adaptation function at the termination point."; 442 reference 443 "G.874.1, January 2002: Optical transport network (OTN): 444 Protocol-neutral management information model for the 445 network element view."; 446 } 448 leaf sink-adapt-active { 449 type boolean; 450 description 451 "This attribute allows for activation or deactivation of 452 the sink adaptation function. 453 The value of TRUE means active."; 454 reference 455 "G.874.1, January 2002: Optical transport network (OTN): 456 Protocol-neutral management information model for the 457 network element view "; 458 } 460 leaf source-adapt-active { 461 type boolean; 462 description 463 "This attribute allows for activation or deactivation of 464 the sink adaptation function. The value of TRUE 465 means active."; 466 reference 467 "G.874.1, January 2002: Optical transport network (OTN): 468 Protocol-neutral management information model for 469 the network element view "; 470 } 472 container tributaryslots { 473 description 474 "A list of tributary slots used by the ODU 475 Termination Point."; 476 leaf-list values { 477 type uint8; 478 description 479 "Tributary slot value."; 480 reference 481 "G.709/Y.1331, February 2012: Interfaces for the 482 Optical Transport Network (OTN)"; 483 } 484 } 486 list supported-payload-types{ 487 key "index"; 489 description "supported payload types of a TP"; 491 leaf index { 492 type uint16; 493 description "payload type index"; 494 } 496 leaf payload-type { 497 type string; 498 description "the payload type supported by this client 499 tp"; 500 reference 501 "http://www.iana.org/assignments/ 502 gmpls-sig-parameters/gmpls-sig-parameters.xhtml 503 not: the payload type is defined as the 504 generalized PIDs in GMPLS."; 505 } 506 } 507 } 509 /* 510 * Data nodes 511 */ 512 augment "/nd:networks/nd:network/nd:network-types/tet:te-topology"{ 513 uses otn-topology-type; 514 description "augment network types to include otn newtork"; 515 } 517 augment "/nd:networks/nd:network" { 518 when "nd:network-types/tet:te-topology/otn-topology" { 519 description "Augment only for otn network"; 520 } 521 uses otn-topology-attributes; 522 description "Augment network configuration"; 523 } 525 augment "/nd:networks/nd:network/nd:node" { 526 when "nd:network-types/tet:te-topology/otn-topology" { 527 description "Augment only for otn network"; 528 } 529 description "Augment node configuration"; 530 uses otn-node-attributes; 531 } 533 augment "/nd:networks/nd:network/lnk:link/tet:te/tet:config" { 534 when "nd:network-types/tet:te-topology/otn-topology" { 535 description "Augment only for otn network."; 536 } 537 description "Augment link configuration"; 539 uses otn-link-attributes; 540 } 542 augment "/nd:networks/nd:network/lnk:link/tet:te/tet:state" { 543 when "nd:network-types/tet:te-topology/otn-topology" { 544 description "Augment only for otn network."; 545 } 546 description "Augment link state"; 548 uses otn-link-attributes; 549 } 551 augment "/nd:networks/nd:network/nd:node/" 552 +"lnk:termination-point/tet:te/tet:config" { 553 when "nd:network-types/tet:te-topology/otn-topology" { 554 description "Augment only for otn network"; 555 } 556 description "OTN TP attributes config in a ODU topology."; 557 uses otn-tp-attributes; 558 } 560 augment "/nd:networks/nd:network/nd:node/" 561 +"lnk:termination-point/tet:te/tet:state" { 562 when "nd:network-types/tet:te-topology/otn-topology" { 563 description "Augment only for otn network"; 564 } 565 description "OTN TP attributes state in a ODU topology."; 566 uses otn-tp-attributes; 567 } 568 } 569 571 4. IANA Considerations 573 TBD. 575 5. Manageability Considerations 577 TBD. 579 6. Security Considerations 581 The data following the model defined in this draft is exchanged via, 582 for example, the interface between an orchestrator and a transport 583 network controller. The security concerns mentioned in 584 [I-D.ietf-teas-yang-te-topo] for using ietf-te-topology.yang model 585 also applies to this draft. 587 The YANG module defined in this document can be accessed via the 588 RESTCONF protocol defined in [I-D.ietf-netconf-restconf], or maybe 589 via the NETCONF protocol [RFC6241]. 591 There are a number of data nodes defined in the YANG module which are 592 writable/creatable/deletable (i.e., config true, which is the 593 default). These data nodes may be considered sensitive or vulnerable 594 in some network environments. Write operations (e.g., POST) to these 595 data nodes without proper protection can have a negative effect on 596 network operations. 598 Editors note: to list specific subtrees and data nodes and their 599 sensitivity/vulnerability. 601 7. Acknowledgements 603 We would like to thank Igor Bryskin, Zhe Liu, Dieter Beller and 604 Daniele Ceccarelli for their comments and discussions. 606 8. Contributors 608 Baoquan Rao 609 Huawei Technologies 610 Email: raobaoquan@huawei.com 612 Sergio Belotti 613 Alcatel Lucent 614 Email: Sergio.belotti@alcatel-lucent.com 615 Huub van Helvoort 616 Hai Gaoming BV 617 the Netherlands 618 Email: huubatwork@gmail.com 620 9. References 622 9.1. Normative References 624 [I-D.ietf-netconf-restconf] 625 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 626 Protocol", draft-ietf-netconf-restconf-17 (work in 627 progress), September 2016. 629 [I-D.ietf-netmod-rfc6087bis] 630 Bierman, A., "Guidelines for Authors and Reviewers of YANG 631 Data Model Documents", draft-ietf-netmod-rfc6087bis-08 632 (work in progress), September 2016. 634 [I-D.ietf-teas-yang-te-topo] 635 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 636 O. Dios, "YANG Data Model for TE Topologies", draft-ietf- 637 teas-yang-te-topo-05 (work in progress), July 2016. 639 [I-D.sharma-ccamp-otn-service-model] 640 ansharma@infinera.com, a., Rao, R., and X. Zhang, "OTN 641 Service YANG Model", draft-sharma-ccamp-otn-service- 642 model-00 (work in progress), July 2016. 644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 645 Requirement Levels", BCP 14, RFC 2119, 646 DOI 10.17487/RFC2119, March 1997, 647 . 649 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 650 the Network Configuration Protocol (NETCONF)", RFC 6020, 651 DOI 10.17487/RFC6020, October 2010, 652 . 654 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 655 and A. Bierman, Ed., "Network Configuration Protocol 656 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 657 . 659 [RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D. 660 Ceccarelli, "Framework for GMPLS and PCE Control of G.709 661 Optical Transport Networks", RFC 7062, 662 DOI 10.17487/RFC7062, November 2013, 663 . 665 [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and 666 J. Drake, "Traffic Engineering Extensions to OSPF for 667 GMPLS Control of Evolving G.709 Optical Transport 668 Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014, 669 . 671 9.2. Informative References 673 [I-D.ietf-ccamp-wson-yang] 674 Lee, Y., Dhody, D., Zhang, X., Guo, A., Lopezalvarez, V., 675 King, D., and B. Yoon, "A Yang Data Model for WSON Optical 676 Networks", draft-ietf-ccamp-wson-yang-03 (work in 677 progress), July 2016. 679 [I-D.vergara-ccamp-flexigrid-yang] 680 Madrid, U., Lopezalvarez, V., Dios, O., King, D., Lee, Y., 681 and Z. Ali, "YANG data model for Flexi-Grid Optical 682 Networks", draft-vergara-ccamp-flexigrid-yang-03 (work in 683 progress), July 2016. 685 Authors' Addresses 687 Xian Zhang 688 Huawei Technologies 689 F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District 690 Shenzhen, Guangdong 518129 691 P.R.China 693 Email: zhang.xian@huawei.com 695 Anurag Sharma 696 Infinera 698 Email: ansharma@infinera.com 700 Xufeng Liu 701 Ericsson 703 Email: xufeng.liu@ericsson.com