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