idnits 2.17.1 draft-zheng-ccamp-client-signal-yang-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 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 332 has weird spacing: '...le-name str...' == Line 360 has weird spacing: '...oint-id str...' == Line 534 has weird spacing: '...el-name str...' == Line 922 has weird spacing: '...rouping etht-...' == Line 948 has weird spacing: '...rouping etht-...' == (4 more instances...) -- The document date (March 27, 2019) is 1829 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 2169, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-ccamp-l1csm-yang-09 == Outdated reference: A later version (-17) 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 28, 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 27, 2019 20 A YANG Data Model for Transport Network Client Signals 21 draft-zheng-ccamp-client-signal-yang-07 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 28, 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 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 . . . . . . . . . . . . . . . . . . . . . . 46 93 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 46 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 95 12.1. Normative References . . . . . . . . . . . . . . . . . . 46 96 12.2. Informative References . . . . . . . . . . . . . . . . . 48 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 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 network 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 modules defined in this document conforms to the Network 131 Management Datastore Architecture (NMDA) defined in [RFC8342]. 133 1.2. Prefixs in Model Names 135 In this document, names of data nodes and other data model objects 136 are prefixed using the standard prefix associated with the 137 corresponding YANG imported modules, including [RFC6991], [RFC8294] 138 and [I-D.ietf-ccamp-otn-tunnel-model], which are shown as follow. 140 +------------+---------------------------+----------------------+ 141 | Prefix | YANG module | Reference | 142 +------------+---------------------------+----------------------+ 143 | yang | ietf-yang-types | [RFC6991] | 144 | te-types | ietf-te-types |[ietf-teas-yang-te-types]| 145 | rt-types | ietf-routing-types | [RFC8294] | 146 | otn-types | ietf-otn-types |[ietf-ccamp-otn-tunnel-model]| 147 | etht-types | ietf-eth-tran-types | This Document | 148 | clntsvc | ietf-trans-client-service | This Document | 149 | ethtsvc | ietf-eth-tran-service | This Document | 150 +------------+---------------------------+----------------------+ 152 2. Terminology and Notations 154 A simplified graphical representation of the data model is used in 155 this document. The meaning of the symbols in the YANG data tree 156 presented later in this document is defined in [RFC8340]. They are 157 provided below for reference. 159 o Brackets "[" and "]" enclose list keys. 161 o Abbreviations before data node names: "rw" means configuration 162 (read-write) and "ro" state data (read-only). 164 o Symbols after data node names: "?" means an optional node, "!" 165 means a presence container, and "*" denotes a list and leaf-list. 167 o Parentheses enclose choice and case nodes, and case nodes are also 168 marked with a colon (":"). 170 o Ellipsis ("...") stands for contents of subtrees that are not 171 shown. 173 3. Transport Network Client Signal Overview 175 3.1. Overview of Service Request and Network Configuration Scenarios 177 A global view of a multi-domain service can be described as the 178 Figure 1 . The customer is usually responsible to configure the CE 179 nodes and to request to the provider the service intent, from the CE 180 nodes perspective, while the provider is responsible to configure the 181 whole network (including the PE nodes) to support the customer 182 service intent. Generally speaking, the network configurations 183 required to support a customer service can be split into two 184 different groups: CE-PE and PE-PE. The CE-PE configuration deals 185 with the client layer one-hop access link, while PE-PE configuration 186 deals with the server layer tunnel. In Figure 1 we mark the 187 intermediate nodes as 'P', which has same switching capability of PE 188 but just not the 'end-point'. In this example, the link P-P and PE-P 189 are a server-layer intra-domain or inter-domain link. 191 +----+ +----+ 192 | CE | | CE | 193 +--+-+ +--+-+ 194 | | 195 | ------------- -------------| 196 //|/ \\\\ ///// |\\\\ 197 // | \\ // | \\ 198 | +--+-+ +---+ +---+ | | +---+ +---+ +--+-+ | 199 | | PE +----+ P +--+ P +---+-----+--+ P +---+ P +---+ PE | | 200 | +----+ +---+ +---+ | | +---+ +---+ +----+ | 201 \\ // \\ // 202 \\\\ //// \\\\\ ///// 203 ------------- ------------- 204 Domain 1 Domain 2 206 Figure 1: Global view of Client Service with the Network Provider 208 According to the responsibilities of each controller in [RFC8453], 209 the controllers have different views of the service request and 210 network configuration. The duty of CNC is to give the MDSC a 211 description of the customer service intent: candidate YANG models 212 include L1CSM [I-D.ietf-ccamp-l1csm-yang], L2SM [RFC8466] and L3SM 213 [RFC8299], which are classified as customer service models, according 214 to [RFC8309]. These models provide necessary attributes to describe 215 the customer service intent from the customer/CE perspective, and do 216 not provide any specific network configuration. These models also 217 implies that the customer service description can be considered in a 218 separate manner rather than integratig with network configurations, 219 which also enable the controllers to abstract/virtualize the network 220 resource to make them visible to the customer and also easier to 221 manage. In other words, the network knowledge is not necessary at 222 CNC and CMI, which is seen in an abstracted form as shown in 223 Figure 2. 225 /---------\ 226 /// \\\ 227 +----+ | | +----+ 228 | CE |--------------+ NETWORK +----------------| CE | 229 +----+ | | +----+ 230 \\\ /// 231 \---------/ 233 Figure 2: CNC Viewpoint on the Client Service 235 The functionalities of MDSC have been described in [RFC8453], which 236 include the customer mapping/translation and multi-domain 237 coordination. By receiving the request from CNC, MDSC need to 238 understand what network configuration can support the customer 239 service intent and turn to the corresponding PNCs for configuration. 240 The service request is therefore decomposed by MDSC into a few 241 network configurations and forwarded to one or multiple PNCs 242 respectively in single-domain and multi-domain scenario. In general, 243 the MDSC has the view of both PE and CE nodes and of some abstract 244 information regarding the P nodes, as shown in Figure 3. It is worth 245 noting that this MDSC view is different with Figure 1 at the intra- 246 domain link. Usually these details are hidden, for scalability 247 purposes, and therefore the MDSC has only an abstract view of each 248 domain internal topology. 250 ------ ----- 251 //// \\\\ ///- -\\\ 252 // \\ // \\ 253 +----+ | +----+ +---+ | |+---+ +----+ | +----+ 254 | CE |-----+-| PE |-----| P |-+--+| P |-----| PE |-+-----| CE | 255 +----+ | +----+ +---+ | |+---+ +----+ | +----+ 256 \\ // \\ // 257 \\\\ //// \\\- -/// 258 ------ ----- 259 Domain 1 Domain 2 261 Figure 3: MDSC view of both Client Service and Network Abstraction 263 PNC is the controller that configure the physical devices, based on 264 the network configuration received from the MDSC. Each PNC has the 265 detailed view of its own domain, the example of view from PNC in 266 domain 1 is shown in Figure 4. The PNC has all the detailed topology 267 information on PE and P nodes and on the intra-domain links. The PNC 268 configures the tunnel/tunnel segment within its domain based on the 269 network configuration provided by the MDSC. The PNC also configures 270 the network part of the CE-PE access links as well as the mapping of 271 the client-layer traffic and the server-layer tunnels, based on the 272 network configuration provided by the MDSC. The interaction between 273 PNC and MDSC for the client-layer network configuration is 274 accomplished by the models defined in this draft. 276 | | | 277 | ------------- | -------------| 278 //|/ \\\\ | ///// |\\\\ 279 // | \\ | // | \\ 280 | +--+-+ +---+ +---+ | | | +---+ +---+ +--+-+ | 281 | | PE +----+ P +--+ P +---+--+--+--+ P +---+ P +---+ PE | | 282 | +----+ +---+ +---+ | | | +---+ +---+ +----+ | 283 \\ // | \\ // 284 \\\\ //// | \\\\\ ///// 285 ------------- | ------------- 286 PNC View in Domain 1 | PNC View in Domain 2 287 | 289 Figure 4: PNC view on Network Configuration 291 3.2. Applicability of Proposed Model 293 Existing TE and technology-specific models, such as topology models 294 and tunnel models, support the network configuration among PEs and 295 Ps. The customer service models, such as L1CSM, L2SM and L3SM, focus 296 on describing the attributes among CEs. However, there is a missing 297 piece on how to configure the CE-PE session. The models defined in 298 this document provide the configuration on CE-PE when the provider 299 server-layer network is TE-based technology. 301 In the example of OTN as the server-layer transport network, a full 302 list of G-PID was summarized in [RFC7139], which can be divided into 303 a few categories. The G-PID signals can be categorized into 304 transparent and non-transparent. Examples of transparent signals may 305 include Ethernetphysical interfaces, FC, STM-n and so on. In this 306 approach the OTN devices is not aware of the client signal type, and 307 this information is only necessary among the controllers. Once the 308 OTN tunnel is set up, there is no switching requested on the client 309 layer, and therefore only signal mapping is needed, without a client 310 tunnel set up. The models that supporting the configuration of 311 transparent signals are defined in Section 4.2. The other category 312 would be non-transparent, such as Carrier Ethernet and MPLS-TP, with 313 a switching request on the client layer. Once the OTN tunnel is set 314 up, a corresponding tunnel in the client layer has to be set up to 315 carry services. The models that supporting the configuration of 316 transparent signals are defined in Section 4.1. 318 It is also worth noting that some client signal can be carried over 319 multiple types of networks. For example, the Ethernet services can 320 be carried over either OTN or Ethernet TE tunnels (over optical or 321 microwave networks). The model specified in this document allows the 322 support from networks with different technologies. 324 4. YANG Model for Transport Network Client Signal 326 4.1. YANG Tree for Ethernet Service 328 module: ietf-eth-tran-service 329 +--rw etht-svc 330 +--rw globals 331 | +--rw named-bandwidth-profiles* [bandwidth-profile-name] 332 | +--rw bandwidth-profile-name string 333 | +--rw bandwidth-profile-type? etht-types:bandwidth- 334 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-types:te-global-id 350 | +--rw client-id? te-types:te-global-id 351 | +--rw topology-id? te-types: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? 401 etht-types:bandwidth-profile-type 402 | | | +--rw CIR? uint64 403 | | | +--rw CBS? uint64 404 | | | +--rw EIR? uint64 405 | | | +--rw EBS? uint64 406 | | | +--rw color-aware? boolean 407 | | | +--rw coupling-flag? boolean 408 | | +--:(asymmetrical) 409 | | +--rw ingress-bandwidth-profile 410 | | | +--rw (style)? 411 | | | +--:(named) 412 | | | | +--rw bandwidth-profile-name? string 413 | | | +--:(value) 414 | | | +--rw bandwidth-profile-type? 415 etht-types:bandwidth-profile-type 416 | | | +--rw CIR? uint64 417 | | | +--rw CBS? uint64 418 | | | +--rw EIR? uint64 419 | | | +--rw EBS? uint64 420 | | | +--rw color-aware? boolean 421 | | | +--rw coupling-flag? boolean 422 | | +--rw egress-bandwidth-profile 423 | | +--rw (style)? 424 | | +--:(named) 425 | | | +--rw bandwidth-profile-name? string 426 | | +--:(value) 427 | | +--rw bandwidth-profile-type? 428 etht-types:bandwidth-profile-type 429 | | +--rw CIR? uint64 430 | | +--rw CBS? uint64 431 | | +--rw EIR? uint64 432 | | +--rw EBS? uint64 433 | | +--rw color-aware? boolean 434 | | +--rw coupling-flag? boolean 435 | +--rw vlan-operations 436 | +--rw (direction)? 437 | +--:(symmetrical) 438 | | +--rw symmetrical-operation 439 | | +--rw pop-tags? uint8 440 | | +--rw push-tags 441 | | +--rw outer-tag! 442 | | | +--rw tag-type? etht-types:eth-tag-type 443 | | | +--rw vlan-value? etht-types:vlanid 444 | | | +--rw default-pcp? uint8 445 | | +--rw second-tag! 446 | | +--rw tag-type? etht-types:eth-tag-type 447 | | +--rw vlan-value? etht-types:vlanid 448 | | +--rw default-pcp? uint8 449 | +--:(asymmetrical) 450 | +--rw asymmetrical-operation 451 | +--rw ingress 452 | | +--rw pop-tags? uint8 453 | | +--rw push-tags 454 | | +--rw outer-tag! 455 | | | +--rw tag-type? etht-types:eth-tag 456 -type 457 | | | +--rw vlan-value? etht-types:vlanid 458 | | | +--rw default-pcp? uint8 459 | | +--rw second-tag! 460 | | +--rw tag-type? etht-types:eth-tag 461 -type 462 | | +--rw vlan-value? etht-types:vlanid 463 | | +--rw default-pcp? uint8 464 | +--rw egress 465 | +--rw pop-tags? uint8 466 | +--rw push-tags 467 | +--rw outer-tag! 468 | | +--rw tag-type? etht-types:eth-tag 469 -type 470 | | +--rw vlan-value? etht-types:vlanid 471 | | +--rw default-pcp? uint8 472 | +--rw second-tag! 473 | +--rw tag-type? etht-types:eth-tag 474 -type 475 | +--rw vlan-value? etht-types:vlanid 476 | +--rw default-pcp? uint8 477 +--rw etht-svc-tunnels* [tunnel-name] 478 | +--rw tunnel-name string 479 | +--rw (svc-multiplexing-tag)? 480 | | +--:(other) 481 | | +--:(none) 482 | | +--:(vlan-tag) 483 | | +--:(pw-segment) 484 | | +--rw pw-id? string 485 | | +--rw pw-name? string 486 | | +--rw transmit-label? rt-types:mpls-label 487 | | +--rw receive-label? rt-types:mpls-label 488 | | +--rw encaplate-type? identityref 489 | | +--ro oper-status? identityref 490 | | +--rw ingress-bandwidth-profile 491 | | +--rw (style)? 492 | | +--:(named) 493 | | | +--rw bandwidth-profile-name? leafref 494 | | +--:(value) 495 | | +--rw bandwidth-profile-type? 496 etht-types:bandwidth-profile-type 497 | | +--rw CIR? uint64 498 | | +--rw CBS? uint64 499 | | +--rw EIR? uint64 500 | | +--rw EBS? uint64 501 | +--rw src-split-horizon-group? string 502 | +--rw dst-split-horizon-group? string 503 +--rw admin-status? identityref 504 +--ro state 505 +--ro operational-state? identityref 506 +--ro provisioning-state? identityref 507 +--ro creation-time? yang:date-and-time 508 +--ro last-updated-time? yang:date-and-time 510 4.2. YANG Tree for other Transport Network Client Signal Model 512 module: ietf-trans-client-service 513 +--rw client-svc 514 +--rw client-svc-instances* [client-svc-name] 515 +--rw client-svc-name string 516 +--rw client-svc-id? string 517 +--rw client-svc-descr? string 518 +--rw client-svc-customer? string 519 +--rw resilience 520 +--rw te-topology-identifier 521 | +--rw provider-id? te-types:te-global-id 522 | +--rw client-id? te-types:te-global-id 523 | +--rw topology-id? te-types:te-topology-id 524 +--rw admin-status? identityref 525 +--rw src-access-ports 526 | +--rw access-node-id? te-types:te-node-id 527 | +--rw access-ltp-id? te-types:te-tp-id 528 | +--rw client-signal? identityref 529 +--rw dst-access-ports 530 | +--rw access-node-id? te-types:te-node-id 531 | +--rw access-ltp-id? te-types:te-tp-id 532 | +--rw client-signal? identityref 533 +--rw svc-tunnels* [tunnel-name] 534 | +--rw tunnel-name string 535 +--ro operational-state? identityref 536 +--ro provisioning-state? identityref 537 +--ro creation-time? yang:date-and-time 538 +--ro last-updated-time? yang:date-and-time 540 5. YANG Code for Transport Network Client Signal 542 5.1. The ETH Service YANG Code 544 This module imports typedefs and modules from [RFC6991], [RFC8294], 545 [I-D.ietf-teas-yang-te-types]. 547 file "ietf-eth-tran-service@2019-03-27.yang" 548 module ietf-eth-tran-service { 549 yang-version 1.1; 550 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-tran-service"; 552 prefix "ethtsvc"; 554 import ietf-yang-types { 555 prefix "yang"; 556 reference "RFC 6991 - Common YANG Data Types"; 558 } 560 import ietf-te-types { 561 prefix "te-types"; 562 reference "RFC YYYY - Traffic Engineering Common YANG Types"; 563 } 565 import ietf-eth-tran-types { 566 prefix "etht-types"; 567 reference "RFC XXXX - A YANG Data Model for Transport 568 Network Client Signals"; 569 } 571 import ietf-routing-types { 572 prefix "rt-types"; 573 reference "RFC 8294 - Common YANG Data Types for the 574 Routing Area"; 576 } 578 organization 579 "Internet Engineering Task Force (IETF) CCAMP WG"; 580 contact 581 " 582 WG List: 584 ID-draft editor: 585 Haomian Zheng (zhenghaomian@huawei.com); 586 Italo Busi (italo.busi@huawei.com); 587 Aihua Guo (aihuaguo@huawei.com); 588 Anton Snitser (antons@sedonasys.com); 589 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 590 Yunbin Xu (xuyunbin@ritt.cn); 591 Yang Zhao (zhaoyangyjy@chinamobile.com); 592 Xufeng Liu (Xufeng_Liu@jabil.com); 593 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 594 "; 596 description 597 "This module defines a YANG data model for describing 598 the Ethernet services. 600 Copyright (c) 2019 IETF Trust and the persons 601 identified as authors of the code. All rights reserved. 603 Redistribution and use in source and binary forms, with or 604 without modification, is permitted pursuant to, and subject 605 to the license terms contained in, the Simplified BSD License 606 set forth in Section 4.c of the IETF Trust's Legal Provisions 607 Relating to IETF Documents 608 (https://trustee.ietf.org/license-info)."; 610 revision 2019-03-27 { 611 description 612 "version -07 as an I-D"; 613 reference 614 "draft-zheng-ccamp-client-signal-yang"; 615 } 617 /* 618 * Groupings 619 */ 621 grouping vlan-classification { 622 description 623 "A grouping represents classification on an 802.1Q VLAN tag."; 625 leaf tag-type { 626 type etht-types:eth-tag-classify; 627 description 628 "The tag type used for VLAN classification."; 629 } 630 choice individual-bundling-vlan { 631 description 632 "VLAN based classification can be individual 633 or bundling."; 635 case individual-vlan { 636 leaf vlan-value { 637 type etht-types:vlanid; 638 description 639 "VLAN ID value."; 640 } 641 } 643 case vlan-bundling { 644 leaf vlan-range { 645 type etht-types:vid-range-type; 646 description 647 "List of VLAN ID values."; 648 } 649 } 650 } 651 } 653 grouping vlan-write { 654 description 655 "A grouping which represents push/pop operations 656 of an 802.1Q VLAN tag."; 658 leaf tag-type { 659 type etht-types:eth-tag-type; 660 description 661 "The VLAN tag type to push/swap."; 662 } 663 leaf vlan-value { 664 type etht-types:vlanid; 665 description 666 "The VLAN ID value to push/swap."; 667 } 668 /* 669 * To be added: this attribute is used when: 670 * a) the ETH service has only one CoS (as in current version) 671 * b) as a default when a mapping between a given CoS value 672 * and the PCP value is not defined (in future versions) 673 */ 674 leaf default-pcp { 675 type uint8 { 676 range "0..7"; 677 } 678 description 679 "The default Priority Code Point (PCP) value to push/swap"; 680 } 681 } 683 grouping vlan-operations { 684 description 685 "A grouping which represents VLAN operations."; 687 leaf pop-tags { 688 type uint8 { 689 range "1..2"; 690 } 691 description 692 "The number of VLAN tags to pop (or swap if used in 693 conjunction with push-tags)"; 694 } 695 container push-tags { 696 description 697 "The VLAN tags to push (or swap if used in 698 conjunction with pop-tags)"; 700 container outer-tag { 701 presence 702 "Indicates existence of the outermost VLAN tag to 703 push/swap"; 705 description 706 "The outermost VLAN tag to push/swap."; 708 uses vlan-write; 709 } 710 container second-tag { 711 must 712 '../outer-tag/tag-type = "etht-types:s-vlan-tag-type" and ' + 713 'tag-type = "etht-types:c-vlan-tag-type"' 714 { 716 error-message 717 " 718 When pushing/swapping two tags, the outermost tag must 719 be specified and of S-VLAN type and the second 720 outermost tag must be of C-VLAN tag type. 721 "; 722 description 723 " 724 For IEEE 802.1Q interoperability, when pushing/swapping 725 two tags, it is required that the outermost tag exists 726 and is an S-VLAN, and the second outermost tag is a 727 C-VLAN. 728 "; 729 } 731 presence 732 "Indicates existence of a second outermost VLAN tag to 733 push/swap"; 735 description 736 "The second outermost VLAN tag to push/swap."; 738 uses vlan-write; 739 } 740 } 742 } 744 grouping named-or-value-bandwidth-profile { 745 description 746 "A grouping to configure a bandwdith profile either by 747 referencing a named bandwidth profile or by 748 configuring the values of the bandwidth profile attributes."; 749 choice style { 750 description 751 "Whether the bandwidth profile is named or defined by value"; 753 case named { 754 description 755 "Named bandwidth profile."; 756 leaf bandwidth-profile-name { 757 type "string"; 758 description 759 "Name of the bandwidth profile."; 760 } 761 } 762 case value { 763 description 764 "Bandwidth profile configured by value."; 765 uses etht-types:etht-bandwidth-profiles; 766 } 767 } 768 } 770 grouping bandwidth-profiles { 771 description 772 "A grouping which represent bandwidth profile configuration."; 774 choice direction { 775 description 776 "Whether the bandwidth profiles are symmetrical or 777 asymmetrical"; 778 case symmetrical { 779 description 780 "The same bandwidth profile is used to describe both 781 the ingress and the egress bandwidth profile."; 782 container ingress-egress-bandwidth-profile { 783 description 784 "The bandwdith profile used in both directions."; 785 uses named-or-value-bandwidth-profile; 786 } 787 } 788 case asymmetrical { 789 description 790 "Ingress and egress bandwidth profiles can be specified."; 791 container ingress-bandwidth-profile { 792 description 793 "The bandwdith profile used in the ingress direction."; 794 uses named-or-value-bandwidth-profile; 795 } 796 container egress-bandwidth-profile { 797 description 798 "The bandwdith profile used in the egress direction."; 799 uses named-or-value-bandwidth-profile; 800 } 801 } 802 } 803 } 805 grouping etht-svc-access-parameters { 806 description 807 "ETH services access parameters"; 809 leaf access-node-id { 810 type te-types:te-node-id; 811 description 812 "The identifier of the access node in 813 the ETH topology."; 814 } 815 leaf access-ltp-id { 816 type te-types:te-tp-id; 817 description 818 "The TE link termination point identifier, used 819 together with access-node-id to identify the 820 access LTP."; 821 } 822 leaf access-role { 823 type identityref { 824 base etht-types:access-role; 825 } 826 description 827 "Indicate the role of access, e.g., working or protection. "; 828 } 830 container pm-config { 831 uses pm-config-grouping; 832 description 833 "This grouping is used to set the threshold value for 834 performance monitoring. "; 835 } 837 container state { 838 config false; 839 description 840 "The state is used to monitor the status of service. "; 841 leaf operational-state { 842 type identityref { 843 base te-types:tunnel-state-type; 844 } 845 description 846 "Indicating the operational state of client signal. "; 847 } 848 leaf provisioning-state { 849 type identityref { 850 base te-types:lsp-state-type; 851 } 852 description 853 "Indicating the provisional state of client signal, 854 especially when there is a change, i.e., revise, create. "; 855 } 856 } 858 leaf performance { 859 type identityref { 860 base etht-types:performance; 861 } 862 config false; 863 description 864 "Performance Monitoring for the service. "; 865 } 867 } 869 grouping etht-svc-tunnel-parameters { 870 description 871 "ETH services tunnel parameters"; 873 leaf tunnel-name { 874 type string; 875 description 876 "Underlying TE tunnel instance name."; 877 } 878 choice svc-multiplexing-tag { 879 description 880 "Service multiplexing is optional and flexible."; 882 case other { 883 /* 884 placeholder to support proprietary multiplexing 885 (for further discussion) 886 */ 887 } 889 case none { 890 /* no additional information is needed */ 891 } 893 case vlan-tag { 894 /* 895 No additional information is needed 896 The C-Tag or S-Tag used for service mulitplexing is defined 897 by the VLAN classification and operations configured in the 898 etht-svc-access-parameters grouping 899 */ 900 } 902 case pw-segment { 903 uses pw-segment-grouping; 904 } 905 } 907 /* 908 * Open issue: can we constraints it to be used only with mp services? 909 */ 910 leaf src-split-horizon-group { 911 type string; 912 description 913 "Identify a split horizon group at the Tunnel source TTP"; 914 } 915 leaf dst-split-horizon-group { 916 type string; 917 description 918 "Identify a split horizon group at the Tunnel destination TTP"; 919 } 920 } 922 grouping etht-svc-pm-threshold-config { 923 description 924 "Configuraiton parameters for Ethernet service PM thresholds."; 926 leaf sending-rate-high { 927 type uint64; 928 description 929 "High threshold of packet sending rate in kbps."; 930 } 931 leaf sending-rate-low { 932 type uint64; 933 description 934 "Low threshold of packet sending rate in kbps."; 935 } 936 leaf receiving-rate-high { 937 type uint64; 938 description 939 "High threshold of packet receiving rate in kbps."; 940 } 941 leaf receiving-rate-low { 942 type uint64; 943 description 944 "Low threshold of packet receiving rate in kbps."; 945 } 946 } 948 grouping etht-svc-pm-stats { 949 description 950 "Ethernet service PM statistics."; 952 leaf sending-rate-too-high { 953 type uint32; 954 description 955 "Counter that indicates the number of times the 956 sending rate is above the high threshold"; 957 } 958 leaf sending-rate-too-low { 959 type uint32; 960 description 961 "Counter that indicates the number of times the 962 sending rate is below the low threshold"; 963 } 964 leaf receiving-rate-too-high { 965 type uint32; 966 description 967 "Counter that indicates the number of times the 968 receiving rate is above the high threshold"; 969 } 970 leaf receiving-rate-too-low { 971 type uint32; 972 description 973 "Counter that indicates the number of times the 974 receiving rate is below the low threshold"; 975 } 976 } 978 grouping etht-svc-instance-config { 979 description 980 "Configuraiton parameters for Ethernet services."; 982 leaf etht-svc-name { 983 type string; 984 description 985 "Name of the ETH service."; 986 } 988 leaf etht-svc-id { 989 type string; 990 description 991 "The Identifier of the ETH service."; 992 } 994 leaf etht-svc-descr { 995 type string; 996 description 997 "Description of the ETH service."; 998 } 1000 leaf etht-svc-customer { 1001 type string; 1002 description 1003 "Customer of the ETH service."; 1004 } 1006 leaf etht-svc-type { 1007 type etht-types:service-type; 1008 description 1009 "Type of ETH service (p2p, mp2mp or rmp)."; 1010 /* Add default as p2p */ 1011 } 1013 leaf etht-svc-lifecycle { 1014 type etht-types:lifecycle-status; 1015 description 1016 "Lifecycle state of ETH service."; 1017 /* Add default as installed */ 1018 } 1019 uses te-types:te-topology-identifier; 1021 uses resilience-grouping; 1023 list etht-svc-end-points { 1024 key etht-svc-end-point-name; 1025 description 1026 "The logical end point for the ETH service. "; 1027 uses etht-svc-end-point-grouping; 1028 } 1029 list etht-svc-tunnels { 1030 key tunnel-name; 1031 description 1032 "List of the TE Tunnels supporting the ETH 1033 service."; 1035 uses etht-svc-tunnel-parameters; 1036 } 1038 leaf admin-status { 1039 type identityref { 1040 base te-types:tunnel-admin-state-type; 1041 } 1042 default te-types:tunnel-admin-state-up; 1043 description "ETH service administrative state."; 1044 } 1045 } 1047 grouping etht-svc-instance-state { 1048 description 1049 "State parameters for Ethernet services."; 1051 leaf operational-state { 1052 type identityref { 1053 base te-types:tunnel-state-type; 1054 } 1055 default te-types:tunnel-state-up; 1056 description "ETH service operational state."; 1057 } 1058 leaf provisioning-state { 1059 type identityref { 1060 base te-types:lsp-state-type; 1061 } 1062 description "ETH service provisioning state."; 1063 } 1064 leaf creation-time { 1065 type yang:date-and-time; 1066 description 1067 "Time of ETH service creation."; 1068 } 1069 leaf last-updated-time { 1070 type yang:date-and-time; 1071 description 1072 "Time of ETH service last update."; 1073 } 1075 } 1076 /* 1077 * Data nodes 1078 */ 1080 container etht-svc { 1081 description 1082 "ETH services."; 1084 container globals { 1085 description 1086 "Globals Ethernet configuration data container"; 1087 list named-bandwidth-profiles { 1088 key bandwidth-profile-name; 1089 description 1090 "List of named bandwidth profiles used by 1091 Ethernet services."; 1093 leaf bandwidth-profile-name { 1094 type string; 1095 description 1096 "Name of the bandwidth profile."; 1097 } 1098 uses etht-types:etht-bandwidth-profiles; 1099 } 1100 } 1102 list etht-svc-instances { 1103 key etht-svc-name; 1104 description 1105 "The list of p2p ETH service instances"; 1107 uses etht-svc-instance-config; 1109 container state { 1110 config false; 1111 description 1112 "Ethernet Service states."; 1114 uses etht-svc-instance-state; 1115 } 1116 } 1117 } 1119 grouping resilience-grouping { 1120 description 1121 "Grouping for resilience configuration. "; 1122 container resilience { 1123 description 1124 "To configure the data plane protection parameters, 1125 currently a placeholder only, future candidate attributes 1126 include, Revert, WTR, Hold-off Timer, ..."; 1127 } 1128 } 1130 grouping etht-svc-end-point-grouping { 1131 description 1132 "Grouping for the end point configuration."; 1133 leaf etht-svc-end-point-name { 1134 type string; 1135 description 1136 "The name of the logical end point of ETH service. "; 1137 } 1139 leaf etht-svc-end-point-id { 1140 type string; 1141 description 1142 "The identifier of the logical end point of ETH service."; 1143 } 1145 leaf etht-svc-end-point-descr { 1146 type string; 1147 description 1148 "The description of the logical end point of ETH service. "; 1149 } 1151 leaf topology-role { 1152 type identityref { 1153 base etht-types:topology-role; 1154 } 1155 description 1156 "The underlay topology role, e.g., hub,spoke, any-to-any "; 1157 } 1159 container resilience { 1160 description 1161 "Placeholder for resilience configuration, for future study. "; 1162 } 1164 list etht-svc-access-points { 1165 key access-point-id; 1166 min-elements "1"; 1167 /* 1168 Open Issue: 1169 Is it possible to limit the max-elements only for p2p services? 1171 max-elements "2"; 1173 */ 1174 description 1175 "List of the ETH trasport services access point instances."; 1177 leaf access-point-id { 1178 type string; 1179 description 1180 "ID of the service access point instance"; 1181 } 1182 uses etht-svc-access-parameters; 1183 } 1185 leaf service-classification-type { 1186 type identityref { 1187 base etht-types:service-classification-type; 1188 } 1189 description 1190 "Service classification type."; 1191 } 1193 choice service-classification { 1194 description 1195 "Access classification can be port-based or 1196 VLAN based."; 1198 case port-classification { 1199 /* no additional information */ 1200 } 1202 case vlan-classification { 1203 container outer-tag { 1204 presence "The outermost VLAN tag exists"; 1205 description 1206 "Classifies traffic using the outermost VLAN tag."; 1208 uses vlan-classification; 1209 } 1210 container second-tag { 1211 must 1212 '../outer-tag/tag-type = "etht-types:classify-s-vlan" and '+ 1213 'tag-type = "etht-types:classify-c-vlan"' 1214 { 1215 error-message 1216 " 1217 When matching two tags, the outermost tag must be 1218 specified and of S-VLAN type and the second 1219 outermost tag must be of C-VLAN tag type. 1220 "; 1222 description 1223 " 1224 For IEEE 802.1Q interoperability, when matching two 1225 tags, it is required that the outermost tag exists 1226 and is an S-VLAN, and the second outermost tag is a 1227 C-VLAN. 1228 "; 1229 } 1230 presence "The second outermost VLAN tag exists"; 1232 description 1233 "Classifies traffic using the second outermost VLAN tag."; 1235 uses vlan-classification; 1236 } 1237 } 1238 } 1240 /* 1241 * Open issue: can we constraints it to be used only with mp services? 1242 */ 1243 leaf split-horizon-group { 1244 type string; 1245 description "Identify a split horizon group"; 1246 } 1248 uses bandwidth-profiles; 1250 container vlan-operations { 1251 description 1252 "Configuration of VLAN operations."; 1253 choice direction { 1254 description 1255 "Whether the VLAN operations are symmetrical or 1256 asymmetrical"; 1257 case symmetrical { 1258 container symmetrical-operation { 1259 uses vlan-operations; 1260 description 1261 "Symmetrical operations. 1262 Expressed in the ingress direction, but 1263 the reverse operation is applied to egress traffic"; 1264 } 1265 } 1266 case asymmetrical { 1267 container asymmetrical-operation { 1268 description "Asymmetrical operations"; 1269 container ingress { 1270 uses vlan-operations; 1271 description "Ingress operations"; 1272 } 1273 container egress { 1274 uses vlan-operations; 1275 description "Egress operations"; 1276 } 1277 } 1278 } 1279 } 1280 } 1282 } 1284 grouping pm-config-grouping { 1285 description 1286 "Grouping used for Performance Monitoring Configuration. "; 1287 leaf pm-enable { 1288 type boolean; 1289 description 1290 "Whether to enable the performance monitoring."; 1291 } 1293 leaf sending-rate-high { 1294 type uint64; 1295 description 1296 "The upperbound of sending rate."; 1297 } 1299 leaf sending-rate-low { 1300 type uint64; 1301 description 1302 "The lowerbound of sending rate."; 1303 } 1305 leaf receiving-rate-high { 1306 type uint64; 1307 description 1308 "The upperbound of receiving rate."; 1309 } 1311 leaf receiving-rate-low { 1312 type uint64; 1313 description 1314 "The lowerbound of receiving rate."; 1315 } 1316 } 1317 grouping pw-segment-grouping { 1318 description 1319 "Grouping used for PW configuration. "; 1320 leaf pw-id { 1321 type string; 1322 description 1323 "The Identifier information of pseudowire. "; 1324 } 1326 leaf pw-name { 1327 type string; 1328 description 1329 "The name information of pseudowire."; 1330 } 1332 leaf transmit-label { 1333 type rt-types:mpls-label; 1334 description 1335 "Transmit label information in PW. "; 1336 } 1338 leaf receive-label { 1339 type rt-types:mpls-label; 1340 description 1341 "Receive label information in PW. "; 1342 } 1344 leaf encaplate-type { 1345 type identityref { 1346 base etht-types:encaplate-type; 1347 } 1348 description 1349 "The encapsulation type, raw or tag. "; 1350 } 1352 leaf oper-status { 1353 type identityref { 1354 base te-types:tunnel-state-type; 1355 } 1356 config false; 1357 description 1358 "The operational state of the PW segment. "; 1359 } 1361 container ingress-bandwidth-profile { 1362 description 1363 "Bandwidth Profile for ingress. "; 1364 uses pw-segment-named-or-value-bandwidth-profile; 1366 } 1367 } 1369 grouping pw-segment-named-or-value-bandwidth-profile { 1370 description 1371 "A grouping to configure a bandwdith profile either by 1372 referencing a named bandwidth profile or by 1373 configuring the values of the bandwidth profile attributes."; 1374 choice style { 1375 description 1376 "Whether the bandwidth profile is named or defined by value"; 1377 case named { 1378 description 1379 "Named bandwidth profile."; 1380 leaf bandwidth-profile-name { 1381 type leafref { 1382 path "/ethtsvc:etht-svc/ethtsvc:globals/ethtsvc:named-bandwidth-profiles/ethtsvc:bandwidth-profile-name"; 1383 } 1384 description 1385 "Name of the bandwidth profile."; 1386 } 1387 } 1388 case value { 1389 description 1390 "Bandwidth profile configured by value."; 1391 uses etht-types:pw-segement-bandwidth-profile-grouping; 1392 } 1393 } 1394 } 1395 } 1396 1398 5.2. YANG Code for ETH type 1400 This module references a few documents including [RFC2697], 1401 [RFC2698], [RFC4115], [IEEE802.1ad], [IEEE802.1q] and [MEF10]. 1403 file "ietf-eth-tran-types@2019-03-27.yang" 1404 module ietf-eth-tran-types { 1405 yang-version 1.1; 1406 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-tran-types"; 1408 prefix "etht-types"; 1410 organization 1411 "Internet Engineering Task Force (IETF) CCAMP WG"; 1412 contact 1413 " 1414 WG List: 1416 ID-draft editor: 1417 Haomian Zheng (zhenghaomian@huawei.com); 1418 Italo Busi (italo.busi@huawei.com); 1419 Aihua Guo (aihuaguo@huawei.com); 1420 Anton Snitser (antons@sedonasys.com); 1421 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 1422 Yunbin Xu (xuyunbin@ritt.cn); 1423 Yang Zhao (zhaoyangyjy@chinamobile.com); 1424 Xufeng Liu (Xufeng_Liu@jabil.com); 1425 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 1426 "; 1428 description 1429 "This module defines the ETH types. 1431 Copyright (c) 2019 IETF Trust and the persons 1432 identified as authors of the code. All rights reserved. 1434 Redistribution and use in source and binary forms, with or 1435 without modification, is permitted pursuant to, and subject 1436 to the license terms contained in, the Simplified BSD License 1437 set forth in Section 4.c of the IETF Trust's Legal Provisions 1438 Relating to IETF Documents 1439 (https://trustee.ietf.org/license-info)."; 1441 revision 2019-03-27 { 1442 description 1443 "version -07 as an I-D"; 1444 reference 1445 "draft-zheng-ccamp-client-signal-yang"; 1446 } 1448 /* 1449 * Identities 1450 */ 1452 identity eth-vlan-tag-type { 1453 description 1454 "ETH VLAN tag type."; 1455 } 1457 identity c-vlan-tag-type { 1458 base eth-vlan-tag-type; 1459 description 1460 "802.1Q Customer VLAN"; 1461 } 1463 identity s-vlan-tag-type { 1464 base eth-vlan-tag-type; 1465 description 1466 "802.1Q Service VLAN (QinQ)"; 1467 } 1469 identity service-classification-type { 1470 description 1471 "Service classification."; 1472 } 1474 identity port-classification { 1475 base service-classification-type; 1476 description 1477 "Port classification."; 1478 } 1480 identity vlan-classification { 1481 base service-classification-type; 1482 description 1483 "VLAN classification."; 1484 } 1486 identity eth-vlan-tag-classify { 1487 description 1488 "VLAN tag classification."; 1489 } 1491 identity classify-c-vlan { 1492 base eth-vlan-tag-classify; 1493 description 1494 "Classify 802.1Q Customer VLAN tag. 1495 Only C-tag type is accepted"; 1496 } 1498 identity classify-s-vlan { 1499 base eth-vlan-tag-classify; 1500 description 1501 "Classify 802.1Q Service VLAN (QinQ) tag. 1502 Only S-tag type is accepted"; 1503 } 1505 identity classify-s-or-c-vlan { 1506 base eth-vlan-tag-classify; 1507 description 1508 "Classify S-VLAN or C-VLAN tag-classify. 1509 Either tag is accepted"; 1510 } 1512 identity bandwidth-profile-type { 1513 description 1514 "Bandwidth Profile Types"; 1515 } 1517 identity mef-10-bwp { 1518 base bandwidth-profile-type; 1519 description 1520 "MEF 10 Bandwidth Profile"; 1521 } 1523 identity rfc-2697-bwp { 1524 base bandwidth-profile-type; 1525 description 1526 "RFC 2697 Bandwidth Profile"; 1527 } 1529 identity rfc-2698-bwp { 1530 base bandwidth-profile-type; 1531 description 1532 "RFC 2698 Bandwidth Profile"; 1533 } 1535 identity rfc-4115-bwp { 1536 base bandwidth-profile-type; 1537 description 1538 "RFC 4115 Bandwidth Profile"; 1539 } 1541 identity service-type { 1542 description 1543 "Type of Ethernet service."; 1544 } 1546 identity p2p-svc { 1547 base service-type; 1548 description 1549 "Ethernet point-to-point service (EPL, EVPL)."; 1550 } 1552 identity rmp-svc { 1553 base service-type; 1554 description 1555 "Ethernet rooted-multitpoint service (E-TREE, EP-TREE)."; 1556 } 1558 identity mp2mp-svc { 1559 base service-type; 1560 description 1561 "Ethernet multipoint-to-multitpoint service (E-LAN, EP-LAN)."; 1562 } 1564 identity lifecycle-status { 1565 description 1566 "Lifecycle Status."; 1567 } 1569 identity installed { 1570 base lifecycle-status; 1571 description 1572 "Installed."; 1573 } 1575 identity planned { 1576 base lifecycle-status; 1577 description 1578 "Planned."; 1579 } 1581 identity pending-removal { 1582 base lifecycle-status; 1583 description 1584 "Pending Removal."; 1585 } 1587 /* 1588 * Type Definitions 1589 */ 1591 typedef eth-tag-type { 1592 type identityref { 1593 base eth-vlan-tag-type; 1594 } 1595 description 1596 "Identifies a specific ETH VLAN tag type."; 1597 } 1599 typedef eth-tag-classify { 1600 type identityref { 1601 base eth-vlan-tag-classify; 1602 } 1603 description 1604 "Identifies a specific VLAN tag classification."; 1605 } 1607 typedef vlanid { 1608 type uint16 { 1609 range "1..4094"; 1610 } 1611 description 1612 "The 12-bit VLAN-ID used in the VLAN Tag header."; 1613 } 1615 typedef vid-range-type { 1616 type string { 1617 pattern "([1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?" + 1618 "(,[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?)*)"; 1619 } 1620 description 1621 "A list of VLAN Ids, or non overlapping VLAN ranges, in 1622 ascending order, between 1 and 4094. 1623 This type is used to match an ordered list of VLAN Ids, or 1624 contiguous ranges of VLAN Ids. Valid VLAN Ids must be in the 1625 range 1 to 4094, and included in the list in non overlapping 1626 ascending order. 1628 For example: 1,10-100,50,500-1000"; 1629 } 1631 typedef bandwidth-profile-type { 1632 type identityref { 1633 base bandwidth-profile-type; 1634 } 1635 description 1636 "Identifies a specific Bandwidth Profile type."; 1637 } 1639 typedef service-type { 1640 type identityref { 1641 base service-type; 1642 } 1643 description 1644 "Identifies the type of Ethernet service."; 1645 } 1647 typedef lifecycle-status { 1648 type identityref { 1649 base lifecycle-status; 1650 } 1651 description 1652 "Identifies the lLifecycle Status ."; 1653 } 1655 /* 1656 * Grouping Definitions 1657 */ 1659 grouping etht-bandwidth-profiles { 1660 description 1661 "Bandwidth profile configuration paramters."; 1663 leaf bandwidth-profile-type { 1664 type etht-types:bandwidth-profile-type; 1665 description 1666 "The type of bandwidth profile."; 1667 } 1668 leaf CIR { 1669 type uint64; 1670 description 1671 "Committed Information Rate in Kbps"; 1672 } 1673 leaf CBS { 1674 type uint64; 1675 description 1676 "Committed Burst Size in in KBytes"; 1677 } 1678 leaf EIR { 1679 type uint64; 1680 /* Need to indicate that EIR is not supported by RFC 2697 1682 must 1683 '../bw-profile-type = "mef-10-bwp" or ' + 1684 '../bw-profile-type = "rfc-2698-bwp" or ' + 1685 '../bw-profile-type = "rfc-4115-bwp"' 1687 must 1688 '../bw-profile-type != "rfc-2697-bwp"' 1689 */ 1690 description 1691 "Excess Information Rate in Kbps 1692 In case of RFC 2698, PIR = CIR + EIR"; 1693 } 1694 leaf EBS { 1695 type uint64; 1696 description 1697 "Excess Burst Size in KBytes. 1698 In case of RFC 2698, PBS = CBS + EBS"; 1700 } 1701 leaf color-aware { 1702 type boolean; 1703 description 1704 "The color-mode is color-aware or color-blind."; 1705 } 1706 leaf coupling-flag { 1707 type boolean; 1708 /* Need to indicate that Coupling Flag is defined only for MEF 10 1710 must 1711 '../bw-profile-type = "mef-10-bwp"' 1712 */ 1713 description 1714 "Coupling Flag."; 1715 } 1716 } 1718 identity topology-role { 1719 description 1720 "The rold of underlay topology, e.g., hub, spoke, any-to-any. "; 1721 } 1723 identity resilience { 1724 description 1725 "Placeholder for resilience information , for future study. "; 1726 } 1728 identity access-role { 1729 description 1730 "Indicating whether the access is a working or protection access."; 1731 } 1733 identity performance { 1734 description 1735 "Placeholder for performace information, for future study."; 1736 } 1738 identity encaplate-type { 1739 description 1740 "How the service is encapsulated (to PW), e.g, raw or tag. "; 1741 } 1743 grouping pw-segement-bandwidth-profile-grouping { 1744 description 1745 "bandwidth profile grouping for PW segment. "; 1746 leaf bandwidth-profile-type { 1747 type etht-types:bandwidth-profile-type; 1748 description 1749 "The type of bandwidth profile."; 1750 } 1751 leaf CIR { 1752 type uint64; 1753 description 1754 "Committed Information Rate in Kbps"; 1755 } 1756 leaf CBS { 1757 type uint64; 1758 description 1759 "Committed Burst Size in in KBytes"; 1760 } 1761 leaf EIR { 1762 type uint64; 1763 /* Need to indicate that EIR is not supported by RFC 2697 1765 must 1766 '../bw-profile-type = "mef-10-bwp" or ' + 1767 '../bw-profile-type = "rfc-2698-bwp" or ' + 1768 '../bw-profile-type = "rfc-4115-bwp"' 1770 must 1771 '../bw-profile-type != "rfc-2697-bwp"' 1772 */ 1773 description 1774 "Excess Information Rate in Kbps 1775 In case of RFC 2698, PIR = CIR + EIR"; 1776 } 1777 leaf EBS { 1778 type uint64; 1779 description 1780 "Excess Burst Size in KBytes. 1781 In case of RFC 2698, PBS = CBS + EBS"; 1782 } 1783 } 1784 grouping eth-bandwidth { 1785 description 1786 "Available bandwith for ethernet."; 1787 leaf eth-bandwidth { 1788 type uint64{ 1789 range "0..10000000000"; 1790 } 1791 units "Kbps"; 1792 description 1793 "Available bandwith value expressed in kilobits per second"; 1794 } 1795 } 1796 grouping eth-label-restriction { 1797 description 1798 "Label Restriction for ethernet."; 1799 leaf tag-type { 1800 type etht-types:eth-tag-type; 1801 description "VLAN tag type."; 1802 } 1803 leaf priority { 1804 type uint8; 1805 description "priority."; 1806 } 1807 } 1809 grouping eth-label { 1810 description 1811 "Label for ethernet."; 1812 leaf vlanid { 1813 type etht-types:vlanid; 1814 description 1815 "VLAN tag id."; 1816 } 1817 } 1819 grouping eth-label-step { 1820 description "Label step for Ethernet VLAN"; 1821 leaf eth-step { 1822 type uint16 { 1823 range "1..4095"; 1824 } 1825 default 1; 1826 description 1827 "Label step which represent possible increments for 1828 an Ethernet VLAN tag."; 1829 reference 1830 "IEEE 802.1ad: Provider Bridges."; 1831 } 1832 } 1833 } 1834 1836 5.3. Other Transport Network Client Signal YANG Code 1838 This module imports typedefs and modules from [RFC6991], 1839 [I-D.ietf-ccamp-otn-tunnel-model], [I-D.ietf-teas-yang-te-types]. 1841 file "ietf-trans-client-service@2019-03-27.yang" 1842 module ietf-trans-client-service { 1843 /* TODO: FIXME */ 1844 yang-version 1.1; 1846 namespace "urn:ietf:params:xml:ns:yang:ietf-trans-client-service"; 1847 prefix "clntsvc"; 1849 import ietf-te-types { 1850 prefix "te-types"; 1851 reference "RFC YYYY - Traffic Engineering Common YANG Types"; 1852 } 1854 import ietf-otn-types { 1855 prefix "otn-types"; 1856 reference "RFC ZZZZ - OTN Tunnel YANG Model"; 1857 } 1859 import ietf-yang-types { 1860 prefix "yang"; 1861 reference "RFC 6991 - Common YANG Data Types"; 1862 } 1864 organization 1865 "Internet Engineering Task Force (IETF) CCAMP WG"; 1866 contact 1867 " 1868 ID-draft editor: 1869 Haomian Zheng (zhenghaomian@huawei.com); 1870 Aihua Guo (aihuaguo@huawei.com); 1871 Italo Busi (italo.busi@huawei.com); 1872 Anton Snitser (antons@sedonasys.com); 1873 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 1874 Yunbin Xu (xuyunbin@ritt.cn); 1875 Yang Zhao (zhaoyangyjy@chinamobile.com); 1876 Xufeng Liu (Xufeng_Liu@jabil.com); 1877 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 1878 "; 1880 description 1881 "This module defines a YANG data model for describing 1882 transport network client services. 1884 Copyright (c) 2019 IETF Trust and the persons 1885 identified as authors of the code. All rights reserved. 1887 Redistribution and use in source and binary forms, with or 1888 without modification, is permitted pursuant to, and subject 1889 to the license terms contained in, the Simplified BSD License 1890 set forth in Section 4.c of the IETF Trust's Legal Provisions 1891 Relating to IETF Documents 1892 (https://trustee.ietf.org/license-info)."; 1894 revision 2019-03-27 { 1895 description 1896 "version -07 as an I-D"; 1897 reference 1898 "draft-zheng-ccamp-client-signal-yang"; 1899 } 1901 /* 1902 * Groupings 1903 */ 1904 grouping client-svc-access-parameters { 1905 description 1906 "Transport network client signals access parameters"; 1908 leaf access-node-id { 1909 type te-types:te-node-id; 1910 description 1911 "The identifier of the access node in the underlying 1912 transport network topology."; 1913 } 1915 leaf access-ltp-id { 1916 type te-types:te-tp-id; 1917 description 1918 "The TE link termination point identifier, used together with 1919 access-node-id to identify the access LTP."; 1920 } 1922 leaf client-signal { 1923 type identityref { 1924 base otn-types:client-signal; 1925 } 1926 description 1927 "Identifiies the client signal type associated with this port"; 1928 } 1929 } 1931 grouping client-svc-tunnel-parameters { 1932 description 1933 "Transport network client signals tunnel parameters"; 1935 leaf tunnel-name { 1936 type string; 1937 description 1938 "TE tunnel instance name."; 1939 } 1940 } 1942 grouping client-svc-instance-config { 1943 description 1944 "Configuration parameters for client services."; 1945 leaf client-svc-name { 1946 type string; 1947 description 1948 "Identifier of the p2p transport network client signals."; 1949 } 1951 leaf client-svc-id { 1952 type string; 1953 description 1954 "Name of the p2p transport network client signals."; 1955 } 1957 leaf client-svc-descr { 1958 type string; 1959 description 1960 "Description of the transport network client signals."; 1961 } 1963 leaf client-svc-customer { 1964 type string; 1965 description 1966 "Customer of the transport network client signals."; 1967 } 1969 container resilience { 1970 description "Place holder for resilience functionalities"; 1971 } 1973 uses te-types:te-topology-identifier; 1975 leaf admin-status { 1976 type identityref { 1977 base te-types:tunnel-admin-state-type; 1978 } 1979 default te-types:tunnel-admin-state-up; 1980 description "Client signals administrative state."; 1981 } 1983 container src-access-ports { 1984 description 1985 "Source access port of a client signal."; 1987 uses client-svc-access-parameters; 1988 } 1990 container dst-access-ports { 1991 description 1992 "Destination access port of a client signal."; 1993 uses client-svc-access-parameters; 1994 } 1996 list svc-tunnels { 1997 key tunnel-name; 1998 description 1999 "List of the TE Tunnels supporting the client signal."; 2000 uses client-svc-tunnel-parameters; 2001 } 2002 } 2004 grouping client-svc-instance-state { 2005 description 2006 "State parameters for client services."; 2007 leaf operational-state { 2008 type identityref { 2009 base te-types:tunnel-state-type; 2010 } 2011 config false; 2012 description "Client signal operational state."; 2013 } 2014 leaf provisioning-state { 2015 type identityref { 2016 base te-types:lsp-state-type; 2017 } 2018 config false; 2019 description "Client signal provisioning state."; 2020 } 2021 leaf creation-time { 2022 type yang:date-and-time; 2023 config false; 2024 description "The time of the client signal be created."; 2025 } 2026 leaf last-updated-time { 2027 type yang:date-and-time; 2028 config false; 2029 description "The time of the client signal's latest update."; 2030 } 2031 } 2033 /* 2034 * Data nodes 2035 */ 2037 container client-svc { 2038 description 2039 "Transport client services."; 2041 list client-svc-instances { 2042 key client-svc-name; 2043 description 2044 "The list of p2p transport client service instances"; 2046 uses client-svc-instance-config; 2047 uses client-svc-instance-state; 2048 } 2049 } 2050 } 2052 2054 6. Considerations and Open Issue 2056 Editor Notes: This section is used to note temporary discussion/ 2057 conclusion that to be fixed in the future version, and will be 2058 removed before publication. We currently categorize all the client 2059 signal types into transparent and non-transparent, with separate 2060 models. There was consensus that no common model is needed for these 2061 two categories. Further Alignment with RFC8407 would be required 2062 before publication. The RFC Editor will replace XXXX, YYYY and ZZZZ 2063 with the number assigned to the RFC once this draft becomes an RFC. 2065 7. IANA Considerations 2067 It is proposed that IANA should assign new URIs from the "IETF XML 2068 Registry" [RFC3688] as follows: 2070 URI: urn:ietf:params:xml:ns:yang:ietf-eth-tran-service 2071 Registrant Contact: The IESG 2072 XML: N/A; the requested URI is an XML namespace. 2074 URI: urn:ietf:params:xml:ns:yang:ietf-trans-client-service 2075 Registrant Contact: The IESG 2076 XML: N/A; the requested URI is an XML namespace. 2078 URI: urn:ietf:params:xml:ns:yang:ietf-eth-tran-types 2079 Registrant Contact: The IESG 2080 XML: N/A; the requested URI is an XML namespace. 2082 This document registers following YANG modules in the YANG Module 2083 Names registry [RFC6020]. 2085 name: ietf-eth-tran-service 2086 namespace: urn:ietf:params:xml:ns:yang:ietf-eth-tran-service 2087 prefix: ethtsvc 2088 reference: RFC XXXX: A YANG Data Model for Transport 2089 Network Client Signals 2091 name: ietf-eth-tran-types 2092 namespace: urn:ietf:params:xml:ns:yang:ietf-eth-tran-types 2093 prefix: etht-types 2094 reference: RFC XXXX: A YANG Data Model for Transport 2095 Network Client Signals 2097 name: ietf-trans-client-service 2098 namespace: urn:ietf:params:xml:ns:yang:ietf-trans-client-service 2099 prefix: clntsvc 2100 reference: RFC XXXX: A YANG Data Model for Transport 2101 Network Client Signals 2103 8. Manageability Considerations 2105 TBD. 2107 9. Security Considerations 2109 The data following the model defined in this document is exchanged 2110 via, for example, the interface between an orchestrator and a network 2111 domain controller. 2113 The YANG module defined in this document can be accessed via the 2114 RESTCONF protocol defined in [RFC8040], or maybe via the NETCONF 2115 protocol [RFC6241]. 2117 There are a number of data nodes defined in the YANG module which are 2118 writable/creatable/deletable (i.e., config true, which is the 2119 default). These data nodes may be considered sensitive or vulnerable 2120 in some network environments. Write operations (e.g., POST) to these 2121 data nodes without proper protection can have a negative effect on 2122 network operations. 2124 10. Acknowledgements 2126 We would like to thank Igor Bryskin and Daniel King for their 2127 comments and discussions. 2129 11. Contributors 2131 Yanlei Zheng 2132 China Unicom 2133 Email: zhengyl@dimpt.com 2135 Zhe Liu 2136 Huawei Technologies, 2137 Email: liuzhe123@huawei.com 2139 Sergio Belotti 2140 Nokia, 2141 Email: sergio.belotti@nokia.com 2143 Yingxi Yao 2144 Shanghai Bell, 2145 yingxi.yao@nokia-sbell.com 2147 12. References 2149 12.1. Normative References 2151 [I-D.ietf-ccamp-l1csm-yang] 2152 Fioccola, G., Lee, K., Lee, Y., Dhody, D., and D. 2153 Ceccarelli, "A YANG Data Model for L1 Connectivity Service 2154 Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-09 (work in 2155 progress), March 2019. 2157 [I-D.ietf-ccamp-otn-topo-yang] 2158 Zheng, H., Guo, A., Busi, I., Sharma, A., Liu, X., 2159 Belotti, S., Xu, Y., Wang, L., and O. Dios, "A YANG Data 2160 Model for Optical Transport Network Topology", draft-ietf- 2161 ccamp-otn-topo-yang-06 (work in progress), February 2019. 2163 [I-D.ietf-ccamp-otn-tunnel-model] 2164 Zheng, H., Guo, A., Busi, I., Sharma, A., Rao, R., 2165 Belotti, S., Lopezalvarez, V., Li, Y., and Y. Xu, "OTN 2166 Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel-model-06 2167 (work in progress), February 2019. 2169 [I-D.ietf-teas-yang-te-topo] 2170 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 2171 O. Dios, "YANG Data Model for Traffic Engineering (TE) 2172 Topologies", draft-ietf-teas-yang-te-topo-19 (work in 2173 progress), February 2019. 2175 [I-D.ietf-teas-yang-te-types] 2176 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 2177 "Traffic Engineering Common YANG Types", draft-ietf-teas- 2178 yang-te-types-06 (work in progress), February 2019. 2180 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2181 the Network Configuration Protocol (NETCONF)", RFC 6020, 2182 DOI 10.17487/RFC6020, October 2010, 2183 . 2185 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2186 and A. Bierman, Ed., "Network Configuration Protocol 2187 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2188 . 2190 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2191 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2192 . 2194 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 2195 and K. Pithewan, "GMPLS Signaling Extensions for Control 2196 of Evolving G.709 Optical Transport Networks", RFC 7139, 2197 DOI 10.17487/RFC7139, March 2014, 2198 . 2200 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2201 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2202 . 2204 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2205 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2206 . 2208 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 2209 "Common YANG Data Types for the Routing Area", RFC 8294, 2210 DOI 10.17487/RFC8294, December 2017, 2211 . 2213 12.2. Informative References 2215 [IEEE802.1ad] 2216 IEEE, 802., "IEEE 802.1ad - Provider Bridges.", IEEE 2217 802.1ad , May 2006. 2219 [IEEE802.1q] 2220 IEEE, 802., "IEEE 802.1q - Virtual Bridged Local Area 2221 Networks", IEEE 802.1q , June 2005. 2223 [MEF10] MEF, 10., "Ethernet Services Attributes Phase 1", MEF10 , 2224 November 2004. 2226 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 2227 Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, 2228 . 2230 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 2231 Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, 2232 . 2234 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2235 DOI 10.17487/RFC3688, January 2004, 2236 . 2238 [RFC4115] Aboul-Magd, O. and S. Rabie, "A Differentiated Service 2239 Two-Rate, Three-Color Marker with Efficient Handling of 2240 in-Profile Traffic", RFC 4115, DOI 10.17487/RFC4115, July 2241 2005, . 2243 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 2244 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 2245 DOI 10.17487/RFC8299, January 2018, 2246 . 2248 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2249 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2250 . 2252 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2253 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2254 . 2256 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2257 and R. Wilton, "Network Management Datastore Architecture 2258 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2259 . 2261 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 2262 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 2263 DOI 10.17487/RFC8453, August 2018, 2264 . 2266 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2267 Data Model for Layer 2 Virtual Private Network (L2VPN) 2268 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2269 2018, . 2271 Authors' Addresses 2273 Haomian Zheng 2274 Huawei Technologies 2275 H1-1-A043S Huawei Industrial Base, Songshanhu 2276 Dongguan, Guangdong 2277 P.R.China 2279 Email: zhenghaomian@huawei.com 2281 Aihua Guo 2282 Huawei Technologies 2284 Email: aihuaguo@huawei.com 2286 Italo Busi 2287 Huawei Technologies 2289 Email: Italo.Busi@huawei.com 2291 Anton Snitser 2292 Sedona 2294 Email: antons@sedonasys.com 2295 Francesco Lazzeri 2296 Ericsson 2298 Email: francesco.lazzeri@ericsson.com 2300 Yunbin Xu 2301 CAICT 2303 Email: xuyunbin@ritt.cn 2305 Yang Zhao 2306 China Mobile 2308 Email: zhaoyangyjy@chinamobile.com 2310 Xufeng Liu 2311 Volta Networks 2313 Email: xufeng.liu.ietf@gmail.com 2315 Giuseppe Fioccola 2316 Huawei Technologies 2318 Email: giuseppe.fioccola@huawei.com