idnits 2.17.1 draft-ietf-ccamp-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 is 1 instance of too long lines in the document, the longest one being 4 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 336 has weird spacing: '...le-name str...' == Line 388 has weird spacing: '...oint-id str...' == Line 588 has weird spacing: '...rw name str...' == Line 622 has weird spacing: '...el-name str...' == Line 1018 has weird spacing: '...rouping etht-...' == (5 more instances...) -- The document date (November 3, 2019) is 1635 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) == Unused Reference: 'I-D.ietf-teas-yang-te-topo' is defined on line 2421, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-ccamp-l1csm-yang-10 == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-otn-topo-yang-09 == Outdated reference: A later version (-20) exists of draft-ietf-ccamp-otn-tunnel-model-09 == Outdated reference: A later version (-13) exists of draft-ietf-teas-yang-te-types-12 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group H. Zheng 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track A. Guo 5 Expires: May 6, 2020 Individual 6 I. Busi 7 Huawei Technologies 8 A. Snitser 9 Sedona 10 F. Lazzeri 11 Ericsson 12 Y. Xu 13 CAICT 14 Y. Zhao 15 China Mobile 16 X. Liu 17 Volta Networks 18 G. Fioccola 19 Huawei Technologies 20 November 3, 2019 22 A YANG Data Model for Transport Network Client Signals 23 draft-ietf-ccamp-client-signal-yang-01 25 Abstract 27 A transport network is a server-layer network to provide connectivity 28 services to its client. The topology and tunnel information in the 29 transport layer has already been defined by generic Traffic- 30 engineered models and technology-specific models (e.g., OTN, WSON). 31 However, how the client signals are accessing to the network has not 32 been described. These information is necessary to both client and 33 provider. 35 This draft describes how the client signals are carried over 36 transport network and defines YANG data models which are required 37 during configuration procedure. More specifically, several client 38 signal (of transport network) models including ETH, STM-n, FC and so 39 on, are defined in this draft. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on May 6, 2020. 58 Copyright Notice 60 Copyright (c) 2019 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.2. Prefixs in Model Names . . . . . . . . . . . . . . . . . 3 78 2. Terminology and Notations . . . . . . . . . . . . . . . . . . 4 79 3. Transport Network Client Signal Overview . . . . . . . . . . 4 80 3.1. Overview of Service Request and Network Configuration 81 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 4 82 3.2. Applicability of Proposed Model . . . . . . . . . . . . . 7 83 4. YANG Model for Transport Network Client Signal . . . . . . . 8 84 4.1. YANG Tree for Ethernet Service . . . . . . . . . . . . . 8 85 4.2. YANG Tree for other Transport Network Client Signal Model 13 86 5. YANG Code for Transport Network Client Signal . . . . . . . . 14 87 5.1. The ETH Service YANG Code . . . . . . . . . . . . . . . . 14 88 5.2. YANG Code for ETH type . . . . . . . . . . . . . . . . . 33 89 5.3. Other Client Signal YANG Code . . . . . . . . . . . . . . 43 90 5.4. Other Client Signal Types YANG Code . . . . . . . . . . . 48 91 6. Considerations and Open Issue . . . . . . . . . . . . . . . . 49 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 93 8. Manageability Considerations . . . . . . . . . . . . . . . . 51 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 51 95 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 96 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 98 12.1. Normative References . . . . . . . . . . . . . . . . . . 52 99 12.2. Informative References . . . . . . . . . . . . . . . . . 53 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 102 1. Introduction 104 1.1. Overview 106 A transport network is a server-layer network designed to provide 107 connectivity services for a client-layer network to carry the client 108 traffic transparently across the server-layer network resources. 109 Currently the topology and tunnel models which have been defined for 110 transport networks, such as [I-D.ietf-ccamp-otn-topo-yang] and 111 [I-D.ietf-ccamp-otn-tunnel-model], provide server-layer topology 112 abstraction and tunnel configuration between PEs. However, there is 113 a missing piece for configuring how the PEs should map the client- 114 layer traffic, received from the CE, over the server-layer-tunnels: 115 this gap is expected to be solved in this document. 117 This document defines a data model of all transport network client 118 signals, using YANG language defined in [RFC7950]. The model can be 119 used by applications exposing to a transport network controller via a 120 RESTconf interface. Furthermore, it can be used by an application 121 for the following purposes (but not limited to): 123 o To request/update an end-to-end service by driving a new tunnel to 124 be set up to support this service; 126 o To request/update an end-to-end service by using an existing 127 tunnel; 129 o To receive notification with regard to the information change of 130 the given service; 132 The YANG modules defined in this document conforms to the Network 133 Management Datastore Architecture (NMDA) defined in [RFC8342]. 135 1.2. Prefixs in Model Names 137 In this document, names of data nodes and other data model objects 138 are prefixed using the standard prefix associated with the 139 corresponding YANG imported modules, including [RFC6991], [RFC8294] 140 and [I-D.ietf-ccamp-otn-tunnel-model], which are shown as follow. 142 +-------------+---------------------------+----------------------+ 143 | Prefix | YANG module | Reference | 144 +-------------+---------------------------+----------------------+ 145 | yang | ietf-yang-types | [RFC6991] | 146 | te-types | ietf-te-types |[ietf-teas-yang-te-types]| 147 | rt-types | ietf-routing-types | [RFC8294] | 148 | otn-types | ietf-otn-types |[ietf-ccamp-otn-tunnel-model]| 149 | etht-types | ietf-eth-tran-types | This Document | 150 | clntsvc | ietf-trans-client-service | This Document | 151 | ethtsvc | ietf-eth-tran-service | This Document | 152 |clntsvc-types|ietf-trans-client-svc-types| This Document | 153 +-------------+---------------------------+----------------------+ 155 2. Terminology and Notations 157 A simplified graphical representation of the data model is used in 158 this document. The meaning of the symbols in the YANG data tree 159 presented later in this document is defined in [RFC8340]. They are 160 provided below for reference. 162 o Brackets "[" and "]" enclose list keys. 164 o Abbreviations before data node names: "rw" means configuration 165 (read-write) and "ro" state data (read-only). 167 o Symbols after data node names: "?" means an optional node, "!" 168 means a presence container, and "*" denotes a list and leaf-list. 170 o Parentheses enclose choice and case nodes, and case nodes are also 171 marked with a colon (":"). 173 o Ellipsis ("...") stands for contents of subtrees that are not 174 shown. 176 3. Transport Network Client Signal Overview 178 3.1. Overview of Service Request and Network Configuration Scenarios 180 A global view of a multi-domain service can be described as the 181 Figure 1 . The customer is usually responsible to configure the CE 182 nodes and to request to the provider the service intent, from the CE 183 nodes perspective, while the provider is responsible to configure the 184 whole network (including the PE nodes) to support the customer 185 service intent. Generally speaking, the network configurations 186 required to support a customer service can be split into two 187 different groups: CE-PE and PE-PE. The CE-PE configuration deals 188 with the client layer one-hop access link, while PE-PE configuration 189 deals with the server layer tunnel. In Figure 1 we mark the 190 intermediate nodes as 'P', which has same switching capability of PE 191 but just not the 'end-point'. In this example, the link P-P and PE-P 192 are a server-layer intra-domain or inter-domain link. 194 +----+ +----+ 195 | CE | | CE | 196 +--+-+ +--+-+ 197 | | 198 | ------------- -------------| 199 //|/ \\\\ ///// |\\\\ 200 // | \\ // | \\ 201 | +--+-+ +---+ +---+ | | +---+ +---+ +--+-+ | 202 | | PE +----+ P +--+ P +---+-----+--+ P +---+ P +---+ PE | | 203 | +----+ +---+ +---+ | | +---+ +---+ +----+ | 204 \\ // \\ // 205 \\\\ //// \\\\\ ///// 206 ------------- ------------- 207 Domain 1 Domain 2 209 Figure 1: Global view of Client Service with the Network Provider 211 According to the responsibilities of each controller in [RFC8453], 212 the controllers have different views of the service request and 213 network configuration. The duty of CNC is to give the MDSC a 214 description of the customer service intent: candidate YANG models 215 include L1CSM [I-D.ietf-ccamp-l1csm-yang], L2SM [RFC8466] and L3SM 216 [RFC8299], which are classified as customer service models, according 217 to [RFC8309]. These models provide necessary attributes to describe 218 the customer service intent from the customer/CE perspective, and do 219 not provide any specific network configuration. These models also 220 implies that the customer service description can be considered in a 221 separate manner rather than integratig with network configurations, 222 which also enable the controllers to abstract/virtualize the network 223 resource to make them visible to the customer and also easier to 224 manage. In other words, the network knowledge is not necessary at 225 CNC and CMI, which is seen in an abstracted form as shown in 226 Figure 2. 228 /---------\ 229 /// \\\ 230 +----+ | | +----+ 231 | CE |--------------+ NETWORK +----------------| CE | 232 +----+ | | +----+ 233 \\\ /// 234 \---------/ 236 Figure 2: CNC Viewpoint on the Client Service 238 The functionalities of MDSC have been described in [RFC8453], which 239 include the customer mapping/translation and multi-domain 240 coordination. By receiving the request from CNC, MDSC need to 241 understand what network configuration can support the customer 242 service intent and turn to the corresponding PNCs for configuration. 243 The service request is therefore decomposed by MDSC into a few 244 network configurations and forwarded to one or multiple PNCs 245 respectively in single-domain and multi-domain scenario. In general, 246 the MDSC has the view of both PE and CE nodes and of some abstract 247 information regarding the P nodes, as shown in Figure 3. It is worth 248 noting that this MDSC view is different with Figure 1 at the intra- 249 domain link. Usually these details are hidden, for scalability 250 purposes, and therefore the MDSC has only an abstract view of each 251 domain internal topology. 253 ------ ----- 254 //// \\\\ ///- -\\\ 255 // \\ // \\ 256 +----+ | +----+ +---+ | |+---+ +----+ | +----+ 257 | CE |-----+-| PE |-----| P |-+--+| P |-----| PE |-+-----| CE | 258 +----+ | +----+ +---+ | |+---+ +----+ | +----+ 259 \\ // \\ // 260 \\\\ //// \\\- -/// 261 ------ ----- 262 Domain 1 Domain 2 264 Figure 3: MDSC view of both Client Service and Network Abstraction 266 PNC is the controller that configure the physical devices, based on 267 the network configuration received from the MDSC. Each PNC has the 268 detailed view of its own domain, the example of view from PNC in 269 domain 1 is shown in Figure 4. The PNC has all the detailed topology 270 information on PE and P nodes and on the intra-domain links. The PNC 271 configures the tunnel/tunnel segment within its domain based on the 272 network configuration provided by the MDSC. The PNC also configures 273 the network part of the CE-PE access links as well as the mapping of 274 the client-layer traffic and the server-layer tunnels, based on the 275 network configuration provided by the MDSC. The interaction between 276 PNC and MDSC for the client-layer network configuration is 277 accomplished by the models defined in this draft. 279 | | | 280 | ------------- | -------------| 281 //|/ \\\\ | ///// |\\\\ 282 // | \\ | // | \\ 283 | +--+-+ +---+ +---+ | | | +---+ +---+ +--+-+ | 284 | | PE +----+ P +--+ P +---+--+--+--+ P +---+ P +---+ PE | | 285 | +----+ +---+ +---+ | | | +---+ +---+ +----+ | 286 \\ // | \\ // 287 \\\\ //// | \\\\\ ///// 288 ------------- | ------------- 289 PNC View in Domain 1 | PNC View in Domain 2 290 | 292 Figure 4: PNC view on Network Configuration 294 3.2. Applicability of Proposed Model 296 Existing TE and technology-specific models, such as topology models 297 and tunnel models, support the network configuration among PEs and 298 Ps. The customer service models, such as L1CSM, L2SM and L3SM, focus 299 on describing the attributes among CEs. However, there is a missing 300 piece on how to configure the CE-PE session. The models defined in 301 this document provide the configuration on CE-PE when the provider 302 server-layer network is TE-based technology. 304 In the example of OTN as the server-layer transport network, a full 305 list of G-PID was summarized in [RFC7139], which can be divided into 306 a few categories. The G-PID signals can be categorized into 307 transparent and non-transparent. Examples of transparent signals may 308 include Ethernetphysical interfaces, FC, STM-n and so on. In this 309 approach the OTN devices is not aware of the client signal type, and 310 this information is only necessary among the controllers. Once the 311 OTN tunnel is set up, there is no switching requested on the client 312 layer, and therefore only signal mapping is needed, without a client 313 tunnel set up. The models that supporting the configuration of 314 transparent signals are defined in Section 4.2. The other category 315 would be non-transparent, such as Carrier Ethernet and MPLS-TP, with 316 a switching request on the client layer. Once the OTN tunnel is set 317 up, a corresponding tunnel in the client layer has to be set up to 318 carry services. The models that supporting the configuration of 319 transparent signals are defined in Section 4.1. 321 It is also worth noting that some client signal can be carried over 322 multiple types of networks. For example, the Ethernet services can 323 be carried over either OTN or Ethernet TE tunnels (over optical or 324 microwave networks). The model specified in this document allows the 325 support from networks with different technologies. 327 4. YANG Model for Transport Network Client Signal 329 4.1. YANG Tree for Ethernet Service 331 module: ietf-eth-tran-service 332 +--rw etht-svc 333 +--rw globals 334 | +--rw named-bandwidth-profiles* 335 | [bandwidth-profile-name] 336 | +--rw bandwidth-profile-name string 337 | +--rw bandwidth-profile-type? 338 | | etht-types:bandwidth-profile-type 339 | +--rw CIR? uint64 340 | +--rw CBS? uint64 341 | +--rw EIR? uint64 342 | +--rw EBS? uint64 343 | +--rw color-aware? boolean 344 | +--rw coupling-flag? boolean 345 +--rw etht-svc-instances* [etht-svc-name] 346 +--rw etht-svc-name string 347 +--rw etht-svc-title? string 348 +--rw etht-svc-descr? string 349 +--rw etht-svc-customer? string 350 +--rw etht-svc-type? 351 | etht-types:service-type 352 +--rw etht-svc-lifecycle? 353 | etht-types:lifecycle-status 354 +--rw te-topology-identifier 355 | +--rw provider-id? te-global-id 356 | +--rw client-id? te-global-id 357 | +--rw topology-id? te-topology-id 358 +--rw resilience 359 | +--rw protection 360 | | +--rw enable? boolean 361 | | +--rw protection-type? 362 | | | identityref 363 | | +--rw protection-reversion-disable? boolean 364 | | +--rw hold-off-time? uint32 365 | | +--rw wait-to-revert? uint16 366 | | +--rw aps-signal-id? uint8 367 | +--rw restoration 368 | +--rw enable? boolean 369 | +--rw restoration-type? 370 | | identityref 371 | +--rw restoration-scheme? 372 | | identityref 373 | +--rw restoration-reversion-disable? boolean 374 | +--rw hold-off-time? uint32 375 | +--rw wait-to-restore? uint16 376 | +--rw wait-to-revert? uint16 377 +--rw etht-svc-end-points* [etht-svc-end-point-name] 378 | +--rw etht-svc-end-point-name 379 | | string 380 | +--rw etht-svc-end-point-id? 381 | | string 382 | +--rw etht-svc-end-point-descr? 383 | | string 384 | +--rw topology-role? 385 | | identityref 386 | +--rw resilience 387 | +--rw etht-svc-access-points* [access-point-id] 388 | | +--rw access-point-id string 389 | | +--rw access-node-id? te-types:te-node-id 390 | | +--rw access-ltp-id? te-types:te-tp-id 391 | | +--rw access-role? identityref 392 | | +--rw pm-config 393 | | | +--rw pm-enable? boolean 394 | | | +--rw sending-rate-high? uint64 395 | | | +--rw sending-rate-low? uint64 396 | | | +--rw receiving-rate-high? uint64 397 | | | +--rw receiving-rate-low? uint64 398 | | +--ro state 399 | | | +--ro operational-state? identityref 400 | | | +--ro provisioning-state? identityref 401 | | +--ro performance? identityref 402 | +--rw service-classification-type? 403 | | identityref 404 | +--rw (service-classification)? 405 | | +--:(port-classification) 406 | | +--:(vlan-classification) 407 | | +--rw outer-tag! 408 | | | +--rw tag-type? 409 | | | | etht-types:eth-tag-classify 410 | | | +--rw (individual-bundling-vlan)? 411 | | | +--:(individual-vlan) 412 | | | | +--rw vlan-value? 413 | | | | etht-types:vlanid 414 | | | +--:(vlan-bundling) 415 | | | +--rw vlan-range? 416 | | | etht-types:vid-range-type 417 | | +--rw second-tag! 418 | | +--rw tag-type? 419 | | | etht-types:eth-tag-classify 420 | | +--rw (individual-bundling-vlan)? 421 | | +--:(individual-vlan) 422 | | | +--rw vlan-value? 423 | | | etht-types:vlanid 424 | | +--:(vlan-bundling) 425 | | +--rw vlan-range? 426 | | etht-types:vid-range-type 427 | +--rw split-horizon-group? 428 | | string 429 | +--rw (direction)? 430 | | +--:(symmetrical) 431 | | | +--rw ingress-egress-bandwidth-profile 432 | | | +--rw (style)? 433 | | | +--:(named) 434 | | | | +--rw bandwidth-profile-name? 435 | | | | string 436 | | | +--:(value) 437 | | | +--rw bandwidth-profile-type? 438 | | | | etht-types:bandwidth-profile-type 439 | | | +--rw CIR? 440 | | | | uint64 441 | | | +--rw CBS? 442 | | | | uint64 443 | | | +--rw EIR? 444 | | | | uint64 445 | | | +--rw EBS? 446 | | | | uint64 447 | | | +--rw color-aware? 448 | | | | boolean 449 | | | +--rw coupling-flag? 450 | | | boolean 451 | | +--:(asymmetrical) 452 | | +--rw ingress-bandwidth-profile 453 | | | +--rw (style)? 454 | | | +--:(named) 455 | | | | +--rw bandwidth-profile-name? 456 | | | | string 457 | | | +--:(value) 458 | | | +--rw bandwidth-profile-type? 459 | | | | etht-types:bandwidth-profile-type 460 | | | +--rw CIR? 461 | | | | uint64 462 | | | +--rw CBS? 463 | | | | uint64 464 | | | +--rw EIR? 465 | | | | uint64 466 | | | +--rw EBS? 467 | | | | uint64 468 | | | +--rw color-aware? 469 | | | | boolean 470 | | | +--rw coupling-flag? 471 | | | boolean 472 | | +--rw egress-bandwidth-profile 473 | | +--rw (style)? 474 | | +--:(named) 475 | | | +--rw bandwidth-profile-name? 476 | | | string 477 | | +--:(value) 478 | | +--rw bandwidth-profile-type? 479 | | | etht-types:bandwidth-profile-type 480 | | +--rw CIR? 481 | | | uint64 482 | | +--rw CBS? 483 | | | uint64 484 | | +--rw EIR? 485 | | | uint64 486 | | +--rw EBS? 487 | | | uint64 488 | | +--rw color-aware? 489 | | | boolean 490 | | +--rw coupling-flag? 491 | | boolean 492 | +--rw vlan-operations 493 | +--rw (direction)? 494 | +--:(symmetrical) 495 | | +--rw symmetrical-operation 496 | | +--rw pop-tags? uint8 497 | | +--rw push-tags 498 | | +--rw outer-tag! 499 | | | +--rw tag-type? 500 | | | | etht-types:eth-tag-type 501 | | | +--rw vlan-value? 502 | | | | etht-types:vlanid 503 | | | +--rw default-pcp? uint8 504 | | +--rw second-tag! 505 | | +--rw tag-type? 506 | | | etht-types:eth-tag-type 507 | | +--rw vlan-value? 508 | | | etht-types:vlanid 509 | | +--rw default-pcp? uint8 510 | +--:(asymmetrical) 511 | +--rw asymmetrical-operation 512 | +--rw ingress 513 | | +--rw pop-tags? uint8 514 | | +--rw push-tags 515 | | +--rw outer-tag! 516 | | | +--rw tag-type? 517 | | | | etht-types:eth-tag-type 518 | | | +--rw vlan-value? 519 | | | | etht-types:vlanid 520 | | | +--rw default-pcp? uint8 521 | | +--rw second-tag! 522 | | +--rw tag-type? 523 | | | etht-types:eth-tag-type 524 | | +--rw vlan-value? 525 | | | etht-types:vlanid 526 | | +--rw default-pcp? uint8 527 | +--rw egress 528 | +--rw pop-tags? uint8 529 | +--rw push-tags 530 | +--rw outer-tag! 531 | | +--rw tag-type? 532 | | | etht-types:eth-tag-type 533 | | +--rw vlan-value? 534 | | | etht-types:vlanid 535 | | +--rw default-pcp? uint8 536 | +--rw second-tag! 537 | +--rw tag-type? 538 | | etht-types:eth-tag-type 539 | +--rw vlan-value? 540 | | etht-types:vlanid 541 | +--rw default-pcp? uint8 542 +--rw underlay 543 | +--rw (technology)? 544 | | +--:(native-ethernet) 545 | | | +--rw eth-tunnels* [name] 546 | | | +--rw name 547 | | | | -> /te:te/tunnels/tunnel/name 548 | | | +--rw encoding? identityref 549 | | | +--rw switching-type? identityref 550 | | +--:(frame-base) 551 | | | +--rw otn-tunnels* [name] 552 | | | +--rw name 553 | | | | -> /te:te/tunnels/tunnel/name 554 | | | +--rw encoding? identityref 555 | | | +--rw switching-type? identityref 556 | | +--:(mpls-tp) 557 | | +--rw pw 558 | | +--rw pw-id? 559 | | | string 560 | | +--rw pw-name? 561 | | | string 562 | | +--rw transmit-label? 563 | | | rt-types:mpls-label 564 | | +--rw receive-label? 565 | | | rt-types:mpls-label 566 | | +--rw encapsulation-type? 567 | | | identityref 568 | | +--ro oper-status? 569 | | | identityref 570 | | +--rw ingress-bandwidth-profile 571 | | | +--rw (style)? 572 | | | +--:(named) 573 | | | | +--rw bandwidth-profile-name? leafref 574 | | | +--:(value) 575 | | | +--rw bandwidth-profile-type? 576 | | | | etht-types:bandwidth-profile-type 577 | | | +--rw CIR? 578 | | | | uint64 579 | | | +--rw CBS? 580 | | | | uint64 581 | | | +--rw EIR? 582 | | | | uint64 583 | | | +--rw EBS? 584 | | | uint64 585 | | +--rw pw-paths* [path-id] 586 | | +--rw path-id uint8 587 | | +--rw tp-tunnels* [name] 588 | | +--rw name string 589 | +--rw src-split-horizon-group? string 590 | +--rw dst-split-horizon-group? string 591 +--rw admin-status? identityref 592 +--ro state 593 +--ro operational-state? identityref 594 +--ro provisioning-state? identityref 595 +--ro creation-time? yang:date-and-time 596 +--ro last-updated-time? yang:date-and-time 598 4.2. YANG Tree for other Transport Network Client Signal Model 599 module: ietf-trans-client-service 600 +--rw client-svc 601 +--rw client-svc-instances* [client-svc-name] 602 +--rw client-svc-name string 603 +--rw client-svc-title? string 604 +--rw client-svc-descr? string 605 +--rw client-svc-customer? string 606 +--rw resilience 607 +--rw te-topology-identifier 608 | +--rw provider-id? te-global-id 609 | +--rw client-id? te-global-id 610 | +--rw topology-id? te-topology-id 611 +--rw admin-status? identityref 612 +--rw src-access-ports 613 | +--rw access-node-id? te-types:te-node-id 614 | +--rw access-ltp-id? te-types:te-tp-id 615 | +--rw client-signal? identityref 616 +--rw dst-access-ports 617 | +--rw access-node-id? te-types:te-node-id 618 | +--rw access-ltp-id? te-types:te-tp-id 619 | +--rw client-signal? identityref 620 +--rw direction? identityref 621 +--rw svc-tunnels* [tunnel-name] 622 | +--rw tunnel-name string 623 +--ro operational-state? identityref 624 +--ro provisioning-state? identityref 625 +--ro creation-time? yang:date-and-time 626 +--ro last-updated-time? yang:date-and-time 628 5. YANG Code for Transport Network Client Signal 630 5.1. The ETH Service YANG Code 632 This module imports typedefs and modules from [RFC6991], [RFC8294], 633 [I-D.ietf-teas-yang-te-types]. 635 file "ietf-eth-tran-service@2019-11-03.yang" 636 module ietf-eth-tran-service { 637 yang-version 1.1; 638 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-tran-service"; 640 prefix "ethtsvc"; 642 import ietf-yang-types { 643 prefix "yang"; 644 reference "RFC 6991 - Common YANG Data Types"; 645 } 647 import ietf-te-types { 648 prefix "te-types"; 649 reference "RFC YYYY - Traffic Engineering Common YANG Types"; 650 } 652 import ietf-eth-tran-types { 653 prefix "etht-types"; 654 reference "RFC XXXX - A YANG Data Model for Transport 655 Network Client Signals"; 656 } 658 import ietf-routing-types { 659 prefix "rt-types"; 660 reference "RFC 8294 - Common YANG Data Types for the 661 Routing Area"; 663 } 665 import ietf-te { 666 prefix "te"; 667 reference "RFC YYYY - A YANG Data Model for Traffic 668 Engineering Tunnels and Interfaces"; 669 } 671 organization 672 "Internet Engineering Task Force (IETF) CCAMP WG"; 673 contact 674 " 675 WG List: 677 ID-draft editor: 678 Haomian Zheng (zhenghaomian@huawei.com); 679 Italo Busi (italo.busi@huawei.com); 680 Aihua Guo (aihuaguo.ietf@gmail.com); 681 Anton Snitser (antons@sedonasys.com);0 682 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 683 Yunbin Xu (xuyunbin@caict.ac.cn); 684 Yang Zhao (zhaoyangyjy@chinamobile.com); 685 Xufeng Liu (xufeng.liu.ietf@gmail.com); 686 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 687 "; 689 description 690 "This module defines a YANG data model for describing 691 the Ethernet services. The model fully conforms to the 692 Network Management Datastore Architecture (NMDA). 694 Copyright (c) 2019 IETF Trust and the persons 695 identified as authors of the code. All rights reserved. 697 Redistribution and use in source and binary forms, with or 698 without modification, is permitted pursuant to, and subject 699 to the license terms contained in, the Simplified BSD License 700 set forth in Section 4.c of the IETF Trust's Legal Provisions 701 Relating to IETF Documents 702 (https://trustee.ietf.org/license-info). 703 This version of this YANG module is part of RFC XXXX; see 704 the RFC itself for full legal notices."; 706 revision 2019-11-03 { 707 description 708 "version -01 as an WG document"; 709 reference 710 "draft-ietf-ccamp-client-signal-yang"; 711 } 713 /* 714 * Groupings 715 */ 717 grouping vlan-classification { 718 description 719 "A grouping which represents classification 720 on an 802.1Q VLAN tag."; 722 leaf tag-type { 723 type etht-types:eth-tag-classify; 724 description 725 "The tag type used for VLAN classification."; 726 } 727 choice individual-bundling-vlan { 728 description 729 "VLAN based classification can be individual 730 or bundling."; 732 case individual-vlan { 733 leaf vlan-value { 734 type etht-types:vlanid; 735 description 736 "VLAN ID value."; 737 } 738 } 739 case vlan-bundling { 740 leaf vlan-range { 741 type etht-types:vid-range-type; 742 description 743 "List of VLAN ID values."; 744 } 745 } 746 } 747 } 749 grouping vlan-write { 750 description 751 "A grouping which represents push/pop operations 752 of an 802.1Q VLAN tag."; 754 leaf tag-type { 755 type etht-types:eth-tag-type; 756 description 757 "The VLAN tag type to push/swap."; 758 } 759 leaf vlan-value { 760 type etht-types:vlanid; 761 description 762 "The VLAN ID value to push/swap."; 763 } 764 /* 765 * To be added: this attribute is used when: 766 * a) the ETH service has only one CoS (as in current version) 767 * b) as a default when a mapping between a given CoS value 768 * and the PCP value is not defined (in future versions) 769 */ 770 leaf default-pcp { 771 type uint8 { 772 range "0..7"; 773 } 774 description 775 "The default Priority Code Point (PCP) value to push/swap"; 776 } 777 } 779 grouping vlan-operations { 780 description 781 "A grouping which represents VLAN operations."; 783 leaf pop-tags { 784 type uint8 { 785 range "1..2"; 786 } 787 description 788 "The number of VLAN tags to pop (or swap if used in 789 conjunction with push-tags)"; 790 } 791 container push-tags { 792 description 793 "The VLAN tags to push (or swap if used in 794 conjunction with pop-tags)"; 796 container outer-tag { 797 presence 798 "Indicates existence of the outermost VLAN tag to 799 push/swap"; 801 description 802 "The outermost VLAN tag to push/swap."; 804 uses vlan-write; 805 } 806 container second-tag { 807 must 808 '../outer-tag/tag-type = "etht-types:s-vlan-tag-type" and ' + 809 'tag-type = "etht-types:c-vlan-tag-type"' 810 { 812 error-message 813 " 814 When pushing/swapping two tags, the outermost tag must 815 be specified and of S-VLAN type and the second 816 outermost tag must be of C-VLAN tag type. 817 "; 818 description 819 " 820 For IEEE 802.1Q interoperability, when pushing/swapping 821 two tags, it is required that the outermost tag exists 822 and is an S-VLAN, and the second outermost tag is a 823 C-VLAN. 824 "; 825 } 827 presence 828 "Indicates existence of a second outermost VLAN tag to 829 push/swap"; 831 description 832 "The second outermost VLAN tag to push/swap."; 834 uses vlan-write; 836 } 837 } 838 } 840 grouping named-or-value-bandwidth-profile { 841 description 842 "A grouping to configure a bandwdith profile either by 843 referencing a named bandwidth profile or by 844 configuring the values of the bandwidth profile attributes."; 845 choice style { 846 description 847 "Whether the bandwidth profile is named or defined by value"; 849 case named { 850 description 851 "Named bandwidth profile."; 852 leaf bandwidth-profile-name { 853 type "string"; 854 description 855 "Name of the bandwidth profile."; 856 } 857 } 858 case value { 859 description 860 "Bandwidth profile configured by value."; 861 uses etht-types:etht-bandwidth-profiles; 862 } 863 } 864 } 866 grouping bandwidth-profiles { 867 description 868 "A grouping which represent bandwidth profile configuration."; 870 choice direction { 871 description 872 "Whether the bandwidth profiles are symmetrical or 873 asymmetrical"; 874 case symmetrical { 875 description 876 "The same bandwidth profile is used to describe both 877 the ingress and the egress bandwidth profile."; 878 container ingress-egress-bandwidth-profile { 879 description 880 "The bandwdith profile used in both directions."; 881 uses named-or-value-bandwidth-profile; 882 } 883 } 884 case asymmetrical { 885 description 886 "Ingress and egress bandwidth profiles can be specified."; 887 container ingress-bandwidth-profile { 888 description 889 "The bandwdith profile used in the ingress direction."; 890 uses named-or-value-bandwidth-profile; 891 } 892 container egress-bandwidth-profile { 893 description 894 "The bandwdith profile used in the egress direction."; 895 uses named-or-value-bandwidth-profile; 896 } 897 } 898 } 899 } 901 grouping etht-svc-access-parameters { 902 description 903 "ETH services access parameters"; 905 leaf access-node-id { 906 type te-types:te-node-id; 907 description 908 "The identifier of the access node in 909 the ETH topology."; 910 } 911 leaf access-ltp-id { 912 type te-types:te-tp-id; 913 description 914 "The TE link termination point identifier, used 915 together with access-node-id to identify the 916 access LTP."; 917 } 918 leaf access-role { 919 type identityref { 920 base etht-types:access-role; 921 } 922 description 923 "Indicate the role of access, e.g., working or protection. "; 924 } 926 container pm-config { 927 uses pm-config-grouping; 928 description 929 "This grouping is used to set the threshold value for 930 performance monitoring. "; 931 } 932 container state { 933 config false; 934 description 935 "The state is used to monitor the status of service. "; 936 leaf operational-state { 937 type identityref { 938 base te-types:tunnel-state-type; 939 } 940 description 941 "Indicating the operational state of client signal. "; 942 } 943 leaf provisioning-state { 944 type identityref { 945 base te-types:lsp-state-type; 946 } 947 description 948 "Indicating the provisional state of client signal, 949 especially when there is a change, i.e., revise, create. "; 950 } 951 } 953 leaf performance { 954 type identityref { 955 base etht-types:performance; 956 } 957 config false; 958 description 959 "Performance Monitoring for the service. "; 960 } 962 } 964 grouping etht-svc-tunnel-parameters { 965 description 966 "ETH services tunnel parameters."; 967 choice technology { 968 description 969 "Service multiplexing is optional and flexible."; 971 case native-ethernet { 972 /* 973 placeholder to support proprietary multiplexing 974 (for further discussion) 975 */ 976 list eth-tunnels { 977 key name; 978 description 980 "ETH Tunnel list in native Ethernet scenario."; 981 uses tunnels-grouping; 982 } 983 } 985 case frame-base { 986 list otn-tunnels { 987 key name; 988 description 989 "OTN Tunnel list in Frame-based scenario."; 990 uses tunnels-grouping; 991 } 992 } 994 case mpls-tp { 995 container pw { 996 description 997 "Pseudowire information for Ethernet over MPLS-TP."; 998 uses pw-segment-grouping; 999 } 1000 } 1001 } 1003 /* 1004 * Open issue: can we constraints it to be used only with mp services? 1005 */ 1006 leaf src-split-horizon-group { 1007 type string; 1008 description 1009 "Identify a split horizon group at the Tunnel source TTP"; 1010 } 1011 leaf dst-split-horizon-group { 1012 type string; 1013 description 1014 "Identify a split horizon group at the Tunnel destination TTP"; 1015 } 1016 } 1018 grouping etht-svc-pm-threshold-config { 1019 description 1020 "Configuraiton parameters for Ethernet service PM thresholds."; 1022 leaf sending-rate-high { 1023 type uint64; 1024 description 1025 "High threshold of packet sending rate in kbps."; 1026 } 1027 leaf sending-rate-low { 1028 type uint64; 1029 description 1030 "Low threshold of packet sending rate in kbps."; 1031 } 1032 leaf receiving-rate-high { 1033 type uint64; 1034 description 1035 "High threshold of packet receiving rate in kbps."; 1036 } 1037 leaf receiving-rate-low { 1038 type uint64; 1039 description 1040 "Low threshold of packet receiving rate in kbps."; 1041 } 1042 } 1044 grouping etht-svc-pm-stats { 1045 description 1046 "Ethernet service PM statistics."; 1048 leaf sending-rate-too-high { 1049 type uint32; 1050 description 1051 "Counter that indicates the number of times the sending 1052 rate is above the high threshold"; 1053 } 1054 leaf sending-rate-too-low { 1055 type uint32; 1056 description 1057 "Counter that indicates the number of times the sending 1058 rate is below the low threshold"; 1059 } 1060 leaf receiving-rate-too-high { 1061 type uint32; 1062 description 1063 "Counter that indicates the number of times the receiving 1064 rate is above the high threshold"; 1065 } 1066 leaf receiving-rate-too-low { 1067 type uint32; 1068 description 1069 "Counter that indicates the number of times the receiving 1070 rate is below the low threshold"; 1071 } 1072 } 1074 grouping etht-svc-instance-config { 1075 description 1076 "Configuraiton parameters for Ethernet services."; 1078 leaf etht-svc-name { 1079 type string; 1080 description 1081 "Name of the ETH service."; 1082 } 1084 leaf etht-svc-title { 1085 type string; 1086 description 1087 "The Identifier of the ETH service."; 1088 } 1090 leaf etht-svc-descr { 1091 type string; 1092 description 1093 "Description of the ETH service."; 1094 } 1096 leaf etht-svc-customer { 1097 type string; 1098 description 1099 "Customer of the ETH service."; 1100 } 1102 leaf etht-svc-type { 1103 type etht-types:service-type; 1104 description 1105 "Type of ETH service (p2p, mp2mp or rmp)."; 1106 /* Add default as p2p */ 1107 } 1109 leaf etht-svc-lifecycle { 1110 type etht-types:lifecycle-status; 1111 description 1112 "Lifecycle state of ETH service."; 1113 /* Add default as installed */ 1114 } 1115 uses te-types:te-topology-identifier; 1117 uses resilience-grouping; 1119 list etht-svc-end-points { 1120 key etht-svc-end-point-name; 1121 description 1122 "The logical end point for the ETH service. "; 1123 uses etht-svc-end-point-grouping; 1125 } 1127 container underlay { 1128 description 1129 "The unterlay tunnel information that 1130 carrying the ETH service. "; 1131 uses etht-svc-tunnel-parameters; 1132 } 1134 leaf admin-status { 1135 type identityref { 1136 base te-types:tunnel-admin-state-type; 1137 } 1138 default te-types:tunnel-admin-state-up; 1139 description "ETH service administrative state."; 1140 } 1141 } 1143 grouping etht-svc-instance-state { 1144 description 1145 "State parameters for Ethernet services."; 1147 leaf operational-state { 1148 type identityref { 1149 base te-types:tunnel-state-type; 1150 } 1151 default te-types:tunnel-state-up; 1152 description "ETH service operational state."; 1153 } 1154 leaf provisioning-state { 1155 type identityref { 1156 base te-types:lsp-state-type; 1157 } 1158 description "ETH service provisioning state."; 1159 } 1160 leaf creation-time { 1161 type yang:date-and-time; 1162 description 1163 "Time of ETH service creation."; 1164 } 1165 leaf last-updated-time { 1166 type yang:date-and-time; 1167 description 1168 "Time of ETH service last update."; 1169 } 1171 } 1172 /* 1173 * Data nodes 1174 */ 1176 container etht-svc { 1177 description 1178 "ETH services."; 1180 container globals { 1181 description 1182 "Globals Ethernet configuration data container"; 1183 list named-bandwidth-profiles { 1184 key bandwidth-profile-name; 1185 description 1186 "List of named bandwidth profiles used by 1187 Ethernet services."; 1189 leaf bandwidth-profile-name { 1190 type string; 1191 description 1192 "Name of the bandwidth profile."; 1193 } 1194 uses etht-types:etht-bandwidth-profiles; 1195 } 1196 } 1198 list etht-svc-instances { 1199 key etht-svc-name; 1200 description 1201 "The list of p2p ETH service instances"; 1203 uses etht-svc-instance-config; 1205 container state { 1206 config false; 1207 description 1208 "Ethernet Service states."; 1210 uses etht-svc-instance-state; 1211 } 1212 } 1213 } 1215 grouping resilience-grouping { 1216 description 1217 "Grouping for resilience configuration. "; 1218 container resilience { 1219 description 1220 "To configure the data plane protection parameters, 1221 currently a placeholder only, future candidate attributes 1222 include, Revert, WTR, Hold-off Timer, ..."; 1223 uses te:protection-restoration-properties; 1224 } 1225 } 1227 grouping etht-svc-end-point-grouping { 1228 description 1229 "Grouping for the end point configuration."; 1230 leaf etht-svc-end-point-name { 1231 type string; 1232 description 1233 "The name of the logical end point of ETH service. "; 1234 } 1236 leaf etht-svc-end-point-id { 1237 type string; 1238 description 1239 "The identifier of the logical end point of ETH service."; 1240 } 1242 leaf etht-svc-end-point-descr { 1243 type string; 1244 description 1245 "The description of the logical end point of ETH service. "; 1246 } 1248 leaf topology-role { 1249 type identityref { 1250 base etht-types:topology-role; 1251 } 1252 description 1253 "Indicating the underlay topology role, 1254 e.g., hub,spoke, any-to-any "; 1255 } 1257 container resilience { 1258 description 1259 "Placeholder for resilience configuration, for future study. "; 1260 } 1262 list etht-svc-access-points { 1263 key access-point-id; 1264 min-elements "1"; 1265 /* 1266 Open Issue: 1267 Is it possible to limit the max-elements only for p2p services? 1268 max-elements "2"; 1269 */ 1270 description 1271 "List of the ETH trasport services access point instances."; 1273 leaf access-point-id { 1274 type string; 1275 description 1276 "ID of the service access point instance"; 1277 } 1278 uses etht-svc-access-parameters; 1279 } 1281 leaf service-classification-type { 1282 type identityref { 1283 base etht-types:service-classification-type; 1284 } 1285 description 1286 "Service classification type."; 1287 } 1289 choice service-classification { 1290 description 1291 "Access classification can be port-based or 1292 VLAN based."; 1294 case port-classification { 1295 /* no additional information */ 1296 } 1298 case vlan-classification { 1299 container outer-tag { 1300 presence "The outermost VLAN tag exists"; 1301 description 1302 "Classifies traffic using the outermost VLAN tag."; 1304 uses vlan-classification; 1305 } 1306 container second-tag { 1307 must 1308 '../outer-tag/tag-type = "etht-types:classify-s-vlan" and ' + 1309 'tag-type = "etht-types:classify-c-vlan"' 1310 { 1311 error-message 1312 " 1313 When matching two tags, the outermost tag must be 1314 specified and of S-VLAN type and the second 1315 outermost tag must be of C-VLAN tag type. 1317 "; 1318 description 1319 " 1320 For IEEE 802.1Q interoperability, when matching two 1321 tags, it is required that the outermost tag exists 1322 and is an S-VLAN, and the second outermost tag is a 1323 C-VLAN. 1324 "; 1325 } 1326 presence "The second outermost VLAN tag exists"; 1328 description 1329 "Classifies traffic using the second outermost VLAN tag."; 1331 uses vlan-classification; 1332 } 1333 } 1334 } 1336 /* 1337 * Open issue: can we constraints it to be used only with mp services? 1338 */ 1339 leaf split-horizon-group { 1340 type string; 1341 description "Identify a split horizon group"; 1342 } 1344 uses bandwidth-profiles; 1346 container vlan-operations { 1347 description 1348 "Configuration of VLAN operations."; 1349 choice direction { 1350 description 1351 "Whether the VLAN operations are symmetrical or 1352 asymmetrical"; 1353 case symmetrical { 1354 container symmetrical-operation { 1355 uses vlan-operations; 1356 description 1357 "Symmetrical operations. 1358 Expressed in the ingress direction, but 1359 the reverse operation is applied to egress traffic"; 1360 } 1361 } 1362 case asymmetrical { 1363 container asymmetrical-operation { 1364 description "Asymmetrical operations"; 1365 container ingress { 1366 uses vlan-operations; 1367 description "Ingress operations"; 1368 } 1369 container egress { 1370 uses vlan-operations; 1371 description "Egress operations"; 1372 } 1373 } 1374 } 1375 } 1376 } 1378 } 1380 grouping pm-config-grouping { 1381 description 1382 "Grouping used for Performance Monitoring Configuration. "; 1383 leaf pm-enable { 1384 type boolean; 1385 description 1386 "Whether to enable the performance monitoring."; 1387 } 1389 leaf sending-rate-high { 1390 type uint64; 1391 description 1392 "The upperbound of sending rate."; 1393 } 1395 leaf sending-rate-low { 1396 type uint64; 1397 description 1398 "The lowerbound of sending rate."; 1399 } 1401 leaf receiving-rate-high { 1402 type uint64; 1403 description 1404 "The upperbound of receiving rate."; 1405 } 1407 leaf receiving-rate-low { 1408 type uint64; 1409 description 1410 "The lowerbound of receiving rate."; 1411 } 1412 } 1413 grouping pw-segment-grouping { 1414 description 1415 "Grouping used for PW configuration. "; 1416 leaf pw-id { 1417 type string; 1418 description 1419 "The Identifier information of pseudowire. "; 1420 } 1422 leaf pw-name { 1423 type string; 1424 description 1425 "The name information of pseudowire."; 1426 } 1428 leaf transmit-label { 1429 type rt-types:mpls-label; 1430 description 1431 "Transmit label information in PW. "; 1432 } 1434 leaf receive-label { 1435 type rt-types:mpls-label; 1436 description 1437 "Receive label information in PW. "; 1438 } 1440 leaf encapsulation-type { 1441 type identityref { 1442 base etht-types:encapsulation-type; 1443 } 1444 description 1445 "The encapsulation type, raw or tag. "; 1446 } 1448 leaf oper-status { 1449 type identityref { 1450 base te-types:tunnel-state-type; 1451 } 1452 config false; 1453 description 1454 "The operational state of the PW segment. "; 1455 } 1457 container ingress-bandwidth-profile { 1458 description 1459 "Bandwidth Profile for ingress. "; 1460 uses pw-segment-named-or-value-bandwidth-profile; 1462 } 1464 list pw-paths { 1465 key path-id; 1466 description 1467 "A list of pw paths. "; 1469 leaf path-id { 1470 type uint8; 1471 description 1472 "The identifier of pw paths. "; 1474 } 1476 list tp-tunnels { 1477 key name; 1478 description 1479 "Names of TP Tunnel underlay"; 1480 leaf name { 1481 type string; 1482 description 1483 "Names of TP Tunnel underlay"; 1484 } 1485 } 1486 } 1488 } 1490 grouping pw-segment-named-or-value-bandwidth-profile { 1491 description 1492 "A grouping to configure a bandwdith profile either by 1493 referencing a named bandwidth profile or by 1494 configuring the values of the bandwidth profile attributes."; 1495 choice style { 1496 description 1497 "Whether the bandwidth profile is named or defined by value"; 1498 case named { 1499 description 1500 "Named bandwidth profile."; 1501 leaf bandwidth-profile-name { 1502 type leafref { 1503 path "/ethtsvc:etht-svc/ethtsvc:globals/" 1504 + "ethtsvc:named-bandwidth-profiles/" 1505 + "ethtsvc:bandwidth-profile-name"; 1506 } 1507 description 1508 "Name of the bandwidth profile."; 1509 } 1511 } 1512 case value { 1513 description 1514 "Bandwidth profile configured by value."; 1515 uses etht-types:pw-segement-bandwidth-profile-grouping; 1516 } 1517 } 1518 } 1520 grouping tunnels-grouping { 1521 description 1522 "A group of tunnels. "; 1523 leaf name { 1524 type leafref { 1525 path "/te:te/te:tunnels/te:tunnel/te:name"; 1526 require-instance false; 1527 } 1528 description "Dependency tunnel name"; 1529 } 1530 leaf encoding { 1531 type identityref { 1532 base te-types:lsp-encoding-types; 1533 } 1534 description "LSP encoding type"; 1535 reference "RFC3945"; 1536 } 1537 leaf switching-type { 1538 type identityref { 1539 base te-types:switching-capabilities; 1540 } 1541 description "LSP switching type"; 1542 reference "RFC3945"; 1543 } 1544 } 1545 } 1546 1548 5.2. YANG Code for ETH type 1550 This module references a few documents including [RFC2697], 1551 [RFC2698], [RFC4115], [IEEE802.1ad], [IEEE802.1q] and [MEF10]. 1553 file "ietf-eth-tran-types@2019-11-03.yang" 1554 module ietf-eth-tran-types { 1555 yang-version 1.1; 1556 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-tran-types"; 1557 prefix "etht-types"; 1559 organization 1560 "Internet Engineering Task Force (IETF) CCAMP WG"; 1561 contact 1562 " 1563 WG List: 1565 ID-draft editor: 1566 Haomian Zheng (zhenghaomian@huawei.com); 1567 Italo Busi (italo.busi@huawei.com); 1568 Aihua Guo (aihuaguo.ietf@gmail.com); 1569 Anton Snitser (antons@sedonasys.com);0 1570 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 1571 Yunbin Xu (xuyunbin@caict.ac.cn); 1572 Yang Zhao (zhaoyangyjy@chinamobile.com); 1573 Xufeng Liu (xufeng.liu.ietf@gmail.com); 1574 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 1575 "; 1577 description 1578 "This module defines the ETH types. 1579 The model fully conforms to the Network Management 1580 Datastore Architecture (NMDA). 1582 Copyright (c) 2019 IETF Trust and the persons 1583 identified as authors of the code. All rights reserved. 1585 Redistribution and use in source and binary forms, with or 1586 without modification, is permitted pursuant to, and subject 1587 to the license terms contained in, the Simplified BSD License 1588 set forth in Section 4.c of the IETF Trust's Legal Provisions 1589 Relating to IETF Documents 1590 (https://trustee.ietf.org/license-info). 1591 This version of this YANG module is part of RFC XXXX; see 1592 the RFC itself for full legal notices."; 1594 revision 2019-11-03 { 1595 description 1596 "version -01 as a WG draft"; 1597 reference 1598 "draft-ietf-ccamp-client-signal-yang"; 1599 } 1601 /* 1602 * Identities 1603 */ 1605 identity eth-vlan-tag-type { 1606 description 1607 "ETH VLAN tag type."; 1608 } 1610 identity c-vlan-tag-type { 1611 base eth-vlan-tag-type; 1612 description 1613 "802.1Q Customer VLAN"; 1614 } 1616 identity s-vlan-tag-type { 1617 base eth-vlan-tag-type; 1618 description 1619 "802.1Q Service VLAN (QinQ)"; 1620 } 1622 identity service-classification-type { 1623 description 1624 "Service classification."; 1625 } 1627 identity port-classification { 1628 base service-classification-type; 1629 description 1630 "Port classification."; 1631 } 1633 identity vlan-classification { 1634 base service-classification-type; 1635 description 1636 "VLAN classification."; 1637 } 1639 identity eth-vlan-tag-classify { 1640 description 1641 "VLAN tag classification."; 1642 } 1644 identity classify-c-vlan { 1645 base eth-vlan-tag-classify; 1646 description 1647 "Classify 802.1Q Customer VLAN tag. 1648 Only C-tag type is accepted"; 1649 } 1651 identity classify-s-vlan { 1652 base eth-vlan-tag-classify; 1653 description 1654 "Classify 802.1Q Service VLAN (QinQ) tag. 1655 Only S-tag type is accepted"; 1656 } 1658 identity classify-s-or-c-vlan { 1659 base eth-vlan-tag-classify; 1660 description 1661 "Classify S-VLAN or C-VLAN tag-classify. 1662 Either tag is accepted"; 1663 } 1665 identity bandwidth-profile-type { 1666 description 1667 "Bandwidth Profile Types"; 1668 } 1670 identity mef-10-bwp { 1671 base bandwidth-profile-type; 1672 description 1673 "MEF 10 Bandwidth Profile"; 1674 } 1676 identity rfc-2697-bwp { 1677 base bandwidth-profile-type; 1678 description 1679 "RFC 2697 Bandwidth Profile"; 1680 } 1682 identity rfc-2698-bwp { 1683 base bandwidth-profile-type; 1684 description 1685 "RFC 2698 Bandwidth Profile"; 1686 } 1688 identity rfc-4115-bwp { 1689 base bandwidth-profile-type; 1690 description 1691 "RFC 4115 Bandwidth Profile"; 1692 } 1694 identity service-type { 1695 description 1696 "Type of Ethernet service."; 1697 } 1699 identity p2p-svc { 1700 base service-type; 1701 description 1702 "Ethernet point-to-point service (EPL, EVPL)."; 1703 } 1705 identity rmp-svc { 1706 base service-type; 1707 description 1708 "Ethernet rooted-multitpoint service (E-TREE, EP-TREE)."; 1709 } 1711 identity mp2mp-svc { 1712 base service-type; 1713 description 1714 "Ethernet multipoint-to-multitpoint service (E-LAN, EP-LAN)."; 1715 } 1717 identity lifecycle-status { 1718 description 1719 "Lifecycle Status."; 1720 } 1722 identity installed { 1723 base lifecycle-status; 1724 description 1725 "Installed."; 1726 } 1728 identity planned { 1729 base lifecycle-status; 1730 description 1731 "Planned."; 1732 } 1734 identity pending-removal { 1735 base lifecycle-status; 1736 description 1737 "Pending Removal."; 1738 } 1740 /* 1741 * Type Definitions 1742 */ 1744 typedef eth-tag-type { 1745 type identityref { 1746 base eth-vlan-tag-type; 1747 } 1748 description 1749 "Identifies a specific ETH VLAN tag type."; 1750 } 1752 typedef eth-tag-classify { 1753 type identityref { 1754 base eth-vlan-tag-classify; 1755 } 1756 description 1757 "Identifies a specific VLAN tag classification."; 1758 } 1760 typedef vlanid { 1761 type uint16 { 1762 range "1..4094"; 1763 } 1764 description 1765 "The 12-bit VLAN-ID used in the VLAN Tag header."; 1766 } 1768 typedef vid-range-type { 1769 type string { 1770 pattern "([1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?" + 1771 "(,[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?)*)"; 1772 } 1773 description 1774 "A list of VLAN Ids, or non overlapping VLAN ranges, in 1775 ascending order, between 1 and 4094. 1776 This type is used to match an ordered list of VLAN Ids, or 1777 contiguous ranges of VLAN Ids. Valid VLAN Ids must be in the 1778 range 1 to 4094, and included in the list in non overlapping 1779 ascending order. 1781 For example: 1,10-100,50,500-1000"; 1782 } 1784 typedef bandwidth-profile-type { 1785 type identityref { 1786 base bandwidth-profile-type; 1787 } 1788 description 1789 "Identifies a specific Bandwidth Profile type."; 1790 } 1792 typedef service-type { 1793 type identityref { 1794 base service-type; 1795 } 1796 description 1797 "Identifies the type of Ethernet service."; 1798 } 1800 typedef lifecycle-status { 1801 type identityref { 1802 base lifecycle-status; 1803 } 1804 description 1805 "Identifies the lLifecycle Status ."; 1806 } 1808 /* 1809 * Grouping Definitions 1810 */ 1812 grouping etht-bandwidth-profiles { 1813 description 1814 "Bandwidth profile configuration paramters."; 1816 leaf bandwidth-profile-type { 1817 type etht-types:bandwidth-profile-type; 1818 description 1819 "The type of bandwidth profile."; 1820 } 1821 leaf CIR { 1822 type uint64; 1823 description 1824 "Committed Information Rate in Kbps"; 1825 } 1826 leaf CBS { 1827 type uint64; 1828 description 1829 "Committed Burst Size in in KBytes"; 1830 } 1831 leaf EIR { 1832 type uint64; 1833 /* Need to indicate that EIR is not supported by RFC 2697 1835 must 1836 '../bw-profile-type = "mef-10-bwp" or ' + 1837 '../bw-profile-type = "rfc-2698-bwp" or ' + 1838 '../bw-profile-type = "rfc-4115-bwp"' 1840 must 1841 '../bw-profile-type != "rfc-2697-bwp"' 1842 */ 1843 description 1844 "Excess Information Rate in Kbps 1845 In case of RFC 2698, PIR = CIR + EIR"; 1846 } 1847 leaf EBS { 1848 type uint64; 1849 description 1850 "Excess Burst Size in KBytes. 1851 In case of RFC 2698, PBS = CBS + EBS"; 1852 } 1853 leaf color-aware { 1854 type boolean; 1855 description 1856 "Indicates weather the color-mode is 1857 color-aware or color-blind."; 1858 } 1859 leaf coupling-flag { 1860 type boolean; 1861 /* Need to indicate that Coupling Flag is defined only for MEF 10 1863 must 1864 '../bw-profile-type = "mef-10-bwp"' 1865 */ 1866 description 1867 "Coupling Flag."; 1868 } 1869 } 1871 identity topology-role { 1872 description 1873 "The rold of underlay topology, e.g., 1874 hub, spoke, any-to-any. "; 1875 } 1877 identity resilience { 1878 description 1879 "Placeholder for resilience information in data plane, 1880 for future study. "; 1881 } 1883 identity access-role { 1884 description 1885 "Indicating whether the access is a working or protection access."; 1886 } 1888 identity performance { 1889 description 1890 "Placeholder for performace information, for future study."; 1891 } 1892 identity encapsulation-type { 1893 description 1894 "Indicating how the service is encapsulated (to PW), e.g, raw or tag. "; 1895 } 1897 grouping pw-segement-bandwidth-profile-grouping { 1898 description 1899 "bandwidth profile grouping for PW segment. "; 1900 leaf bandwidth-profile-type { 1901 type etht-types:bandwidth-profile-type; 1902 description 1903 "The type of bandwidth profile."; 1904 } 1905 leaf CIR { 1906 type uint64; 1907 description 1908 "Committed Information Rate in Kbps"; 1909 } 1910 leaf CBS { 1911 type uint64; 1912 description 1913 "Committed Burst Size in in KBytes"; 1914 } 1915 leaf EIR { 1916 type uint64; 1917 /* Need to indicate that EIR is not supported by RFC 2697 1919 must 1920 '../bw-profile-type = "mef-10-bwp" or ' + 1921 '../bw-profile-type = "rfc-2698-bwp" or ' + 1922 '../bw-profile-type = "rfc-4115-bwp"' 1924 must 1925 '../bw-profile-type != "rfc-2697-bwp"' 1926 */ 1927 description 1928 "Excess Information Rate in Kbps 1929 In case of RFC 2698, PIR = CIR + EIR"; 1930 } 1931 leaf EBS { 1932 type uint64; 1933 description 1934 "Excess Burst Size in KBytes. 1935 In case of RFC 2698, PBS = CBS + EBS"; 1936 } 1937 } 1938 grouping eth-bandwidth { 1939 description 1940 "Available bandwith for ethernet."; 1941 leaf eth-bandwidth { 1942 type uint64{ 1943 range "0..10000000000"; 1944 } 1945 units "Kbps"; 1946 description 1947 "Available bandwith value expressed in kilobits per second"; 1948 } 1949 } 1951 grouping eth-label-restriction { 1952 description 1953 "Label Restriction for ethernet."; 1954 leaf tag-type { 1955 type etht-types:eth-tag-type; 1956 description "VLAN tag type."; 1957 } 1958 leaf priority { 1959 type uint8; 1960 description "priority."; 1961 } 1962 } 1964 grouping eth-label { 1965 description 1966 "Label for ethernet."; 1967 leaf vlanid { 1968 type etht-types:vlanid; 1969 description 1970 "VLAN tag id."; 1971 } 1972 } 1974 grouping eth-label-step { 1975 description "Label step for Ethernet VLAN"; 1976 leaf eth-step { 1977 type uint16 { 1978 range "1..4095"; 1979 } 1980 default 1; 1981 description 1982 "Label step which represent possible increments for 1983 an Ethernet VLAN tag."; 1984 reference 1985 "IEEE 802.1ad: Provider Bridges."; 1986 } 1987 } 1989 } 1991 1993 5.3. Other Client Signal YANG Code 1995 This module imports typedefs and modules from [RFC6991], 1996 [I-D.ietf-ccamp-otn-tunnel-model], [I-D.ietf-teas-yang-te-types]. 1998 file "ietf-trans-client-service@2019-11-03.yang" 1999 module ietf-trans-client-service { 2000 /* TODO: FIXME */ 2001 yang-version 1.1; 2003 namespace "urn:ietf:params:xml:ns:yang:ietf-trans-client-service"; 2004 prefix "clntsvc"; 2006 import ietf-te-types { 2007 prefix "te-types"; 2008 reference "RFC YYYY - Traffic Engineering Common YANG Types"; 2009 } 2011 import ietf-layer1-types { 2012 prefix "layer1-types"; 2013 reference "RFC ZZZZ - A YANG Data Model for Layer 1 Types"; 2014 } 2016 import ietf-yang-types { 2017 prefix "yang"; 2018 reference "RFC 6991 - Common YANG Data Types"; 2019 } 2021 import ietf-trans-client-svc-types { 2022 prefix "clntsvc-types"; 2023 reference "RFC XXXX - A YANG Data Model for 2024 Transport Network Client Signals"; 2025 } 2027 organization 2028 "Internet Engineering Task Force (IETF) CCAMP WG"; 2029 contact 2030 " 2031 ID-draft editor: 2032 Haomian Zheng (zhenghaomian@huawei.com); 2033 Aihua Guo (aihuaguo.ietf@gmail.com); 2034 Italo Busi (italo.busi@huawei.com); 2035 Anton Snitser (antons@sedonasys.com); 2036 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 2037 Yunbin Xu (xuyunbin@caict.ac.cn); 2038 Yang Zhao (zhaoyangyjy@chinamobile.com); 2039 Xufeng Liu (Xufeng_Liu@jabil.com); 2040 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 2041 "; 2043 description 2044 "This module defines a YANG data model for describing 2045 transport network client services. The model fully conforms 2046 to the Network Management Datastore Architecture (NMDA). 2048 Copyright (c) 2019 IETF Trust and the persons 2049 identified as authors of the code. All rights reserved. 2051 Redistribution and use in source and binary forms, with or 2052 without modification, is permitted pursuant to, and subject 2053 to the license terms contained in, the Simplified BSD License 2054 set forth in Section 4.c of the IETF Trust's Legal Provisions 2055 Relating to IETF Documents 2056 (https://trustee.ietf.org/license-info). 2057 This version of this YANG module is part of RFC XXXX; see 2058 the RFC itself for full legal notices."; 2060 revision 2019-11-03 { 2061 description 2062 "version -01 as a WG document"; 2063 reference 2064 "draft-ietf-ccamp-client-signal-yang"; 2065 } 2067 /* 2068 * Groupings 2069 */ 2070 grouping client-svc-access-parameters { 2071 description 2072 "Transport network client signals access parameters"; 2074 leaf access-node-id { 2075 type te-types:te-node-id; 2076 description 2077 "The identifier of the access node in the underlying 2078 transport network topology."; 2079 } 2081 leaf access-ltp-id { 2082 type te-types:te-tp-id; 2083 description 2084 "The TE link termination point identifier, used together with 2085 access-node-id to identify the access LTP."; 2086 } 2088 leaf client-signal { 2089 type identityref { 2090 base layer1-types:client-signal; 2091 } 2092 description 2093 "Identify the client signal type associated with this port"; 2094 } 2096 } 2098 grouping client-svc-tunnel-parameters { 2099 description 2100 "Transport network client signals tunnel parameters"; 2102 leaf tunnel-name { 2103 type string; 2104 description 2105 "TE tunnel instance name."; 2106 } 2107 } 2109 grouping client-svc-instance-config { 2110 description 2111 "Configuration parameters for client services."; 2112 leaf client-svc-name { 2113 type string; 2114 description 2115 "Identifier of the p2p transport network client signals."; 2116 } 2118 leaf client-svc-title { 2119 type string; 2120 description 2121 "Name of the p2p transport network client signals."; 2122 } 2124 leaf client-svc-descr { 2125 type string; 2126 description 2127 "Description of the transport network client signals."; 2128 } 2129 leaf client-svc-customer { 2130 type string; 2131 description 2132 "Customer of the transport network client signals."; 2133 } 2135 container resilience { 2136 description "Place holder for resilience functionalities"; 2137 } 2139 uses te-types:te-topology-identifier; 2141 leaf admin-status { 2142 type identityref { 2143 base te-types:tunnel-admin-state-type; 2144 } 2145 default te-types:tunnel-admin-state-up; 2146 description "Client signals administrative state."; 2147 } 2149 container src-access-ports { 2150 description 2151 "Source access port of a client signal."; 2152 uses client-svc-access-parameters; 2153 } 2155 container dst-access-ports { 2156 description 2157 "Destination access port of a client signal."; 2158 uses client-svc-access-parameters; 2159 } 2161 leaf direction { 2162 type identityref { 2163 base clntsvc-types:direction; 2164 } 2165 description "Uni-dir or Bi-dir for the client signal."; 2166 } 2168 list svc-tunnels { 2169 key tunnel-name; 2170 description 2171 "List of the TE Tunnels supporting the client signal."; 2172 uses client-svc-tunnel-parameters; 2173 } 2174 } 2176 grouping client-svc-instance-state { 2177 description 2178 "State parameters for client services."; 2179 leaf operational-state { 2180 type identityref { 2181 base te-types:tunnel-state-type; 2182 } 2183 config false; 2184 description "Client signal operational state."; 2185 } 2186 leaf provisioning-state { 2187 type identityref { 2188 base te-types:lsp-state-type; 2189 } 2190 config false; 2191 description "Client signal provisioning state."; 2192 } 2193 leaf creation-time { 2194 type yang:date-and-time; 2195 config false; 2196 description "The time of the client signal be created."; 2197 } 2198 leaf last-updated-time { 2199 type yang:date-and-time; 2200 config false; 2201 description "The time of the client signal's latest update."; 2202 } 2204 } 2206 /* 2207 * Data nodes 2208 */ 2210 container client-svc { 2211 description 2212 "Transport client services."; 2214 list client-svc-instances { 2215 key client-svc-name; 2216 description 2217 "The list of p2p transport client service instances"; 2219 uses client-svc-instance-config; 2220 uses client-svc-instance-state; 2221 } 2222 } 2223 } 2225 2227 5.4. Other Client Signal Types YANG Code 2229 This module defines the types for other client signal types. 2231 file "ietf-trans-client-service@2019-11-03.yang" 2233 module ietf-trans-client-svc-types { 2234 namespace "urn:ietf:params:xml:ns:yang:ietf-trans-client-svc-types"; 2235 prefix "clntsvc-types"; 2237 organization 2238 "Internet Engineering Task Force (IETF) CCAMP WG"; 2239 contact 2240 " 2241 ID-draft editor: 2242 Haomian Zheng (zhenghaomian@huawei.com); 2243 Aihua Guo (aihuaguo.ietf@gmail.com); 2244 Italo Busi (italo.busi@huawei.com); 2245 Anton Snitser (antons@sedonasys.com); 2246 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 2247 Yunbin Xu (xuyunbin@caict.ac.cn); 2248 Yang Zhao (zhaoyangyjy@chinamobile.com); 2249 Xufeng Liu (Xufeng_Liu@jabil.com); 2250 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 2251 "; 2253 description 2254 "This module defines a YANG data model for describing 2255 transport network client types. The model fully conforms 2256 to the Network Management Datastore Architecture (NMDA). 2258 Copyright (c) 2019 IETF Trust and the persons 2259 identified as authors of the code. All rights reserved. 2261 Redistribution and use in source and binary forms, with or 2262 without modification, is permitted pursuant to, and subject 2263 to the license terms contained in, the Simplified BSD License 2264 set forth in Section 4.c of the IETF Trust's Legal Provisions 2265 Relating to IETF Documents 2266 (https://trustee.ietf.org/license-info). 2267 This version of this YANG module is part of RFC XXXX; see 2268 the RFC itself for full legal notices."; 2270 revision 2019-11-03 { 2271 description 2272 "version -01 as a WG document"; 2273 reference 2274 "draft-ietf-ccamp-client-signal-yang"; 2275 } 2277 identity direction { 2278 description 2279 "Direction information of Client Signal."; 2280 } 2282 identity bidirectional { 2283 base direction; 2284 description 2285 "Client Signal is bi-directional."; 2286 } 2288 identity unidirectional { 2289 base direction; 2290 description 2291 "Client Signal is uni-directional."; 2292 } 2294 } 2295 2297 6. Considerations and Open Issue 2299 Editor Notes: This section is used to note temporary discussion/ 2300 conclusion that to be fixed in the future version, and will be 2301 removed before publication. We currently categorize all the client 2302 signal types into transparent and non-transparent, with separate 2303 models. There was consensus that no common model is needed for these 2304 two categories. Further Alignment with RFC8407 would be required 2305 before publication. The RFC Editor will replace XXXX, YYYY and ZZZZ 2306 with the number assigned to the RFC once this draft becomes an RFC. 2308 7. IANA Considerations 2310 It is proposed that IANA should assign new URIs from the "IETF XML 2311 Registry" [RFC3688] as follows: 2313 URI: urn:ietf:params:xml:ns:yang:ietf-eth-tran-service 2314 Registrant Contact: The IESG 2315 XML: N/A; the requested URI is an XML namespace. 2317 URI: urn:ietf:params:xml:ns:yang:ietf-trans-client-service 2318 Registrant Contact: The IESG 2319 XML: N/A; the requested URI is an XML namespace. 2321 URI: urn:ietf:params:xml:ns:yang:ietf-eth-tran-types 2322 Registrant Contact: The IESG 2323 XML: N/A; the requested URI is an XML namespace. 2325 URI: urn:ietf:params:xml:ns:yang:ietf-trans-client-svc-types 2326 Registrant Contact: The IESG 2327 XML: N/A; the requested URI is an XML namespace. 2329 This document registers following YANG modules in the YANG Module 2330 Names registry [RFC6020]. 2332 name: ietf-eth-tran-service 2333 namespace: urn:ietf:params:xml:ns:yang:ietf-eth-tran-service 2334 prefix: ethtsvc 2335 reference: RFC XXXX: A YANG Data Model for Transport 2336 Network Client Signals 2338 name: ietf-eth-tran-types 2339 namespace: urn:ietf:params:xml:ns:yang:ietf-eth-tran-types 2340 prefix: etht-types 2341 reference: RFC XXXX: A YANG Data Model for Transport 2342 Network Client Signals 2344 name: ietf-trans-client-service 2345 namespace: urn:ietf:params:xml:ns:yang:ietf-trans-client-service 2346 prefix: clntsvc 2347 reference: RFC XXXX: A YANG Data Model for Transport 2348 Network Client Signals 2350 name: ietf-trans-client-svc-types 2351 namespace: urn:ietf:params:xml:ns:yang:ietf-trans-client-svc-types 2352 prefix: clntsvc-types 2353 reference: RFC XXXX: A YANG Data Model for Transport 2354 Network Client Signals 2356 8. Manageability Considerations 2358 TBD. 2360 9. Security Considerations 2362 The data following the model defined in this document is exchanged 2363 via, for example, the interface between an orchestrator and a network 2364 domain controller. 2366 The YANG module defined in this document can be accessed via the 2367 RESTCONF protocol defined in [RFC8040], or maybe via the NETCONF 2368 protocol [RFC6241]. 2370 There are a number of data nodes defined in the YANG module which are 2371 writable/creatable/deletable (i.e., config true, which is the 2372 default). These data nodes may be considered sensitive or vulnerable 2373 in some network environments. Write operations (e.g., POST) to these 2374 data nodes without proper protection can have a negative effect on 2375 network operations. 2377 10. Acknowledgements 2379 We would like to thank Igor Bryskin and Daniel King for their 2380 comments and discussions. 2382 11. Contributors 2384 Yanlei Zheng 2385 China Unicom 2386 Email: zhengyl@dimpt.com 2388 Zhe Liu 2389 Huawei Technologies, 2390 Email: liuzhe123@huawei.com 2392 Sergio Belotti 2393 Nokia, 2394 Email: sergio.belotti@nokia.com 2396 Yingxi Yao 2397 Shanghai Bell, 2398 yingxi.yao@nokia-sbell.com 2400 12. References 2402 12.1. Normative References 2404 [I-D.ietf-ccamp-l1csm-yang] 2405 Lee, Y., Lee, K., Zheng, H., Dhody, D., Dios, O., and D. 2406 Ceccarelli, "A YANG Data Model for L1 Connectivity Service 2407 Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-10 (work in 2408 progress), September 2019. 2410 [I-D.ietf-ccamp-otn-topo-yang] 2411 Zheng, H., Busi, I., Liu, X., Belotti, S., and O. Dios, "A 2412 YANG Data Model for Optical Transport Network Topology", 2413 draft-ietf-ccamp-otn-topo-yang-09 (work in progress), 2414 November 2019. 2416 [I-D.ietf-ccamp-otn-tunnel-model] 2417 Zheng, H., Busi, I., Belotti, S., Lopezalvarez, V., and Y. 2418 Xu, "OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel- 2419 model-09 (work in progress), November 2019. 2421 [I-D.ietf-teas-yang-te-topo] 2422 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 2423 O. Dios, "YANG Data Model for Traffic Engineering (TE) 2424 Topologies", draft-ietf-teas-yang-te-topo-22 (work in 2425 progress), June 2019. 2427 [I-D.ietf-teas-yang-te-types] 2428 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 2429 "Traffic Engineering Common YANG Types", draft-ietf-teas- 2430 yang-te-types-12 (work in progress), November 2019. 2432 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2433 the Network Configuration Protocol (NETCONF)", RFC 6020, 2434 DOI 10.17487/RFC6020, October 2010, 2435 . 2437 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2438 and A. Bierman, Ed., "Network Configuration Protocol 2439 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2440 . 2442 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2443 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2444 . 2446 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 2447 and K. Pithewan, "GMPLS Signaling Extensions for Control 2448 of Evolving G.709 Optical Transport Networks", RFC 7139, 2449 DOI 10.17487/RFC7139, March 2014, 2450 . 2452 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2453 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2454 . 2456 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2457 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2458 . 2460 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 2461 "Common YANG Data Types for the Routing Area", RFC 8294, 2462 DOI 10.17487/RFC8294, December 2017, 2463 . 2465 12.2. Informative References 2467 [IEEE802.1ad] 2468 IEEE, 802., "IEEE 802.1ad - Provider Bridges.", IEEE 2469 802.1ad , May 2006. 2471 [IEEE802.1q] 2472 IEEE, 802., "IEEE 802.1q - Virtual Bridged Local Area 2473 Networks", IEEE 802.1q , June 2005. 2475 [MEF10] MEF, 10., "Ethernet Services Attributes Phase 1", MEF10 , 2476 November 2004. 2478 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 2479 Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, 2480 . 2482 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 2483 Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, 2484 . 2486 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2487 DOI 10.17487/RFC3688, January 2004, 2488 . 2490 [RFC4115] Aboul-Magd, O. and S. Rabie, "A Differentiated Service 2491 Two-Rate, Three-Color Marker with Efficient Handling of 2492 in-Profile Traffic", RFC 4115, DOI 10.17487/RFC4115, July 2493 2005, . 2495 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 2496 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 2497 DOI 10.17487/RFC8299, January 2018, 2498 . 2500 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2501 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2502 . 2504 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2505 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2506 . 2508 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2509 and R. Wilton, "Network Management Datastore Architecture 2510 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2511 . 2513 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 2514 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 2515 DOI 10.17487/RFC8453, August 2018, 2516 . 2518 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2519 Data Model for Layer 2 Virtual Private Network (L2VPN) 2520 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2521 2018, . 2523 Authors' Addresses 2525 Haomian Zheng 2526 Huawei Technologies 2527 H1-1-A043S Huawei Industrial Base, Songshanhu 2528 Dongguan, Guangdong 2529 P.R.China 2531 Email: zhenghaomian@huawei.com 2533 Aihua Guo 2534 Individual 2536 Email: aihuaguo.ietf@gmail.com 2537 Italo Busi 2538 Huawei Technologies 2540 Email: Italo.Busi@huawei.com 2542 Anton Snitser 2543 Sedona 2545 Email: antons@sedonasys.com 2547 Francesco Lazzeri 2548 Ericsson 2550 Email: francesco.lazzeri@ericsson.com 2552 Yunbin Xu 2553 CAICT 2555 Email: xuyunbin@caict.ac.cn 2557 Yang Zhao 2558 China Mobile 2560 Email: zhaoyangyjy@chinamobile.com 2562 Xufeng Liu 2563 Volta Networks 2565 Email: xufeng.liu.ietf@gmail.com 2567 Giuseppe Fioccola 2568 Huawei Technologies 2570 Email: giuseppe.fioccola@huawei.com