idnits 2.17.1 draft-zheng-ccamp-otn-client-signal-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 : ---------------------------------------------------------------------------- ** There are 38 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 169 has weird spacing: '...le-name str...' == Line 246 has weird spacing: '...el-name str...' == Line 319 has weird spacing: '...el-name str...' == Line 717 has weird spacing: '...rouping etht-...' == Line 762 has weird spacing: '...rouping etht-...' -- The document date (October 30, 2017) is 2369 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-ccamp-otn-topo-yang-01 == 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 (-06) exists of draft-ietf-netmod-yang-tree-diagrams-02 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 H. Zheng 3 Internet-Draft A. Guo 4 Intended status: Standards Track I. Busi 5 Expires: May 3, 2018 Huawei Technologies 6 Y. Xu 7 CAICT 8 Y. Zhao 9 China Mobile 10 X. Liu 11 Jabil 12 G. Fioccola 13 Telecom Italia 14 October 30, 2017 16 A YANG Data Model for Optical Transport Network Client Signals 17 draft-zheng-ccamp-otn-client-signal-yang-01 19 Abstract 21 A transport network is a server-layer network to provide connectivity 22 services to its client. The topology and tunnel information in the 23 transport layer has already been defined by Traffic-engineered models 24 and OTN models, however, the access to the network has not been 25 described. These information is useful to both client and provider. 27 This draft describe how the client signals are carried over OTN and 28 defined corresponding YANG data model which is required during 29 configuration procedure. More specifically, several client signal 30 (of OTN) models including ETH, STM-n, FC and so on, are defined in 31 this draft. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 3, 2018. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology and Notations . . . . . . . . . . . . . . . . . . 3 69 3. OTN Client Signal Overview . . . . . . . . . . . . . . . . . 4 70 4. YANG Model for OTN Client Signal . . . . . . . . . . . . . . 4 71 4.1. YANG Tree for Ethernet Service . . . . . . . . . . . . . 4 72 4.2. YANG Tree for other OTN Client Signal Model . . . . . . . 8 73 5. YANG Code for OTN Client Signal . . . . . . . . . . . . . . . 8 74 5.1. The ETH Service YANG Code . . . . . . . . . . . . . . . . 8 75 5.2. YANG Code for ETH transport type . . . . . . . . . . . . 18 76 5.3. Other OTN client signal YANG Code . . . . . . . . . . . . 24 77 6. Considerations and Open Issue . . . . . . . . . . . . . . . . 24 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 79 8. Manageability Considerations . . . . . . . . . . . . . . . . 24 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 82 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 84 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 85 12.2. Informative References . . . . . . . . . . . . . . . . . 26 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 88 1. Introduction 90 A transport network is a server-layer network designed to provide 91 connectivity services for a client-layer network to carry the client 92 traffic transparently across the server-layer network resources. 93 Currently there has been topology and tunnel model defined for 94 transport network, such as [I-D.ietf-ccamp-otn-topo-yang] and 95 [I-D.ietf-ccamp-otn-tunnel-model], which has described the network 96 model between PEs. However, there is a missing piece between the PE 97 and CE, which is expected to be solved in this document. 99 This document defines a data model of all OTN network client signals, 100 using YANG language defined in [RFC7950]. The model can be used by 101 applications exposing to a transport controller via a REST interface. 102 Furthermore, it can be used by an application for the following 103 purposes (but not limited to): 105 o To request/update an end-to-end service by driving a new OTN 106 tunnel to be set up to support this service; 108 o To request/update an end-to-end service by using an existing OTN 109 tunnel; 111 o To receive notification with regard to the information change of 112 the given service; 114 The YANG model defined in this document is independent of control 115 plane protocols and captures topology related information pertaining 116 to an Optical Transport Networks (OTN)-electrical layer, as the scope 117 specified by [RFC7062] and [RFC7139]. Furthermore, it is not a 118 stand-alone model, but augmenting from the TE topology YANG model 119 defined in [I-D.ietf-teas-yang-te-topo]. 121 2. Terminology and Notations 123 A simplified graphical representation of the data model is used in 124 this document. The meaning of the symbols in the YANG data tree 125 presented later in this document is defined in 126 [I-D.ietf-netmod-yang-tree-diagrams]. They are provided below for 127 reference. 129 o Brackets "[" and "]" enclose list keys. 131 o Abbreviations before data node names: "rw" means configuration 132 (read-write) and "ro" state data (read-only). 134 o Symbols after data node names: "?" means an optional node, "!" 135 means a presence container, and "*" denotes a list and leaf-list. 137 o Parentheses enclose choice and case nodes, and case nodes are also 138 marked with a colon (":"). 140 o Ellipsis ("...") stands for contents of subtrees that are not 141 shown. 143 3. OTN Client Signal Overview 145 The OTN is usually a server-layer network designed to provide 146 connectivity services for a client-layer network to carry the client 147 traffic opaquely across the server-layer network resources. A 148 transport network may be constructed from equipments utilizing any of 149 a number of different transport technologies such as the evolving 150 optical transport infrastructure (SONET/SDH and OTN) or packet 151 transport as epitomized by the MPLS Transport Profile (MPLS-TP). 153 A full list of G-PID was summarized in [RFC7139], which can be 154 divided into a few categories of OTN client signal. The first 155 category of service type is Ethernet related, including GE, WAN/LAN 156 to support EPL/EVPL service. Another category of service type would 157 be client service which includes SDH/SONET, OTN service, SAN storage 158 (FICON, Fiber Channel) and other applications such as video service 159 (HD-SDI, 3G-SDI, etc.). 161 4. YANG Model for OTN Client Signal 163 4.1. YANG Tree for Ethernet Service 165 module: ietf-eth-tran-service 166 +--rw etht-svc 167 +--rw globals 168 | +--rw etht-svc-bandwidth-profiles* [bandwidth-profile-name] 169 | +--rw bandwidth-profile-name string 170 | +--rw bandwidth-profile-type? etht-types:bandwidth-profile-type 171 | +--rw CIR? uint64 172 | +--rw CBS? uint64 173 | +--rw EIR? uint64 174 | +--rw EBS? uint64 175 | +--rw color-aware? boolean 176 | +--rw coupling-flag? boolean 177 +--rw etht-svc-instances* [etht-svc-name] 178 +--rw etht-svc-name -> ../config/etht-svc-name 179 +--rw config 180 | +--rw etht-svc-name? string 181 | +--rw access-provider-id? te-types:te-global-id 182 | +--rw access-client-id? te-types:te-global-id 183 | +--rw access-topology-id? te-types:te-topology-id 184 | +--rw admin-status? identityref 185 | +--rw etht-svc-access-ports* [access-port-id] 186 | | +--rw access-port-id uint16 187 | | +--rw access-node-id? te-types:te-node-id 188 | | +--rw access-ltp-id? te-types:te-tp-id 189 | | +--rw service-classification-type? identityref 190 | | +--rw (service-classification)? 191 | | | +--:(port-classification) 192 | | | +--:(vlan-classification) 193 | | | +--rw outer-tag! 194 | | | | +--rw tag-type? etht-types:eth-tag-classify 195 | | | | +--rw (individual-bundling-vlan)? 196 | | | | +--:(individual-vlan) 197 | | | | | +--rw vlan-value? etht-types:vlanid 198 | | | | +--:(vlan-bundling) 199 | | | | +--rw vlan-range? etht-types:vid-range-type 200 | | | +--rw second-tag! 201 | | | +--rw tag-type? etht-types:eth-tag-classify 202 | | | +--rw (individual-bundling-vlan)? 203 | | | +--:(individual-vlan) 204 | | | | +--rw vlan-value? etht-types:vlanid 205 | | | +--:(vlan-bundling) 206 | | | +--rw vlan-range? etht-types:vid-range-type 207 | | +--rw (direction)? 208 | | | +--:(symmetrical) 209 | | | | +--rw ingress-egress-bandwidth-profile-name? string 210 | | | +--:(asymmetrical) 211 | | | +--rw ingress-bandwidth-profile-name? string 212 | | | +--rw egress-bandwidth-profile-name? string 213 | | +--rw vlan-operations 214 | | +--rw (direction)? 215 | | +--:(symmetrical) 216 | | | +--rw symmetrical-operation 217 | | | +--rw pop-tags? uint8 218 | | | +--rw push-tags 219 | | | +--rw outer-tag! 220 | | | | +--rw tag-type? etht-types:eth-tag-type 221 | | | | +--rw vlan-value? etht-types:vlanid 222 | | | +--rw second-tag! 223 | | | +--rw tag-type? etht-types:eth-tag-type 224 | | | +--rw vlan-value? etht-types:vlanid 225 | | +--:(asymmetrical) 226 | | +--rw asymmetrical-operation 227 | | +--rw ingress 228 | | | +--rw pop-tags? uint8 229 | | | +--rw push-tags 230 | | | +--rw outer-tag! 231 | | | | +--rw tag-type? etht-types:eth-tag-type 232 | | | | +--rw vlan-value? etht-types:vlanid 233 | | | +--rw second-tag! 234 | | | +--rw tag-type? etht-types:eth-tag-type 235 | | | +--rw vlan-value? etht-types:vlanid 236 | | +--rw egress 237 | | +--rw pop-tags? uint8 238 | | +--rw push-tags 239 | | +--rw outer-tag! 240 | | | +--rw tag-type? etht-types:eth-tag-type 241 | | | +--rw vlan-value? etht-types:vlanid 242 | | +--rw second-tag! 243 | | +--rw tag-type? etht-types:eth-tag-type 244 | | +--rw vlan-value? etht-types:vlanid 245 | +--rw etht-svc-tunnels* [tunnel-name] 246 | +--rw tunnel-name string 247 | +--rw (svc-multiplexing-tag)? 248 | +--:(other) 249 | +--:(none) 250 | +--:(vlan-tag) 251 | +--:(pw) 252 +--ro state 253 +--ro etht-svc-name? string 254 +--ro access-provider-id? te-types:te-global-id 255 +--ro access-client-id? te-types:te-global-id 256 +--ro access-topology-id? te-types:te-topology-id 257 +--ro admin-status? identityref 258 +--ro etht-svc-access-ports* [access-port-id] 259 | +--ro access-port-id uint16 260 | +--ro access-node-id? te-types:te-node-id 261 | +--ro access-ltp-id? te-types:te-tp-id 262 | +--ro service-classification-type? identityref 263 | +--ro (service-classification)? 264 | | +--:(port-classification) 265 | | +--:(vlan-classification) 266 | | +--ro outer-tag! 267 | | | +--ro tag-type? etht-types:eth-tag-classify 268 | | | +--ro (individual-bundling-vlan)? 269 | | | +--:(individual-vlan) 270 | | | | +--ro vlan-value? etht-types:vlanid 271 | | | +--:(vlan-bundling) 272 | | | +--ro vlan-range? etht-types:vid-range-type 273 | | +--ro second-tag! 274 | | +--ro tag-type? etht-types:eth-tag-classify 275 | | +--ro (individual-bundling-vlan)? 276 | | +--:(individual-vlan) 277 | | | +--ro vlan-value? etht-types:vlanid 278 | | +--:(vlan-bundling) 279 | | +--ro vlan-range? etht-types:vid-range-type 280 | +--ro (direction)? 281 | | +--:(symmetrical) 282 | | | +--ro ingress-egress-bandwidth-profile-name? string 283 | | +--:(asymmetrical) 284 | | +--ro ingress-bandwidth-profile-name? string 285 | | +--ro egress-bandwidth-profile-name? string 286 | +--ro vlan-operations 287 | +--ro (direction)? 288 | +--:(symmetrical) 289 | | +--ro symmetrical-operation 290 | | +--ro pop-tags? uint8 291 | | +--ro push-tags 292 | | +--ro outer-tag! 293 | | | +--ro tag-type? etht-types:eth-tag-type 294 | | | +--ro vlan-value? etht-types:vlanid 295 | | +--ro second-tag! 296 | | +--ro tag-type? etht-types:eth-tag-type 297 | | +--ro vlan-value? etht-types:vlanid 298 | +--:(asymmetrical) 299 | +--ro asymmetrical-operation 300 | +--ro ingress 301 | | +--ro pop-tags? uint8 302 | | +--ro push-tags 303 | | +--ro outer-tag! 304 | | | +--ro tag-type? etht-types:eth-tag-type 305 | | | +--ro vlan-value? etht-types:vlanid 306 | | +--ro second-tag! 307 | | +--ro tag-type? etht-types:eth-tag-type 308 | | +--ro vlan-value? etht-types:vlanid 309 | +--ro egress 310 | +--ro pop-tags? uint8 311 | +--ro push-tags 312 | +--ro outer-tag! 313 | | +--ro tag-type? etht-types:eth-tag-type 314 | | +--ro vlan-value? etht-types:vlanid 315 | +--ro second-tag! 316 | +--ro tag-type? etht-types:eth-tag-type 317 | +--ro vlan-value? etht-types:vlanid 318 +--ro etht-svc-tunnels* [tunnel-name] 319 | +--ro tunnel-name string 320 | +--ro (svc-multiplexing-tag)? 321 | +--:(other) 322 | +--:(none) 323 | +--:(vlan-tag) 324 | +--:(pw) 325 +--ro operational-state? identityref 326 +--ro provisioning-state? identityref 328 4.2. YANG Tree for other OTN Client Signal Model 330 This section will be completed later. 332 5. YANG Code for OTN Client Signal 334 5.1. The ETH Service YANG Code 336 file "ietf-eth-tran-service@2017-09-12.yang" 338 module ietf-eth-tran-service { 339 /* TODO: FIXME */ 340 yang-version 1.1; 342 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-tran-svc"; 344 prefix "ethtsvc"; 346 /* 347 import ietf-inet-types { 348 prefix "inet"; 349 } 350 */ 352 import ietf-te-types { 353 prefix "te-types"; 354 } 356 import ietf-eth-tran-types { 357 prefix "etht-types"; 358 } 360 organization 361 "Internet Engineering Task Force (IETF) CCAMP WG"; 362 contact 363 " 364 WG List: 366 ID-draft editor: 367 Haomian Zheng (zhenghaomian@huawei.com); 368 Italo Busi (italo.busi@huawei.com); 369 Aihua Guo (aihuaguo@huawei.com); 370 Yunbin Xu (xuyunbin@ritt.cn); 371 Yang Zhao (zhaoyangyjy@chinamobile.com); 372 Xufeng Liu (Xufeng_Liu@jabil.com); 373 Giuseppe Fioccola (giuseppe.fioccola@telecomitalia.it); 374 "; 376 description 377 "This module defines a YANG data model for describing 378 the Ethernet transport services."; 380 revision 2017-09-12 { 381 description 382 "Updated version: 384 Changed s-tag to vlan-tag choice in svc-multiplexing-tag 385 to support also services where the C-Tag is used 386 as service multiplexing tag 387 (assume proper coordination/configuration of C-Tag is adopted) 389 Added support for bandwidth profiles. 391 Split config and state data for Ethernet services. 392 "; 393 } 395 revision 2017-08-10 { 396 description 397 "Initial version"; 398 } 400 /* 401 Groupings 402 */ 404 grouping vlan-classification { 405 description 406 "A grouping which represents classification on an 802.1Q VLAN tag."; 408 leaf tag-type { 409 type etht-types:eth-tag-classify; 410 description 411 "The tag type used for VLAN classification."; 412 } 413 choice individual-bundling-vlan { 414 description 415 "VLAN based classification can be individual 416 or bundling."; 418 case individual-vlan { 419 leaf vlan-value { 420 type etht-types:vlanid; 421 description 422 "VLAN ID value."; 423 } 425 } 427 case vlan-bundling { 428 leaf vlan-range { 429 type etht-types:vid-range-type; 430 description 431 "List of VLAN ID values."; 432 } 433 } 434 } 435 } 437 grouping vlan-write { 438 description 439 "A grouping which represents push/pop operations 440 of an 802.1Q VLAN tag."; 442 leaf tag-type { 443 type etht-types:eth-tag-type; 444 description 445 "The VLAN tag type to push/swap."; 446 } 447 leaf vlan-value { 448 type etht-types:vlanid; 449 description 450 "The VLAN ID value to push/swap."; 451 } 452 } 454 grouping vlan-operations { 455 description 456 "A grouping which represents VLAN operations."; 458 leaf pop-tags { 459 type uint8 { 460 range "1..2"; 461 } 462 description 463 "The number of VLAN tags to pop (or swap if used in 464 conjunction with push-tags)"; 465 } 466 container push-tags { 467 description 468 "The VLAN tags to push (or swap if used in 469 conjunction with pop-tags)"; 471 container outer-tag { 472 presence 473 "Indicates existence of the outermost VLAN tag to 474 push/swap"; 476 description 477 "The outermost VLAN tag to push/swap."; 479 uses vlan-write; 480 } 481 container second-tag { 482 must 483 '../outer-tag/write-tag-type = "s-vlan-tag-type" and ' + 484 'write-tag-type = "c-vlan-tag-type"' 485 { 487 error-message 488 " 489 When pushing/swapping two tags, the outermost tag must 490 be specified and of S-VLAN type and the second 491 outermost tag must be of C-VLAN tag type. 492 "; 493 description 494 " 495 For IEEE 802.1Q interoperability, when pushing/swapping 496 two tags, it is required that the outermost tag exists 497 and is an S-VLAN, and the second outermost tag is a 498 C-VLAN. 499 "; 500 } 502 presence 503 "Indicates existence of a second outermost VLAN tag to 504 push/swap"; 506 description 507 "The second outermost VLAN tag to push/swap."; 509 uses vlan-write; 510 } 511 } 512 } 514 grouping bandwidth-profiles { 515 description 516 "A grouping which represent bandwidth profile configuration."; 518 choice direction { 519 description 520 "Whether the bandwidth profiles are symmetrical or 521 asymmetrical"; 522 case symmetrical { 523 description 524 "The same bandwidth profile is used to describe the ingress 525 and the egress bandwidth profile."; 527 leaf ingress-egress-bandwidth-profile-name { 528 type "string"; 529 description 530 "Name of the bandwidth profile."; 531 } 532 } 533 case asymmetrical { 534 description 535 "Ingress and egress bandwidth profiles can be specified."; 536 leaf ingress-bandwidth-profile-name { 537 type "string"; 538 description 539 "Name of the bandwidth profile used in 540 the ingress direction."; 541 } 542 leaf egress-bandwidth-profile-name { 543 type "string"; 544 description 545 "Name of the bandwidth profile used in 546 the egress direction."; 547 } 548 } 549 } 550 } 552 grouping etht-svc-access-parameters { 553 description 554 "ETH transport services access parameters"; 556 leaf access-node-id { 557 type te-types:te-node-id; 558 description 559 "The identifier of the access node in 560 the ETH transport topology."; 561 } 562 leaf access-ltp-id { 563 type te-types:te-tp-id; 564 description 565 "The TE link termination point identifier, used 566 together with access-node-id to identify the 567 access LTP."; 568 } 569 leaf service-classification-type { 570 type identityref { 571 base etht-types:service-classification-type; 572 } 573 description 574 "Service classification type."; 575 } 577 choice service-classification { 578 description 579 "Access classification can be port-based or 580 VLAN based."; 582 case port-classification { 583 /* no additional information */ 584 } 586 case vlan-classification { 587 container outer-tag { 588 presence "The outermost VLAN tag exists"; 589 description 590 "Classifies traffic using the outermost VLAN tag."; 592 uses vlan-classification; 593 } 594 container second-tag { 595 must 596 '../outer-tag/access-tag-type = "classify-s-vlan" and ' + 597 'access-tag-type = "classify-s-vlan"' 598 { 600 error-message 601 " 602 When matching two tags, the outermost tag must be 603 specified and of S-VLAN type and the second 604 outermost tag must be of C-VLAN tag type. 605 "; 606 description 607 " 608 For IEEE 802.1Q interoperability, when matching two 609 tags, it is required that the outermost tag exists 610 and is an S-VLAN, and the second outermost tag is a 611 C-VLAN. 612 "; 613 } 614 presence "The second outermost VLAN tag exists"; 616 description 617 "Classifies traffic using the second outermost VLAN tag."; 619 uses vlan-classification; 620 } 621 } 622 } 624 uses bandwidth-profiles; 626 container vlan-operations { 627 choice direction { 628 description 629 "Whether the VLAN operations are symmetrical or 630 asymmetrical"; 631 case symmetrical { 632 container symmetrical-operation { 633 uses vlan-operations; 634 description 635 "Symmetrical operations. 636 Expressed in the ingress direction, but 637 the reverse operation is applied to egress traffic"; 638 } 639 } 640 case asymmetrical { 641 container asymmetrical-operation { 642 description "Asymmetrical operations"; 643 container ingress { 644 uses vlan-operations; 645 description "Ingress operations"; 646 } 647 container egress { 648 uses vlan-operations; 649 description "Egress operations"; 650 } 651 } 652 } 653 } 654 } 655 } 657 grouping etht-svc-tunnel-parameters { 658 description 659 "ETH transport services tunnel parameters"; 661 leaf tunnel-name { 662 type string; 663 description 664 "TE service tunnel instance name."; 666 } 667 choice svc-multiplexing-tag { 668 description 669 "Service multiplexing is optional and flexible."; 671 case other { 672 /* 673 placeholder to support proprietary multiplexing 674 (for further discussion) 675 */ 676 } 678 case none { 679 /* no additional information is needed */ 680 } 682 case vlan-tag { 683 /* 684 No additional information is needed 685 The C-Tag or S-Tag used for service mulitplexing is defined 686 by the VLAN classification and operations configured in the 687 etht-svc-access-parameters grouping 688 */ 689 } 691 case pw { 692 /* to be completed (for further discussion) */ 693 } 694 } 695 } 697 grouping te-topology-identifier { 698 leaf access-provider-id { 699 type te-types:te-global-id; 700 description 701 "An identifier to uniquely identify a provider."; 702 } 703 leaf access-client-id { 704 type te-types:te-global-id; 705 description 706 "An identifier to uniquely identify a client."; 707 } 708 leaf access-topology-id { 709 type te-types:te-topology-id; 710 description 711 "Identifies the topology the 712 service access ports belong to."; 713 } 715 } 717 grouping etht-svc-instance_config { 718 description 719 "Configuraiton parameters for Ethernet services."; 721 leaf etht-svc-name { 722 type string; 723 description 724 "Name of the p2p ETH transport service."; 725 } 727 uses te-topology-identifier; 729 leaf admin-status { 730 type identityref { 731 base te-types:state-type; 732 } 733 default te-types:state-up; 734 description "ETH service administrative state."; 735 } 737 list etht-svc-access-ports { 738 key access-port-id; 739 min-elements "1"; 740 /* to be updated if extended to mp services */ 741 max-elements "2"; 742 description 743 "List of the ETH trasport services access port instances."; 745 leaf access-port-id { 746 type uint16; 747 description 748 "ID of the service access port instance"; 749 } 750 uses etht-svc-access-parameters; 751 } 752 list etht-svc-tunnels { 753 key tunnel-name; 754 description 755 "List of the TE Tunnels supporting the ETH 756 transport service."; 758 uses etht-svc-tunnel-parameters; 759 } 760 } 762 grouping etht-svc-instance_state { 763 description 764 "State parameters for Ethernet services."; 766 leaf operational-state { 767 type identityref { 768 base te-types:state-type; 769 } 770 description "ETH service operational state."; 771 } 772 leaf provisioning-state { 773 type identityref { 774 base te-types:prov-state-type; 775 } 776 description "ETH service provisioning state."; 777 } 778 } 780 /* 781 Data nodes 782 */ 784 container etht-svc { 785 description 786 "ETH transport services."; 788 container globals { 789 list etht-svc-bandwidth-profiles { 790 key bandwidth-profile-name; 791 description 792 "List of bandwidth profile templates used by 793 Ethernet services."; 795 uses etht-types:etht-bandwidth-profiles; 796 } 797 } 799 list etht-svc-instances { 800 key etht-svc-name; 801 description 802 "The list of p2p ETH transport service instances"; 804 leaf etht-svc-name { 805 type leafref { 806 path "../config/etht-svc-name"; 807 } 808 description 809 "ID of the p2p ETH transport service instance."; 810 } 811 container config { 812 description 813 "Configuration of intended parameters."; 815 uses etht-svc-instance_config; 816 } 818 container state { 819 config false; 820 description 821 "Configuration of applied parameters and states."; 823 uses etht-svc-instance_config; 824 uses etht-svc-instance_state; 825 } 826 } 827 } 828 } 830 832 5.2. YANG Code for ETH transport type 834 file "ietf-eth-tran-types@2017-09-12.yang" 836 module ietf-eth-tran-types { 837 /* TODO: FIXME */ 838 yang-version 1.1; 840 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-tran-types"; 842 prefix "etht-types"; 844 organization 845 "Internet Engineering Task Force (IETF) CCAMP WG"; 846 contact 847 " 848 WG List: 850 ID-draft editor: 851 Haomian Zheng (zhenghaomian@huawei.com); 852 Italo Busi (italo.busi@huawei.com); 853 Aihua Guo (aihuaguo@huawei.com); 854 Yunbin Xu (xuyunbin@ritt.cn); 855 Yang Zhao (zhaoyangyjy@chinamobile.com); 856 Xufeng Liu (Xufeng_Liu@jabil.com); 857 Giuseppe Fioccola (giuseppe.fioccola@telecomitalia.it); 858 "; 860 description 861 "This module defines the ETH transport types."; 863 revision 2017-09-12 { 864 description 865 "Updeated version: 867 Added bandwidth-profile-type 868 "; 869 } 871 revision 2017-08-10 { 872 description 873 "Initial version"; 874 } 876 /* 877 Identities 878 */ 880 identity eth-vlan-tag-type { 881 description 882 "ETH VLAN tag type."; 883 } 885 identity c-vlan-tag-type { 886 base eth-vlan-tag-type; 887 description 888 "802.1Q Customer VLAN"; 889 } 891 identity s-vlan-tag-type { 892 base eth-vlan-tag-type; 893 description 894 "802.1Q Service VLAN (QinQ)"; 895 } 897 identity service-classification-type { 898 description 899 "Service classification."; 900 } 902 identity port-classification { 903 base service-classification-type; 904 description 905 "Port classification."; 906 } 908 identity vlan-classification { 909 base service-classification-type; 910 description 911 "VLAN classification."; 912 } 914 identity eth-vlan-tag-classify { 915 description 916 "VLAN tag classification."; 917 } 919 identity classify-c-vlan { 920 base eth-vlan-tag-classify; 921 description 922 "Classify 802.1Q Customer VLAN tag. 923 Only C-tag type is accepted"; 924 } 926 identity classify-s-vlan { 927 base eth-vlan-tag-classify; 928 description 929 "Classify 802.1Q Service VLAN (QinQ) tag. 930 Only S-tag type is accepted"; 931 } 933 identity classify-s-or-c-vlan { 934 base eth-vlan-tag-classify; 935 description 936 "Classify S-VLAN or C-VLAN tag-classify. 937 Either tag is accepted"; 938 } 940 identity bandwidth-profile-type { 941 description 942 "Bandwidth Profile Types"; 943 } 945 identity mef-10-bwp { 946 base bandwidth-profile-type; 947 description 948 "MEF 10 Bandwidth Profile"; 949 } 951 identity rfc-2697-bwp { 952 base bandwidth-profile-type; 953 description 954 "RFC 2697 Bandwidth Profile"; 955 } 957 identity rfc-2698-bwp { 958 base bandwidth-profile-type; 959 description 960 "RFC 2698 Bandwidth Profile"; 961 } 963 identity rfc-4115-bwp { 964 base bandwidth-profile-type; 965 description 966 "RFC 4115 Bandwidth Profile"; 967 } 969 /* 970 Type Definitions 971 */ 973 typedef eth-tag-type { 974 type identityref { 975 base eth-vlan-tag-type; 976 } 977 description 978 "Identifies a specific ETH VLAN tag type."; 979 } 981 typedef eth-tag-classify { 982 type identityref { 983 base eth-vlan-tag-classify; 984 } 985 description 986 "Identifies a specific VLAN tag classification."; 987 } 989 typedef vlanid { 990 type uint16 { 991 range "1..4094"; 992 } 993 description 994 "The 12-bit VLAN-ID used in the VLAN Tag header."; 995 } 997 typedef vid-range-type { 998 type string { 999 pattern "([1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?" + 1000 "(,[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?)*)"; 1001 } 1002 description 1003 "A list of VLAN Ids, or non overlapping VLAN ranges, in 1004 ascending order, between 1 and 4094. 1006 This type is used to match an ordered list of VLAN Ids, or 1007 contiguous ranges of VLAN Ids. Valid VLAN Ids must be in the 1008 range 1 to 4094, and included in the list in non overlapping 1009 ascending order. 1011 For example: 1,10-100,50,500-1000"; 1012 } 1014 typedef bandwidth-profile-type { 1015 type identityref { 1016 base bandwidth-profile-type; 1017 } 1018 description 1019 "Identifies a specific Bandwidth Profile type."; 1020 } 1022 /* 1023 Grouping Definitions 1024 */ 1025 grouping etht-bandwidth-profiles { 1026 description 1027 "Bandwidth profile configuration paramters."; 1029 leaf bandwidth-profile-name { 1030 type string; 1031 description 1032 "Name of the bandwidth profile."; 1033 } 1034 leaf bandwidth-profile-type { 1035 type etht-types:bandwidth-profile-type; 1036 description 1037 "The type of bandwidth profile."; 1038 } 1039 leaf CIR { 1040 type uint64; 1041 description 1042 "Committed Information Rate in Kbps"; 1043 } 1044 leaf CBS { 1045 type uint64; 1046 description 1047 "Committed Burst Size in in KBytes"; 1049 } 1050 leaf EIR { 1051 type uint64; 1052 /* 1053 Need to indicate that EIR is not supported by RFC 2697 1055 must 1056 '../bw-profile-type = "mef-10-bwp" or ' + 1057 '../bw-profile-type = "rfc-2698-bwp" or ' + 1058 '../bw-profile-type = "rfc-4115-bwp"' 1060 must 1061 '../bw-profile-type != "rfc-2697-bwp"' 1062 */ 1063 description 1064 "Excess Information Rate in Kbps 1065 In case of RFC 2698, PIR = CIR + EIR"; 1066 } 1067 leaf EBS { 1068 type uint64; 1069 description 1070 "Excess Burst Size in KBytes. 1071 In case of RFC 2698, PBS = CBS + EBS"; 1072 } 1073 leaf color-aware { 1074 type boolean; 1075 description 1076 "Indicates weather the color-mode is 1077 color-aware or color-blind."; 1078 } 1079 leaf coupling-flag { 1080 type boolean; 1081 /* 1082 Need to indicate Coupling Flag is defined only for MEF 10 1084 must 1085 '../bw-profile-type = "mef-10-bwp"' 1086 */ 1087 description 1088 "Coupling Flag."; 1089 } 1090 } 1091 } 1093 1095 5.3. Other OTN client signal YANG Code 1097 TBD. 1099 6. Considerations and Open Issue 1101 Editor Notes: This section is used to note temporary discussion/ 1102 conclusion that to be fixed in the future version, and will be 1103 removed before publication. Currently this work only covers the 1104 Ethernet related service model. Other client signals would be 1105 defined in later version. We currently assume that there won't be 1106 much common part between Ethernet service model and other client 1107 signals service model, therefore the two groups of models are defined 1108 independetly. 1110 It is possible that there can be something in common for Ethernet 1111 service and other client signal service. If there is any need to 1112 construct a base model, we will also work it out in this draft. It 1113 is worth noting that a previous ID draft 1114 [I-D.zhang-teas-transport-service-model] is also addressing the same 1115 problem by defining a base model. But unfortunately we have not 1116 found any chance to augment to that model. Need to determine how we 1117 should go depending on the discussion in WG. 1119 7. IANA Considerations 1121 TBD. 1123 8. Manageability Considerations 1125 TBD. 1127 9. Security Considerations 1129 The data following the model defined in this document is exchanged 1130 via, for example, the interface between an orchestrator and a 1131 transport network controller. The security concerns mentioned in 1132 [I-D.ietf-teas-yang-te-topo] for using ietf-te-topology.yang model 1133 also applies to this document. 1135 The YANG module defined in this document can be accessed via the 1136 RESTCONF protocol defined in [RFC8040], or maybe via the NETCONF 1137 protocol [RFC6241]. 1139 There are a number of data nodes defined in the YANG module which are 1140 writable/creatable/deletable (i.e., config true, which is the 1141 default). These data nodes may be considered sensitive or vulnerable 1142 in some network environments. Write operations (e.g., POST) to these 1143 data nodes without proper protection can have a negative effect on 1144 network operations. 1146 Editors note: to list specific subtrees and data nodes and their 1147 sensitivity/vulnerability. 1149 10. Acknowledgements 1151 We would like to thank Igor Bryskin and Daniel King for their 1152 comments and discussions. 1154 11. Contributors 1156 Yanlei Zheng 1157 China Unicom 1158 Email: zhengyl@dimpt.com 1160 Zhe Liu 1161 Huawei Technologies, 1162 Email: liuzhe123@huawei.com 1164 Zheyu Fan 1165 Huawei Technologies, 1166 Email: fanzheyu2@huawei.com 1168 Sergio Belotti 1169 Nokia, 1170 Email: sergio.belotti@nokia.com 1172 Yingxi Yao 1173 Shanghai Bell, 1174 yingxi.yao@nokia-sbell.com 1176 12. References 1178 12.1. Normative References 1180 [I-D.ietf-ccamp-otn-topo-yang] 1181 zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., Liu, X., 1182 Belotti, S., Xu, Y., Wang, L., and O. Dios, "A YANG Data 1183 Model for Optical Transport Network Topology", draft-ietf- 1184 ccamp-otn-topo-yang-01 (work in progress), September 2017. 1186 [I-D.ietf-ccamp-otn-tunnel-model] 1187 zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., Rao, R., 1188 Belotti, S., Lopezalvarez, V., and Y. Li, "OTN Tunnel YANG 1189 Model", draft-ietf-ccamp-otn-tunnel-model-00 (work in 1190 progress), July 2017. 1192 [I-D.ietf-teas-yang-te-topo] 1193 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 1194 O. Dios, "YANG Data Model for Traffic Engineering (TE) 1195 Topologies", draft-ietf-teas-yang-te-topo-13 (work in 1196 progress), October 2017. 1198 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1199 and A. Bierman, Ed., "Network Configuration Protocol 1200 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1201 . 1203 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 1204 and K. Pithewan, "GMPLS Signaling Extensions for Control 1205 of Evolving G.709 Optical Transport Networks", RFC 7139, 1206 DOI 10.17487/RFC7139, March 2014, 1207 . 1209 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1210 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1211 . 1213 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1214 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1215 . 1217 12.2. Informative References 1219 [I-D.ietf-netmod-yang-tree-diagrams] 1220 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 1221 ietf-netmod-yang-tree-diagrams-02 (work in progress), 1222 October 2017. 1224 [I-D.zhang-teas-transport-service-model] 1225 Zhang, X. and J. Ryoo, "A Service YANG Model for 1226 Connection-oriented Transport Networks", draft-zhang-teas- 1227 transport-service-model-01 (work in progress), October 1228 2016. 1230 [RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D. 1231 Ceccarelli, "Framework for GMPLS and PCE Control of G.709 1232 Optical Transport Networks", RFC 7062, 1233 DOI 10.17487/RFC7062, November 2013, 1234 . 1236 Authors' Addresses 1238 Haomian Zheng 1239 Huawei Technologies 1240 F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District 1241 Shenzhen, Guangdong 518129 1242 P.R.China 1244 Email: zhenghaomian@huawei.com 1246 Aihua Guo 1247 Huawei Technologies 1249 Email: aihuaguo@huawei.com 1251 Italo Busi 1252 Huawei Technologies 1254 Email: Italo.Busi@huawei.com 1256 Yunbin Xu 1257 CAICT 1259 Email: xuyunbin@ritt.cn 1261 Yang Zhao 1262 China Mobile 1264 Email: zhaoyangyjy@chinamobile.com 1266 Xufeng Liu 1267 Jabil 1269 Email: Xufeng_Liu@jabil.com 1271 Giuseppe Fioccola 1272 Telecom Italia 1274 Email: giuseppe.fioccola@telecomitalia.it