idnits 2.17.1 draft-ietf-ccamp-client-signal-yang-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances 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 365 has weird spacing: '...le-name str...' == Line 409 has weird spacing: '...oint-id str...' == Line 575 has weird spacing: '...rw name str...' == Line 612 has weird spacing: '...el-name str...' == Line 1015 has weird spacing: '...rouping etht-...' == (5 more instances...) -- The document date (July 09, 2021) is 1021 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 (-26) exists of draft-ietf-ccamp-l1csm-yang-14 == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-layer1-types-10 == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-otn-topo-yang-12 == Outdated reference: A later version (-20) exists of draft-ietf-ccamp-otn-tunnel-model-13 Summary: 1 error (**), 0 flaws (~~), 11 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: January 10, 2022 Futurewei 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 July 09, 2021 22 A YANG Data Model for Transport Network Client Signals 23 draft-ietf-ccamp-client-signal-yang-05 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 January 10, 2022. 58 Copyright Notice 60 Copyright (c) 2021 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 3.3. State of Services . . . . . . . . . . . . . . . . . . . . 8 84 4. YANG Model for Transport Network Client Signal . . . . . . . 8 85 4.1. YANG Tree for Ethernet Service . . . . . . . . . . . . . 8 86 4.2. YANG Tree for other Transport Network Client Signal Model 13 87 5. YANG Code for Transport Network Client Signal . . . . . . . . 14 88 5.1. The ETH Service YANG Code . . . . . . . . . . . . . . . . 14 89 5.2. YANG Code for ETH type . . . . . . . . . . . . . . . . . 34 90 5.3. Other Client Signal YANG Code . . . . . . . . . . . . . . 44 91 5.4. Other Client Signal Types YANG Code . . . . . . . . . . . 49 92 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 50 93 6.1. Usage of the ETH Service YANG Model on ONAP . . . . . . . 51 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 95 8. Manageability Considerations . . . . . . . . . . . . . . . . 53 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 53 97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 98 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 100 12.1. Normative References . . . . . . . . . . . . . . . . . . 54 101 12.2. Informative References . . . . . . . . . . . . . . . . . 55 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 104 1. Introduction 106 1.1. Overview 108 A transport network is a server-layer network designed to provide 109 connectivity services for a client-layer network to carry the client 110 traffic transparently across the server-layer network resources. 111 Currently the topology and tunnel models have been defined for 112 transport networks, including [I-D.ietf-ccamp-otn-topo-yang] and 113 [I-D.ietf-ccamp-otn-tunnel-model], providing server-layer topology 114 abstraction and tunnel configuration between PEs. However, there is 115 a missing piece for configuring how the PEs should map the client- 116 layer traffic, received from the CE, over the server-layer tunnels: 117 this gap is expected to be solved in this document. 119 This document defines a data model of all transport network client 120 signals, using YANG language defined in [RFC7950]. The model can be 121 used by applications exposing to a transport network controller via a 122 RESTconf interface. Furthermore, it can be used by an application 123 for the following purposes (but not limited to): 125 o To request/update an end-to-end service by driving a new tunnel to 126 be set up to support this service; 128 o To request/update an end-to-end service by using an existing 129 tunnel; 131 o To receive notification with regard to the information change of 132 the given service; 134 The YANG modules defined in this document conforms to the Network 135 Management Datastore Architecture (NMDA) defined in [RFC8342]. 137 1.2. Prefixs in Model Names 139 In this document, names of data nodes and other data model objects 140 are prefixed using the standard prefix associated with the 141 corresponding YANG imported modules, including [RFC6991], [RFC8294] 142 and [I-D.ietf-ccamp-otn-tunnel-model], which are shown as follow. 144 +-------------+---------------------------+----------------------+ 145 | Prefix | YANG module | Reference | 146 +-------------+---------------------------+----------------------+ 147 | yang | ietf-yang-types | [RFC6991] | 148 | te-types | ietf-te-types | [RFC8776] | 149 | rt-types | ietf-routing-types | [RFC8294] | 150 | l1-types | ietf-layer1-types |[ietf-ccamp-layer1-types]| 151 | etht-types | ietf-eth-tran-types | This Document | 152 | clntsvc | ietf-trans-client-service | This Document | 153 | ethtsvc | ietf-eth-tran-service | This Document | 154 |clntsvc-types|ietf-trans-client-svc-types| This Document | 155 +-------------+---------------------------+----------------------+ 157 2. Terminology and Notations 159 A simplified graphical representation of the data model is used in 160 this document. The meaning of the symbols in the YANG data tree 161 presented later in this document is defined in [RFC8340]. They are 162 provided below for reference. 164 o Brackets "[" and "]" enclose list keys. 166 o Abbreviations before data node names: "rw" means configuration 167 (read-write) and "ro" state data (read-only). 169 o Symbols after data node names: "?" means an optional node, "!" 170 means a presence container, and "*" denotes a list and leaf-list. 172 o Parentheses enclose choice and case nodes, and case nodes are also 173 marked with a colon (":"). 175 o Ellipsis ("...") stands for contents of subtrees that are not 176 shown. 178 3. Transport Network Client Signal Overview 180 3.1. Overview of Service Request and Network Configuration Scenarios 182 A global view of a multi-domain service can be described as the 183 Figure 1 . The customer is usually responsible to configure the CE 184 nodes and to request to the provider the service intent, from the CE 185 nodes perspective, while the provider is responsible to configure the 186 whole network (including the PE nodes) to support the customer 187 service intent. Generally speaking, the network configurations 188 required to support a customer service can be split into two 189 different groups: CE-PE and PE-PE. The CE-PE configuration deals 190 with the client layer one-hop access link, while PE-PE configuration 191 deals with the server layer tunnel. In Figure 1 we mark the 192 intermediate nodes as 'P', which has same switching capability of PE 193 but just not the 'end-point'. In this example, the link P-P and PE-P 194 are a server-layer intra-domain or inter-domain link. 196 +----+ +----+ 197 | CE | | CE | 198 +--+-+ +--+-+ 199 | | 200 | ------------- -------------| 201 //|/ \\\\ ///// |\\\\ 202 // | \\ // | \\ 203 | +--+-+ +---+ +---+ | | +---+ +---+ +--+-+ | 204 | | PE +----+ P +--+ P +---+-----+--+ P +---+ P +---+ PE | | 205 | +----+ +---+ +---+ | | +---+ +---+ +----+ | 206 \\ // \\ // 207 \\\\ //// \\\\\ ///// 208 ------------- ------------- 209 Domain 1 Domain 2 211 Figure 1: Global view of Client Service with the Network Provider 213 According to the responsibilities of each controller in [RFC8453], 214 the controllers have different views of the service request and 215 network configuration. The duty of CNC is to give the MDSC a 216 description of the customer service intent: candidate YANG models 217 include L1CSM [I-D.ietf-ccamp-l1csm-yang], L2SM [RFC8466] and L3SM 218 [RFC8299], which are classified as customer service models, according 219 to [RFC8309]. These models provide necessary attributes to describe 220 the customer service intent from the customer/CE perspective, and do 221 not provide any specific network configuration. These models also 222 implies that the customer service description can be considered in a 223 separate manner rather than integratig with network configurations, 224 which also enable the controllers to abstract/virtualize the network 225 resource to make them visible to the customer and also easier to 226 manage. In other words, the network knowledge is not necessary at 227 CNC and CMI, which is seen in an abstracted form as shown in 228 Figure 2. 230 /---------\ 231 /// \\\ 232 +----+ | | +----+ 233 | CE |--------------+ NETWORK +----------------| CE | 234 +----+ | | +----+ 235 \\\ /// 236 \---------/ 238 Figure 2: CNC Viewpoint on the Client Service 240 The functionalities of MDSC have been described in [RFC8453], which 241 include the customer mapping/translation and multi-domain 242 coordination. By receiving the request from CNC, MDSC need to 243 understand what network configuration can support the customer 244 service intent and turn to the corresponding PNCs for configuration. 245 The service request is therefore decomposed by MDSC into a few 246 network configurations and forwarded to one or multiple PNCs 247 respectively in single-domain and multi-domain scenario. In general, 248 the MDSC has the view of both PE and CE nodes and of some abstract 249 information regarding the P nodes, as shown in Figure 3. It is worth 250 noting that this MDSC view is different with Figure 1 at the intra- 251 domain link. Usually these details are hidden, for scalability 252 purposes, and therefore the MDSC has only an abstract view of each 253 domain internal topology. 255 ------ ----- 256 //// \\\\ ///- -\\\ 257 // \\ // \\ 258 +----+ | +----+ +---+ | |+---+ +----+ | +----+ 259 | CE |-----+-| PE |-----| P |-+--+| P |-----| PE |-+-----| CE | 260 +----+ | +----+ +---+ | |+---+ +----+ | +----+ 261 \\ // \\ // 262 \\\\ //// \\\- -/// 263 ------ ----- 264 Domain 1 Domain 2 266 Figure 3: MDSC view of both Client Service and Network Abstraction 268 PNC is the controller that configure the physical devices, based on 269 the network configuration received from the MDSC. Each PNC has the 270 detailed view of its own domain, the example of view from PNC in 271 domain 1 is shown in Figure 4. The PNC has all the detailed topology 272 information on PE and P nodes and on the intra-domain links. The PNC 273 configures the tunnel/tunnel segment within its domain based on the 274 network configuration provided by the MDSC. The PNC also configures 275 the network part of the CE-PE access links as well as the mapping of 276 the client-layer traffic and the server-layer tunnels, based on the 277 network configuration provided by the MDSC. The interaction between 278 PNC and MDSC for the client-layer network configuration is 279 accomplished by the models defined in this draft. 281 | | | 282 | ------------- | -------------| 283 //|/ \\\\ | ///// |\\\\ 284 // | \\ | // | \\ 285 | +--+-+ +---+ +---+ | | | +---+ +---+ +--+-+ | 286 | | PE +----+ P +--+ P +---+--+--+--+ P +---+ P +---+ PE | | 287 | +----+ +---+ +---+ | | | +---+ +---+ +----+ | 288 \\ // | \\ // 289 \\\\ //// | \\\\\ ///// 290 ------------- | ------------- 291 PNC View in Domain 1 | PNC View in Domain 2 292 | 294 Figure 4: PNC view on Network Configuration 296 3.2. Applicability of Proposed Model 298 Existing TE and technology-specific models, such as topology models 299 and tunnel models, support the network configuration among PEs and 300 Ps. The customer service models, such as L1CSM, L2SM and L3SM, focus 301 on describing the attributes among CEs. However, there is a missing 302 piece on how to configure the CE-PE session. The models defined in 303 this document provide the configuration on CE-PE when the provider 304 server-layer network is TE-based technology. 306 In the example of OTN as the server-layer transport network, a full 307 list of G-PID was summarized in [RFC7139], which can be divided into 308 a few categories. The G-PID signals can be categorized into 309 transparent and non-transparent. Examples of transparent signals may 310 include Ethernetphysical interfaces, FC, STM-n and so on. In this 311 approach the OTN devices is not aware of the client signal type, and 312 this information is only necessary among the controllers. Once the 313 OTN tunnel is set up, there is no switching requested on the client 314 layer, and therefore only signal mapping is needed, without a client 315 tunnel set up. The models that supporting the configuration of 316 transparent signals are defined in Section 4.2. The other category 317 would be non-transparent, such as Carrier Ethernet and MPLS-TP, with 318 a switching request on the client layer. Once the OTN tunnel is set 319 up, a corresponding tunnel in the client layer has to be set up to 320 carry services. The models that supporting the configuration of 321 transparent signals are defined in Section 4.1. 323 It is also worth noting that some client signal can be carried over 324 multiple types of networks. For example, the Ethernet services can 325 be carried over either OTN or Ethernet TE tunnels (over optical or 326 microwave networks). The model specified in this document allows the 327 support from networks with different technologies. The list of 328 identities for client signals are defined in 329 [I-D.ietf-ccamp-layer1-types]. 331 3.3. State of Services 333 States have been defined to retrieve the status of the delivered 334 services. A few generic states defined in [RFC8776] are reused in 335 this document. These states include the operational state and the 336 provisioning state. 338 A few other parameters are defined for the management of the 339 services. Given the complicated labor division, the creation, update 340 and maintainance may have different responsible systems. So the log 341 of the service would be helpful and should be easy to retrived in a 342 standard way as well. These information include, but not restricted 343 to the following: 345 o When the service is created and has been last updated, these are 346 specified in the creation-time and last-updated-time. 348 o Who created the service and who made the last update to the 349 service, these are specified in the created-by and last-updated- 350 by. 352 o The owner of the service is specifed as owned-by, which would be 353 useful when the service is delegated by or to a specific system. 354 The identifier of the system is used to represent such 355 information. 357 4. YANG Model for Transport Network Client Signal 359 4.1. YANG Tree for Ethernet Service 361 module: ietf-eth-tran-service 362 +--rw etht-svc 363 +--rw globals 364 | +--rw named-bandwidth-profiles* [bandwidth-profile-name] 365 | +--rw bandwidth-profile-name string 366 | +--rw bandwidth-profile-type? 367 | | etht-types:bandwidth-profile-type 368 | +--rw CIR? uint64 369 | +--rw CBS? uint64 370 | +--rw EIR? uint64 371 | +--rw EBS? uint64 372 | +--rw color-aware? boolean 373 | +--rw coupling-flag? boolean 374 +--rw etht-svc-instances* [etht-svc-name] 375 +--rw etht-svc-name string 376 +--rw etht-svc-title? string 377 +--rw etht-svc-descr? string 378 +--rw etht-svc-customer? string 379 +--rw etht-svc-type? etht-types:service-type 380 +--rw etht-svc-lifecycle? etht-types:lifecycle-status 381 +--rw te-topology-identifier 382 | +--rw provider-id? te-global-id 383 | +--rw client-id? te-global-id 384 | +--rw topology-id? te-topology-id 385 +--rw resilience 386 | +--rw protection 387 | | +--rw enable? boolean 388 | | +--rw protection-type? identityref 389 | | +--rw protection-reversion-disable? boolean 390 | | +--rw hold-off-time? uint32 391 | | +--rw wait-to-revert? uint16 392 | | +--rw aps-signal-id? uint8 393 | +--rw restoration 394 | +--rw enable? boolean 395 | +--rw restoration-type? identityref 396 | +--rw restoration-scheme? identityref 397 | +--rw restoration-reversion-disable? boolean 398 | +--rw hold-off-time? uint32 399 | +--rw wait-to-restore? uint16 400 | +--rw wait-to-revert? uint16 401 +--rw etht-svc-end-points* [etht-svc-end-point-name] 402 | +--rw etht-svc-end-point-name string 403 | +--rw etht-svc-end-point-id? string 404 | +--rw etht-svc-end-point-descr? string 405 | +--rw topology-role? 406 | | identityref 407 | +--rw resilience 408 | +--rw etht-svc-access-points* [access-point-id] 409 | | +--rw access-point-id string 410 | | +--rw access-node-id? te-types:te-node-id 411 | | +--rw access-ltp-id? te-types:te-tp-id 412 | | +--rw access-role? identityref 413 | | +--rw pm-config 414 | | | +--rw pm-enable? boolean 415 | | | +--rw sending-rate-high? uint64 416 | | | +--rw sending-rate-low? uint64 417 | | | +--rw receiving-rate-high? uint64 418 | | | +--rw receiving-rate-low? uint64 419 | | +--ro state 420 | | | +--ro operational-state? identityref 421 | | | +--ro provisioning-state? identityref 422 | | +--ro performance? identityref 423 | +--rw service-classification-type? 424 | | identityref 425 | +--rw (service-classification)? 426 | | +--:(port-classification) 427 | | +--:(vlan-classification) 428 | | +--rw outer-tag! 429 | | | +--rw tag-type? 430 | | | | etht-types:eth-tag-classify 431 | | | +--rw (individual-bundling-vlan)? 432 | | | +--:(individual-vlan) 433 | | | | +--rw vlan-value? etht-types:vlanid 434 | | | +--:(vlan-bundling) 435 | | | +--rw vlan-range? 436 | | | etht-types:vid-range-type 437 | | +--rw second-tag! 438 | | +--rw tag-type? 439 | | | etht-types:eth-tag-classify 440 | | +--rw (individual-bundling-vlan)? 441 | | +--:(individual-vlan) 442 | | | +--rw vlan-value? etht-types:vlanid 443 | | +--:(vlan-bundling) 444 | | +--rw vlan-range? 445 | | etht-types:vid-range-type 446 | +--rw split-horizon-group? string 447 | +--rw (direction)? 448 | | +--:(symmetrical) 449 | | | +--rw ingress-egress-bandwidth-profile 450 | | | +--rw (style)? 451 | | | +--:(named) 452 | | | | +--rw bandwidth-profile-name? leafref 453 | | | +--:(value) 454 | | | +--rw bandwidth-profile-type? 455 | | | | etht-types:bandwidth-profile-type 456 | | | +--rw CIR? uint64 457 | | | +--rw CBS? uint64 458 | | | +--rw EIR? uint64 459 | | | +--rw EBS? uint64 460 | | | +--rw color-aware? boolean 461 | | | +--rw coupling-flag? boolean 462 | | +--:(asymmetrical) 463 | | +--rw ingress-bandwidth-profile 464 | | | +--rw (style)? 465 | | | +--:(named) 466 | | | | +--rw bandwidth-profile-name? leafref 467 | | | +--:(value) 468 | | | +--rw bandwidth-profile-type? 469 | | | | etht-types:bandwidth-profile-type 470 | | | +--rw CIR? uint64 471 | | | +--rw CBS? uint64 472 | | | +--rw EIR? uint64 473 | | | +--rw EBS? uint64 474 | | | +--rw color-aware? boolean 475 | | | +--rw coupling-flag? boolean 476 | | +--rw egress-bandwidth-profile 477 | | +--rw (style)? 478 | | +--:(named) 479 | | | +--rw bandwidth-profile-name? leafref 480 | | +--:(value) 481 | | +--rw bandwidth-profile-type? 482 | | | etht-types:bandwidth-profile-type 483 | | +--rw CIR? uint64 484 | | +--rw CBS? uint64 485 | | +--rw EIR? uint64 486 | | +--rw EBS? uint64 487 | | +--rw color-aware? boolean 488 | | +--rw coupling-flag? boolean 489 | +--rw vlan-operations 490 | +--rw (direction)? 491 | +--:(symmetrical) 492 | | +--rw symmetrical-operation 493 | | +--rw pop-tags? uint8 494 | | +--rw push-tags 495 | | +--rw outer-tag! 496 | | | +--rw tag-type? 497 | | | | etht-types:eth-tag-type 498 | | | +--rw vlan-value? etht-types:vlanid 499 | | | +--rw default-pcp? uint8 500 | | +--rw second-tag! 501 | | +--rw tag-type? 502 | | | etht-types:eth-tag-type 503 | | +--rw vlan-value? etht-types:vlanid 504 | | +--rw default-pcp? uint8 505 | +--:(asymmetrical) 506 | +--rw asymmetrical-operation 507 | +--rw ingress 508 | | +--rw pop-tags? uint8 509 | | +--rw push-tags 510 | | +--rw outer-tag! 511 | | | +--rw tag-type? 512 | | | | etht-types:eth-tag-type 513 | | | +--rw vlan-value? 514 | | | | etht-types:vlanid 515 | | | +--rw default-pcp? uint8 516 | | +--rw second-tag! 517 | | +--rw tag-type? 518 | | | etht-types:eth-tag-type 519 | | +--rw vlan-value? 520 | | | etht-types:vlanid 521 | | +--rw default-pcp? uint8 522 | +--rw egress 523 | +--rw pop-tags? uint8 524 | +--rw push-tags 525 | +--rw outer-tag! 526 | | +--rw tag-type? 527 | | | etht-types:eth-tag-type 528 | | +--rw vlan-value? 529 | | | etht-types:vlanid 530 | | +--rw default-pcp? uint8 531 | +--rw second-tag! 532 | +--rw tag-type? 533 | | etht-types:eth-tag-type 534 | +--rw vlan-value? 535 | | etht-types:vlanid 536 | +--rw default-pcp? uint8 537 +--rw underlay 538 | +--rw (technology)? 539 | | +--:(native-ethernet) 540 | | | +--rw eth-tunnels* [name] 541 | | | +--rw name 542 | | | | -> /te:te/tunnels/tunnel/name 543 | | | +--rw encoding? identityref 544 | | | +--rw switching-type? identityref 545 | | +--:(frame-base) 546 | | | +--rw otn-tunnels* [name] 547 | | | +--rw name 548 | | | | -> /te:te/tunnels/tunnel/name 549 | | | +--rw encoding? identityref 550 | | | +--rw switching-type? identityref 551 | | +--:(mpls-tp) 552 | | +--rw pw 553 | | +--rw pw-id? string 554 | | +--rw pw-name? string 555 | | +--rw transmit-label? 556 | | | rt-types:mpls-label 557 | | +--rw receive-label? 558 | | | rt-types:mpls-label 559 | | +--rw encapsulation-type? identityref 560 | | +--ro oper-status? identityref 561 | | +--rw ingress-bandwidth-profile 562 | | | +--rw (style)? 563 | | | +--:(named) 564 | | | | +--rw bandwidth-profile-name? leafref 565 | | | +--:(value) 566 | | | +--rw bandwidth-profile-type? 567 | | | | etht-types:bandwidth-profile-type 568 | | | +--rw CIR? uint64 569 | | | +--rw CBS? uint64 570 | | | +--rw EIR? uint64 571 | | | +--rw EBS? uint64 572 | | +--rw pw-paths* [path-id] 573 | | +--rw path-id uint8 574 | | +--rw tp-tunnels* [name] 575 | | +--rw name string 576 | +--rw src-split-horizon-group? string 577 | +--rw dst-split-horizon-group? string 578 +--rw admin-status? identityref 579 +--ro state 580 +--ro operational-state? identityref 581 +--ro provisioning-state? identityref 582 +--ro creation-time? yang:date-and-time 583 +--ro last-updated-time? yang:date-and-time 584 +--ro created-by? string 585 +--ro last-updated-by? string 586 +--ro owned-by? string 588 4.2. YANG Tree for other Transport Network Client Signal Model 589 module: ietf-trans-client-service 590 +--rw client-svc 591 +--rw client-svc-instances* [client-svc-name] 592 +--rw client-svc-name string 593 +--rw client-svc-title? string 594 +--rw client-svc-descr? string 595 +--rw client-svc-customer? string 596 +--rw resilience 597 +--rw te-topology-identifier 598 | +--rw provider-id? te-global-id 599 | +--rw client-id? te-global-id 600 | +--rw topology-id? te-topology-id 601 +--rw admin-status? identityref 602 +--rw src-access-ports 603 | +--rw access-node-id? te-types:te-node-id 604 | +--rw access-ltp-id? te-types:te-tp-id 605 | +--rw client-signal? identityref 606 +--rw dst-access-ports 607 | +--rw access-node-id? te-types:te-node-id 608 | +--rw access-ltp-id? te-types:te-tp-id 609 | +--rw client-signal? identityref 610 +--rw direction? identityref 611 +--rw svc-tunnels* [tunnel-name] 612 | +--rw tunnel-name string 613 +--ro operational-state? identityref 614 +--ro provisioning-state? identityref 615 +--ro creation-time? yang:date-and-time 616 +--ro last-updated-time? yang:date-and-time 617 +--ro created-by? string 618 +--ro last-updated-by? string 619 +--ro owned-by? string 621 5. YANG Code for Transport Network Client Signal 623 5.1. The ETH Service YANG Code 625 This module imports typedefs and modules from [RFC6991], [RFC8294], 626 [RFC8776]. 628 file "ietf-eth-tran-service@2021-01-11.yang" 629 module ietf-eth-tran-service { 630 yang-version 1.1; 631 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-tran-service"; 633 prefix "ethtsvc"; 634 import ietf-yang-types { 635 prefix "yang"; 636 reference "RFC 6991 - Common YANG Data Types"; 637 } 639 import ietf-te-types { 640 prefix "te-types"; 641 reference "RFC 8776 - Traffic Engineering Common YANG Types"; 642 } 644 import ietf-eth-tran-types { 645 prefix "etht-types"; 646 reference "RFC XXXX - A YANG Data Model for Transport 647 Network Client Signals"; 648 } 650 import ietf-routing-types { 651 prefix "rt-types"; 652 reference "RFC 8294 - Common YANG Data Types for the 653 Routing Area"; 655 } 657 import ietf-te { 658 prefix "te"; 659 reference "RFC YYYY - A YANG Data Model for Traffic 660 Engineering Tunnels and Interfaces"; 661 } 663 organization 664 "Internet Engineering Task Force (IETF) CCAMP WG"; 665 contact 666 " 667 WG List: 669 ID-draft editor: 670 Haomian Zheng (zhenghaomian@huawei.com); 671 Italo Busi (italo.busi@huawei.com); 672 Aihua Guo (aihuaguo.ietf@gmail.com); 673 Anton Snitser (antons@sedonasys.com);0 674 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 675 Yunbin Xu (xuyunbin@caict.ac.cn); 676 Yang Zhao (zhaoyangyjy@chinamobile.com); 677 Xufeng Liu (xufeng.liu.ietf@gmail.com); 678 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 679 "; 681 description 682 "This module defines a YANG data model for describing 683 the Ethernet services. The model fully conforms to the 684 Network Management Datastore Architecture (NMDA). 686 Copyright (c) 2021 IETF Trust and the persons 687 identified as authors of the code. All rights reserved. 689 Redistribution and use in source and binary forms, with or 690 without modification, is permitted pursuant to, and subject 691 to the license terms contained in, the Simplified BSD License 692 set forth in Section 4.c of the IETF Trust's Legal Provisions 693 Relating to IETF Documents 694 (https://trustee.ietf.org/license-info). 695 This version of this YANG module is part of RFC XXXX; see 696 the RFC itself for full legal notices."; 698 revision 2021-01-11 { 699 description 700 "version -04 as an WG document"; 701 reference 702 "draft-ietf-ccamp-client-signal-yang"; 703 } 705 /* 706 * Groupings 707 */ 709 grouping vlan-classification { 710 description 711 "A grouping which represents classification 712 on an 802.1Q VLAN tag."; 714 leaf tag-type { 715 type etht-types:eth-tag-classify; 716 description 717 "The tag type used for VLAN classification."; 718 } 719 choice individual-bundling-vlan { 720 description 721 "VLAN based classification can be individual 722 or bundling."; 724 case individual-vlan { 725 leaf vlan-value { 726 type etht-types:vlanid; 727 description 728 "VLAN ID value."; 729 } 731 } 733 case vlan-bundling { 734 leaf vlan-range { 735 type etht-types:vid-range-type; 736 description 737 "List of VLAN ID values."; 738 } 739 } 740 } 741 } 743 grouping vlan-write { 744 description 745 "A grouping which represents push/pop operations 746 of an 802.1Q VLAN tag."; 748 leaf tag-type { 749 type etht-types:eth-tag-type; 750 description 751 "The VLAN tag type to push/swap."; 752 } 753 leaf vlan-value { 754 type etht-types:vlanid; 755 description 756 "The VLAN ID value to push/swap."; 757 } 758 /* 759 * To be added: this attribute is used when: 760 * a) the ETH service has only one CoS (as in current version) 761 * b) as a default when a mapping between a given CoS value 762 * and the PCP value is not defined (in future versions) 763 */ 764 leaf default-pcp { 765 type uint8 { 766 range "0..7"; 767 } 768 description 769 "The default Priority Code Point (PCP) value to push/swap"; 770 } 771 } 773 grouping vlan-operations { 774 description 775 "A grouping which represents VLAN operations."; 777 leaf pop-tags { 778 type uint8 { 779 range "1..2"; 780 } 781 description 782 "The number of VLAN tags to pop (or swap if used in 783 conjunction with push-tags)"; 784 } 785 container push-tags { 786 description 787 "The VLAN tags to push (or swap if used in 788 conjunction with pop-tags)"; 790 container outer-tag { 791 presence 792 "Indicates existence of the outermost VLAN tag to 793 push/swap"; 795 description 796 "The outermost VLAN tag to push/swap."; 798 uses vlan-write; 799 } 800 container second-tag { 801 must 802 '../outer-tag/tag-type = "etht-types:s-vlan-tag-type" and ' + 803 'tag-type = "etht-types:c-vlan-tag-type"' 804 { 806 error-message 807 " 808 When pushing/swapping two tags, the outermost tag must 809 be specified and of S-VLAN type and the second 810 outermost tag must be of C-VLAN tag type. 811 "; 812 description 813 " 814 For IEEE 802.1Q interoperability, when pushing/swapping 815 two tags, it is required that the outermost tag exists 816 and is an S-VLAN, and the second outermost tag is a 817 C-VLAN. 818 "; 819 } 821 presence 822 "Indicates existence of a second outermost VLAN tag to 823 push/swap"; 825 description 826 "The second outermost VLAN tag to push/swap."; 828 uses vlan-write; 829 } 830 } 831 } 833 grouping named-or-value-bandwidth-profile { 834 description 835 "A grouping to configure a bandwdith profile either by 836 referencing a named bandwidth profile or by 837 configuring the values of the bandwidth profile attributes."; 838 choice style { 839 description 840 "Whether the bandwidth profile is named or defined by value"; 842 case named { 843 description 844 "Named bandwidth profile."; 845 leaf bandwidth-profile-name { 846 type leafref { 847 path "/ethtsvc:etht-svc/ethtsvc:globals/" 848 + "ethtsvc:named-bandwidth-profiles/" 849 + "ethtsvc:bandwidth-profile-name"; 850 } 851 description 852 "Name of the bandwidth profile."; 853 } 854 } 855 case value { 856 description 857 "Bandwidth profile configured by value."; 858 uses etht-types:etht-bandwidth-profiles; 859 } 860 } 861 } 863 grouping bandwidth-profiles { 864 description 865 "A grouping which represent bandwidth profile configuration."; 867 choice direction { 868 description 869 "Whether the bandwidth profiles are symmetrical or 870 asymmetrical"; 871 case symmetrical { 872 description 873 "The same bandwidth profile is used to describe both 874 the ingress and the egress bandwidth profile."; 875 container ingress-egress-bandwidth-profile { 876 description 877 "The bandwdith profile used in both directions."; 878 uses named-or-value-bandwidth-profile; 879 } 880 } 881 case asymmetrical { 882 description 883 "Ingress and egress bandwidth profiles can be specified."; 884 container ingress-bandwidth-profile { 885 description 886 "The bandwdith profile used in the ingress direction."; 887 uses named-or-value-bandwidth-profile; 888 } 889 container egress-bandwidth-profile { 890 description 891 "The bandwdith profile used in the egress direction."; 892 uses named-or-value-bandwidth-profile; 893 } 894 } 895 } 896 } 898 grouping etht-svc-access-parameters { 899 description 900 "ETH services access parameters"; 902 leaf access-node-id { 903 type te-types:te-node-id; 904 description 905 "The identifier of the access node in 906 the ETH topology."; 907 } 908 leaf access-ltp-id { 909 type te-types:te-tp-id; 910 description 911 "The TE link termination point identifier, used 912 together with access-node-id to identify the 913 access LTP."; 914 } 915 leaf access-role { 916 type identityref { 917 base etht-types:access-role; 918 } 919 description 920 "Indicate the role of access, e.g., working or protection. "; 921 } 923 container pm-config { 924 uses pm-config-grouping; 925 description 926 "This grouping is used to set the threshold value for 927 performance monitoring. "; 928 } 930 container state { 931 config false; 932 description 933 "The state is used to monitor the status of service. "; 934 leaf operational-state { 935 type identityref { 936 base te-types:tunnel-state-type; 937 } 938 description 939 "Indicating the operational state of client signal. "; 940 } 941 leaf provisioning-state { 942 type identityref { 943 base te-types:lsp-state-type; 944 } 945 description 946 "Indicating the provisional state of client signal, 947 especially when there is a change, i.e., revise, create. "; 948 } 949 } 951 leaf performance { 952 type identityref { 953 base etht-types:performance; 954 } 955 config false; 956 description 957 "Performance Monitoring for the service. "; 958 } 960 } 962 grouping etht-svc-tunnel-parameters { 963 description 964 "ETH services tunnel parameters."; 965 choice technology { 966 description 967 "Service multiplexing is optional and flexible."; 969 case native-ethernet { 970 /* 971 placeholder to support proprietary multiplexing 972 (for further discussion) 973 */ 974 list eth-tunnels { 975 key name; 976 description 977 "ETH Tunnel list in native Ethernet scenario."; 978 uses tunnels-grouping; 979 } 980 } 982 case frame-base { 983 list otn-tunnels { 984 key name; 985 description 986 "OTN Tunnel list in Frame-based scenario."; 987 uses tunnels-grouping; 988 } 989 } 991 case mpls-tp { 992 container pw { 993 description 994 "Pseudowire information for Ethernet over MPLS-TP."; 995 uses pw-segment-grouping; 996 } 997 } 998 } 1000 /* 1001 * Open issue: can we constraints it to be used only with mp services? 1002 */ 1003 leaf src-split-horizon-group { 1004 type string; 1005 description 1006 "Identify a split horizon group at the Tunnel source TTP"; 1007 } 1008 leaf dst-split-horizon-group { 1009 type string; 1010 description 1011 "Identify a split horizon group at the Tunnel destination TTP"; 1012 } 1013 } 1015 grouping etht-svc-pm-threshold-config { 1016 description 1017 "Configuraiton parameters for Ethernet service PM thresholds."; 1019 leaf sending-rate-high { 1020 type uint64; 1021 description 1022 "High threshold of packet sending rate in kbps."; 1023 } 1024 leaf sending-rate-low { 1025 type uint64; 1026 description 1027 "Low threshold of packet sending rate in kbps."; 1028 } 1029 leaf receiving-rate-high { 1030 type uint64; 1031 description 1032 "High threshold of packet receiving rate in kbps."; 1033 } 1034 leaf receiving-rate-low { 1035 type uint64; 1036 description 1037 "Low threshold of packet receiving rate in kbps."; 1038 } 1039 } 1041 grouping etht-svc-pm-stats { 1042 description 1043 "Ethernet service PM statistics."; 1045 leaf sending-rate-too-high { 1046 type uint32; 1047 description 1048 "Counter that indicates the number of times the 1049 sending rate is above the high threshold"; 1050 } 1051 leaf sending-rate-too-low { 1052 type uint32; 1053 description 1054 "Counter that indicates the number of times the 1055 sending rate is below the low threshold"; 1056 } 1057 leaf receiving-rate-too-high { 1058 type uint32; 1059 description 1060 "Counter that indicates the number of times the 1061 receiving rate is above the high threshold"; 1062 } 1063 leaf receiving-rate-too-low { 1064 type uint32; 1065 description 1066 "Counter that indicates the number of times the 1067 receiving rate is below the low threshold"; 1068 } 1069 } 1071 grouping etht-svc-instance-config { 1072 description 1073 "Configuraiton parameters for Ethernet services."; 1075 leaf etht-svc-name { 1076 type string; 1077 description 1078 "Name of the ETH service."; 1079 } 1081 leaf etht-svc-title { 1082 type string; 1083 description 1084 "The Identifier of the ETH service."; 1085 } 1087 leaf etht-svc-descr { 1088 type string; 1089 description 1090 "Description of the ETH service."; 1091 } 1093 leaf etht-svc-customer { 1094 type string; 1095 description 1096 "Customer of the ETH service."; 1097 } 1099 leaf etht-svc-type { 1100 type etht-types:service-type; 1101 description 1102 "Type of ETH service (p2p, mp2mp or rmp)."; 1103 /* Add default as p2p */ 1104 } 1106 leaf etht-svc-lifecycle { 1107 type etht-types:lifecycle-status; 1108 description 1109 "Lifecycle state of ETH service."; 1110 /* Add default as installed */ 1111 } 1112 uses te-types:te-topology-identifier; 1114 uses resilience-grouping; 1115 list etht-svc-end-points { 1116 key etht-svc-end-point-name; 1117 description 1118 "The logical end point for the ETH service. "; 1119 uses etht-svc-end-point-grouping; 1120 } 1122 container underlay { 1123 description 1124 "The unterlay tunnel information that carrying the 1125 ETH service. "; 1126 uses etht-svc-tunnel-parameters; 1127 } 1129 leaf admin-status { 1130 type identityref { 1131 base te-types:tunnel-admin-state-type; 1132 } 1133 default te-types:tunnel-admin-state-up; 1134 description "ETH service administrative state."; 1135 } 1136 } 1138 grouping etht-svc-instance-state { 1139 description 1140 "State parameters for Ethernet services."; 1142 leaf operational-state { 1143 type identityref { 1144 base te-types:tunnel-state-type; 1145 } 1146 default te-types:tunnel-state-up; 1147 description "ETH service operational state."; 1148 } 1149 leaf provisioning-state { 1150 type identityref { 1151 base te-types:lsp-state-type; 1152 } 1153 description "ETH service provisioning state."; 1154 } 1155 leaf creation-time { 1156 type yang:date-and-time; 1157 description 1158 "Time of ETH service creation."; 1159 } 1160 leaf last-updated-time { 1161 type yang:date-and-time; 1162 description 1163 "Time of ETH service last update."; 1164 } 1166 leaf created-by { 1167 type string; 1168 description 1169 "The client signal is created by whom, 1170 can be a system or staff ID."; 1171 } 1172 leaf last-updated-by { 1173 type string; 1174 description 1175 "The client signal is last updated by whom, 1176 can be a system or staff ID."; 1177 } 1178 leaf owned-by { 1179 type string; 1180 description 1181 "The client signal is last updated by whom, 1182 can be a system ID."; 1183 } 1184 } 1186 /* 1187 * Data nodes 1188 */ 1190 container etht-svc { 1191 description 1192 "ETH services."; 1194 container globals { 1195 description 1196 "Globals Ethernet configuration data container"; 1197 list named-bandwidth-profiles { 1198 key bandwidth-profile-name; 1199 description 1200 "List of named bandwidth profiles used by 1201 Ethernet services."; 1203 leaf bandwidth-profile-name { 1204 type string; 1205 description 1206 "Name of the bandwidth profile."; 1207 } 1208 uses etht-types:etht-bandwidth-profiles; 1209 } 1211 } 1213 list etht-svc-instances { 1214 key etht-svc-name; 1215 description 1216 "The list of p2p ETH service instances"; 1218 uses etht-svc-instance-config; 1220 container state { 1221 config false; 1222 description 1223 "Ethernet Service states."; 1225 uses etht-svc-instance-state; 1226 } 1227 } 1228 } 1230 grouping resilience-grouping { 1231 description 1232 "Grouping for resilience configuration. "; 1233 container resilience { 1234 description 1235 "To configure the data plane protection parameters, 1236 currently a placeholder only, future candidate attributes 1237 include, Revert, WTR, Hold-off Timer, ..."; 1238 uses te:protection-restoration-properties; 1239 } 1240 } 1242 grouping etht-svc-end-point-grouping { 1243 description 1244 "Grouping for the end point configuration."; 1245 leaf etht-svc-end-point-name { 1246 type string; 1247 description 1248 "The name of the logical end point of ETH service. "; 1249 } 1251 leaf etht-svc-end-point-id { 1252 type string; 1253 description 1254 "The identifier of the logical end point of ETH service."; 1255 } 1257 leaf etht-svc-end-point-descr { 1258 type string; 1259 description 1260 "The description of the logical end point of ETH service. "; 1261 } 1263 leaf topology-role { 1264 type identityref { 1265 base etht-types:topology-role; 1266 } 1267 description 1268 "Indicating the underlay topology role, 1269 e.g., hub,spoke, any-to-any "; 1270 } 1272 container resilience { 1273 description 1274 "Placeholder for resilience configuration, for future study. "; 1275 } 1277 list etht-svc-access-points { 1278 key access-point-id; 1279 min-elements "1"; 1280 /* 1281 Open Issue: 1282 Is it possible to limit the max-elements only for p2p services? 1283 max-elements "2"; 1284 */ 1285 description 1286 "List of the ETH trasport services access point instances."; 1288 leaf access-point-id { 1289 type string; 1290 description 1291 "ID of the service access point instance"; 1292 } 1293 uses etht-svc-access-parameters; 1294 } 1296 leaf service-classification-type { 1297 type identityref { 1298 base etht-types:service-classification-type; 1299 } 1300 description 1301 "Service classification type."; 1302 } 1304 choice service-classification { 1305 description 1306 "Access classification can be port-based or 1307 VLAN based."; 1309 case port-classification { 1310 /* no additional information */ 1311 } 1313 case vlan-classification { 1314 container outer-tag { 1315 presence "The outermost VLAN tag exists"; 1316 description 1317 "Classifies traffic using the outermost VLAN tag."; 1319 uses vlan-classification; 1320 } 1321 container second-tag { 1322 must 1323 '../outer-tag/tag-type = "etht-types:classify-s-vlan" and ' + 1324 'tag-type = "etht-types:classify-c-vlan"' 1325 { 1326 error-message 1327 " 1328 When matching two tags, the outermost tag must be 1329 specified and of S-VLAN type and the second 1330 outermost tag must be of C-VLAN tag type. 1331 "; 1332 description 1333 " 1334 For IEEE 802.1Q interoperability, when matching two 1335 tags, it is required that the outermost tag exists 1336 and is an S-VLAN, and the second outermost tag is a 1337 C-VLAN. 1338 "; 1339 } 1340 presence "The second outermost VLAN tag exists"; 1342 description 1343 "Classifies traffic using the second outermost VLAN tag."; 1345 uses vlan-classification; 1346 } 1347 } 1348 } 1350 /* 1351 * Open issue: can we constraints it to be used only with mp services? 1352 */ 1353 leaf split-horizon-group { 1354 type string; 1355 description "Identify a split horizon group"; 1356 } 1358 uses bandwidth-profiles; 1360 container vlan-operations { 1361 description 1362 "Configuration of VLAN operations."; 1363 choice direction { 1364 description 1365 "Whether the VLAN operations are symmetrical or 1366 asymmetrical"; 1367 case symmetrical { 1368 container symmetrical-operation { 1369 uses vlan-operations; 1370 description 1371 "Symmetrical operations. 1372 Expressed in the ingress direction, but 1373 the reverse operation is applied to egress traffic"; 1374 } 1375 } 1376 case asymmetrical { 1377 container asymmetrical-operation { 1378 description "Asymmetrical operations"; 1379 container ingress { 1380 uses vlan-operations; 1381 description "Ingress operations"; 1382 } 1383 container egress { 1384 uses vlan-operations; 1385 description "Egress operations"; 1386 } 1387 } 1388 } 1389 } 1390 } 1391 } 1393 grouping pm-config-grouping { 1394 description 1395 "Grouping used for Performance Monitoring Configuration. "; 1396 leaf pm-enable { 1397 type boolean; 1398 description 1399 "Whether to enable the performance monitoring."; 1400 } 1402 leaf sending-rate-high { 1403 type uint64; 1404 description 1405 "The upperbound of sending rate."; 1406 } 1408 leaf sending-rate-low { 1409 type uint64; 1410 description 1411 "The lowerbound of sending rate."; 1412 } 1414 leaf receiving-rate-high { 1415 type uint64; 1416 description 1417 "The upperbound of receiving rate."; 1418 } 1420 leaf receiving-rate-low { 1421 type uint64; 1422 description 1423 "The lowerbound of receiving rate."; 1424 } 1425 } 1427 grouping pw-segment-grouping { 1428 description 1429 "Grouping used for PW configuration. "; 1430 leaf pw-id { 1431 type string; 1432 description 1433 "The Identifier information of pseudowire. "; 1434 } 1436 leaf pw-name { 1437 type string; 1438 description 1439 "The name information of pseudowire."; 1440 } 1442 leaf transmit-label { 1443 type rt-types:mpls-label; 1444 description 1445 "Transmit label information in PW. "; 1446 } 1448 leaf receive-label { 1449 type rt-types:mpls-label; 1450 description 1451 "Receive label information in PW. "; 1452 } 1454 leaf encapsulation-type { 1455 type identityref { 1456 base etht-types:encapsulation-type; 1457 } 1458 description 1459 "The encapsulation type, raw or tag. "; 1460 } 1462 leaf oper-status { 1463 type identityref { 1464 base te-types:tunnel-state-type; 1465 } 1466 config false; 1467 description 1468 "The operational state of the PW segment. "; 1469 } 1471 container ingress-bandwidth-profile { 1472 description 1473 "Bandwidth Profile for ingress. "; 1474 uses pw-segment-named-or-value-bandwidth-profile; 1475 } 1477 list pw-paths { 1478 key path-id; 1479 description 1480 "A list of pw paths. "; 1482 leaf path-id { 1483 type uint8; 1484 description 1485 "The identifier of pw paths. "; 1487 } 1489 list tp-tunnels { 1490 key name; 1491 description 1492 "Names of TP Tunnel underlay"; 1493 leaf name { 1494 type string; 1495 description 1496 "Names of TP Tunnel underlay"; 1497 } 1498 } 1500 } 1502 } 1504 grouping pw-segment-named-or-value-bandwidth-profile { 1505 description 1506 "A grouping to configure a bandwdith profile either by 1507 referencing a named bandwidth profile or by 1508 configuring the values of the bandwidth profile attributes."; 1509 choice style { 1510 description 1511 "Whether the bandwidth profile is named or defined by value"; 1512 case named { 1513 description 1514 "Named bandwidth profile."; 1515 leaf bandwidth-profile-name { 1516 type leafref { 1517 path "/ethtsvc:etht-svc/ethtsvc:globals/" 1518 + "ethtsvc:named-bandwidth-profiles/" 1519 + "ethtsvc:bandwidth-profile-name"; 1520 } 1521 description 1522 "Name of the bandwidth profile."; 1523 } 1524 } 1525 case value { 1526 description 1527 "Bandwidth profile configured by value."; 1528 uses etht-types:pw-segement-bandwidth-profile-grouping; 1529 } 1530 } 1531 } 1533 grouping tunnels-grouping { 1534 description 1535 "A group of tunnels. "; 1536 leaf name { 1537 type leafref { 1538 path "/te:te/te:tunnels/te:tunnel/te:name"; 1539 require-instance false; 1540 } 1541 description "Dependency tunnel name"; 1542 } 1543 leaf encoding { 1544 type identityref { 1545 base te-types:lsp-encoding-types; 1546 } 1547 description "LSP encoding type"; 1548 reference "RFC3945"; 1549 } 1550 leaf switching-type { 1551 type identityref { 1552 base te-types:switching-capabilities; 1553 } 1554 description "LSP switching type"; 1555 reference "RFC3945"; 1556 } 1557 } 1558 } 1559 1561 5.2. YANG Code for ETH type 1563 This module references a few documents including [RFC2697], 1564 [RFC2698], [RFC4115], [IEEE802.1ad], [IEEE802.1q] and [MEF10]. 1566 file "ietf-eth-tran-types@2021-07-07.yang" 1567 module ietf-eth-tran-types { 1568 yang-version 1.1; 1569 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-tran-types"; 1571 prefix "etht-types"; 1573 organization 1574 "Internet Engineering Task Force (IETF) CCAMP WG"; 1575 contact 1576 " 1577 WG List: 1579 ID-draft editor: 1580 Haomian Zheng (zhenghaomian@huawei.com); 1581 Italo Busi (italo.busi@huawei.com); 1582 Aihua Guo (aihuaguo.ietf@gmail.com); 1583 Anton Snitser (antons@sedonasys.com); 1584 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 1585 Yunbin Xu (xuyunbin@caict.ac.cn); 1586 Yang Zhao (zhaoyangyjy@chinamobile.com); 1587 Xufeng Liu (xufeng.liu.ietf@gmail.com); 1588 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 1589 "; 1591 description 1592 "This module defines the ETH types. 1593 The model fully conforms to the Network Management 1594 Datastore Architecture (NMDA). 1596 Copyright (c) 2019 IETF Trust and the persons 1597 identified as authors of the code. All rights reserved. 1599 Redistribution and use in source and binary forms, with or 1600 without modification, is permitted pursuant to, and subject 1601 to the license terms contained in, the Simplified BSD License 1602 set forth in Section 4.c of the IETF Trust's Legal Provisions 1603 Relating to IETF Documents 1604 (https://trustee.ietf.org/license-info). 1605 This version of this YANG module is part of RFC XXXX; see 1606 the RFC itself for full legal notices."; 1608 revision 2021-07-07 { 1609 description 1610 "version -05 as a WG draft"; 1611 reference 1612 "draft-ietf-ccamp-client-signal-yang"; 1613 } 1615 /* 1616 * Identities 1617 */ 1619 identity eth-vlan-tag-type { 1620 description 1621 "ETH VLAN tag type."; 1622 } 1624 identity c-vlan-tag-type { 1625 base eth-vlan-tag-type; 1626 description 1627 "802.1Q Customer VLAN"; 1628 } 1630 identity s-vlan-tag-type { 1631 base eth-vlan-tag-type; 1632 description 1633 "802.1Q Service VLAN (QinQ)"; 1634 } 1636 identity service-classification-type { 1637 description 1638 "Service classification."; 1639 } 1641 identity port-classification { 1642 base service-classification-type; 1643 description 1644 "Port classification."; 1645 } 1647 identity vlan-classification { 1648 base service-classification-type; 1649 description 1650 "VLAN classification."; 1651 } 1653 identity eth-vlan-tag-classify { 1654 description 1655 "VLAN tag classification."; 1656 } 1658 identity classify-c-vlan { 1659 base eth-vlan-tag-classify; 1660 description 1661 "Classify 802.1Q Customer VLAN tag. 1662 Only C-tag type is accepted"; 1663 } 1665 identity classify-s-vlan { 1666 base eth-vlan-tag-classify; 1667 description 1668 "Classify 802.1Q Service VLAN (QinQ) tag. 1669 Only S-tag type is accepted"; 1670 } 1672 identity classify-s-or-c-vlan { 1673 base eth-vlan-tag-classify; 1674 description 1675 "Classify S-VLAN or C-VLAN tag-classify. 1676 Either tag is accepted"; 1677 } 1679 identity bandwidth-profile-type { 1680 description 1681 "Bandwidth Profile Types"; 1682 } 1684 identity mef-10-bwp { 1685 base bandwidth-profile-type; 1686 description 1687 "MEF 10 Bandwidth Profile"; 1688 } 1689 identity rfc-2697-bwp { 1690 base bandwidth-profile-type; 1691 description 1692 "RFC 2697 Bandwidth Profile"; 1693 } 1695 identity rfc-2698-bwp { 1696 base bandwidth-profile-type; 1697 description 1698 "RFC 2698 Bandwidth Profile"; 1699 } 1701 identity rfc-4115-bwp { 1702 base bandwidth-profile-type; 1703 description 1704 "RFC 4115 Bandwidth Profile"; 1705 } 1707 identity service-type { 1708 description 1709 "Type of Ethernet service."; 1710 } 1712 identity p2p-svc { 1713 base service-type; 1714 description 1715 "Ethernet point-to-point service (EPL, EVPL)."; 1716 } 1718 identity rmp-svc { 1719 base service-type; 1720 description 1721 "Ethernet rooted-multitpoint service (E-TREE, EP-TREE)."; 1722 } 1724 identity mp2mp-svc { 1725 base service-type; 1726 description 1727 "Ethernet multipoint-to-multitpoint service (E-LAN, EP-LAN)."; 1728 } 1730 identity lifecycle-status { 1731 description 1732 "Lifecycle Status."; 1733 } 1735 identity installed { 1736 base lifecycle-status; 1737 description 1738 "Installed."; 1739 } 1741 identity planned { 1742 base lifecycle-status; 1743 description 1744 "Planned."; 1745 } 1747 identity pending-removal { 1748 base lifecycle-status; 1749 description 1750 "Pending Removal."; 1751 } 1753 /* 1754 * Type Definitions 1755 */ 1757 typedef eth-tag-type { 1758 type identityref { 1759 base eth-vlan-tag-type; 1760 } 1761 description 1762 "Identifies a specific ETH VLAN tag type."; 1763 } 1765 typedef eth-tag-classify { 1766 type identityref { 1767 base eth-vlan-tag-classify; 1768 } 1769 description 1770 "Identifies a specific VLAN tag classification."; 1771 } 1773 typedef vlanid { 1774 type uint16 { 1775 range "1..4094"; 1776 } 1777 description 1778 "The 12-bit VLAN-ID used in the VLAN Tag header."; 1779 } 1781 typedef vid-range-type { 1782 type string { 1783 pattern "([1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?" + 1784 "(,[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?)*)"; 1786 } 1787 description 1788 "A list of VLAN Ids, or non overlapping VLAN ranges, in 1789 ascending order, between 1 and 4094. 1790 This type is used to match an ordered list of VLAN Ids, or 1791 contiguous ranges of VLAN Ids. Valid VLAN Ids must be in the 1792 range 1 to 4094, and included in the list in non overlapping 1793 ascending order. 1795 For example: 1,10-100,50,500-1000"; 1796 } 1798 typedef bandwidth-profile-type { 1799 type identityref { 1800 base bandwidth-profile-type; 1801 } 1802 description 1803 "Identifies a specific Bandwidth Profile type."; 1804 } 1806 typedef service-type { 1807 type identityref { 1808 base service-type; 1809 } 1810 description 1811 "Identifies the type of Ethernet service."; 1812 } 1814 typedef lifecycle-status { 1815 type identityref { 1816 base lifecycle-status; 1817 } 1818 description 1819 "Identifies the lLifecycle Status ."; 1820 } 1822 /* 1823 * Grouping Definitions 1824 */ 1826 grouping etht-bandwidth-profiles { 1827 description 1828 "Bandwidth profile configuration paramters."; 1830 leaf bandwidth-profile-type { 1831 type etht-types:bandwidth-profile-type; 1832 description 1833 "The type of bandwidth profile."; 1835 } 1836 leaf CIR { 1837 type uint64; 1838 description 1839 "Committed Information Rate in Kbps"; 1840 } 1841 leaf CBS { 1842 type uint64; 1843 description 1844 "Committed Burst Size in in KBytes"; 1845 } 1846 leaf EIR { 1847 type uint64; 1848 /* Need to indicate that EIR is not supported by RFC 2697 1850 must 1851 '../bw-profile-type = "mef-10-bwp" or ' + 1852 '../bw-profile-type = "rfc-2698-bwp" or ' + 1853 '../bw-profile-type = "rfc-4115-bwp"' 1855 must 1856 '../bw-profile-type != "rfc-2697-bwp"' 1857 */ 1858 description 1859 "Excess Information Rate in Kbps 1860 In case of RFC 2698, PIR = CIR + EIR"; 1861 } 1862 leaf EBS { 1863 type uint64; 1864 description 1865 "Excess Burst Size in KBytes. 1866 In case of RFC 2698, PBS = CBS + EBS"; 1867 } 1868 leaf color-aware { 1869 type boolean; 1870 description 1871 "Indicates weather the color-mode is 1872 color-aware or color-blind."; 1873 } 1874 leaf coupling-flag { 1875 type boolean; 1876 /* Need to indicate that Coupling Flag is defined only for MEF 10 1878 must 1879 '../bw-profile-type = "mef-10-bwp"' 1880 */ 1881 description 1882 "Coupling Flag."; 1884 } 1885 } 1887 identity topology-role { 1888 description 1889 "The role of underlay topology: e.g., hub, spoke, 1890 any-to-any."; 1891 } 1893 identity resilience { 1894 description 1895 "Placeholder for resilience information in data plane, 1896 for future study. "; 1897 } 1899 identity access-role { 1900 description 1901 "Indicating whether the access is a working or protection access."; 1902 } 1904 identity root-primary { 1905 base access-role; 1906 description 1907 "Designates the primary root UNI of an E-Tree service, and may also 1908 designates the UNI access role of E-LINE and E-LAN service."; 1909 } 1911 identity root-backup { 1912 base access-role; 1913 description 1914 "Designates the backup root UNI of an E-Tree service."; 1915 } 1917 identity leaf-access { 1918 base access-role; 1919 description 1920 "Designates the leaf UNI of an E-Tree service."; 1921 } 1923 identity performance { 1924 description 1925 "Placeholder for performance information, for future study."; 1926 } 1928 identity encapsulation-type { 1929 description 1930 "Indicating how the service is encapsulated (to PW), e.g, raw or tag. "; 1931 } 1932 grouping pw-segement-bandwidth-profile-grouping { 1933 description 1934 "bandwidth profile grouping for PW segment. "; 1935 leaf bandwidth-profile-type { 1936 type etht-types:bandwidth-profile-type; 1937 description 1938 "The type of bandwidth profile."; 1939 } 1940 leaf CIR { 1941 type uint64; 1942 description 1943 "Committed Information Rate in Kbps"; 1944 } 1945 leaf CBS { 1946 type uint64; 1947 description 1948 "Committed Burst Size in in KBytes"; 1949 } 1950 leaf EIR { 1951 type uint64; 1952 /* Need to indicate that EIR is not supported by RFC 2697 1954 must 1955 '../bw-profile-type = "mef-10-bwp" or ' + 1956 '../bw-profile-type = "rfc-2698-bwp" or ' + 1957 '../bw-profile-type = "rfc-4115-bwp"' 1959 must 1960 '../bw-profile-type != "rfc-2697-bwp"' 1961 */ 1962 description 1963 "Excess Information Rate in Kbps 1964 In case of RFC 2698, PIR = CIR + EIR"; 1965 } 1966 leaf EBS { 1967 type uint64; 1968 description 1969 "Excess Burst Size in KBytes. 1970 In case of RFC 2698, PBS = CBS + EBS"; 1971 } 1972 } 1973 grouping eth-bandwidth { 1974 description 1975 "Available bandwith for ethernet."; 1976 leaf eth-bandwidth { 1977 type uint64{ 1978 range "0..10000000000"; 1979 } 1980 units "Kbps"; 1981 description 1982 "Available bandwith value expressed in kilobits per second"; 1983 } 1984 } 1986 grouping eth-label-restriction { 1987 description 1988 "Label Restriction for ethernet."; 1989 leaf tag-type { 1990 type etht-types:eth-tag-type; 1991 description "VLAN tag type."; 1992 } 1993 leaf priority { 1994 type uint8; 1995 description "priority."; 1996 } 1997 } 1998 grouping eth-label { 1999 description 2000 "Label for ethernet."; 2001 leaf vlanid { 2002 type etht-types:vlanid; 2003 description 2004 "VLAN tag id."; 2005 } 2006 } 2008 grouping eth-label-step { 2009 description "Label step for Ethernet VLAN"; 2010 leaf eth-step { 2011 type uint16 { 2012 range "1..4095"; 2013 } 2014 default 1; 2015 description 2016 "Label step which represent possible increments for 2017 an Ethernet VLAN tag."; 2018 reference 2019 "IEEE 802.1ad: Provider Bridges."; 2020 } 2021 } 2022 } 2024 2025 5.3. Other Client Signal YANG Code 2027 This module imports typedefs and modules from [RFC6991], 2028 [I-D.ietf-ccamp-otn-tunnel-model], [RFC8776]. 2030 file "ietf-trans-client-service@2021-01-11.yang" 2031 module ietf-trans-client-service { 2032 /* TODO: FIXME */ 2033 yang-version 1.1; 2035 namespace "urn:ietf:params:xml:ns:yang:ietf-trans-client-service"; 2036 prefix "clntsvc"; 2038 import ietf-te-types { 2039 prefix "te-types"; 2040 reference "RFC 8776 - Traffic Engineering Common YANG Types"; 2041 } 2043 import ietf-layer1-types { 2044 prefix "layer1-types"; 2045 reference "RFC ZZZZ - A YANG Data Model for Layer 1 Types"; 2046 } 2048 import ietf-yang-types { 2049 prefix "yang"; 2050 reference "RFC 6991 - Common YANG Data Types"; 2051 } 2053 import ietf-trans-client-svc-types { 2054 prefix "clntsvc-types"; 2055 reference "RFC XXXX - A YANG Data Model for 2056 Transport Network Client Signals"; 2057 } 2059 organization 2060 "Internet Engineering Task Force (IETF) CCAMP WG"; 2061 contact 2062 " 2063 ID-draft editor: 2064 Haomian Zheng (zhenghaomian@huawei.com); 2065 Aihua Guo (aihuaguo.ietf@gmail.com); 2066 Italo Busi (italo.busi@huawei.com); 2067 Anton Snitser (antons@sedonasys.com); 2068 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 2069 Yunbin Xu (xuyunbin@caict.ac.cn); 2070 Yang Zhao (zhaoyangyjy@chinamobile.com); 2071 Xufeng Liu (Xufeng_Liu@jabil.com); 2072 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 2073 "; 2075 description 2076 "This module defines a YANG data model for describing 2077 transport network client services. The model fully conforms 2078 to the Network Management Datastore Architecture (NMDA). 2080 Copyright (c) 2021 IETF Trust and the persons 2081 identified as authors of the code. All rights reserved. 2083 Redistribution and use in source and binary forms, with or 2084 without modification, is permitted pursuant to, and subject 2085 to the license terms contained in, the Simplified BSD License 2086 set forth in Section 4.c of the IETF Trust's Legal Provisions 2087 Relating to IETF Documents 2088 (https://trustee.ietf.org/license-info). 2089 This version of this YANG module is part of RFC XXXX; see 2090 the RFC itself for full legal notices."; 2092 revision 2021-01-11 { 2093 description 2094 "version -04 as a WG document"; 2095 reference 2096 "draft-ietf-ccamp-client-signal-yang"; 2097 } 2099 /* 2100 * Groupings 2101 */ 2102 grouping client-svc-access-parameters { 2103 description 2104 "Transport network client signals access parameters"; 2106 leaf access-node-id { 2107 type te-types:te-node-id; 2108 description 2109 "The identifier of the access node in the underlying 2110 transport network topology."; 2111 } 2113 leaf access-ltp-id { 2114 type te-types:te-tp-id; 2115 description 2116 "The TE link termination point identifier, used together with 2117 access-node-id to identify the access LTP."; 2118 } 2119 leaf client-signal { 2120 type identityref { 2121 base layer1-types:client-signal; 2122 } 2123 description 2124 "Identify the client signal type associated with this port"; 2125 } 2127 } 2129 grouping client-svc-tunnel-parameters { 2130 description 2131 "Transport network client signals tunnel parameters"; 2133 leaf tunnel-name { 2134 type string; 2135 description 2136 "TE tunnel instance name."; 2137 } 2138 } 2140 grouping client-svc-instance-config { 2141 description 2142 "Configuration parameters for client services."; 2143 leaf client-svc-name { 2144 type string; 2145 description 2146 "Identifier of the p2p transport network client signals."; 2147 } 2149 leaf client-svc-title { 2150 type string; 2151 description 2152 "Name of the p2p transport network client signals."; 2153 } 2155 leaf client-svc-descr { 2156 type string; 2157 description 2158 "Description of the transport network client signals."; 2159 } 2161 leaf client-svc-customer { 2162 type string; 2163 description 2164 "Customer of the transport network client signals."; 2165 } 2166 container resilience { 2167 description "Place holder for resilience functionalities"; 2168 } 2170 uses te-types:te-topology-identifier; 2172 leaf admin-status { 2173 type identityref { 2174 base te-types:tunnel-admin-state-type; 2175 } 2176 default te-types:tunnel-admin-state-up; 2177 description "Client signals administrative state."; 2178 } 2180 container src-access-ports { 2181 description 2182 "Source access port of a client signal."; 2183 uses client-svc-access-parameters; 2184 } 2186 container dst-access-ports { 2187 description 2188 "Destination access port of a client signal."; 2189 uses client-svc-access-parameters; 2190 } 2192 leaf direction { 2193 type identityref { 2194 base clntsvc-types:direction; 2195 } 2196 description "Uni-dir or Bi-dir for the client signal."; 2197 } 2199 list svc-tunnels { 2200 key tunnel-name; 2201 description 2202 "List of the TE Tunnels supporting the client signal."; 2203 uses client-svc-tunnel-parameters; 2204 } 2205 } 2207 grouping client-svc-instance-state { 2208 description 2209 "State parameters for client services."; 2210 leaf operational-state { 2211 type identityref { 2212 base te-types:tunnel-state-type; 2213 } 2214 config false; 2215 description "Client signal operational state."; 2216 } 2217 leaf provisioning-state { 2218 type identityref { 2219 base te-types:lsp-state-type; 2220 } 2221 config false; 2222 description "Client signal provisioning state."; 2223 } 2224 leaf creation-time { 2225 type yang:date-and-time; 2226 config false; 2227 description "The time of the client signal be created."; 2228 } 2229 leaf last-updated-time { 2230 type yang:date-and-time; 2231 config false; 2232 description "The time of the client signal's latest update."; 2233 } 2234 leaf created-by { 2235 type string; 2236 config false; 2237 description 2238 "The client signal is created by whom, 2239 can be a system or staff ID."; 2240 } 2241 leaf last-updated-by { 2242 type string; 2243 config false; 2244 description 2245 "The client signal is last updated by whom, 2246 can be a system or staff ID."; 2247 } 2248 leaf owned-by { 2249 type string; 2250 config false; 2251 description 2252 "The client signal is owned by whom, 2253 can be a system ID."; 2254 } 2255 } 2257 /* 2258 * Data nodes 2259 */ 2261 container client-svc { 2262 description 2263 "Transport client services."; 2265 list client-svc-instances { 2266 key client-svc-name; 2267 description 2268 "The list of p2p transport client service instances"; 2270 uses client-svc-instance-config; 2271 uses client-svc-instance-state; 2272 } 2273 } 2274 } 2275 2277 5.4. Other Client Signal Types YANG Code 2279 This module defines the types for other client signal types. 2281 file "ietf-trans-client-svc-types@2019-11-03.yang" 2283 module ietf-trans-client-svc-types { 2284 namespace "urn:ietf:params:xml:ns:yang:ietf-trans-client-svc-types"; 2285 prefix "clntsvc-types"; 2287 organization 2288 "Internet Engineering Task Force (IETF) CCAMP WG"; 2289 contact 2290 " 2291 ID-draft editor: 2292 Haomian Zheng (zhenghaomian@huawei.com); 2293 Aihua Guo (aihuaguo.ietf@gmail.com); 2294 Italo Busi (italo.busi@huawei.com); 2295 Anton Snitser (antons@sedonasys.com); 2296 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 2297 Yunbin Xu (xuyunbin@caict.ac.cn); 2298 Yang Zhao (zhaoyangyjy@chinamobile.com); 2299 Xufeng Liu (Xufeng_Liu@jabil.com); 2300 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 2301 "; 2303 description 2304 "This module defines a YANG data model for describing 2305 transport network client types. The model fully conforms 2306 to the Network Management Datastore Architecture (NMDA). 2308 Copyright (c) 2019 IETF Trust and the persons 2309 identified as authors of the code. All rights reserved. 2311 Redistribution and use in source and binary forms, with or 2312 without modification, is permitted pursuant to, and subject 2313 to the license terms contained in, the Simplified BSD License 2314 set forth in Section 4.c of the IETF Trust's Legal Provisions 2315 Relating to IETF Documents 2316 (https://trustee.ietf.org/license-info). 2317 This version of this YANG module is part of RFC XXXX; see 2318 the RFC itself for full legal notices."; 2320 revision 2019-11-03 { 2321 description 2322 "version -01 as a WG document"; 2323 reference 2324 "draft-ietf-ccamp-client-signal-yang"; 2325 } 2327 identity direction { 2328 description 2329 "Direction information of Client Signal."; 2330 } 2332 identity bidirectional { 2333 base direction; 2334 description 2335 "Client Signal is bi-directional."; 2336 } 2338 identity unidirectional { 2339 base direction; 2340 description 2341 "Client Signal is uni-directional."; 2342 } 2344 } 2345 2347 6. Implementation Status 2349 [Note to the RFC Editor - remove this section before publication, as 2350 well as remove the reference to RFC [RFC7942].] 2352 This section records the status of known implementations of the 2353 protocol defined by this specification at the time of posting of this 2354 Internet-Draft, and is based on a proposal described in [RFC7942]. 2356 The description of implementations in this section is intended to 2357 assist the IETF in its decision processes in progressing drafts to 2358 RFCs. Please note that the listing of any individual implementation 2359 here does not imply endorsement by the IETF. Furthermore, no effort 2360 has been spent to verify the information presented here that was 2361 supplied by IETF contributors. This is not intended as, and must not 2362 be construed to be, a catalog of available implementations or their 2363 features. Readers are advised to note that other implementations may 2364 exist. 2366 According to [RFC7942], "this will allow reviewers and working groups 2367 to assign due consideration to documents that have the benefit of 2368 running code, which may serve as evidence of valuable experimentation 2369 and feedback that have made the implemented protocols more mature. 2370 It is up to the individual working groups to use this information as 2371 they see fit". 2373 6.1. Usage of the ETH Service YANG Model on ONAP 2375 The implementation of the CCVPN (Cross Domain and Cross Layer VPN) 2376 use-case on ONAP follows the ACTN [RFC8453] architecture. In the 2377 design of CCVPN, ONAP presumes the responsibility of the MDSC, and 2378 third party network domain controllers the PNCs. Consequently, the 2379 ETH Service YANG model is used as the MPI between ONAP and the domain 2380 controllers. 2382 o Organization: China Mobile, Huawei Technologies, etc. 2384 o Implementation: ONAP CCVPN uses the ETH Service YANG model as the 2385 ACTN MPI 2387 o Description: ONAP CCVPN realizes the E-LINE and E-TREE service on 2388 a multi-domain network. Both of the services are modeled on ONAP 2389 by the ETH Service YANG model, and the model instances (e.g., JSON 2390 objects) are sent between ONAP and the domain controllers. Refer 2391 to the following CCVPN wiki for more information: 2392 https://wiki.onap.org/display/DW/ 2393 CCVPN%28Cross+Domain+and+Cross+Layer+VPN%29+USE+CASE 2395 o Maturity Level: Prototype 2397 o Coverage: Partial 2399 o Contact: henry.yu1@huawei.com 2401 7. IANA Considerations 2403 It is proposed that IANA should assign new URIs from the "IETF XML 2404 Registry" [RFC3688] as follows: 2406 URI: urn:ietf:params:xml:ns:yang:ietf-eth-tran-service 2407 Registrant Contact: The IESG 2408 XML: N/A; the requested URI is an XML namespace. 2410 URI: urn:ietf:params:xml:ns:yang:ietf-trans-client-service 2411 Registrant Contact: The IESG 2412 XML: N/A; the requested URI is an XML namespace. 2414 URI: urn:ietf:params:xml:ns:yang:ietf-eth-tran-types 2415 Registrant Contact: The IESG 2416 XML: N/A; the requested URI is an XML namespace. 2418 URI: urn:ietf:params:xml:ns:yang:ietf-trans-client-svc-types 2419 Registrant Contact: The IESG 2420 XML: N/A; the requested URI is an XML namespace. 2422 This document registers following YANG modules in the YANG Module 2423 Names registry [RFC6020]. 2425 name: ietf-eth-tran-service 2426 namespace: urn:ietf:params:xml:ns:yang:ietf-eth-tran-service 2427 prefix: ethtsvc 2428 reference: RFC XXXX: A YANG Data Model for Transport 2429 Network Client Signals 2431 name: ietf-eth-tran-types 2432 namespace: urn:ietf:params:xml:ns:yang:ietf-eth-tran-types 2433 prefix: etht-types 2434 reference: RFC XXXX: A YANG Data Model for Transport 2435 Network Client Signals 2437 name: ietf-trans-client-service 2438 namespace: urn:ietf:params:xml:ns:yang:ietf-trans-client-service 2439 prefix: clntsvc 2440 reference: RFC XXXX: A YANG Data Model for Transport 2441 Network Client Signals 2443 name: ietf-trans-client-svc-types 2444 namespace: urn:ietf:params:xml:ns:yang:ietf-trans-client-svc-types 2445 prefix: clntsvc-types 2446 reference: RFC XXXX: A YANG Data Model for Transport 2447 Network Client Signals 2449 8. Manageability Considerations 2451 TBD. 2453 9. Security Considerations 2455 The data following the model defined in this document is exchanged 2456 via, for example, the interface between an orchestrator and a network 2457 domain controller. 2459 The YANG module defined in this document can be accessed via the 2460 RESTCONF protocol defined in [RFC8040], or maybe via the NETCONF 2461 protocol [RFC6241]. 2463 There are a number of data nodes defined in the YANG module which are 2464 writable/creatable/deletable (i.e., config true, which is the 2465 default). These data nodes may be considered sensitive or vulnerable 2466 in some network environments. Write operations (e.g., POST) to these 2467 data nodes without proper protection can have a negative effect on 2468 network operations. 2470 10. Acknowledgements 2472 We would like to thank Igor Bryskin and Daniel King for their 2473 comments and discussions. 2475 11. Contributors 2477 Yanlei Zheng 2478 China Unicom 2479 Email: zhengyl@dimpt.com 2481 Zhe Liu 2482 Huawei Technologies, 2483 Email: liuzhe123@huawei.com 2485 Sergio Belotti 2486 Nokia, 2487 Email: sergio.belotti@nokia.com 2489 Yingxi Yao 2490 Shanghai Bell, 2491 yingxi.yao@nokia-sbell.com 2493 Henry Yu 2494 Huawei Technologies, 2495 henry.yu1@huawei.com 2497 12. References 2499 12.1. Normative References 2501 [I-D.ietf-ccamp-l1csm-yang] 2502 Lee, Y., Lee, K., Zheng, H., Dios, O. G. D., and D. 2503 Ceccarelli, "A YANG Data Model for L1 Connectivity Service 2504 Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-14 (work in 2505 progress), February 2021. 2507 [I-D.ietf-ccamp-layer1-types] 2508 Zheng, H. and I. Busi, "A YANG Data Model for Layer 1 2509 Types", draft-ietf-ccamp-layer1-types-10 (work in 2510 progress), February 2021. 2512 [I-D.ietf-ccamp-otn-topo-yang] 2513 Zheng, H., Busi, I., Liu, X., Belotti, S., and O. G. D. 2514 Dios, "A YANG Data Model for Optical Transport Network 2515 Topology", draft-ietf-ccamp-otn-topo-yang-12 (work in 2516 progress), February 2021. 2518 [I-D.ietf-ccamp-otn-tunnel-model] 2519 Zheng, H., Busi, I., Belotti, S., Lopez, V., and Y. Xu, 2520 "OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel- 2521 model-13 (work in progress), April 2021. 2523 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2524 the Network Configuration Protocol (NETCONF)", RFC 6020, 2525 DOI 10.17487/RFC6020, October 2010, 2526 . 2528 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2529 and A. Bierman, Ed., "Network Configuration Protocol 2530 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2531 . 2533 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2534 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2535 . 2537 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 2538 and K. Pithewan, "GMPLS Signaling Extensions for Control 2539 of Evolving G.709 Optical Transport Networks", RFC 7139, 2540 DOI 10.17487/RFC7139, March 2014, 2541 . 2543 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2544 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2545 . 2547 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2548 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2549 . 2551 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 2552 "Common YANG Data Types for the Routing Area", RFC 8294, 2553 DOI 10.17487/RFC8294, December 2017, 2554 . 2556 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 2557 "Common YANG Data Types for Traffic Engineering", 2558 RFC 8776, DOI 10.17487/RFC8776, June 2020, 2559 . 2561 12.2. Informative References 2563 [IEEE802.1ad] 2564 IEEE, 802., "IEEE 802.1ad - Provider Bridges.", IEEE 2565 802.1ad , May 2006. 2567 [IEEE802.1q] 2568 IEEE, 802., "IEEE 802.1q - Virtual Bridged Local Area 2569 Networks", IEEE 802.1q , June 2005. 2571 [MEF10] MEF, 10., "Ethernet Services Attributes Phase 1", MEF10 , 2572 November 2004. 2574 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 2575 Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, 2576 . 2578 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 2579 Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, 2580 . 2582 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2583 DOI 10.17487/RFC3688, January 2004, 2584 . 2586 [RFC4115] Aboul-Magd, O. and S. Rabie, "A Differentiated Service 2587 Two-Rate, Three-Color Marker with Efficient Handling of 2588 in-Profile Traffic", RFC 4115, DOI 10.17487/RFC4115, July 2589 2005, . 2591 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2592 Code: The Implementation Status Section", BCP 205, 2593 RFC 7942, DOI 10.17487/RFC7942, July 2016, 2594 . 2596 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 2597 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 2598 DOI 10.17487/RFC8299, January 2018, 2599 . 2601 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2602 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2603 . 2605 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2606 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2607 . 2609 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2610 and R. Wilton, "Network Management Datastore Architecture 2611 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2612 . 2614 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 2615 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 2616 DOI 10.17487/RFC8453, August 2018, 2617 . 2619 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2620 Data Model for Layer 2 Virtual Private Network (L2VPN) 2621 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2622 2018, . 2624 Authors' Addresses 2626 Haomian Zheng 2627 Huawei Technologies 2628 H1 XiliuBeipo Village, Songshan Lake 2629 Dongguan, Guangdong 2630 China 2632 Email: zhenghaomian@huawei.com 2634 Aihua Guo 2635 Futurewei 2637 Email: aihuaguo.ietf@gmail.com 2639 Italo Busi 2640 Huawei Technologies 2642 Email: Italo.Busi@huawei.com 2644 Anton Snitser 2645 Sedona 2647 Email: antons@sedonasys.com 2649 Francesco Lazzeri 2650 Ericsson 2652 Email: francesco.lazzeri@ericsson.com 2653 Yunbin Xu 2654 CAICT 2656 Email: xuyunbin@caict.ac.cn 2658 Yang Zhao 2659 China Mobile 2661 Email: zhaoyangyjy@chinamobile.com 2663 Xufeng Liu 2664 Volta Networks 2666 Email: xufeng.liu.ietf@gmail.com 2668 Giuseppe Fioccola 2669 Huawei Technologies 2671 Email: giuseppe.fioccola@huawei.com