idnits 2.17.1 draft-zheng-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 26 instances of too long lines in the document, the longest one being 45 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 333 has weird spacing: '...le-name str...' == Line 360 has weird spacing: '...oint-id str...' == Line 526 has weird spacing: '...el-name str...' == Line 912 has weird spacing: '...rouping etht-...' == Line 938 has weird spacing: '...rouping etht-...' == (4 more instances...) -- The document date (March 11, 2019) is 1874 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-teas-yang-te-topo' is defined on line 2144, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-ccamp-l1csm-yang-09 == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-otn-topo-yang-06 == Outdated reference: A later version (-20) exists of draft-ietf-ccamp-otn-tunnel-model-06 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-19 == Outdated reference: A later version (-13) exists of draft-ietf-teas-yang-te-types-06 Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group H. Zheng 3 Internet-Draft A. Guo 4 Intended status: Standards Track I. Busi 5 Expires: September 12, 2019 Huawei Technologies 6 A. Snitser 7 Sedona 8 F. Lazzeri 9 Ericsson 10 Y. Xu 11 CAICT 12 Y. Zhao 13 China Mobile 14 X. Liu 15 Volta Networks 16 G. Fioccola 17 Huawei Technologies 18 March 11, 2019 20 A YANG Data Model for Transport Network Client Signals 21 draft-zheng-ccamp-client-signal-yang-06 23 Abstract 25 A transport network is a server-layer network to provide connectivity 26 services to its client. The topology and tunnel information in the 27 transport layer has already been defined by generic Traffic- 28 engineered models and technology-specific models (e.g., OTN, WSON). 29 However, how the client signals are accessing to the network has not 30 been described. These information is necessary to both client and 31 provider. 33 This draft describes how the client signals are carried over 34 transport network and defines YANG data models which are required 35 during configuration procedure. More specifically, several client 36 signal (of transport network) models including ETH, STM-n, FC and so 37 on, are defined in this draft. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on September 12, 2019. 56 Copyright Notice 58 Copyright (c) 2019 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.2. Prefixs in Model Names . . . . . . . . . . . . . . . . . 3 76 2. Terminology and Notations . . . . . . . . . . . . . . . . . . 4 77 3. Transport Network Client Signal Overview . . . . . . . . . . 4 78 3.1. Overview of Service Request and Network Configuration 79 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 4 80 3.2. Applicability of Proposed Model . . . . . . . . . . . . . 7 81 4. YANG Model for Transport Network Client Signal . . . . . . . 8 82 4.1. YANG Tree for Ethernet Service . . . . . . . . . . . . . 8 83 4.2. YANG Tree for other Transport Network Client Signal Model 12 84 5. YANG Code for Transport Network Client Signal . . . . . . . . 12 85 5.1. The ETH Service YANG Code . . . . . . . . . . . . . . . . 12 86 5.2. YANG Code for ETH transport type . . . . . . . . . . . . 30 87 5.3. Other Transport Network client signal YANG Code . . . . . 39 88 6. Considerations and Open Issue . . . . . . . . . . . . . . . . 44 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 90 8. Manageability Considerations . . . . . . . . . . . . . . . . 45 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 45 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 93 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 95 12.1. Normative References . . . . . . . . . . . . . . . . . . 46 96 12.2. Informative References . . . . . . . . . . . . . . . . . 47 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 100 1. Introduction 102 1.1. Overview 104 A transport network is a server-layer network designed to provide 105 connectivity services for a client-layer network to carry the client 106 traffic transparently across the server-layer network resources. 107 Currently the topology and tunnel models which have been defined for 108 transport networks, such as [I-D.ietf-ccamp-otn-topo-yang] and 109 [I-D.ietf-ccamp-otn-tunnel-model], provide server-layer topology 110 abstraction and tunnel configuration between PEs. However, there is 111 a missing piece for configuring how the PEs should map the client- 112 layer traffic, received from the CE, over the server-layer-tunnels: 113 this gap is expected to be solved in this document. 115 This document defines a data model of all transport network client 116 signals, using YANG language defined in [RFC7950]. The model can be 117 used by applications exposing to a transport controller via a 118 RESTconf interface. Furthermore, it can be used by an application 119 for the following purposes (but not limited to): 121 o To request/update an end-to-end service by driving a new tunnel to 122 be set up to support this service; 124 o To request/update an end-to-end service by using an existing 125 tunnel; 127 o To receive notification with regard to the information change of 128 the given service; 130 The YANG module ietf-otn-topology defined in this document conforms 131 to the Network Management Datastore Architecture (NMDA) defined in 132 [RFC8342]. 134 1.2. Prefixs in Model Names 136 In this document, names of data nodes and other data model objects 137 are prefixed using the standard prefix associated with the 138 corresponding YANG imported modules, including [RFC6991], [RFC8294] 139 and [I-D.ietf-ccamp-otn-tunnel-model], which are shown as follow. 141 +------------+---------------------------+----------------------+ 142 | Prefix | YANG module | Reference | 143 +------------+---------------------------+----------------------+ 144 | yang | ietf-yang-types | [RFC6991] | 145 | te-types | ietf-te-types |[ietf-teas-yang-te-types]| 146 | rt-types | ietf-routing-types | [RFC8294] | 147 | otn-types | ietf-otn-types |[ietf-ccamp-otn-tunnel-model]| 148 | etht-types | ietf-eth-tran-types | This Document | 149 | clntsvc | ietf-trans-client-service | This Document | 150 | ethtsvc | ietf-eth-tran-service | This Document | 151 +------------+---------------------------+----------------------+ 153 2. Terminology and Notations 155 A simplified graphical representation of the data model is used in 156 this document. The meaning of the symbols in the YANG data tree 157 presented later in this document is defined in [RFC8340]. They are 158 provided below for reference. 160 o Brackets "[" and "]" enclose list keys. 162 o Abbreviations before data node names: "rw" means configuration 163 (read-write) and "ro" state data (read-only). 165 o Symbols after data node names: "?" means an optional node, "!" 166 means a presence container, and "*" denotes a list and leaf-list. 168 o Parentheses enclose choice and case nodes, and case nodes are also 169 marked with a colon (":"). 171 o Ellipsis ("...") stands for contents of subtrees that are not 172 shown. 174 3. Transport Network Client Signal Overview 176 3.1. Overview of Service Request and Network Configuration Scenarios 178 A global view of a multi-domain service can be described as the 179 Figure 1 . The customer is usually responsible to configure the CE 180 nodes and to request to the provider the service intent, from the CE 181 nodes perspective, while the provider is responsible to configure the 182 whole network (including the PE nodes) to support the customer 183 service intent. Generally speaking, the network configurations 184 required to support a customer service can be split into two 185 different groups: CE-PE and PE-PE. The CE-PE configuration deals 186 with the client layer one-hop access link, while PE-PE configuration 187 deals with the server layer tunnel. In Figure 1 we mark the 188 intermediate nodes as 'P', which has same switching capability of PE 189 but just not the 'end-point'. In this example, the link P-P and PE-P 190 are a server-layer intra-domain or inter-domain link. 192 +----+ +----+ 193 | CE | | CE | 194 +--+-+ +--+-+ 195 | | 196 | ------------- -------------| 197 //|/ \\\\ ///// |\\\\ 198 // | \\ // | \\ 199 | +--+-+ +---+ +---+ | | +---+ +---+ +--+-+ | 200 | | PE +----+ P +--+ P +---+-----+--+ P +---+ P +---+ PE | | 201 | +----+ +---+ +---+ | | +---+ +---+ +----+ | 202 \\ // \\ // 203 \\\\ //// \\\\\ ///// 204 ------------- ------------- 205 Domain 1 Domain 2 207 Figure 1: Global view of Client Service with the Network Provider 209 According to the responsibilities of each controller in [RFC8453], 210 the controllers have different views of the service request and 211 network configuration. The duty of CNC is to give the MDSC a 212 description of the customer service intent: candidate YANG models 213 include L1CSM [I-D.ietf-ccamp-l1csm-yang], L2SM [RFC8466] and L3SM 214 [RFC8299], which are classified as customer service models, according 215 to [RFC8309]. These models provide necessary attributes to describe 216 the customer service intent from the customer/CE perspective, and do 217 not provide any specific network configuration. These models also 218 implies that the customer service description can be considered in a 219 separate manner rather than integratig with network configurations, 220 which also enable the controllers to abstract/virtualize the network 221 resource to make them visible to the customer and also easier to 222 manage. In other words, the network knowledge is not necessary at 223 CNC and CMI, which is seen in an abstracted form as shown in 224 Figure 2. 226 /---------\ 227 /// \\\ 228 +----+ | | +----+ 229 | CE |--------------+ NETWORK +----------------| CE | 230 +----+ | | +----+ 231 \\\ /// 232 \---------/ 234 Figure 2: CNC Viewpoint on the Client Service 236 The functionalities of MDSC have been described in [RFC8453], which 237 include the customer mapping/translation and multi-domain 238 coordination. By receiving the request from CNC, MDSC need to 239 understand what network configuration can support the customer 240 service intent and turn to the corresponding PNCs for configuration. 241 The service request is therefore decomposed by MDSC into a few 242 network configurations and forwarded to one or multiple PNCs 243 respectively in single-domain and multi-domain scenario. In general, 244 the MDSC has the view of both PE and CE nodes and of some abstract 245 information regarding the P nodes, as shown in Figure 3. It is worth 246 noting that this MDSC view is different with Figure 1 at the intra- 247 domain link. Usually these details are hidden, for scalability 248 purposes, and therefore the MDSC has only an abstract view of each 249 domain internal topology. 251 ------ ----- 252 //// \\\\ ///- -\\\ 253 // \\ // \\ 254 +----+ | +----+ +---+ | |+---+ +----+ | +----+ 255 | CE |-----+-| PE |-----| P |-+--+| P |-----| PE |-+-----| CE | 256 +----+ | +----+ +---+ | |+---+ +----+ | +----+ 257 \\ // \\ // 258 \\\\ //// \\\- -/// 259 ------ ----- 260 Domain 1 Domain 2 262 Figure 3: MDSC view of both Client Service and Network Abstraction 264 PNC is the controller that configure the physical devices, based on 265 the network configuration received from the MDSC. Each PNC has the 266 detailed view of its own domain, the example of view from PNC in 267 domain 1 is shown in Figure 4. The PNC has all the detailed topology 268 information on PE and P nodes and on the intra-domain links. The PNC 269 configures the tunnel/tunnel segment within its domain based on the 270 network configuration provided by the MDSC. The PNC also configures 271 the network part of the CE-PE access links as well as the mapping of 272 the client-layer traffic and the server-layer tunnels, based on the 273 network configuration provided by the MDSC. The interaction between 274 PNC and MDSC for the client-layer network configuration is 275 accomplished by the models defined in this draft. 277 | | | 278 | ------------- | -------------| 279 //|/ \\\\ | ///// |\\\\ 280 // | \\ | // | \\ 281 | +--+-+ +---+ +---+ | | | +---+ +---+ +--+-+ | 282 | | PE +----+ P +--+ P +---+--+--+--+ P +---+ P +---+ PE | | 283 | +----+ +---+ +---+ | | | +---+ +---+ +----+ | 284 \\ // | \\ // 285 \\\\ //// | \\\\\ ///// 286 ------------- | ------------- 287 PNC View in Domain 1 | PNC View in Domain 2 288 | 290 Figure 4: PNC view on Network Configuration 292 3.2. Applicability of Proposed Model 294 Existing TE and technology-specific models, such as topology models 295 and tunnel models, support the network configuration among PEs and 296 Ps. The customer service models, such as L1CSM, L2SM and L3SM, focus 297 on describing the attributes among CEs. However, there is a missing 298 piece on how to configure the CE-PE session. The models defined in 299 this document provide the configuration on CE-PE when the provider 300 server-layer network is TE-based technology. 302 In the example of OTN as the server-layer transport network, a full 303 list of G-PID was summarized in [RFC7139], which can be divided into 304 a few categories. The G-PID signals can be categorized into 305 transparent and non-transparent. Examples of transparent signals may 306 include Ethernetphysical interfaces, FC, STM-n and so on. In this 307 approach the OTN devices is not aware of the client signal type, and 308 this information is only necessary among the controllers. Once the 309 OTN tunnel is set up, there is no switching requested on the client 310 layer, and therefore only signal mapping is needed, without a client 311 tunnel set up. The models that supporting the configuration of 312 transparent signals are defined in Section 4.2. The other category 313 would be non-transparent, such as Carrier Ethernet and MPLS-TP, with 314 a switching request on the client layer. Once the OTN tunnel is set 315 up, a corresponding tunnel in the client layer has to be set up to 316 carry services. The models that supporting the configuration of 317 transparent signals are defined in Section 4.1. 319 It is also worth noting that some client signal can be carried over 320 multiple types of networks. For example, the Ethernet services can 321 be carried over either OTN or Ethernet TE tunnels (over optical or 322 microwave networks). The model specified in this document allows the 323 support from networks with different technologies. 325 4. YANG Model for Transport Network Client Signal 327 4.1. YANG Tree for Ethernet Service 329 module: ietf-eth-tran-service 330 +--rw etht-svc 331 +--rw globals 332 | +--rw named-bandwidth-profiles* [bandwidth-profile-name] 333 | +--rw bandwidth-profile-name string 334 | +--rw bandwidth-profile-type? etht-types:bandwidth-profile-type 335 | +--rw CIR? uint64 336 | +--rw CBS? uint64 337 | +--rw EIR? uint64 338 | +--rw EBS? uint64 339 | +--rw color-aware? boolean 340 | +--rw coupling-flag? boolean 341 +--rw etht-svc-instances* [etht-svc-name] 342 +--rw etht-svc-name string 343 +--rw etht-svc-id? string 344 +--rw etht-svc-descr? string 345 +--rw etht-svc-customer? string 346 +--rw etht-svc-type? etht-types:service-type 347 +--rw etht-svc-lifecycle? etht-types:lifecycle-status 348 +--rw te-topology-identifier 349 | +--rw provider-id? te-global-id 350 | +--rw client-id? te-global-id 351 | +--rw topology-id? te-topology-id 352 +--rw resilience 353 +--rw etht-svc-end-points* [etht-svc-end-point-name] 354 | +--rw etht-svc-end-point-name string 355 | +--rw etht-svc-end-point-id? string 356 | +--rw etht-svc-end-point-descr? string 357 | +--rw topology-role? identityref 358 | +--rw resilience 359 | +--rw etht-svc-access-points* [access-point-id] 360 | | +--rw access-point-id string 361 | | +--rw access-node-id? te-types:te-node-id 362 | | +--rw access-ltp-id? te-types:te-tp-id 363 | | +--rw access-role? identityref 364 | | +--rw pm-config 365 | | | +--rw pm-enable? boolean 366 | | | +--rw sending-rate-high? uint64 367 | | | +--rw sending-rate-low? uint64 368 | | | +--rw receiving-rate-high? uint64 369 | | | +--rw receiving-rate-low? uint64 370 | | +--ro state 371 | | | +--ro operational-state? identityref 372 | | | +--ro provisioning-state? identityref 373 | | +--ro performance? identityref 374 | +--rw service-classification-type? identityref 375 | +--rw (service-classification)? 376 | | +--:(port-classification) 377 | | +--:(vlan-classification) 378 | | +--rw outer-tag! 379 | | | +--rw tag-type? etht-types:eth-tag-classify 380 | | | +--rw (individual-bundling-vlan)? 381 | | | +--:(individual-vlan) 382 | | | | +--rw vlan-value? etht-types:vlanid 383 | | | +--:(vlan-bundling) 384 | | | +--rw vlan-range? etht-types:vid-range-type 385 | | +--rw second-tag! 386 | | +--rw tag-type? etht-types:eth-tag-classify 387 | | +--rw (individual-bundling-vlan)? 388 | | +--:(individual-vlan) 389 | | | +--rw vlan-value? etht-types:vlanid 390 | | +--:(vlan-bundling) 391 | | +--rw vlan-range? etht-types:vid-range-type 392 | +--rw split-horizon-group? string 393 | +--rw (direction)? 394 | | +--:(symmetrical) 395 | | | +--rw ingress-egress-bandwidth-profile 396 | | | +--rw (style)? 397 | | | +--:(named) 398 | | | | +--rw bandwidth-profile-name? string 399 | | | +--:(value) 400 | | | +--rw bandwidth-profile-type? etht-types:bandwidth-profile-type 401 | | | +--rw CIR? uint64 402 | | | +--rw CBS? uint64 403 | | | +--rw EIR? uint64 404 | | | +--rw EBS? uint64 405 | | | +--rw color-aware? boolean 406 | | | +--rw coupling-flag? boolean 407 | | +--:(asymmetrical) 408 | | +--rw ingress-bandwidth-profile 409 | | | +--rw (style)? 410 | | | +--:(named) 411 | | | | +--rw bandwidth-profile-name? string 412 | | | +--:(value) 413 | | | +--rw bandwidth-profile-type? etht-types:bandwidth-profile-type 414 | | | +--rw CIR? uint64 415 | | | +--rw CBS? uint64 416 | | | +--rw EIR? uint64 417 | | | +--rw EBS? uint64 418 | | | +--rw color-aware? boolean 419 | | | +--rw coupling-flag? boolean 420 | | +--rw egress-bandwidth-profile 421 | | +--rw (style)? 422 | | +--:(named) 423 | | | +--rw bandwidth-profile-name? string 424 | | +--:(value) 425 | | +--rw bandwidth-profile-type? etht-types:bandwidth-profile-type 426 | | +--rw CIR? uint64 427 | | +--rw CBS? uint64 428 | | +--rw EIR? uint64 429 | | +--rw EBS? uint64 430 | | +--rw color-aware? boolean 431 | | +--rw coupling-flag? boolean 432 | +--rw vlan-operations 433 | +--rw (direction)? 434 | +--:(symmetrical) 435 | | +--rw symmetrical-operation 436 | | +--rw pop-tags? uint8 437 | | +--rw push-tags 438 | | +--rw outer-tag! 439 | | | +--rw tag-type? etht-types:eth-tag-type 440 | | | +--rw vlan-value? etht-types:vlanid 441 | | | +--rw default-pcp? uint8 442 | | +--rw second-tag! 443 | | +--rw tag-type? etht-types:eth-tag-type 444 | | +--rw vlan-value? etht-types:vlanid 445 | | +--rw default-pcp? uint8 446 | +--:(asymmetrical) 447 | +--rw asymmetrical-operation 448 | +--rw ingress 449 | | +--rw pop-tags? uint8 450 | | +--rw push-tags 451 | | +--rw outer-tag! 452 | | | +--rw tag-type? etht-types:eth-tag-type 453 | | | +--rw vlan-value? etht-types:vlanid 454 | | | +--rw default-pcp? uint8 455 | | +--rw second-tag! 456 | | +--rw tag-type? etht-types:eth-tag-type 457 | | +--rw vlan-value? etht-types:vlanid 458 | | +--rw default-pcp? uint8 459 | +--rw egress 460 | +--rw pop-tags? uint8 461 | +--rw push-tags 462 | +--rw outer-tag! 463 | | +--rw tag-type? etht-types:eth-tag-type 464 | | +--rw vlan-value? etht-types:vlanid 465 | | +--rw default-pcp? uint8 466 | +--rw second-tag! 467 | +--rw tag-type? etht-types:eth-tag-type 468 | +--rw vlan-value? etht-types:vlanid 469 | +--rw default-pcp? uint8 470 +--rw etht-svc-tunnels* [tunnel-name] 471 | +--rw tunnel-name string 472 | +--rw (svc-multiplexing-tag)? 473 | | +--:(other) 474 | | +--:(none) 475 | | +--:(vlan-tag) 476 | | +--:(pw-segment) 477 | | +--rw pw-id? string 478 | | +--rw pw-name? string 479 | | +--rw transmit-label? rt-types:mpls-label 480 | | +--rw receive-label? rt-types:mpls-label 481 | | +--rw encaplate-type? identityref 482 | | +--ro oper-status? identityref 483 | | +--rw ingress-bandwidth-profile 484 | | +--rw (style)? 485 | | +--:(named) 486 | | | +--rw bandwidth-profile-name? leafref 487 | | +--:(value) 488 | | +--rw bandwidth-profile-type? etht-types:bandwidth-profile-type 489 | | +--rw CIR? uint64 490 | | +--rw CBS? uint64 491 | | +--rw EIR? uint64 492 | | +--rw EBS? uint64 493 | +--rw src-split-horizon-group? string 494 | +--rw dst-split-horizon-group? string 495 +--rw admin-status? identityref 496 +--ro state 497 +--ro operational-state? identityref 498 +--ro provisioning-state? identityref 499 +--ro creation-time? yang:date-and-time 500 +--ro last-updated-time? yang:date-and-time 502 4.2. YANG Tree for other Transport Network Client Signal Model 504 module: ietf-trans-client-service 505 +--rw client-svc 506 +--rw client-svc-instances* [client-svc-name] 507 +--rw client-svc-name string 508 +--rw client-svc-id? string 509 +--rw client-svc-descr? string 510 +--rw client-svc-customer? string 511 +--rw resilience 512 +--rw te-topology-identifier 513 | +--rw provider-id? te-types:te-global-id 514 | +--rw client-id? te-types:te-global-id 515 | +--rw topology-id? te-types:te-topology-id 516 +--rw admin-status? identityref 517 +--rw src-access-ports 518 | +--rw access-node-id? te-types:te-node-id 519 | +--rw access-ltp-id? te-types:te-tp-id 520 | +--rw client-signal? identityref 521 +--rw dst-access-ports 522 | +--rw access-node-id? te-types:te-node-id 523 | +--rw access-ltp-id? te-types:te-tp-id 524 | +--rw client-signal? identityref 525 +--rw svc-tunnels* [tunnel-name] 526 | +--rw tunnel-name string 527 +--ro operational-state? identityref 528 +--ro provisioning-state? identityref 529 +--ro creation-time? yang:date-and-time 530 +--ro last-updated-time? yang:date-and-time 532 5. YANG Code for Transport Network Client Signal 534 5.1. The ETH Service YANG Code 536 This module imports typedefs and modules from [RFC6991], [RFC8294], 537 [I-D.ietf-teas-yang-te-types]. 539 file "ietf-eth-tran-service.yang" 540 module ietf-eth-tran-service { 542 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-tran-service"; 544 prefix "ethtsvc"; 545 import ietf-yang-types { 546 prefix "yang"; 547 //reference "RFC 6991 - Common YANG Data Types"; 549 } 551 import ietf-te-types { 552 prefix "te-types"; 553 //reference "RFC XXXX - Traffic Engineering Common YANG Types"; 554 } 556 import ietf-eth-tran-types { 557 prefix "etht-types"; 558 //reference "RFC XXXX - This Document."; 559 } 561 import ietf-routing-types { 562 prefix "rt-types"; 563 //reference "RFC 8294 - Common YANG Data Types for the 564 // Routing Area"; 566 } 568 organization 569 "Internet Engineering Task Force (IETF) CCAMP WG"; 570 contact 571 " 572 WG List: 574 ID-draft editor: 575 Haomian Zheng (zhenghaomian@huawei.com); 576 Italo Busi (italo.busi@huawei.com); 577 Aihua Guo (aihuaguo@huawei.com); 578 Anton Snitser (antons@sedonasys.com); 579 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 580 Yunbin Xu (xuyunbin@ritt.cn); 581 Yang Zhao (zhaoyangyjy@chinamobile.com); 582 Xufeng Liu (Xufeng_Liu@jabil.com); 583 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 584 "; 586 description 587 "This module defines a YANG data model for describing 588 the Ethernet services. 590 Copyright (c) 2019 IETF Trust and the persons 591 identified as authors of the code. All rights reserved. 593 Redistribution and use in source and binary forms, with or 594 without modification, is permitted pursuant to, and subject 595 to the license terms contained in, the Simplified BSD License 596 set forth in Section 4.c of the IETF Trust's Legal Provisions 597 Relating to IETF Documents 598 (https://trustee.ietf.org/license-info)."; 600 revision 2019-03-11 { 601 description 602 "version -06 as an I-D"; 603 reference 604 "draft-zheng-ccamp-client-signal-yang"; 605 } 607 /* 608 * Groupings 609 */ 611 grouping vlan-classification { 612 description 613 "A grouping which represents classification on an 802.1Q VLAN tag."; 615 leaf tag-type { 616 type etht-types:eth-tag-classify; 617 description 618 "The tag type used for VLAN classification."; 619 } 620 choice individual-bundling-vlan { 621 description 622 "VLAN based classification can be individual 623 or bundling."; 625 case individual-vlan { 626 leaf vlan-value { 627 type etht-types:vlanid; 628 description 629 "VLAN ID value."; 630 } 631 } 633 case vlan-bundling { 634 leaf vlan-range { 635 type etht-types:vid-range-type; 636 description 637 "List of VLAN ID values."; 638 } 639 } 640 } 642 } 644 grouping vlan-write { 645 description 646 "A grouping which represents push/pop operations 647 of an 802.1Q VLAN tag."; 649 leaf tag-type { 650 type etht-types:eth-tag-type; 651 description 652 "The VLAN tag type to push/swap."; 653 } 654 leaf vlan-value { 655 type etht-types:vlanid; 656 description 657 "The VLAN ID value to push/swap."; 658 } 659 /* 660 * To be added: this attribute is used when: 661 * a) the ETH service has only one CoS (as in current version) 662 * b) as a default when a mapping between a given CoS value 663 * and the PCP value is not defined (in future versions) 664 */ 665 leaf default-pcp { 666 type uint8 { 667 range "0..7"; 668 } 669 description 670 "The default Priority Code Point (PCP) value to push/swap"; 671 } 672 } 674 grouping vlan-operations { 675 description 676 "A grouping which represents VLAN operations."; 678 leaf pop-tags { 679 type uint8 { 680 range "1..2"; 681 } 682 description 683 "The number of VLAN tags to pop (or swap if used in 684 conjunction with push-tags)"; 685 } 686 container push-tags { 687 description 688 "The VLAN tags to push (or swap if used in 689 conjunction with pop-tags)"; 691 container outer-tag { 692 presence 693 "Indicates existence of the outermost VLAN tag to 694 push/swap"; 696 description 697 "The outermost VLAN tag to push/swap."; 699 uses vlan-write; 700 } 701 container second-tag { 702 must 703 '../outer-tag/tag-type = "etht-types:s-vlan-tag-type" and ' + 704 'tag-type = "etht-types:c-vlan-tag-type"' 705 { 707 error-message 708 " 709 When pushing/swapping two tags, the outermost tag must 710 be specified and of S-VLAN type and the second 711 outermost tag must be of C-VLAN tag type. 712 "; 713 description 714 " 715 For IEEE 802.1Q interoperability, when pushing/swapping 716 two tags, it is required that the outermost tag exists 717 and is an S-VLAN, and the second outermost tag is a 718 C-VLAN. 719 "; 720 } 722 presence 723 "Indicates existence of a second outermost VLAN tag to 724 push/swap"; 726 description 727 "The second outermost VLAN tag to push/swap."; 729 uses vlan-write; 730 } 731 } 732 } 734 grouping named-or-value-bandwidth-profile { 735 description 736 "A grouping to configure a bandwdith profile either by 737 referencing a named bandwidth profile or by 738 configuring the values of the bandwidth profile attributes."; 740 choice style { 741 description 742 "Whether the bandwidth profile is named or defined by value"; 744 case named { 745 description 746 "Named bandwidth profile."; 747 leaf bandwidth-profile-name { 748 type "string"; 749 description 750 "Name of the bandwidth profile."; 751 } 752 } 753 case value { 754 description 755 "Bandwidth profile configured by value."; 756 uses etht-types:etht-bandwidth-profiles; 757 } 758 } 759 } 761 grouping bandwidth-profiles { 762 description 763 "A grouping which represent bandwidth profile configuration."; 765 choice direction { 766 description 767 "Whether the bandwidth profiles are symmetrical or 768 asymmetrical"; 769 case symmetrical { 770 description 771 "The same bandwidth profile is used to describe both 772 the ingress and the egress bandwidth profile."; 773 container ingress-egress-bandwidth-profile { 774 description 775 "The bandwdith profile used in both directions."; 776 uses named-or-value-bandwidth-profile; 777 } 778 } 779 case asymmetrical { 780 description 781 "Ingress and egress bandwidth profiles can be specified."; 782 container ingress-bandwidth-profile { 783 description 784 "The bandwdith profile used in the ingress direction."; 785 uses named-or-value-bandwidth-profile; 786 } 787 container egress-bandwidth-profile { 788 description 789 "The bandwdith profile used in the egress direction."; 790 uses named-or-value-bandwidth-profile; 791 } 792 } 793 } 794 } 796 grouping etht-svc-access-parameters { 797 description 798 "ETH services access parameters"; 800 leaf access-node-id { 801 type te-types:te-node-id; 802 description 803 "The identifier of the access node in 804 the ETH topology."; 805 } 806 leaf access-ltp-id { 807 type te-types:te-tp-id; 808 description 809 "The TE link termination point identifier, used 810 together with access-node-id to identify the 811 access LTP."; 812 } 813 leaf access-role { 814 type identityref { 815 base etht-types:access-role; 816 } 817 description 818 "Indicate the role of access, e.g., working or protection. "; 819 } 821 container pm-config { 822 uses pm-config-grouping; 823 description 824 "This grouping is used to set the threshold value for 825 performance monitoring. "; 826 } 828 container state { 829 config false; 830 description 831 "The state is used to monitor the status of service. "; 832 leaf operational-state { 833 type identityref { 834 base te-types:tunnel-state-type; 835 } 836 description 837 "Indicating the operational state of client signal. "; 838 } 839 leaf provisioning-state { 840 type identityref { 841 base te-types:lsp-state-type; 842 } 843 description 844 "Indicating the provisional state of client signal, 845 especially when there is a change, i.e., revise, create. "; 846 } 847 } 849 leaf performance { 850 type identityref { 851 base etht-types:performance; 852 } 853 config false; 854 description 855 "Performance Monitoring for the service. "; 856 } 858 } 860 grouping etht-svc-tunnel-parameters { 861 description 862 "ETH services tunnel parameters"; 864 leaf tunnel-name { 865 type string; 866 description 867 "TE service tunnel instance name."; 868 } 869 choice svc-multiplexing-tag { 870 description 871 "Service multiplexing is optional and flexible."; 873 case other { 874 /* 875 placeholder to support proprietary multiplexing 876 (for further discussion) 877 */ 878 } 880 case none { 881 /* no additional information is needed */ 882 } 883 case vlan-tag { 884 /* 885 No additional information is needed 886 The C-Tag or S-Tag used for service mulitplexing is defined 887 by the VLAN classification and operations configured in the 888 etht-svc-access-parameters grouping 889 */ 890 } 892 case pw-segment { 893 uses pw-segment-grouping; 894 } 895 } 897 /* 898 * Open issue: can we constraints it to be used only with mp services? 899 */ 900 leaf src-split-horizon-group { 901 type string; 902 description 903 "Identify a split horizon group at the Tunnel source TTP"; 904 } 905 leaf dst-split-horizon-group { 906 type string; 907 description 908 "Identify a split horizon group at the Tunnel destination TTP"; 909 } 910 } 912 grouping etht-svc-pm-threshold_config { 913 description 914 "Configuraiton parameters for Ethernet service PM thresholds."; 916 leaf sending-rate-high { 917 type uint64; 918 description 919 "High threshold of packet sending rate in kbps."; 920 } 921 leaf sending-rate-low { 922 type uint64; 923 description 924 "Low threshold of packet sending rate in kbps."; 925 } 926 leaf receiving-rate-high { 927 type uint64; 928 description 929 "High threshold of packet receiving rate in kbps."; 930 } 931 leaf receiving-rate-low { 932 type uint64; 933 description 934 "Low threshold of packet receiving rate in kbps."; 935 } 936 } 938 grouping etht-svc-pm-stats { 939 description 940 "Ethernet service PM statistics."; 942 leaf sending-rate-too-high { 943 type uint32; 944 description 945 "Counter that indicates the number of times the sending rate is above the high threshold"; 946 } 947 leaf sending-rate-too-low { 948 type uint32; 949 description 950 "Counter that indicates the number of times the sending rate is below the low threshold"; 951 } 952 leaf receiving-rate-too-high { 953 type uint32; 954 description 955 "Counter that indicates the number of times the receiving rate is above the high threshold"; 956 } 957 leaf receiving-rate-too-low { 958 type uint32; 959 description 960 "Counter that indicates the number of times the receiving rate is below the low threshold"; 961 } 962 } 964 grouping etht-svc-instance_config { 965 description 966 "Configuraiton parameters for Ethernet services."; 968 leaf etht-svc-name { 969 type string; 970 description 971 "Name of the ETH service."; 972 } 974 leaf etht-svc-id { 975 type string; 976 description 977 "The Identifier of the ETH service."; 978 } 979 leaf etht-svc-descr { 980 type string; 981 description 982 "Description of the ETH service."; 983 } 985 leaf etht-svc-customer { 986 type string; 987 description 988 "Customer of the ETH service."; 989 } 991 leaf etht-svc-type { 992 type etht-types:service-type; 993 description 994 "Type of ETH service (p2p, mp2mp or rmp)."; 995 /* Add default as p2p */ 996 } 998 leaf etht-svc-lifecycle { 999 type etht-types:lifecycle-status; 1000 description 1001 "Lifecycle state of ETH service."; 1002 /* Add default as installed */ 1003 } 1004 uses te-types:te-topology-identifier; 1006 uses resilience-grouping; 1008 list etht-svc-end-points { 1009 key etht-svc-end-point-name; 1010 description 1011 "The logical end point for the ETH service. "; 1012 uses etht-svc-end-point-grouping; 1013 } 1015 list etht-svc-tunnels { 1016 key tunnel-name; 1017 description 1018 "List of the TE Tunnels supporting the ETH 1019 service."; 1021 uses etht-svc-tunnel-parameters; 1022 } 1024 leaf admin-status { 1025 type identityref { 1026 base te-types:tunnel-admin-state-type; 1027 } 1028 default te-types:tunnel-admin-state-up; 1029 description "ETH service administrative state."; 1030 } 1031 } 1033 grouping etht-svc-instance_state { 1034 description 1035 "State parameters for Ethernet services."; 1037 leaf operational-state { 1038 type identityref { 1039 base te-types:tunnel-state-type; 1040 } 1041 default te-types:tunnel-state-up; 1042 description "ETH service operational state."; 1043 } 1044 leaf provisioning-state { 1045 type identityref { 1046 base te-types:lsp-state-type; 1047 } 1048 description "ETH service provisioning state."; 1049 } 1050 leaf creation-time { 1051 type yang:date-and-time; 1052 description 1053 "Time of ETH service creation."; 1054 } 1055 leaf last-updated-time { 1056 type yang:date-and-time; 1057 description 1058 "Time of ETH service last update."; 1059 } 1061 } 1063 /* 1064 * Data nodes 1065 */ 1067 container etht-svc { 1068 description 1069 "ETH services."; 1071 container globals { 1072 description 1073 "Globals Ethernet configuration data container"; 1075 list named-bandwidth-profiles { 1076 key bandwidth-profile-name; 1077 description 1078 "List of named bandwidth profiles used by 1079 Ethernet services."; 1081 leaf bandwidth-profile-name { 1082 type string; 1083 description 1084 "Name of the bandwidth profile."; 1085 } 1086 uses etht-types:etht-bandwidth-profiles; 1087 } 1088 } 1090 list etht-svc-instances { 1091 key etht-svc-name; 1092 description 1093 "The list of p2p ETH service instances"; 1095 uses etht-svc-instance_config; 1097 container state { 1098 config false; 1099 description 1100 "Ethernet Service states."; 1102 uses etht-svc-instance_state; 1103 } 1104 } 1105 } 1107 grouping resilience-grouping { 1108 description 1109 "Grouping for resilience configuration. "; 1110 container resilience { 1111 description 1112 "To configure the data plane protection parameters, 1113 currently a placeholder only, future candidate attributes 1114 include, Revert, WTR, Hold-off Timer, ..."; 1115 } 1116 } 1118 grouping etht-svc-end-point-grouping { 1119 description 1120 "Grouping for the end point configuration."; 1121 leaf etht-svc-end-point-name { 1122 type string; 1123 description 1124 "The name of the logical end point of ETH service. "; 1125 } 1127 leaf etht-svc-end-point-id { 1128 type string; 1129 description 1130 "The identifier of the logical end point of ETH service."; 1131 } 1133 leaf etht-svc-end-point-descr { 1134 type string; 1135 description 1136 "The description of the logical end point of ETH service. "; 1137 } 1139 leaf topology-role { 1140 type identityref { 1141 base etht-types:topology-role; 1142 } 1143 description 1144 "Indicating the underlay topology role, e.g., hub,spoke, any-to-any "; 1145 } 1147 container resilience { 1148 description 1149 "Placeholder for resilience configuration, for future study. "; 1150 } 1152 list etht-svc-access-points { 1153 key access-point-id; 1154 min-elements "1"; 1155 /* 1156 Open Issue: 1157 Is it possible to limit the max-elements only for p2p services? 1159 max-elements "2"; 1160 */ 1161 description 1162 "List of the ETH trasport services access point instances."; 1164 leaf access-point-id { 1165 type string; 1166 description 1167 "ID of the service access point instance"; 1168 } 1169 uses etht-svc-access-parameters; 1170 } 1171 leaf service-classification-type { 1172 type identityref { 1173 base etht-types:service-classification-type; 1174 } 1175 description 1176 "Service classification type."; 1177 } 1179 choice service-classification { 1180 description 1181 "Access classification can be port-based or 1182 VLAN based."; 1184 case port-classification { 1185 /* no additional information */ 1186 } 1188 case vlan-classification { 1189 container outer-tag { 1190 presence "The outermost VLAN tag exists"; 1191 description 1192 "Classifies traffic using the outermost VLAN tag."; 1194 uses vlan-classification; 1195 } 1196 container second-tag { 1197 must 1198 '../outer-tag/tag-type = "etht-types:classify-s-vlan" and ' + 1199 'tag-type = "etht-types:classify-c-vlan"' 1200 { 1201 error-message 1202 " 1203 When matching two tags, the outermost tag must be 1204 specified and of S-VLAN type and the second 1205 outermost tag must be of C-VLAN tag type. 1206 "; 1207 description 1208 " 1209 For IEEE 802.1Q interoperability, when matching two 1210 tags, it is required that the outermost tag exists 1211 and is an S-VLAN, and the second outermost tag is a 1212 C-VLAN. 1213 "; 1214 } 1215 presence "The second outermost VLAN tag exists"; 1217 description 1218 "Classifies traffic using the second outermost VLAN tag."; 1220 uses vlan-classification; 1221 } 1222 } 1223 } 1225 /* 1226 * Open issue: can we constraints it to be used only with mp services? 1227 */ 1228 leaf split-horizon-group { 1229 type string; 1230 description "Identify a split horizon group"; 1231 } 1233 uses bandwidth-profiles; 1235 container vlan-operations { 1236 description 1237 "Configuration of VLAN operations."; 1238 choice direction { 1239 description 1240 "Whether the VLAN operations are symmetrical or 1241 asymmetrical"; 1242 case symmetrical { 1243 container symmetrical-operation { 1244 uses vlan-operations; 1245 description 1246 "Symmetrical operations. 1247 Expressed in the ingress direction, but 1248 the reverse operation is applied to egress traffic"; 1249 } 1250 } 1251 case asymmetrical { 1252 container asymmetrical-operation { 1253 description "Asymmetrical operations"; 1254 container ingress { 1255 uses vlan-operations; 1256 description "Ingress operations"; 1257 } 1258 container egress { 1259 uses vlan-operations; 1260 description "Egress operations"; 1261 } 1262 } 1263 } 1264 } 1265 } 1267 } 1268 grouping pm-config-grouping { 1269 description 1270 "Grouping used for Performance Monitoring Configuration. "; 1271 leaf pm-enable { 1272 type boolean; 1273 description 1274 "Whether to enable the performance monitoring."; 1275 } 1277 leaf sending-rate-high { 1278 type uint64; 1279 description 1280 "The upperbound of sending rate."; 1281 } 1283 leaf sending-rate-low { 1284 type uint64; 1285 description 1286 "The lowerbound of sending rate."; 1287 } 1289 leaf receiving-rate-high { 1290 type uint64; 1291 description 1292 "The upperbound of receiving rate."; 1293 } 1295 leaf receiving-rate-low { 1296 type uint64; 1297 description 1298 "The lowerbound of receiving rate."; 1299 } 1300 } 1302 grouping pw-segment-grouping { 1303 description 1304 "Grouping used for PW configuration. "; 1305 leaf pw-id { 1306 type string; 1307 description 1308 "The Identifier information of pseudowire. "; 1309 } 1311 leaf pw-name { 1312 type string; 1313 description 1314 "The name information of pseudowire."; 1315 } 1316 leaf transmit-label { 1317 type rt-types:mpls-label; 1318 description 1319 "Transmit label information in PW. "; 1320 } 1322 leaf receive-label { 1323 type rt-types:mpls-label; 1324 description 1325 "Receive label information in PW. "; 1326 } 1328 leaf encaplate-type { 1329 type identityref { 1330 base etht-types:encaplate-type; 1331 } 1332 description 1333 "The encapsulation type, raw or tag. "; 1334 } 1336 leaf oper-status { 1337 type identityref { 1338 base te-types:tunnel-state-type; 1339 } 1340 config false; 1341 description 1342 "The operational state of the PW segment. "; 1343 } 1345 container ingress-bandwidth-profile { 1346 description 1347 "Bandwidth Profile for ingress. "; 1348 uses pw-segment-named-or-value-bandwidth-profile; 1349 } 1350 } 1352 grouping pw-segment-named-or-value-bandwidth-profile { 1353 description 1354 "A grouping to configure a bandwdith profile either by 1355 referencing a named bandwidth profile or by 1356 configuring the values of the bandwidth profile attributes."; 1357 choice style { 1358 description 1359 "Whether the bandwidth profile is named or defined by value"; 1360 case named { 1361 description 1362 "Named bandwidth profile."; 1363 leaf bandwidth-profile-name { 1364 type leafref { 1365 path "/ethtsvc:etht-svc/ethtsvc:globals/ethtsvc:named-bandwidth-profiles/ethtsvc:bandwidth-profile-name"; 1366 } 1367 description 1368 "Name of the bandwidth profile."; 1369 } 1370 } 1371 case value { 1372 description 1373 "Bandwidth profile configured by value."; 1374 uses etht-types:pw-segement-bandwidth-profile-grouping; 1375 } 1376 } 1377 } 1378 } 1379 1381 5.2. YANG Code for ETH transport type 1383 This module references a few documents including [RFC2697], 1384 [RFC2698], [RFC4115], [IEEE802.1ad], [IEEE802.1q] and [MEF10]. 1386 file "ietf-eth-tran-types.yang" 1387 module ietf-eth-tran-types { 1389 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-tran-types"; 1391 prefix "etht-types"; 1393 organization 1394 "Internet Engineering Task Force (IETF) CCAMP WG"; 1395 contact 1396 " 1397 WG List: 1399 ID-draft editor: 1400 Haomian Zheng (zhenghaomian@huawei.com); 1401 Italo Busi (italo.busi@huawei.com); 1402 Aihua Guo (aihuaguo@huawei.com); 1403 Anton Snitser (antons@sedonasys.com); 1404 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 1405 Yunbin Xu (xuyunbin@ritt.cn); 1406 Yang Zhao (zhaoyangyjy@chinamobile.com); 1407 Xufeng Liu (Xufeng_Liu@jabil.com); 1408 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 1409 "; 1411 description 1412 "This module defines the ETH transport types. 1414 Copyright (c) 2019 IETF Trust and the persons 1415 identified as authors of the code. All rights reserved. 1417 Redistribution and use in source and binary forms, with or 1418 without modification, is permitted pursuant to, and subject 1419 to the license terms contained in, the Simplified BSD License 1420 set forth in Section 4.c of the IETF Trust's Legal Provisions 1421 Relating to IETF Documents 1422 (https://trustee.ietf.org/license-info)."; 1424 revision 2019-03-11 { 1425 description 1426 "version -06 as an I-D"; 1427 reference 1428 "draft-zheng-ccamp-client-signal-yang"; 1429 } 1431 /* 1432 * Identities 1433 */ 1435 identity eth-vlan-tag-type { 1436 description 1437 "ETH VLAN tag type."; 1438 } 1440 identity c-vlan-tag-type { 1441 base eth-vlan-tag-type; 1442 description 1443 "802.1Q Customer VLAN"; 1444 } 1446 identity s-vlan-tag-type { 1447 base eth-vlan-tag-type; 1448 description 1449 "802.1Q Service VLAN (QinQ)"; 1450 } 1452 identity service-classification-type { 1453 description 1454 "Service classification."; 1455 } 1457 identity port-classification { 1458 base service-classification-type; 1459 description 1460 "Port classification."; 1461 } 1463 identity vlan-classification { 1464 base service-classification-type; 1465 description 1466 "VLAN classification."; 1467 } 1469 identity eth-vlan-tag-classify { 1470 description 1471 "VLAN tag classification."; 1472 } 1474 identity classify-c-vlan { 1475 base eth-vlan-tag-classify; 1476 description 1477 "Classify 802.1Q Customer VLAN tag. 1478 Only C-tag type is accepted"; 1479 } 1481 identity classify-s-vlan { 1482 base eth-vlan-tag-classify; 1483 description 1484 "Classify 802.1Q Service VLAN (QinQ) tag. 1485 Only S-tag type is accepted"; 1486 } 1488 identity classify-s-or-c-vlan { 1489 base eth-vlan-tag-classify; 1490 description 1491 "Classify S-VLAN or C-VLAN tag-classify. 1492 Either tag is accepted"; 1493 } 1495 identity bandwidth-profile-type { 1496 description 1497 "Bandwidth Profile Types"; 1498 } 1500 identity mef-10-bwp { 1501 base bandwidth-profile-type; 1502 description 1503 "MEF 10 Bandwidth Profile"; 1504 } 1506 identity rfc-2697-bwp { 1507 base bandwidth-profile-type; 1508 description 1509 "RFC 2697 Bandwidth Profile"; 1510 } 1512 identity rfc-2698-bwp { 1513 base bandwidth-profile-type; 1514 description 1515 "RFC 2698 Bandwidth Profile"; 1516 } 1518 identity rfc-4115-bwp { 1519 base bandwidth-profile-type; 1520 description 1521 "RFC 4115 Bandwidth Profile"; 1522 } 1524 identity service-type { 1525 description 1526 "Type of Ethernet service."; 1527 } 1529 identity p2p-svc { 1530 base service-type; 1531 description 1532 "Ethernet point-to-point service (EPL, EVPL)."; 1533 } 1535 identity rmp-svc { 1536 base service-type; 1537 description 1538 "Ethernet rooted-multitpoint service (E-TREE, EP-TREE)."; 1539 } 1541 identity mp2mp-svc { 1542 base service-type; 1543 description 1544 "Ethernet multipoint-to-multitpoint service (E-LAN, EP-LAN)."; 1545 } 1547 identity lifecycle-status { 1548 description 1549 "Lifecycle Status."; 1550 } 1552 identity installed { 1553 base lifecycle-status; 1554 description 1555 "Installed."; 1556 } 1558 identity planned { 1559 base lifecycle-status; 1560 description 1561 "Planned."; 1562 } 1564 identity pending-removal { 1565 base lifecycle-status; 1566 description 1567 "Pending Removal."; 1568 } 1570 /* 1571 * Type Definitions 1572 */ 1574 typedef eth-tag-type { 1575 type identityref { 1576 base eth-vlan-tag-type; 1577 } 1578 description 1579 "Identifies a specific ETH VLAN tag type."; 1580 } 1582 typedef eth-tag-classify { 1583 type identityref { 1584 base eth-vlan-tag-classify; 1585 } 1586 description 1587 "Identifies a specific VLAN tag classification."; 1588 } 1590 typedef vlanid { 1591 type uint16 { 1592 range "1..4094"; 1593 } 1594 description 1595 "The 12-bit VLAN-ID used in the VLAN Tag header."; 1596 } 1598 typedef vid-range-type { 1599 type string { 1600 pattern "([1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?" + 1601 "(,[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?)*)"; 1602 } 1603 description 1604 "A list of VLAN Ids, or non overlapping VLAN ranges, in 1605 ascending order, between 1 and 4094. 1606 This type is used to match an ordered list of VLAN Ids, or 1607 contiguous ranges of VLAN Ids. Valid VLAN Ids must be in the 1608 range 1 to 4094, and included in the list in non overlapping 1609 ascending order. 1611 For example: 1,10-100,50,500-1000"; 1612 } 1614 typedef bandwidth-profile-type { 1615 type identityref { 1616 base bandwidth-profile-type; 1617 } 1618 description 1619 "Identifies a specific Bandwidth Profile type."; 1620 } 1622 typedef service-type { 1623 type identityref { 1624 base service-type; 1625 } 1626 description 1627 "Identifies the type of Ethernet service."; 1628 } 1630 typedef lifecycle-status { 1631 type identityref { 1632 base lifecycle-status; 1633 } 1634 description 1635 "Identifies the lLifecycle Status ."; 1636 } 1638 /* 1639 * Grouping Definitions 1640 */ 1642 grouping etht-bandwidth-profiles { 1643 description 1644 "Bandwidth profile configuration paramters."; 1646 leaf bandwidth-profile-type { 1647 type etht-types:bandwidth-profile-type; 1648 description 1649 "The type of bandwidth profile."; 1650 } 1651 leaf CIR { 1652 type uint64; 1653 description 1654 "Committed Information Rate in Kbps"; 1655 } 1656 leaf CBS { 1657 type uint64; 1658 description 1659 "Committed Burst Size in in KBytes"; 1660 } 1661 leaf EIR { 1662 type uint64; 1663 /* Need to indicate that EIR is not supported by RFC 2697 1665 must 1666 '../bw-profile-type = "mef-10-bwp" or ' + 1667 '../bw-profile-type = "rfc-2698-bwp" or ' + 1668 '../bw-profile-type = "rfc-4115-bwp"' 1670 must 1671 '../bw-profile-type != "rfc-2697-bwp"' 1672 */ 1673 description 1674 "Excess Information Rate in Kbps 1675 In case of RFC 2698, PIR = CIR + EIR"; 1676 } 1677 leaf EBS { 1678 type uint64; 1679 description 1680 "Excess Burst Size in KBytes. 1681 In case of RFC 2698, PBS = CBS + EBS"; 1682 } 1683 leaf color-aware { 1684 type boolean; 1685 description 1686 "Indicates weather the color-mode is color-aware or color-blind."; 1687 } 1688 leaf coupling-flag { 1689 type boolean; 1690 /* Need to indicate that Coupling Flag is defined only for MEF 10 1692 must 1693 '../bw-profile-type = "mef-10-bwp"' 1694 */ 1695 description 1696 "Coupling Flag."; 1697 } 1698 } 1699 identity topology-role { 1700 description 1701 "The rold of underlay topology, e.g., hub, spoke, any-to-any. "; 1702 } 1704 identity resilience { 1705 description 1706 "Placeholder for resilience information in data plane, for future study. "; 1707 } 1709 identity access-role { 1710 description 1711 "Indicating whether the access is a working or protection access."; 1712 } 1714 identity performance { 1715 description 1716 "Placeholder for performace information, for future study."; 1717 } 1719 identity encaplate-type { 1720 description 1721 "Indicating how the service is encapsulated (to PW), e.g, raw or tag. "; 1722 } 1724 grouping pw-segement-bandwidth-profile-grouping { 1725 description 1726 "bandwidth profile grouping for PW segment. "; 1727 leaf bandwidth-profile-type { 1728 type etht-types:bandwidth-profile-type; 1729 description 1730 "The type of bandwidth profile."; 1731 } 1732 leaf CIR { 1733 type uint64; 1734 description 1735 "Committed Information Rate in Kbps"; 1736 } 1737 leaf CBS { 1738 type uint64; 1739 description 1740 "Committed Burst Size in in KBytes"; 1741 } 1742 leaf EIR { 1743 type uint64; 1744 /* Need to indicate that EIR is not supported by RFC 2697 1746 must 1747 '../bw-profile-type = "mef-10-bwp" or ' + 1748 '../bw-profile-type = "rfc-2698-bwp" or ' + 1749 '../bw-profile-type = "rfc-4115-bwp"' 1751 must 1752 '../bw-profile-type != "rfc-2697-bwp"' 1753 */ 1754 description 1755 "Excess Information Rate in Kbps 1756 In case of RFC 2698, PIR = CIR + EIR"; 1757 } 1758 leaf EBS { 1759 type uint64; 1760 description 1761 "Excess Burst Size in KBytes. 1762 In case of RFC 2698, PBS = CBS + EBS"; 1763 } 1764 } 1765 grouping eth-bandwidth { 1766 description 1767 "Available bandwith for ethernet."; 1768 leaf eth-bandwidth { 1769 type uint64{ 1770 range "0..10000000000"; 1771 } 1772 units "Kbps"; 1773 description 1774 "Available bandwith value expressed in kilobits per second"; 1775 } 1776 } 1778 grouping eth-label-restriction { 1779 description 1780 "Label Restriction for ethernet."; 1781 leaf tag-type { 1782 type etht-types:eth-tag-type; 1783 description "VLAN tag type."; 1784 } 1785 leaf priority { 1786 type uint8; 1787 description "priority."; 1788 } 1789 } 1791 grouping eth-label { 1792 description 1793 "Label for ethernet."; 1794 leaf vlanid { 1795 type etht-types:vlanid; 1796 description 1797 "VLAN tag id."; 1798 } 1799 } 1801 grouping eth-label-step { 1802 description "Label step for Ethernet VLAN"; 1803 leaf eth-step { 1804 type uint16 { 1805 range "1..4095"; 1806 } 1807 default 1; 1808 description 1809 "Label step which represent possible increments for 1810 an Ethernet VLAN tag."; 1811 reference 1812 "IEEE 802.1ad: Provider Bridges."; 1813 } 1814 } 1815 } 1817 1819 5.3. Other Transport Network client signal YANG Code 1821 This module imports typedefs and modules from [RFC6991], 1822 [I-D.ietf-ccamp-otn-tunnel-model], [I-D.ietf-teas-yang-te-types]. 1824 file "ietf-trans-client-service.yang" 1825 module ietf-trans-client-service { 1826 /* TODO: FIXME */ 1827 //yang-version 1.1; 1829 namespace "urn:ietf:params:xml:ns:yang:ietf-trans-client-service"; 1830 prefix "clntsvc"; 1832 import ietf-te-types { 1833 prefix "te-types"; 1834 //reference "RFC XXXX - Traffic Engineering Common YANG Types"; 1835 } 1837 import ietf-otn-types { 1838 prefix "otn-types"; 1839 //reference "RFC XXXX - OTN Tunnel YANG Model"; 1840 } 1841 import ietf-yang-types { 1842 prefix "yang"; 1843 //reference "RFC 6991 - Common YANG Data Types"; 1844 } 1846 organization 1847 "Internet Engineering Task Force (IETF) CCAMP WG"; 1848 contact 1849 " 1850 ID-draft editor: 1851 Haomian Zheng (zhenghaomian@huawei.com); 1852 Aihua Guo (aihuaguo@huawei.com); 1853 Italo Busi (italo.busi@huawei.com); 1854 Anton Snitser (antons@sedonasys.com); 1855 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 1856 Yunbin Xu (xuyunbin@ritt.cn); 1857 Yang Zhao (zhaoyangyjy@chinamobile.com); 1858 Xufeng Liu (Xufeng_Liu@jabil.com); 1859 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 1860 "; 1862 description 1863 "This module defines a YANG data model for describing 1864 transport client services. 1866 Copyright (c) 2019 IETF Trust and the persons 1867 identified as authors of the code. All rights reserved. 1869 Redistribution and use in source and binary forms, with or 1870 without modification, is permitted pursuant to, and subject 1871 to the license terms contained in, the Simplified BSD License 1872 set forth in Section 4.c of the IETF Trust's Legal Provisions 1873 Relating to IETF Documents 1874 (https://trustee.ietf.org/license-info)."; 1876 revision 2019-03-11 { 1877 description 1878 "version -06 as an I-D"; 1879 reference 1880 "draft-zheng-ccamp-client-signal-yang"; 1881 } 1883 /* 1884 * Groupings 1885 */ 1886 grouping client-svc-access-parameters { 1887 description 1888 "Transport client services access parameters"; 1890 leaf access-node-id { 1891 type te-types:te-node-id; 1892 description 1893 "The identifier of the access node in the underlying 1894 transport topology."; 1895 } 1897 leaf access-ltp-id { 1898 type te-types:te-tp-id; 1899 description 1900 "The TE link termination point identifier, used together with 1901 access-node-id to identify the access LTP."; 1902 } 1904 leaf client-signal { 1905 type identityref { 1906 base otn-types:client-signal; 1907 } 1908 description 1909 "Identifiies the client signal type associated with this port"; 1910 } 1911 } 1913 grouping client-svc-tunnel-parameters { 1914 description 1915 "Transport client services tunnel parameters"; 1917 leaf tunnel-name { 1918 type string; 1919 description 1920 "TE service tunnel instance name."; 1921 } 1922 } 1924 grouping client-svc-instance_config { 1925 description 1926 "Configuraiton parameters for client services."; 1927 leaf client-svc-name { 1928 type string; 1929 description 1930 "Identifier of the p2p transport client service."; 1931 } 1933 leaf client-svc-id { 1934 type string; 1935 description 1936 "Name of the p2p transport client service."; 1937 } 1938 leaf client-svc-descr { 1939 type string; 1940 description 1941 "Description of the transport client service."; 1942 } 1944 leaf client-svc-customer { 1945 type string; 1946 description 1947 "Customer of the transport client service."; 1948 } 1950 container resilience { 1951 description ""; 1952 } 1954 uses te-types:te-topology-identifier; 1956 leaf admin-status { 1957 type identityref { 1958 base te-types:tunnel-admin-state-type; 1959 } 1960 default te-types:tunnel-admin-state-up; 1961 description "Client service administrative state."; 1962 } 1964 container src-access-ports { 1965 description 1966 "Source access port of a client service."; 1967 uses client-svc-access-parameters; 1968 } 1970 container dst-access-ports { 1971 description 1972 "Destination access port of a client service."; 1973 uses client-svc-access-parameters; 1974 } 1976 list svc-tunnels { 1977 key tunnel-name; 1978 description 1979 "List of the TE Tunnels supporting the client service."; 1980 uses client-svc-tunnel-parameters; 1981 } 1982 } 1984 grouping client-svc-instance_state { 1985 description 1986 "State parameters for client services."; 1987 leaf operational-state { 1988 type identityref { 1989 base te-types:tunnel-state-type; 1990 } 1991 config false; 1992 description "Client service operational state."; 1993 } 1994 leaf provisioning-state { 1995 type identityref { 1996 base te-types:lsp-state-type; 1997 } 1998 config false; 1999 description "Client service provisioning state."; 2000 } 2001 leaf creation-time { 2002 type yang:date-and-time; 2003 config false; 2004 description "The time of the service be created."; 2005 } 2006 leaf last-updated-time { 2007 type yang:date-and-time; 2008 config false; 2009 description "The time of the service's latest update."; 2010 } 2011 } 2013 /* 2014 * Data nodes 2015 */ 2017 container client-svc { 2018 description 2019 "Transport client services."; 2021 list client-svc-instances { 2022 key client-svc-name; 2023 description 2024 "The list of p2p transport client service instances"; 2026 uses client-svc-instance_config; 2027 uses client-svc-instance_state; 2028 } 2029 } 2030 } 2032 2033 6. Considerations and Open Issue 2035 Editor Notes: This section is used to note temporary discussion/ 2036 conclusion that to be fixed in the future version, and will be 2037 removed before publication. We currently categorize all the client 2038 signal types into transparent and non-transparent, with separate 2039 models. There was consensus that no common model is needed for these 2040 two categories. Further Alignment with RFC8407 would be required 2041 before publication. 2043 7. IANA Considerations 2045 It is proposed that IANA should assign new URIs from the "IETF XML 2046 Registry" [RFC3688] as follows: 2048 URI: urn:ietf:params:xml:ns:yang:ietf-eth-tran-service 2049 Registrant Contact: The IESG 2050 XML: N/A; the requested URI is an XML namespace. 2052 URI: urn:ietf:params:xml:ns:yang:ietf-trans-client-service 2053 Registrant Contact: The IESG 2054 XML: N/A; the requested URI is an XML namespace. 2056 URI: urn:ietf:params:xml:ns:yang:ietf-eth-tran-types 2057 Registrant Contact: The IESG 2058 XML: N/A; the requested URI is an XML namespace. 2060 This document registers following YANG modules in the YANG Module 2061 Names registry [RFC7950]. 2063 name: ietf-eth-tran-service 2064 namespace: urn:ietf:params:xml:ns:yang:ietf-eth-tran-service 2065 prefix: ethtsvc 2066 reference: RFC XXXX: A YANG Data Model for Transport Network Client Signals 2068 name: ietf-eth-tran-types 2069 namespace: urn:ietf:params:xml:ns:yang:ietf-eth-tran-types 2070 prefix: etht-types 2071 reference: RFC XXXX: A YANG Data Model for Transport Network Client Signals 2073 name: ietf-trans-client-service 2074 namespace: urn:ietf:params:xml:ns:yang:ietf-trans-client-service 2075 prefix: clntsvc 2076 reference: RFC XXXX: A YANG Data Model for Transport Network Client Signals 2078 8. Manageability Considerations 2080 TBD. 2082 9. Security Considerations 2084 The data following the model defined in this document is exchanged 2085 via, for example, the interface between an orchestrator and a network 2086 domain controller. 2088 The YANG module defined in this document can be accessed via the 2089 RESTCONF protocol defined in [RFC8040], or maybe via the NETCONF 2090 protocol [RFC6241]. 2092 There are a number of data nodes defined in the YANG module which are 2093 writable/creatable/deletable (i.e., config true, which is the 2094 default). These data nodes may be considered sensitive or vulnerable 2095 in some network environments. Write operations (e.g., POST) to these 2096 data nodes without proper protection can have a negative effect on 2097 network operations. 2099 10. Acknowledgements 2101 We would like to thank Igor Bryskin and Daniel King for their 2102 comments and discussions. 2104 11. Contributors 2106 Yanlei Zheng 2107 China Unicom 2108 Email: zhengyl@dimpt.com 2110 Zhe Liu 2111 Huawei Technologies, 2112 Email: liuzhe123@huawei.com 2114 Sergio Belotti 2115 Nokia, 2116 Email: sergio.belotti@nokia.com 2118 Yingxi Yao 2119 Shanghai Bell, 2120 yingxi.yao@nokia-sbell.com 2122 12. References 2124 12.1. Normative References 2126 [I-D.ietf-ccamp-l1csm-yang] 2127 Fioccola, G., Lee, K., Lee, Y., Dhody, D., and D. 2128 Ceccarelli, "A YANG Data Model for L1 Connectivity Service 2129 Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-09 (work in 2130 progress), March 2019. 2132 [I-D.ietf-ccamp-otn-topo-yang] 2133 Zheng, H., Guo, A., Busi, I., Sharma, A., Liu, X., 2134 Belotti, S., Xu, Y., Wang, L., and O. Dios, "A YANG Data 2135 Model for Optical Transport Network Topology", draft-ietf- 2136 ccamp-otn-topo-yang-06 (work in progress), February 2019. 2138 [I-D.ietf-ccamp-otn-tunnel-model] 2139 Zheng, H., Guo, A., Busi, I., Sharma, A., Rao, R., 2140 Belotti, S., Lopezalvarez, V., Li, Y., and Y. Xu, "OTN 2141 Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel-model-06 2142 (work in progress), February 2019. 2144 [I-D.ietf-teas-yang-te-topo] 2145 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 2146 O. Dios, "YANG Data Model for Traffic Engineering (TE) 2147 Topologies", draft-ietf-teas-yang-te-topo-19 (work in 2148 progress), February 2019. 2150 [I-D.ietf-teas-yang-te-types] 2151 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 2152 "Traffic Engineering Common YANG Types", draft-ietf-teas- 2153 yang-te-types-06 (work in progress), February 2019. 2155 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2156 and A. Bierman, Ed., "Network Configuration Protocol 2157 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2158 . 2160 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2161 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2162 . 2164 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 2165 and K. Pithewan, "GMPLS Signaling Extensions for Control 2166 of Evolving G.709 Optical Transport Networks", RFC 7139, 2167 DOI 10.17487/RFC7139, March 2014, 2168 . 2170 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2171 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2172 . 2174 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2175 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2176 . 2178 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 2179 "Common YANG Data Types for the Routing Area", RFC 8294, 2180 DOI 10.17487/RFC8294, December 2017, 2181 . 2183 12.2. Informative References 2185 [IEEE802.1ad] 2186 IEEE, 802., "IEEE 802.1ad - Provider Bridges.", IEEE 2187 802.1ad , May 2006. 2189 [IEEE802.1q] 2190 IEEE, 802., "IEEE 802.1q - Virtual Bridged Local Area 2191 Networks", IEEE 802.1q , June 2005. 2193 [MEF10] MEF, 10., "Ethernet Services Attributes Phase 1", MEF10 , 2194 November 2004. 2196 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 2197 Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, 2198 . 2200 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 2201 Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, 2202 . 2204 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2205 DOI 10.17487/RFC3688, January 2004, 2206 . 2208 [RFC4115] Aboul-Magd, O. and S. Rabie, "A Differentiated Service 2209 Two-Rate, Three-Color Marker with Efficient Handling of 2210 in-Profile Traffic", RFC 4115, DOI 10.17487/RFC4115, July 2211 2005, . 2213 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 2214 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 2215 DOI 10.17487/RFC8299, January 2018, 2216 . 2218 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2219 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2220 . 2222 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2223 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2224 . 2226 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2227 and R. Wilton, "Network Management Datastore Architecture 2228 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2229 . 2231 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 2232 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 2233 DOI 10.17487/RFC8453, August 2018, 2234 . 2236 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2237 Data Model for Layer 2 Virtual Private Network (L2VPN) 2238 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2239 2018, . 2241 Authors' Addresses 2243 Haomian Zheng 2244 Huawei Technologies 2245 H1-1-A043S Huawei Industrial Base, Songshanhu 2246 Dongguan, Guangdong 2247 P.R.China 2249 Email: zhenghaomian@huawei.com 2251 Aihua Guo 2252 Huawei Technologies 2254 Email: aihuaguo@huawei.com 2256 Italo Busi 2257 Huawei Technologies 2259 Email: Italo.Busi@huawei.com 2260 Anton Snitser 2261 Sedona 2263 Email: antons@sedonasys.com 2265 Francesco Lazzeri 2266 Ericsson 2268 Email: francesco.lazzeri@ericsson.com 2270 Yunbin Xu 2271 CAICT 2273 Email: xuyunbin@ritt.cn 2275 Yang Zhao 2276 China Mobile 2278 Email: zhaoyangyjy@chinamobile.com 2280 Xufeng Liu 2281 Volta Networks 2283 Email: xufeng.liu.ietf@gmail.com 2285 Giuseppe Fioccola 2286 Huawei Technologies 2288 Email: giuseppe.fioccola@huawei.com