idnits 2.17.1 draft-ietf-ccamp-client-signal-yang-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 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 362 has weird spacing: '...le-name str...' == Line 406 has weird spacing: '...oint-id str...' == Line 572 has weird spacing: '...rw name str...' == Line 609 has weird spacing: '...el-name str...' == Line 1012 has weird spacing: '...rouping etht-...' == (5 more instances...) -- The document date (January 13, 2021) is 1197 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-13 == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-otn-topo-yang-11 == Outdated reference: A later version (-20) exists of draft-ietf-ccamp-otn-tunnel-model-11 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group H. Zheng 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track A. Guo 5 Expires: July 17, 2021 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 January 13, 2021 22 A YANG Data Model for Transport Network Client Signals 23 draft-ietf-ccamp-client-signal-yang-04 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 July 17, 2021. 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 . . . . . . . . . . . . . . 43 91 5.4. Other Client Signal Types YANG Code . . . . . . . . . . . 49 92 6. Considerations and Open Issue . . . . . . . . . . . . . . . . 50 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 94 8. Manageability Considerations . . . . . . . . . . . . . . . . 52 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 52 96 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 97 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 98 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 99 12.1. Normative References . . . . . . . . . . . . . . . . . . 53 100 12.2. Informative References . . . . . . . . . . . . . . . . . 54 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 103 1. Introduction 105 1.1. Overview 107 A transport network is a server-layer network designed to provide 108 connectivity services for a client-layer network to carry the client 109 traffic transparently across the server-layer network resources. 110 Currently the topology and tunnel models which have been defined for 111 transport networks, such as [I-D.ietf-ccamp-otn-topo-yang] and 112 [I-D.ietf-ccamp-otn-tunnel-model], provide server-layer topology 113 abstraction and tunnel configuration between PEs. However, there is 114 a missing piece for configuring how the PEs should map the client- 115 layer traffic, received from the CE, over the server-layer-tunnels: 116 this gap is expected to be solved in this document. 118 This document defines a data model of all transport network client 119 signals, using YANG language defined in [RFC7950]. The model can be 120 used by applications exposing to a transport network controller via a 121 RESTconf interface. Furthermore, it can be used by an application 122 for the following purposes (but not limited to): 124 o To request/update an end-to-end service by driving a new tunnel to 125 be set up to support this service; 127 o To request/update an end-to-end service by using an existing 128 tunnel; 130 o To receive notification with regard to the information change of 131 the given service; 133 The YANG modules defined in this document conforms to the Network 134 Management Datastore Architecture (NMDA) defined in [RFC8342]. 136 1.2. Prefixs in Model Names 138 In this document, names of data nodes and other data model objects 139 are prefixed using the standard prefix associated with the 140 corresponding YANG imported modules, including [RFC6991], [RFC8294] 141 and [I-D.ietf-ccamp-otn-tunnel-model], which are shown as follow. 143 +-------------+---------------------------+----------------------+ 144 | Prefix | YANG module | Reference | 145 +-------------+---------------------------+----------------------+ 146 | yang | ietf-yang-types | [RFC6991] | 147 | te-types | ietf-te-types | [RFC8776] | 148 | rt-types | ietf-routing-types | [RFC8294] | 149 | otn-types | ietf-otn-types |[ietf-ccamp-otn-tunnel-model]| 150 | etht-types | ietf-eth-tran-types | This Document | 151 | clntsvc | ietf-trans-client-service | This Document | 152 | ethtsvc | ietf-eth-tran-service | This Document | 153 |clntsvc-types|ietf-trans-client-svc-types| This Document | 154 +-------------+---------------------------+----------------------+ 156 2. Terminology and Notations 158 A simplified graphical representation of the data model is used in 159 this document. The meaning of the symbols in the YANG data tree 160 presented later in this document is defined in [RFC8340]. They are 161 provided below for reference. 163 o Brackets "[" and "]" enclose list keys. 165 o Abbreviations before data node names: "rw" means configuration 166 (read-write) and "ro" state data (read-only). 168 o Symbols after data node names: "?" means an optional node, "!" 169 means a presence container, and "*" denotes a list and leaf-list. 171 o Parentheses enclose choice and case nodes, and case nodes are also 172 marked with a colon (":"). 174 o Ellipsis ("...") stands for contents of subtrees that are not 175 shown. 177 3. Transport Network Client Signal Overview 179 3.1. Overview of Service Request and Network Configuration Scenarios 181 A global view of a multi-domain service can be described as the 182 Figure 1 . The customer is usually responsible to configure the CE 183 nodes and to request to the provider the service intent, from the CE 184 nodes perspective, while the provider is responsible to configure the 185 whole network (including the PE nodes) to support the customer 186 service intent. Generally speaking, the network configurations 187 required to support a customer service can be split into two 188 different groups: CE-PE and PE-PE. The CE-PE configuration deals 189 with the client layer one-hop access link, while PE-PE configuration 190 deals with the server layer tunnel. In Figure 1 we mark the 191 intermediate nodes as 'P', which has same switching capability of PE 192 but just not the 'end-point'. In this example, the link P-P and PE-P 193 are a server-layer intra-domain or inter-domain link. 195 +----+ +----+ 196 | CE | | CE | 197 +--+-+ +--+-+ 198 | | 199 | ------------- -------------| 200 //|/ \\\\ ///// |\\\\ 201 // | \\ // | \\ 202 | +--+-+ +---+ +---+ | | +---+ +---+ +--+-+ | 203 | | PE +----+ P +--+ P +---+-----+--+ P +---+ P +---+ PE | | 204 | +----+ +---+ +---+ | | +---+ +---+ +----+ | 205 \\ // \\ // 206 \\\\ //// \\\\\ ///// 207 ------------- ------------- 208 Domain 1 Domain 2 210 Figure 1: Global view of Client Service with the Network Provider 212 According to the responsibilities of each controller in [RFC8453], 213 the controllers have different views of the service request and 214 network configuration. The duty of CNC is to give the MDSC a 215 description of the customer service intent: candidate YANG models 216 include L1CSM [I-D.ietf-ccamp-l1csm-yang], L2SM [RFC8466] and L3SM 217 [RFC8299], which are classified as customer service models, according 218 to [RFC8309]. These models provide necessary attributes to describe 219 the customer service intent from the customer/CE perspective, and do 220 not provide any specific network configuration. These models also 221 implies that the customer service description can be considered in a 222 separate manner rather than integratig with network configurations, 223 which also enable the controllers to abstract/virtualize the network 224 resource to make them visible to the customer and also easier to 225 manage. In other words, the network knowledge is not necessary at 226 CNC and CMI, which is seen in an abstracted form as shown in 227 Figure 2. 229 /---------\ 230 /// \\\ 231 +----+ | | +----+ 232 | CE |--------------+ NETWORK +----------------| CE | 233 +----+ | | +----+ 234 \\\ /// 235 \---------/ 237 Figure 2: CNC Viewpoint on the Client Service 239 The functionalities of MDSC have been described in [RFC8453], which 240 include the customer mapping/translation and multi-domain 241 coordination. By receiving the request from CNC, MDSC need to 242 understand what network configuration can support the customer 243 service intent and turn to the corresponding PNCs for configuration. 244 The service request is therefore decomposed by MDSC into a few 245 network configurations and forwarded to one or multiple PNCs 246 respectively in single-domain and multi-domain scenario. In general, 247 the MDSC has the view of both PE and CE nodes and of some abstract 248 information regarding the P nodes, as shown in Figure 3. It is worth 249 noting that this MDSC view is different with Figure 1 at the intra- 250 domain link. Usually these details are hidden, for scalability 251 purposes, and therefore the MDSC has only an abstract view of each 252 domain internal topology. 254 ------ ----- 255 //// \\\\ ///- -\\\ 256 // \\ // \\ 257 +----+ | +----+ +---+ | |+---+ +----+ | +----+ 258 | CE |-----+-| PE |-----| P |-+--+| P |-----| PE |-+-----| CE | 259 +----+ | +----+ +---+ | |+---+ +----+ | +----+ 260 \\ // \\ // 261 \\\\ //// \\\- -/// 262 ------ ----- 263 Domain 1 Domain 2 265 Figure 3: MDSC view of both Client Service and Network Abstraction 267 PNC is the controller that configure the physical devices, based on 268 the network configuration received from the MDSC. Each PNC has the 269 detailed view of its own domain, the example of view from PNC in 270 domain 1 is shown in Figure 4. The PNC has all the detailed topology 271 information on PE and P nodes and on the intra-domain links. The PNC 272 configures the tunnel/tunnel segment within its domain based on the 273 network configuration provided by the MDSC. The PNC also configures 274 the network part of the CE-PE access links as well as the mapping of 275 the client-layer traffic and the server-layer tunnels, based on the 276 network configuration provided by the MDSC. The interaction between 277 PNC and MDSC for the client-layer network configuration is 278 accomplished by the models defined in this draft. 280 | | | 281 | ------------- | -------------| 282 //|/ \\\\ | ///// |\\\\ 283 // | \\ | // | \\ 284 | +--+-+ +---+ +---+ | | | +---+ +---+ +--+-+ | 285 | | PE +----+ P +--+ P +---+--+--+--+ P +---+ P +---+ PE | | 286 | +----+ +---+ +---+ | | | +---+ +---+ +----+ | 287 \\ // | \\ // 288 \\\\ //// | \\\\\ ///// 289 ------------- | ------------- 290 PNC View in Domain 1 | PNC View in Domain 2 291 | 293 Figure 4: PNC view on Network Configuration 295 3.2. Applicability of Proposed Model 297 Existing TE and technology-specific models, such as topology models 298 and tunnel models, support the network configuration among PEs and 299 Ps. The customer service models, such as L1CSM, L2SM and L3SM, focus 300 on describing the attributes among CEs. However, there is a missing 301 piece on how to configure the CE-PE session. The models defined in 302 this document provide the configuration on CE-PE when the provider 303 server-layer network is TE-based technology. 305 In the example of OTN as the server-layer transport network, a full 306 list of G-PID was summarized in [RFC7139], which can be divided into 307 a few categories. The G-PID signals can be categorized into 308 transparent and non-transparent. Examples of transparent signals may 309 include Ethernetphysical interfaces, FC, STM-n and so on. In this 310 approach the OTN devices is not aware of the client signal type, and 311 this information is only necessary among the controllers. Once the 312 OTN tunnel is set up, there is no switching requested on the client 313 layer, and therefore only signal mapping is needed, without a client 314 tunnel set up. The models that supporting the configuration of 315 transparent signals are defined in Section 4.2. The other category 316 would be non-transparent, such as Carrier Ethernet and MPLS-TP, with 317 a switching request on the client layer. Once the OTN tunnel is set 318 up, a corresponding tunnel in the client layer has to be set up to 319 carry services. The models that supporting the configuration of 320 transparent signals are defined in Section 4.1. 322 It is also worth noting that some client signal can be carried over 323 multiple types of networks. For example, the Ethernet services can 324 be carried over either OTN or Ethernet TE tunnels (over optical or 325 microwave networks). The model specified in this document allows the 326 support from networks with different technologies. 328 3.3. State of Services 330 States have been defined to retrieve the status of the delivered 331 services. A few generic states defined in [RFC8776] are reused in 332 this document. These states include the operational state and the 333 provisioning state. 335 A few other parameters are defined for the management of the 336 services. Given the complicated labor division, the creation, update 337 and maintainance may have different responsible systems. So the log 338 of the service would be helpful and should be easy to retrived in a 339 standard way as well. These information include, but not restricted 340 to the following: 342 o When the service is created and has been last updated, these are 343 specified in the creation-time and last-updated-time. 345 o Who created the service and who made the last update to the 346 service, these are specified in the created-by and last-updated- 347 by. 349 o The owner of the service is specifed as owned-by, which would be 350 useful when the service is delegated by or to a specific system. 351 The identifier of the system is used to represent such 352 information. 354 4. YANG Model for Transport Network Client Signal 356 4.1. YANG Tree for Ethernet Service 358 module: ietf-eth-tran-service 359 +--rw etht-svc 360 +--rw globals 361 | +--rw named-bandwidth-profiles* [bandwidth-profile-name] 362 | +--rw bandwidth-profile-name string 363 | +--rw bandwidth-profile-type? 364 | | etht-types:bandwidth-profile-type 365 | +--rw CIR? uint64 366 | +--rw CBS? uint64 367 | +--rw EIR? uint64 368 | +--rw EBS? uint64 369 | +--rw color-aware? boolean 370 | +--rw coupling-flag? boolean 371 +--rw etht-svc-instances* [etht-svc-name] 372 +--rw etht-svc-name string 373 +--rw etht-svc-title? string 374 +--rw etht-svc-descr? string 375 +--rw etht-svc-customer? string 376 +--rw etht-svc-type? etht-types:service-type 377 +--rw etht-svc-lifecycle? etht-types:lifecycle-status 378 +--rw te-topology-identifier 379 | +--rw provider-id? te-global-id 380 | +--rw client-id? te-global-id 381 | +--rw topology-id? te-topology-id 382 +--rw resilience 383 | +--rw protection 384 | | +--rw enable? boolean 385 | | +--rw protection-type? identityref 386 | | +--rw protection-reversion-disable? boolean 387 | | +--rw hold-off-time? uint32 388 | | +--rw wait-to-revert? uint16 389 | | +--rw aps-signal-id? uint8 390 | +--rw restoration 391 | +--rw enable? boolean 392 | +--rw restoration-type? identityref 393 | +--rw restoration-scheme? identityref 394 | +--rw restoration-reversion-disable? boolean 395 | +--rw hold-off-time? uint32 396 | +--rw wait-to-restore? uint16 397 | +--rw wait-to-revert? uint16 398 +--rw etht-svc-end-points* [etht-svc-end-point-name] 399 | +--rw etht-svc-end-point-name string 400 | +--rw etht-svc-end-point-id? string 401 | +--rw etht-svc-end-point-descr? string 402 | +--rw topology-role? 403 | | identityref 404 | +--rw resilience 405 | +--rw etht-svc-access-points* [access-point-id] 406 | | +--rw access-point-id string 407 | | +--rw access-node-id? te-types:te-node-id 408 | | +--rw access-ltp-id? te-types:te-tp-id 409 | | +--rw access-role? identityref 410 | | +--rw pm-config 411 | | | +--rw pm-enable? boolean 412 | | | +--rw sending-rate-high? uint64 413 | | | +--rw sending-rate-low? uint64 414 | | | +--rw receiving-rate-high? uint64 415 | | | +--rw receiving-rate-low? uint64 416 | | +--ro state 417 | | | +--ro operational-state? identityref 418 | | | +--ro provisioning-state? identityref 419 | | +--ro performance? identityref 420 | +--rw service-classification-type? 421 | | identityref 422 | +--rw (service-classification)? 423 | | +--:(port-classification) 424 | | +--:(vlan-classification) 425 | | +--rw outer-tag! 426 | | | +--rw tag-type? 427 | | | | etht-types:eth-tag-classify 428 | | | +--rw (individual-bundling-vlan)? 429 | | | +--:(individual-vlan) 430 | | | | +--rw vlan-value? etht-types:vlanid 431 | | | +--:(vlan-bundling) 432 | | | +--rw vlan-range? 433 | | | etht-types:vid-range-type 434 | | +--rw second-tag! 435 | | +--rw tag-type? 436 | | | etht-types:eth-tag-classify 437 | | +--rw (individual-bundling-vlan)? 438 | | +--:(individual-vlan) 439 | | | +--rw vlan-value? etht-types:vlanid 440 | | +--:(vlan-bundling) 441 | | +--rw vlan-range? 442 | | etht-types:vid-range-type 443 | +--rw split-horizon-group? string 444 | +--rw (direction)? 445 | | +--:(symmetrical) 446 | | | +--rw ingress-egress-bandwidth-profile 447 | | | +--rw (style)? 448 | | | +--:(named) 449 | | | | +--rw bandwidth-profile-name? leafref 450 | | | +--:(value) 451 | | | +--rw bandwidth-profile-type? 452 | | | | etht-types:bandwidth-profile-type 453 | | | +--rw CIR? uint64 454 | | | +--rw CBS? uint64 455 | | | +--rw EIR? uint64 456 | | | +--rw EBS? uint64 457 | | | +--rw color-aware? boolean 458 | | | +--rw coupling-flag? boolean 459 | | +--:(asymmetrical) 460 | | +--rw ingress-bandwidth-profile 461 | | | +--rw (style)? 462 | | | +--:(named) 463 | | | | +--rw bandwidth-profile-name? leafref 464 | | | +--:(value) 465 | | | +--rw bandwidth-profile-type? 466 | | | | etht-types:bandwidth-profile-type 467 | | | +--rw CIR? uint64 468 | | | +--rw CBS? uint64 469 | | | +--rw EIR? uint64 470 | | | +--rw EBS? uint64 471 | | | +--rw color-aware? boolean 472 | | | +--rw coupling-flag? boolean 473 | | +--rw egress-bandwidth-profile 474 | | +--rw (style)? 475 | | +--:(named) 476 | | | +--rw bandwidth-profile-name? leafref 477 | | +--:(value) 478 | | +--rw bandwidth-profile-type? 479 | | | etht-types:bandwidth-profile-type 480 | | +--rw CIR? uint64 481 | | +--rw CBS? uint64 482 | | +--rw EIR? uint64 483 | | +--rw EBS? uint64 484 | | +--rw color-aware? boolean 485 | | +--rw coupling-flag? boolean 486 | +--rw vlan-operations 487 | +--rw (direction)? 488 | +--:(symmetrical) 489 | | +--rw symmetrical-operation 490 | | +--rw pop-tags? uint8 491 | | +--rw push-tags 492 | | +--rw outer-tag! 493 | | | +--rw tag-type? 494 | | | | etht-types:eth-tag-type 495 | | | +--rw vlan-value? etht-types:vlanid 496 | | | +--rw default-pcp? uint8 497 | | +--rw second-tag! 498 | | +--rw tag-type? 499 | | | etht-types:eth-tag-type 500 | | +--rw vlan-value? etht-types:vlanid 501 | | +--rw default-pcp? uint8 502 | +--:(asymmetrical) 503 | +--rw asymmetrical-operation 504 | +--rw ingress 505 | | +--rw pop-tags? uint8 506 | | +--rw push-tags 507 | | +--rw outer-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 second-tag! 514 | | +--rw tag-type? 515 | | | etht-types:eth-tag-type 516 | | +--rw vlan-value? 517 | | | etht-types:vlanid 518 | | +--rw default-pcp? uint8 519 | +--rw egress 520 | +--rw pop-tags? uint8 521 | +--rw push-tags 522 | +--rw outer-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 second-tag! 529 | +--rw tag-type? 530 | | etht-types:eth-tag-type 531 | +--rw vlan-value? 532 | | etht-types:vlanid 533 | +--rw default-pcp? uint8 534 +--rw underlay 535 | +--rw (technology)? 536 | | +--:(native-ethernet) 537 | | | +--rw eth-tunnels* [name] 538 | | | +--rw name 539 | | | | -> /te:te/tunnels/tunnel/name 540 | | | +--rw encoding? identityref 541 | | | +--rw switching-type? identityref 542 | | +--:(frame-base) 543 | | | +--rw otn-tunnels* [name] 544 | | | +--rw name 545 | | | | -> /te:te/tunnels/tunnel/name 546 | | | +--rw encoding? identityref 547 | | | +--rw switching-type? identityref 548 | | +--:(mpls-tp) 549 | | +--rw pw 550 | | +--rw pw-id? string 551 | | +--rw pw-name? string 552 | | +--rw transmit-label? 553 | | | rt-types:mpls-label 554 | | +--rw receive-label? 555 | | | rt-types:mpls-label 556 | | +--rw encapsulation-type? identityref 557 | | +--ro oper-status? identityref 558 | | +--rw ingress-bandwidth-profile 559 | | | +--rw (style)? 560 | | | +--:(named) 561 | | | | +--rw bandwidth-profile-name? leafref 562 | | | +--:(value) 563 | | | +--rw bandwidth-profile-type? 564 | | | | etht-types:bandwidth-profile-type 565 | | | +--rw CIR? uint64 566 | | | +--rw CBS? uint64 567 | | | +--rw EIR? uint64 568 | | | +--rw EBS? uint64 569 | | +--rw pw-paths* [path-id] 570 | | +--rw path-id uint8 571 | | +--rw tp-tunnels* [name] 572 | | +--rw name string 573 | +--rw src-split-horizon-group? string 574 | +--rw dst-split-horizon-group? string 575 +--rw admin-status? identityref 576 +--ro state 577 +--ro operational-state? identityref 578 +--ro provisioning-state? identityref 579 +--ro creation-time? yang:date-and-time 580 +--ro last-updated-time? yang:date-and-time 581 +--ro created-by? string 582 +--ro last-updated-by? string 583 +--ro owned-by? string 585 4.2. YANG Tree for other Transport Network Client Signal Model 586 module: ietf-trans-client-service 587 +--rw client-svc 588 +--rw client-svc-instances* [client-svc-name] 589 +--rw client-svc-name string 590 +--rw client-svc-title? string 591 +--rw client-svc-descr? string 592 +--rw client-svc-customer? string 593 +--rw resilience 594 +--rw te-topology-identifier 595 | +--rw provider-id? te-global-id 596 | +--rw client-id? te-global-id 597 | +--rw topology-id? te-topology-id 598 +--rw admin-status? identityref 599 +--rw src-access-ports 600 | +--rw access-node-id? te-types:te-node-id 601 | +--rw access-ltp-id? te-types:te-tp-id 602 | +--rw client-signal? identityref 603 +--rw dst-access-ports 604 | +--rw access-node-id? te-types:te-node-id 605 | +--rw access-ltp-id? te-types:te-tp-id 606 | +--rw client-signal? identityref 607 +--rw direction? identityref 608 +--rw svc-tunnels* [tunnel-name] 609 | +--rw tunnel-name string 610 +--ro operational-state? identityref 611 +--ro provisioning-state? identityref 612 +--ro creation-time? yang:date-and-time 613 +--ro last-updated-time? yang:date-and-time 614 +--ro created-by? string 615 +--ro last-updated-by? string 616 +--ro owned-by? string 618 5. YANG Code for Transport Network Client Signal 620 5.1. The ETH Service YANG Code 622 This module imports typedefs and modules from [RFC6991], [RFC8294], 623 [RFC8776]. 625 file "ietf-eth-tran-service@2021-01-11.yang" 626 module ietf-eth-tran-service { 627 yang-version 1.1; 628 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-tran-service"; 630 prefix "ethtsvc"; 631 import ietf-yang-types { 632 prefix "yang"; 633 reference "RFC 6991 - Common YANG Data Types"; 634 } 636 import ietf-te-types { 637 prefix "te-types"; 638 reference "RFC 8776 - Traffic Engineering Common YANG Types"; 639 } 641 import ietf-eth-tran-types { 642 prefix "etht-types"; 643 reference "RFC XXXX - A YANG Data Model for Transport 644 Network Client Signals"; 645 } 647 import ietf-routing-types { 648 prefix "rt-types"; 649 reference "RFC 8294 - Common YANG Data Types for the 650 Routing Area"; 652 } 654 import ietf-te { 655 prefix "te"; 656 reference "RFC YYYY - A YANG Data Model for Traffic 657 Engineering Tunnels and Interfaces"; 658 } 660 organization 661 "Internet Engineering Task Force (IETF) CCAMP WG"; 662 contact 663 " 664 WG List: 666 ID-draft editor: 667 Haomian Zheng (zhenghaomian@huawei.com); 668 Italo Busi (italo.busi@huawei.com); 669 Aihua Guo (aihuaguo.ietf@gmail.com); 670 Anton Snitser (antons@sedonasys.com);0 671 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 672 Yunbin Xu (xuyunbin@caict.ac.cn); 673 Yang Zhao (zhaoyangyjy@chinamobile.com); 674 Xufeng Liu (xufeng.liu.ietf@gmail.com); 675 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 676 "; 678 description 679 "This module defines a YANG data model for describing 680 the Ethernet services. The model fully conforms to the 681 Network Management Datastore Architecture (NMDA). 683 Copyright (c) 2021 IETF Trust and the persons 684 identified as authors of the code. All rights reserved. 686 Redistribution and use in source and binary forms, with or 687 without modification, is permitted pursuant to, and subject 688 to the license terms contained in, the Simplified BSD License 689 set forth in Section 4.c of the IETF Trust's Legal Provisions 690 Relating to IETF Documents 691 (https://trustee.ietf.org/license-info). 692 This version of this YANG module is part of RFC XXXX; see 693 the RFC itself for full legal notices."; 695 revision 2021-01-11 { 696 description 697 "version -04 as an WG document"; 698 reference 699 "draft-ietf-ccamp-client-signal-yang"; 700 } 702 /* 703 * Groupings 704 */ 706 grouping vlan-classification { 707 description 708 "A grouping which represents classification 709 on an 802.1Q VLAN tag."; 711 leaf tag-type { 712 type etht-types:eth-tag-classify; 713 description 714 "The tag type used for VLAN classification."; 715 } 716 choice individual-bundling-vlan { 717 description 718 "VLAN based classification can be individual 719 or bundling."; 721 case individual-vlan { 722 leaf vlan-value { 723 type etht-types:vlanid; 724 description 725 "VLAN ID value."; 726 } 728 } 730 case vlan-bundling { 731 leaf vlan-range { 732 type etht-types:vid-range-type; 733 description 734 "List of VLAN ID values."; 735 } 736 } 737 } 738 } 740 grouping vlan-write { 741 description 742 "A grouping which represents push/pop operations 743 of an 802.1Q VLAN tag."; 745 leaf tag-type { 746 type etht-types:eth-tag-type; 747 description 748 "The VLAN tag type to push/swap."; 749 } 750 leaf vlan-value { 751 type etht-types:vlanid; 752 description 753 "The VLAN ID value to push/swap."; 754 } 755 /* 756 * To be added: this attribute is used when: 757 * a) the ETH service has only one CoS (as in current version) 758 * b) as a default when a mapping between a given CoS value 759 * and the PCP value is not defined (in future versions) 760 */ 761 leaf default-pcp { 762 type uint8 { 763 range "0..7"; 764 } 765 description 766 "The default Priority Code Point (PCP) value to push/swap"; 767 } 768 } 770 grouping vlan-operations { 771 description 772 "A grouping which represents VLAN operations."; 774 leaf pop-tags { 775 type uint8 { 776 range "1..2"; 777 } 778 description 779 "The number of VLAN tags to pop (or swap if used in 780 conjunction with push-tags)"; 781 } 782 container push-tags { 783 description 784 "The VLAN tags to push (or swap if used in 785 conjunction with pop-tags)"; 787 container outer-tag { 788 presence 789 "Indicates existence of the outermost VLAN tag to 790 push/swap"; 792 description 793 "The outermost VLAN tag to push/swap."; 795 uses vlan-write; 796 } 797 container second-tag { 798 must 799 '../outer-tag/tag-type = "etht-types:s-vlan-tag-type" and ' + 800 'tag-type = "etht-types:c-vlan-tag-type"' 801 { 803 error-message 804 " 805 When pushing/swapping two tags, the outermost tag must 806 be specified and of S-VLAN type and the second 807 outermost tag must be of C-VLAN tag type. 808 "; 809 description 810 " 811 For IEEE 802.1Q interoperability, when pushing/swapping 812 two tags, it is required that the outermost tag exists 813 and is an S-VLAN, and the second outermost tag is a 814 C-VLAN. 815 "; 816 } 818 presence 819 "Indicates existence of a second outermost VLAN tag to 820 push/swap"; 822 description 823 "The second outermost VLAN tag to push/swap."; 825 uses vlan-write; 826 } 827 } 828 } 830 grouping named-or-value-bandwidth-profile { 831 description 832 "A grouping to configure a bandwdith profile either by 833 referencing a named bandwidth profile or by 834 configuring the values of the bandwidth profile attributes."; 835 choice style { 836 description 837 "Whether the bandwidth profile is named or defined by value"; 839 case named { 840 description 841 "Named bandwidth profile."; 842 leaf bandwidth-profile-name { 843 type leafref { 844 path "/ethtsvc:etht-svc/ethtsvc:globals/" 845 + "ethtsvc:named-bandwidth-profiles/" 846 + "ethtsvc:bandwidth-profile-name"; 847 } 848 description 849 "Name of the bandwidth profile."; 850 } 851 } 852 case value { 853 description 854 "Bandwidth profile configured by value."; 855 uses etht-types:etht-bandwidth-profiles; 856 } 857 } 858 } 860 grouping bandwidth-profiles { 861 description 862 "A grouping which represent bandwidth profile configuration."; 864 choice direction { 865 description 866 "Whether the bandwidth profiles are symmetrical or 867 asymmetrical"; 868 case symmetrical { 869 description 870 "The same bandwidth profile is used to describe both 871 the ingress and the egress bandwidth profile."; 872 container ingress-egress-bandwidth-profile { 873 description 874 "The bandwdith profile used in both directions."; 875 uses named-or-value-bandwidth-profile; 876 } 877 } 878 case asymmetrical { 879 description 880 "Ingress and egress bandwidth profiles can be specified."; 881 container ingress-bandwidth-profile { 882 description 883 "The bandwdith profile used in the ingress direction."; 884 uses named-or-value-bandwidth-profile; 885 } 886 container egress-bandwidth-profile { 887 description 888 "The bandwdith profile used in the egress direction."; 889 uses named-or-value-bandwidth-profile; 890 } 891 } 892 } 893 } 895 grouping etht-svc-access-parameters { 896 description 897 "ETH services access parameters"; 899 leaf access-node-id { 900 type te-types:te-node-id; 901 description 902 "The identifier of the access node in 903 the ETH topology."; 904 } 905 leaf access-ltp-id { 906 type te-types:te-tp-id; 907 description 908 "The TE link termination point identifier, used 909 together with access-node-id to identify the 910 access LTP."; 911 } 912 leaf access-role { 913 type identityref { 914 base etht-types:access-role; 915 } 916 description 917 "Indicate the role of access, e.g., working or protection. "; 918 } 920 container pm-config { 921 uses pm-config-grouping; 922 description 923 "This grouping is used to set the threshold value for 924 performance monitoring. "; 925 } 927 container state { 928 config false; 929 description 930 "The state is used to monitor the status of service. "; 931 leaf operational-state { 932 type identityref { 933 base te-types:tunnel-state-type; 934 } 935 description 936 "Indicating the operational state of client signal. "; 937 } 938 leaf provisioning-state { 939 type identityref { 940 base te-types:lsp-state-type; 941 } 942 description 943 "Indicating the provisional state of client signal, 944 especially when there is a change, i.e., revise, create. "; 945 } 946 } 948 leaf performance { 949 type identityref { 950 base etht-types:performance; 951 } 952 config false; 953 description 954 "Performance Monitoring for the service. "; 955 } 957 } 959 grouping etht-svc-tunnel-parameters { 960 description 961 "ETH services tunnel parameters."; 962 choice technology { 963 description 964 "Service multiplexing is optional and flexible."; 966 case native-ethernet { 967 /* 968 placeholder to support proprietary multiplexing 969 (for further discussion) 970 */ 971 list eth-tunnels { 972 key name; 973 description 974 "ETH Tunnel list in native Ethernet scenario."; 975 uses tunnels-grouping; 976 } 977 } 979 case frame-base { 980 list otn-tunnels { 981 key name; 982 description 983 "OTN Tunnel list in Frame-based scenario."; 984 uses tunnels-grouping; 985 } 986 } 988 case mpls-tp { 989 container pw { 990 description 991 "Pseudowire information for Ethernet over MPLS-TP."; 992 uses pw-segment-grouping; 993 } 994 } 995 } 997 /* 998 * Open issue: can we constraints it to be used only with mp services? 999 */ 1000 leaf src-split-horizon-group { 1001 type string; 1002 description 1003 "Identify a split horizon group at the Tunnel source TTP"; 1004 } 1005 leaf dst-split-horizon-group { 1006 type string; 1007 description 1008 "Identify a split horizon group at the Tunnel destination TTP"; 1009 } 1010 } 1012 grouping etht-svc-pm-threshold-config { 1013 description 1014 "Configuraiton parameters for Ethernet service PM thresholds."; 1016 leaf sending-rate-high { 1017 type uint64; 1018 description 1019 "High threshold of packet sending rate in kbps."; 1020 } 1021 leaf sending-rate-low { 1022 type uint64; 1023 description 1024 "Low threshold of packet sending rate in kbps."; 1025 } 1026 leaf receiving-rate-high { 1027 type uint64; 1028 description 1029 "High threshold of packet receiving rate in kbps."; 1030 } 1031 leaf receiving-rate-low { 1032 type uint64; 1033 description 1034 "Low threshold of packet receiving rate in kbps."; 1035 } 1036 } 1038 grouping etht-svc-pm-stats { 1039 description 1040 "Ethernet service PM statistics."; 1042 leaf sending-rate-too-high { 1043 type uint32; 1044 description 1045 "Counter that indicates the number of times the 1046 sending rate is above the high threshold"; 1047 } 1048 leaf sending-rate-too-low { 1049 type uint32; 1050 description 1051 "Counter that indicates the number of times the 1052 sending rate is below the low threshold"; 1053 } 1054 leaf receiving-rate-too-high { 1055 type uint32; 1056 description 1057 "Counter that indicates the number of times the 1058 receiving rate is above the high threshold"; 1059 } 1060 leaf receiving-rate-too-low { 1061 type uint32; 1062 description 1063 "Counter that indicates the number of times the 1064 receiving rate is below the low threshold"; 1065 } 1066 } 1068 grouping etht-svc-instance-config { 1069 description 1070 "Configuraiton parameters for Ethernet services."; 1072 leaf etht-svc-name { 1073 type string; 1074 description 1075 "Name of the ETH service."; 1076 } 1078 leaf etht-svc-title { 1079 type string; 1080 description 1081 "The Identifier of the ETH service."; 1082 } 1084 leaf etht-svc-descr { 1085 type string; 1086 description 1087 "Description of the ETH service."; 1088 } 1090 leaf etht-svc-customer { 1091 type string; 1092 description 1093 "Customer of the ETH service."; 1094 } 1096 leaf etht-svc-type { 1097 type etht-types:service-type; 1098 description 1099 "Type of ETH service (p2p, mp2mp or rmp)."; 1100 /* Add default as p2p */ 1101 } 1103 leaf etht-svc-lifecycle { 1104 type etht-types:lifecycle-status; 1105 description 1106 "Lifecycle state of ETH service."; 1107 /* Add default as installed */ 1108 } 1109 uses te-types:te-topology-identifier; 1111 uses resilience-grouping; 1112 list etht-svc-end-points { 1113 key etht-svc-end-point-name; 1114 description 1115 "The logical end point for the ETH service. "; 1116 uses etht-svc-end-point-grouping; 1117 } 1119 container underlay { 1120 description 1121 "The unterlay tunnel information that carrying the 1122 ETH service. "; 1123 uses etht-svc-tunnel-parameters; 1124 } 1126 leaf admin-status { 1127 type identityref { 1128 base te-types:tunnel-admin-state-type; 1129 } 1130 default te-types:tunnel-admin-state-up; 1131 description "ETH service administrative state."; 1132 } 1133 } 1135 grouping etht-svc-instance-state { 1136 description 1137 "State parameters for Ethernet services."; 1139 leaf operational-state { 1140 type identityref { 1141 base te-types:tunnel-state-type; 1142 } 1143 default te-types:tunnel-state-up; 1144 description "ETH service operational state."; 1145 } 1146 leaf provisioning-state { 1147 type identityref { 1148 base te-types:lsp-state-type; 1149 } 1150 description "ETH service provisioning state."; 1151 } 1152 leaf creation-time { 1153 type yang:date-and-time; 1154 description 1155 "Time of ETH service creation."; 1156 } 1157 leaf last-updated-time { 1158 type yang:date-and-time; 1159 description 1160 "Time of ETH service last update."; 1161 } 1163 leaf created-by { 1164 type string; 1165 description 1166 "The client signal is created by whom, 1167 can be a system or staff ID."; 1168 } 1169 leaf last-updated-by { 1170 type string; 1171 description 1172 "The client signal is last updated by whom, 1173 can be a system or staff ID."; 1174 } 1175 leaf owned-by { 1176 type string; 1177 description 1178 "The client signal is last updated by whom, 1179 can be a system ID."; 1180 } 1181 } 1183 /* 1184 * Data nodes 1185 */ 1187 container etht-svc { 1188 description 1189 "ETH services."; 1191 container globals { 1192 description 1193 "Globals Ethernet configuration data container"; 1194 list named-bandwidth-profiles { 1195 key bandwidth-profile-name; 1196 description 1197 "List of named bandwidth profiles used by 1198 Ethernet services."; 1200 leaf bandwidth-profile-name { 1201 type string; 1202 description 1203 "Name of the bandwidth profile."; 1204 } 1205 uses etht-types:etht-bandwidth-profiles; 1206 } 1208 } 1210 list etht-svc-instances { 1211 key etht-svc-name; 1212 description 1213 "The list of p2p ETH service instances"; 1215 uses etht-svc-instance-config; 1217 container state { 1218 config false; 1219 description 1220 "Ethernet Service states."; 1222 uses etht-svc-instance-state; 1223 } 1224 } 1225 } 1227 grouping resilience-grouping { 1228 description 1229 "Grouping for resilience configuration. "; 1230 container resilience { 1231 description 1232 "To configure the data plane protection parameters, 1233 currently a placeholder only, future candidate attributes 1234 include, Revert, WTR, Hold-off Timer, ..."; 1235 uses te:protection-restoration-properties; 1236 } 1237 } 1239 grouping etht-svc-end-point-grouping { 1240 description 1241 "Grouping for the end point configuration."; 1242 leaf etht-svc-end-point-name { 1243 type string; 1244 description 1245 "The name of the logical end point of ETH service. "; 1246 } 1248 leaf etht-svc-end-point-id { 1249 type string; 1250 description 1251 "The identifier of the logical end point of ETH service."; 1252 } 1254 leaf etht-svc-end-point-descr { 1255 type string; 1256 description 1257 "The description of the logical end point of ETH service. "; 1258 } 1260 leaf topology-role { 1261 type identityref { 1262 base etht-types:topology-role; 1263 } 1264 description 1265 "Indicating the underlay topology role, 1266 e.g., hub,spoke, any-to-any "; 1267 } 1269 container resilience { 1270 description 1271 "Placeholder for resilience configuration, for future study. "; 1272 } 1274 list etht-svc-access-points { 1275 key access-point-id; 1276 min-elements "1"; 1277 /* 1278 Open Issue: 1279 Is it possible to limit the max-elements only for p2p services? 1280 max-elements "2"; 1281 */ 1282 description 1283 "List of the ETH trasport services access point instances."; 1285 leaf access-point-id { 1286 type string; 1287 description 1288 "ID of the service access point instance"; 1289 } 1290 uses etht-svc-access-parameters; 1291 } 1293 leaf service-classification-type { 1294 type identityref { 1295 base etht-types:service-classification-type; 1296 } 1297 description 1298 "Service classification type."; 1299 } 1301 choice service-classification { 1302 description 1303 "Access classification can be port-based or 1304 VLAN based."; 1306 case port-classification { 1307 /* no additional information */ 1308 } 1310 case vlan-classification { 1311 container outer-tag { 1312 presence "The outermost VLAN tag exists"; 1313 description 1314 "Classifies traffic using the outermost VLAN tag."; 1316 uses vlan-classification; 1317 } 1318 container second-tag { 1319 must 1320 '../outer-tag/tag-type = "etht-types:classify-s-vlan" and ' + 1321 'tag-type = "etht-types:classify-c-vlan"' 1322 { 1323 error-message 1324 " 1325 When matching two tags, the outermost tag must be 1326 specified and of S-VLAN type and the second 1327 outermost tag must be of C-VLAN tag type. 1328 "; 1329 description 1330 " 1331 For IEEE 802.1Q interoperability, when matching two 1332 tags, it is required that the outermost tag exists 1333 and is an S-VLAN, and the second outermost tag is a 1334 C-VLAN. 1335 "; 1336 } 1337 presence "The second outermost VLAN tag exists"; 1339 description 1340 "Classifies traffic using the second outermost VLAN tag."; 1342 uses vlan-classification; 1343 } 1344 } 1345 } 1347 /* 1348 * Open issue: can we constraints it to be used only with mp services? 1349 */ 1350 leaf split-horizon-group { 1351 type string; 1352 description "Identify a split horizon group"; 1353 } 1355 uses bandwidth-profiles; 1357 container vlan-operations { 1358 description 1359 "Configuration of VLAN operations."; 1360 choice direction { 1361 description 1362 "Whether the VLAN operations are symmetrical or 1363 asymmetrical"; 1364 case symmetrical { 1365 container symmetrical-operation { 1366 uses vlan-operations; 1367 description 1368 "Symmetrical operations. 1369 Expressed in the ingress direction, but 1370 the reverse operation is applied to egress traffic"; 1371 } 1372 } 1373 case asymmetrical { 1374 container asymmetrical-operation { 1375 description "Asymmetrical operations"; 1376 container ingress { 1377 uses vlan-operations; 1378 description "Ingress operations"; 1379 } 1380 container egress { 1381 uses vlan-operations; 1382 description "Egress operations"; 1383 } 1384 } 1385 } 1386 } 1387 } 1388 } 1390 grouping pm-config-grouping { 1391 description 1392 "Grouping used for Performance Monitoring Configuration. "; 1393 leaf pm-enable { 1394 type boolean; 1395 description 1396 "Whether to enable the performance monitoring."; 1397 } 1399 leaf sending-rate-high { 1400 type uint64; 1401 description 1402 "The upperbound of sending rate."; 1403 } 1405 leaf sending-rate-low { 1406 type uint64; 1407 description 1408 "The lowerbound of sending rate."; 1409 } 1411 leaf receiving-rate-high { 1412 type uint64; 1413 description 1414 "The upperbound of receiving rate."; 1415 } 1417 leaf receiving-rate-low { 1418 type uint64; 1419 description 1420 "The lowerbound of receiving rate."; 1421 } 1422 } 1424 grouping pw-segment-grouping { 1425 description 1426 "Grouping used for PW configuration. "; 1427 leaf pw-id { 1428 type string; 1429 description 1430 "The Identifier information of pseudowire. "; 1431 } 1433 leaf pw-name { 1434 type string; 1435 description 1436 "The name information of pseudowire."; 1437 } 1439 leaf transmit-label { 1440 type rt-types:mpls-label; 1441 description 1442 "Transmit label information in PW. "; 1443 } 1445 leaf receive-label { 1446 type rt-types:mpls-label; 1447 description 1448 "Receive label information in PW. "; 1449 } 1451 leaf encapsulation-type { 1452 type identityref { 1453 base etht-types:encapsulation-type; 1454 } 1455 description 1456 "The encapsulation type, raw or tag. "; 1457 } 1459 leaf oper-status { 1460 type identityref { 1461 base te-types:tunnel-state-type; 1462 } 1463 config false; 1464 description 1465 "The operational state of the PW segment. "; 1466 } 1468 container ingress-bandwidth-profile { 1469 description 1470 "Bandwidth Profile for ingress. "; 1471 uses pw-segment-named-or-value-bandwidth-profile; 1472 } 1474 list pw-paths { 1475 key path-id; 1476 description 1477 "A list of pw paths. "; 1479 leaf path-id { 1480 type uint8; 1481 description 1482 "The identifier of pw paths. "; 1484 } 1486 list tp-tunnels { 1487 key name; 1488 description 1489 "Names of TP Tunnel underlay"; 1490 leaf name { 1491 type string; 1492 description 1493 "Names of TP Tunnel underlay"; 1494 } 1495 } 1497 } 1499 } 1501 grouping pw-segment-named-or-value-bandwidth-profile { 1502 description 1503 "A grouping to configure a bandwdith profile either by 1504 referencing a named bandwidth profile or by 1505 configuring the values of the bandwidth profile attributes."; 1506 choice style { 1507 description 1508 "Whether the bandwidth profile is named or defined by value"; 1509 case named { 1510 description 1511 "Named bandwidth profile."; 1512 leaf bandwidth-profile-name { 1513 type leafref { 1514 path "/ethtsvc:etht-svc/ethtsvc:globals/" 1515 + "ethtsvc:named-bandwidth-profiles/" 1516 + "ethtsvc:bandwidth-profile-name"; 1517 } 1518 description 1519 "Name of the bandwidth profile."; 1520 } 1521 } 1522 case value { 1523 description 1524 "Bandwidth profile configured by value."; 1525 uses etht-types:pw-segement-bandwidth-profile-grouping; 1526 } 1527 } 1528 } 1530 grouping tunnels-grouping { 1531 description 1532 "A group of tunnels. "; 1533 leaf name { 1534 type leafref { 1535 path "/te:te/te:tunnels/te:tunnel/te:name"; 1536 require-instance false; 1537 } 1538 description "Dependency tunnel name"; 1539 } 1540 leaf encoding { 1541 type identityref { 1542 base te-types:lsp-encoding-types; 1543 } 1544 description "LSP encoding type"; 1545 reference "RFC3945"; 1546 } 1547 leaf switching-type { 1548 type identityref { 1549 base te-types:switching-capabilities; 1550 } 1551 description "LSP switching type"; 1552 reference "RFC3945"; 1553 } 1554 } 1555 } 1556 1558 5.2. YANG Code for ETH type 1560 This module references a few documents including [RFC2697], 1561 [RFC2698], [RFC4115], [IEEE802.1ad], [IEEE802.1q] and [MEF10]. 1563 file "ietf-eth-tran-types@2019-11-03.yang" 1564 module ietf-eth-tran-types { 1565 yang-version 1.1; 1566 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-tran-types"; 1568 prefix "etht-types"; 1570 organization 1571 "Internet Engineering Task Force (IETF) CCAMP WG"; 1572 contact 1573 " 1574 WG List: 1576 ID-draft editor: 1577 Haomian Zheng (zhenghaomian@huawei.com); 1578 Italo Busi (italo.busi@huawei.com); 1579 Aihua Guo (aihuaguo.ietf@gmail.com); 1580 Anton Snitser (antons@sedonasys.com);0 1581 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 1582 Yunbin Xu (xuyunbin@caict.ac.cn); 1583 Yang Zhao (zhaoyangyjy@chinamobile.com); 1584 Xufeng Liu (xufeng.liu.ietf@gmail.com); 1585 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 1586 "; 1588 description 1589 "This module defines the ETH types. 1590 The model fully conforms to the Network Management 1591 Datastore Architecture (NMDA). 1593 Copyright (c) 2019 IETF Trust and the persons 1594 identified as authors of the code. All rights reserved. 1596 Redistribution and use in source and binary forms, with or 1597 without modification, is permitted pursuant to, and subject 1598 to the license terms contained in, the Simplified BSD License 1599 set forth in Section 4.c of the IETF Trust's Legal Provisions 1600 Relating to IETF Documents 1601 (https://trustee.ietf.org/license-info). 1602 This version of this YANG module is part of RFC XXXX; see 1603 the RFC itself for full legal notices."; 1605 revision 2019-11-03 { 1606 description 1607 "version -01 as a WG draft"; 1608 reference 1609 "draft-ietf-ccamp-client-signal-yang"; 1610 } 1612 /* 1613 * Identities 1614 */ 1616 identity eth-vlan-tag-type { 1617 description 1618 "ETH VLAN tag type."; 1619 } 1621 identity c-vlan-tag-type { 1622 base eth-vlan-tag-type; 1623 description 1624 "802.1Q Customer VLAN"; 1625 } 1627 identity s-vlan-tag-type { 1628 base eth-vlan-tag-type; 1629 description 1630 "802.1Q Service VLAN (QinQ)"; 1631 } 1633 identity service-classification-type { 1634 description 1635 "Service classification."; 1636 } 1638 identity port-classification { 1639 base service-classification-type; 1640 description 1641 "Port classification."; 1642 } 1644 identity vlan-classification { 1645 base service-classification-type; 1646 description 1647 "VLAN classification."; 1648 } 1650 identity eth-vlan-tag-classify { 1651 description 1652 "VLAN tag classification."; 1653 } 1655 identity classify-c-vlan { 1656 base eth-vlan-tag-classify; 1657 description 1658 "Classify 802.1Q Customer VLAN tag. 1659 Only C-tag type is accepted"; 1660 } 1662 identity classify-s-vlan { 1663 base eth-vlan-tag-classify; 1664 description 1665 "Classify 802.1Q Service VLAN (QinQ) tag. 1666 Only S-tag type is accepted"; 1667 } 1669 identity classify-s-or-c-vlan { 1670 base eth-vlan-tag-classify; 1671 description 1672 "Classify S-VLAN or C-VLAN tag-classify. 1673 Either tag is accepted"; 1674 } 1676 identity bandwidth-profile-type { 1677 description 1678 "Bandwidth Profile Types"; 1679 } 1681 identity mef-10-bwp { 1682 base bandwidth-profile-type; 1683 description 1684 "MEF 10 Bandwidth Profile"; 1685 } 1686 identity rfc-2697-bwp { 1687 base bandwidth-profile-type; 1688 description 1689 "RFC 2697 Bandwidth Profile"; 1690 } 1692 identity rfc-2698-bwp { 1693 base bandwidth-profile-type; 1694 description 1695 "RFC 2698 Bandwidth Profile"; 1696 } 1698 identity rfc-4115-bwp { 1699 base bandwidth-profile-type; 1700 description 1701 "RFC 4115 Bandwidth Profile"; 1702 } 1704 identity service-type { 1705 description 1706 "Type of Ethernet service."; 1707 } 1709 identity p2p-svc { 1710 base service-type; 1711 description 1712 "Ethernet point-to-point service (EPL, EVPL)."; 1713 } 1715 identity rmp-svc { 1716 base service-type; 1717 description 1718 "Ethernet rooted-multitpoint service (E-TREE, EP-TREE)."; 1719 } 1721 identity mp2mp-svc { 1722 base service-type; 1723 description 1724 "Ethernet multipoint-to-multitpoint service (E-LAN, EP-LAN)."; 1725 } 1727 identity lifecycle-status { 1728 description 1729 "Lifecycle Status."; 1730 } 1732 identity installed { 1733 base lifecycle-status; 1734 description 1735 "Installed."; 1736 } 1738 identity planned { 1739 base lifecycle-status; 1740 description 1741 "Planned."; 1742 } 1744 identity pending-removal { 1745 base lifecycle-status; 1746 description 1747 "Pending Removal."; 1748 } 1750 /* 1751 * Type Definitions 1752 */ 1754 typedef eth-tag-type { 1755 type identityref { 1756 base eth-vlan-tag-type; 1757 } 1758 description 1759 "Identifies a specific ETH VLAN tag type."; 1760 } 1762 typedef eth-tag-classify { 1763 type identityref { 1764 base eth-vlan-tag-classify; 1765 } 1766 description 1767 "Identifies a specific VLAN tag classification."; 1768 } 1770 typedef vlanid { 1771 type uint16 { 1772 range "1..4094"; 1773 } 1774 description 1775 "The 12-bit VLAN-ID used in the VLAN Tag header."; 1776 } 1778 typedef vid-range-type { 1779 type string { 1780 pattern "([1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?" + 1781 "(,[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?)*)"; 1783 } 1784 description 1785 "A list of VLAN Ids, or non overlapping VLAN ranges, in 1786 ascending order, between 1 and 4094. 1787 This type is used to match an ordered list of VLAN Ids, or 1788 contiguous ranges of VLAN Ids. Valid VLAN Ids must be in the 1789 range 1 to 4094, and included in the list in non overlapping 1790 ascending order. 1792 For example: 1,10-100,50,500-1000"; 1793 } 1795 typedef bandwidth-profile-type { 1796 type identityref { 1797 base bandwidth-profile-type; 1798 } 1799 description 1800 "Identifies a specific Bandwidth Profile type."; 1801 } 1803 typedef service-type { 1804 type identityref { 1805 base service-type; 1806 } 1807 description 1808 "Identifies the type of Ethernet service."; 1809 } 1811 typedef lifecycle-status { 1812 type identityref { 1813 base lifecycle-status; 1814 } 1815 description 1816 "Identifies the lLifecycle Status ."; 1817 } 1819 /* 1820 * Grouping Definitions 1821 */ 1823 grouping etht-bandwidth-profiles { 1824 description 1825 "Bandwidth profile configuration paramters."; 1827 leaf bandwidth-profile-type { 1828 type etht-types:bandwidth-profile-type; 1829 description 1830 "The type of bandwidth profile."; 1832 } 1833 leaf CIR { 1834 type uint64; 1835 description 1836 "Committed Information Rate in Kbps"; 1837 } 1838 leaf CBS { 1839 type uint64; 1840 description 1841 "Committed Burst Size in in KBytes"; 1842 } 1843 leaf EIR { 1844 type uint64; 1845 /* Need to indicate that EIR is not supported by RFC 2697 1847 must 1848 '../bw-profile-type = "mef-10-bwp" or ' + 1849 '../bw-profile-type = "rfc-2698-bwp" or ' + 1850 '../bw-profile-type = "rfc-4115-bwp"' 1852 must 1853 '../bw-profile-type != "rfc-2697-bwp"' 1854 */ 1855 description 1856 "Excess Information Rate in Kbps 1857 In case of RFC 2698, PIR = CIR + EIR"; 1858 } 1859 leaf EBS { 1860 type uint64; 1861 description 1862 "Excess Burst Size in KBytes. 1863 In case of RFC 2698, PBS = CBS + EBS"; 1864 } 1865 leaf color-aware { 1866 type boolean; 1867 description 1868 "Indicates weather the color-mode is 1869 color-aware or color-blind."; 1870 } 1871 leaf coupling-flag { 1872 type boolean; 1873 /* Need to indicate that Coupling Flag is defined only for MEF 10 1875 must 1876 '../bw-profile-type = "mef-10-bwp"' 1877 */ 1878 description 1879 "Coupling Flag."; 1881 } 1882 } 1884 identity topology-role { 1885 description 1886 "The rold of underlay topology, e.g., 1887 hub, spoke, any-to-any. "; 1888 } 1890 identity resilience { 1891 description 1892 "Placeholder for resilience information in data plane, 1893 for future study. "; 1894 } 1896 identity access-role { 1897 description 1898 "Indicating whether the access is a working or protection access."; 1899 } 1901 identity performance { 1902 description 1903 "Placeholder for performace 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 } 1965 grouping eth-label-restriction { 1966 description 1967 "Label Restriction for ethernet."; 1968 leaf tag-type { 1969 type etht-types:eth-tag-type; 1970 description "VLAN tag type."; 1971 } 1972 leaf priority { 1973 type uint8; 1974 description "priority."; 1975 } 1976 } 1977 grouping eth-label { 1978 description 1979 "Label for ethernet."; 1980 leaf vlanid { 1981 type etht-types:vlanid; 1982 description 1983 "VLAN tag id."; 1984 } 1985 } 1987 grouping eth-label-step { 1988 description "Label step for Ethernet VLAN"; 1989 leaf eth-step { 1990 type uint16 { 1991 range "1..4095"; 1992 } 1993 default 1; 1994 description 1995 "Label step which represent possible increments for 1996 an Ethernet VLAN tag."; 1997 reference 1998 "IEEE 802.1ad: Provider Bridges."; 1999 } 2000 } 2001 } 2003 2005 5.3. Other Client Signal YANG Code 2007 This module imports typedefs and modules from [RFC6991], 2008 [I-D.ietf-ccamp-otn-tunnel-model], [RFC8776]. 2010 file "ietf-trans-client-service@2021-01-11.yang" 2011 module ietf-trans-client-service { 2012 /* TODO: FIXME */ 2013 yang-version 1.1; 2015 namespace "urn:ietf:params:xml:ns:yang:ietf-trans-client-service"; 2016 prefix "clntsvc"; 2018 import ietf-te-types { 2019 prefix "te-types"; 2020 reference "RFC 8776 - Traffic Engineering Common YANG Types"; 2021 } 2022 import ietf-layer1-types { 2023 prefix "layer1-types"; 2024 reference "RFC ZZZZ - A YANG Data Model for Layer 1 Types"; 2025 } 2027 import ietf-yang-types { 2028 prefix "yang"; 2029 reference "RFC 6991 - Common YANG Data Types"; 2030 } 2032 import ietf-trans-client-svc-types { 2033 prefix "clntsvc-types"; 2034 reference "RFC XXXX - A YANG Data Model for 2035 Transport Network Client Signals"; 2036 } 2038 organization 2039 "Internet Engineering Task Force (IETF) CCAMP WG"; 2040 contact 2041 " 2042 ID-draft editor: 2043 Haomian Zheng (zhenghaomian@huawei.com); 2044 Aihua Guo (aihuaguo.ietf@gmail.com); 2045 Italo Busi (italo.busi@huawei.com); 2046 Anton Snitser (antons@sedonasys.com); 2047 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 2048 Yunbin Xu (xuyunbin@caict.ac.cn); 2049 Yang Zhao (zhaoyangyjy@chinamobile.com); 2050 Xufeng Liu (Xufeng_Liu@jabil.com); 2051 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 2052 "; 2054 description 2055 "This module defines a YANG data model for describing 2056 transport network client services. The model fully conforms 2057 to the Network Management Datastore Architecture (NMDA). 2059 Copyright (c) 2021 IETF Trust and the persons 2060 identified as authors of the code. All rights reserved. 2062 Redistribution and use in source and binary forms, with or 2063 without modification, is permitted pursuant to, and subject 2064 to the license terms contained in, the Simplified BSD License 2065 set forth in Section 4.c of the IETF Trust's Legal Provisions 2066 Relating to IETF Documents 2067 (https://trustee.ietf.org/license-info). 2068 This version of this YANG module is part of RFC XXXX; see 2069 the RFC itself for full legal notices."; 2071 revision 2021-01-11 { 2072 description 2073 "version -04 as a WG document"; 2074 reference 2075 "draft-ietf-ccamp-client-signal-yang"; 2076 } 2078 /* 2079 * Groupings 2080 */ 2081 grouping client-svc-access-parameters { 2082 description 2083 "Transport network client signals access parameters"; 2085 leaf access-node-id { 2086 type te-types:te-node-id; 2087 description 2088 "The identifier of the access node in the underlying 2089 transport network topology."; 2090 } 2092 leaf access-ltp-id { 2093 type te-types:te-tp-id; 2094 description 2095 "The TE link termination point identifier, used together with 2096 access-node-id to identify the access LTP."; 2097 } 2099 leaf client-signal { 2100 type identityref { 2101 base layer1-types:client-signal; 2102 } 2103 description 2104 "Identify the client signal type associated with this port"; 2105 } 2107 } 2109 grouping client-svc-tunnel-parameters { 2110 description 2111 "Transport network client signals tunnel parameters"; 2113 leaf tunnel-name { 2114 type string; 2115 description 2116 "TE tunnel instance name."; 2117 } 2119 } 2121 grouping client-svc-instance-config { 2122 description 2123 "Configuration parameters for client services."; 2124 leaf client-svc-name { 2125 type string; 2126 description 2127 "Identifier of the p2p transport network client signals."; 2128 } 2130 leaf client-svc-title { 2131 type string; 2132 description 2133 "Name of the p2p transport network client signals."; 2134 } 2136 leaf client-svc-descr { 2137 type string; 2138 description 2139 "Description of the transport network client signals."; 2140 } 2142 leaf client-svc-customer { 2143 type string; 2144 description 2145 "Customer of the transport network client signals."; 2146 } 2148 container resilience { 2149 description "Place holder for resilience functionalities"; 2150 } 2152 uses te-types:te-topology-identifier; 2154 leaf admin-status { 2155 type identityref { 2156 base te-types:tunnel-admin-state-type; 2157 } 2158 default te-types:tunnel-admin-state-up; 2159 description "Client signals administrative state."; 2160 } 2162 container src-access-ports { 2163 description 2164 "Source access port of a client signal."; 2165 uses client-svc-access-parameters; 2166 } 2167 container dst-access-ports { 2168 description 2169 "Destination access port of a client signal."; 2170 uses client-svc-access-parameters; 2171 } 2173 leaf direction { 2174 type identityref { 2175 base clntsvc-types:direction; 2176 } 2177 description "Uni-dir or Bi-dir for the client signal."; 2178 } 2180 list svc-tunnels { 2181 key tunnel-name; 2182 description 2183 "List of the TE Tunnels supporting the client signal."; 2184 uses client-svc-tunnel-parameters; 2185 } 2186 } 2188 grouping client-svc-instance-state { 2189 description 2190 "State parameters for client services."; 2191 leaf operational-state { 2192 type identityref { 2193 base te-types:tunnel-state-type; 2194 } 2195 config false; 2196 description "Client signal operational state."; 2197 } 2198 leaf provisioning-state { 2199 type identityref { 2200 base te-types:lsp-state-type; 2201 } 2202 config false; 2203 description "Client signal provisioning state."; 2204 } 2205 leaf creation-time { 2206 type yang:date-and-time; 2207 config false; 2208 description "The time of the client signal be created."; 2209 } 2210 leaf last-updated-time { 2211 type yang:date-and-time; 2212 config false; 2213 description "The time of the client signal's latest update."; 2214 } 2215 leaf created-by { 2216 type string; 2217 config false; 2218 description 2219 "The client signal is created by whom, 2220 can be a system or staff ID."; 2221 } 2222 leaf last-updated-by { 2223 type string; 2224 config false; 2225 description 2226 "The client signal is last updated by whom, 2227 can be a system or staff ID."; 2228 } 2229 leaf owned-by { 2230 type string; 2231 config false; 2232 description 2233 "The client signal is owned by whom, 2234 can be a system ID."; 2235 } 2236 } 2238 /* 2239 * Data nodes 2240 */ 2242 container client-svc { 2243 description 2244 "Transport client services."; 2246 list client-svc-instances { 2247 key client-svc-name; 2248 description 2249 "The list of p2p transport client service instances"; 2251 uses client-svc-instance-config; 2252 uses client-svc-instance-state; 2253 } 2254 } 2255 } 2256 2258 5.4. Other Client Signal Types YANG Code 2260 This module defines the types for other client signal types. 2262 file "ietf-trans-client-svc-types@2019-11-03.yang" 2264 module ietf-trans-client-svc-types { 2265 namespace "urn:ietf:params:xml:ns:yang:ietf-trans-client-svc-types"; 2266 prefix "clntsvc-types"; 2268 organization 2269 "Internet Engineering Task Force (IETF) CCAMP WG"; 2270 contact 2271 " 2272 ID-draft editor: 2273 Haomian Zheng (zhenghaomian@huawei.com); 2274 Aihua Guo (aihuaguo.ietf@gmail.com); 2275 Italo Busi (italo.busi@huawei.com); 2276 Anton Snitser (antons@sedonasys.com); 2277 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 2278 Yunbin Xu (xuyunbin@caict.ac.cn); 2279 Yang Zhao (zhaoyangyjy@chinamobile.com); 2280 Xufeng Liu (Xufeng_Liu@jabil.com); 2281 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 2282 "; 2284 description 2285 "This module defines a YANG data model for describing 2286 transport network client types. The model fully conforms 2287 to the Network Management Datastore Architecture (NMDA). 2289 Copyright (c) 2019 IETF Trust and the persons 2290 identified as authors of the code. All rights reserved. 2292 Redistribution and use in source and binary forms, with or 2293 without modification, is permitted pursuant to, and subject 2294 to the license terms contained in, the Simplified BSD License 2295 set forth in Section 4.c of the IETF Trust's Legal Provisions 2296 Relating to IETF Documents 2297 (https://trustee.ietf.org/license-info). 2298 This version of this YANG module is part of RFC XXXX; see 2299 the RFC itself for full legal notices."; 2301 revision 2019-11-03 { 2302 description 2303 "version -01 as a WG document"; 2304 reference 2305 "draft-ietf-ccamp-client-signal-yang"; 2306 } 2308 identity direction { 2309 description 2310 "Direction information of Client Signal."; 2311 } 2313 identity bidirectional { 2314 base direction; 2315 description 2316 "Client Signal is bi-directional."; 2317 } 2319 identity unidirectional { 2320 base direction; 2321 description 2322 "Client Signal is uni-directional."; 2323 } 2325 } 2326 2328 6. Considerations and Open Issue 2330 Editor Notes: This section is used to note temporary discussion/ 2331 conclusion that to be fixed in the future version, and will be 2332 removed before publication. We currently categorize all the client 2333 signal types into transparent and non-transparent, with separate 2334 models. There was consensus that no common model is needed for these 2335 two categories. Further Alignment with RFC8407 would be required 2336 before publication. The RFC Editor will replace XXXX, YYYY and ZZZZ 2337 with the number assigned to the RFC once this draft becomes an RFC. 2339 7. IANA Considerations 2341 It is proposed that IANA should assign new URIs from the "IETF XML 2342 Registry" [RFC3688] as follows: 2344 URI: urn:ietf:params:xml:ns:yang:ietf-eth-tran-service 2345 Registrant Contact: The IESG 2346 XML: N/A; the requested URI is an XML namespace. 2348 URI: urn:ietf:params:xml:ns:yang:ietf-trans-client-service 2349 Registrant Contact: The IESG 2350 XML: N/A; the requested URI is an XML namespace. 2352 URI: urn:ietf:params:xml:ns:yang:ietf-eth-tran-types 2353 Registrant Contact: The IESG 2354 XML: N/A; the requested URI is an XML namespace. 2356 URI: urn:ietf:params:xml:ns:yang:ietf-trans-client-svc-types 2357 Registrant Contact: The IESG 2358 XML: N/A; the requested URI is an XML namespace. 2360 This document registers following YANG modules in the YANG Module 2361 Names registry [RFC6020]. 2363 name: ietf-eth-tran-service 2364 namespace: urn:ietf:params:xml:ns:yang:ietf-eth-tran-service 2365 prefix: ethtsvc 2366 reference: RFC XXXX: A YANG Data Model for Transport 2367 Network Client Signals 2369 name: ietf-eth-tran-types 2370 namespace: urn:ietf:params:xml:ns:yang:ietf-eth-tran-types 2371 prefix: etht-types 2372 reference: RFC XXXX: A YANG Data Model for Transport 2373 Network Client Signals 2375 name: ietf-trans-client-service 2376 namespace: urn:ietf:params:xml:ns:yang:ietf-trans-client-service 2377 prefix: clntsvc 2378 reference: RFC XXXX: A YANG Data Model for Transport 2379 Network Client Signals 2381 name: ietf-trans-client-svc-types 2382 namespace: urn:ietf:params:xml:ns:yang:ietf-trans-client-svc-types 2383 prefix: clntsvc-types 2384 reference: RFC XXXX: A YANG Data Model for Transport 2385 Network Client Signals 2387 8. Manageability Considerations 2389 TBD. 2391 9. Security Considerations 2393 The data following the model defined in this document is exchanged 2394 via, for example, the interface between an orchestrator and a network 2395 domain controller. 2397 The YANG module defined in this document can be accessed via the 2398 RESTCONF protocol defined in [RFC8040], or maybe via the NETCONF 2399 protocol [RFC6241]. 2401 There are a number of data nodes defined in the YANG module which are 2402 writable/creatable/deletable (i.e., config true, which is the 2403 default). These data nodes may be considered sensitive or vulnerable 2404 in some network environments. Write operations (e.g., POST) to these 2405 data nodes without proper protection can have a negative effect on 2406 network operations. 2408 10. Acknowledgements 2410 We would like to thank Igor Bryskin and Daniel King for their 2411 comments and discussions. 2413 11. Contributors 2415 Yanlei Zheng 2416 China Unicom 2417 Email: zhengyl@dimpt.com 2419 Zhe Liu 2420 Huawei Technologies, 2421 Email: liuzhe123@huawei.com 2423 Sergio Belotti 2424 Nokia, 2425 Email: sergio.belotti@nokia.com 2427 Yingxi Yao 2428 Shanghai Bell, 2429 yingxi.yao@nokia-sbell.com 2431 12. References 2433 12.1. Normative References 2435 [I-D.ietf-ccamp-l1csm-yang] 2436 Lee, Y., Lee, K., Zheng, H., Dios, O., and D. Ceccarelli, 2437 "A YANG Data Model for L1 Connectivity Service Model 2438 (L1CSM)", draft-ietf-ccamp-l1csm-yang-13 (work in 2439 progress), November 2020. 2441 [I-D.ietf-ccamp-otn-topo-yang] 2442 Zheng, H., Busi, I., Liu, X., Belotti, S., and O. Dios, "A 2443 YANG Data Model for Optical Transport Network Topology", 2444 draft-ietf-ccamp-otn-topo-yang-11 (work in progress), 2445 September 2020. 2447 [I-D.ietf-ccamp-otn-tunnel-model] 2448 Zheng, H., Busi, I., Belotti, S., Lopez, V., and Y. Xu, 2449 "OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel- 2450 model-11 (work in progress), September 2020. 2452 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2453 the Network Configuration Protocol (NETCONF)", RFC 6020, 2454 DOI 10.17487/RFC6020, October 2010, 2455 . 2457 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2458 and A. Bierman, Ed., "Network Configuration Protocol 2459 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2460 . 2462 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2463 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2464 . 2466 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 2467 and K. Pithewan, "GMPLS Signaling Extensions for Control 2468 of Evolving G.709 Optical Transport Networks", RFC 7139, 2469 DOI 10.17487/RFC7139, March 2014, 2470 . 2472 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2473 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2474 . 2476 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2477 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2478 . 2480 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 2481 "Common YANG Data Types for the Routing Area", RFC 8294, 2482 DOI 10.17487/RFC8294, December 2017, 2483 . 2485 [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 2486 "Common YANG Data Types for Traffic Engineering", 2487 RFC 8776, DOI 10.17487/RFC8776, June 2020, 2488 . 2490 12.2. Informative References 2492 [IEEE802.1ad] 2493 IEEE, 802., "IEEE 802.1ad - Provider Bridges.", IEEE 2494 802.1ad , May 2006. 2496 [IEEE802.1q] 2497 IEEE, 802., "IEEE 802.1q - Virtual Bridged Local Area 2498 Networks", IEEE 802.1q , June 2005. 2500 [MEF10] MEF, 10., "Ethernet Services Attributes Phase 1", MEF10 , 2501 November 2004. 2503 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 2504 Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, 2505 . 2507 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 2508 Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, 2509 . 2511 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2512 DOI 10.17487/RFC3688, January 2004, 2513 . 2515 [RFC4115] Aboul-Magd, O. and S. Rabie, "A Differentiated Service 2516 Two-Rate, Three-Color Marker with Efficient Handling of 2517 in-Profile Traffic", RFC 4115, DOI 10.17487/RFC4115, July 2518 2005, . 2520 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 2521 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 2522 DOI 10.17487/RFC8299, January 2018, 2523 . 2525 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2526 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2527 . 2529 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2530 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2531 . 2533 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2534 and R. Wilton, "Network Management Datastore Architecture 2535 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2536 . 2538 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 2539 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 2540 DOI 10.17487/RFC8453, August 2018, 2541 . 2543 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2544 Data Model for Layer 2 Virtual Private Network (L2VPN) 2545 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2546 2018, . 2548 Authors' Addresses 2550 Haomian Zheng 2551 Huawei Technologies 2552 H1 XiliuBeipo Village, Songshan Lake 2553 Dongguan, Guangdong 2554 China 2556 Email: zhenghaomian@huawei.com 2558 Aihua Guo 2559 Futurewei 2561 Email: aihuaguo.ietf@gmail.com 2563 Italo Busi 2564 Huawei Technologies 2566 Email: Italo.Busi@huawei.com 2568 Anton Snitser 2569 Sedona 2571 Email: antons@sedonasys.com 2572 Francesco Lazzeri 2573 Ericsson 2575 Email: francesco.lazzeri@ericsson.com 2577 Yunbin Xu 2578 CAICT 2580 Email: xuyunbin@caict.ac.cn 2582 Yang Zhao 2583 China Mobile 2585 Email: zhaoyangyjy@chinamobile.com 2587 Xufeng Liu 2588 Volta Networks 2590 Email: xufeng.liu.ietf@gmail.com 2592 Giuseppe Fioccola 2593 Huawei Technologies 2595 Email: giuseppe.fioccola@huawei.com