idnits 2.17.1 draft-ietf-ccamp-client-signal-yang-02.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 lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 336 has weird spacing: '...le-name str...' == Line 388 has weird spacing: '...oint-id str...' == Line 588 has weird spacing: '...rw name str...' == Line 622 has weird spacing: '...el-name str...' == Line 1018 has weird spacing: '...rouping etht-...' == (5 more instances...) -- The document date (May 6, 2020) is 1445 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 2422, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-ccamp-l1csm-yang-11 == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-otn-topo-yang-10 == Outdated reference: A later version (-20) exists of draft-ietf-ccamp-otn-tunnel-model-10 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group H. Zheng 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track A. Guo 5 Expires: November 7, 2020 Futurewei 6 I. Busi 7 Huawei Technologies 8 A. Snitser 9 Sedona 10 F. Lazzeri 11 Ericsson 12 Y. Xu 13 CAICT 14 Y. Zhao 15 China Mobile 16 X. Liu 17 Volta Networks 18 G. Fioccola 19 Huawei Technologies 20 May 6, 2020 22 A YANG Data Model for Transport Network Client Signals 23 draft-ietf-ccamp-client-signal-yang-02 25 Abstract 27 A transport network is a server-layer network to provide connectivity 28 services to its client. The topology and tunnel information in the 29 transport layer has already been defined by generic Traffic- 30 engineered models and technology-specific models (e.g., OTN, WSON). 31 However, how the client signals are accessing to the network has not 32 been described. These information is necessary to both client and 33 provider. 35 This draft describes how the client signals are carried over 36 transport network and defines YANG data models which are required 37 during configuration procedure. More specifically, several client 38 signal (of transport network) models including ETH, STM-n, FC and so 39 on, are defined in this draft. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on November 7, 2020. 58 Copyright Notice 60 Copyright (c) 2020 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.2. Prefixs in Model Names . . . . . . . . . . . . . . . . . 3 78 2. Terminology and Notations . . . . . . . . . . . . . . . . . . 4 79 3. Transport Network Client Signal Overview . . . . . . . . . . 4 80 3.1. Overview of Service Request and Network Configuration 81 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 4 82 3.2. Applicability of Proposed Model . . . . . . . . . . . . . 7 83 4. YANG Model for Transport Network Client Signal . . . . . . . 8 84 4.1. YANG Tree for Ethernet Service . . . . . . . . . . . . . 8 85 4.2. YANG Tree for other Transport Network Client Signal Model 13 86 5. YANG Code for Transport Network Client Signal . . . . . . . . 14 87 5.1. The ETH Service YANG Code . . . . . . . . . . . . . . . . 14 88 5.2. YANG Code for ETH type . . . . . . . . . . . . . . . . . 33 89 5.3. Other Client Signal YANG Code . . . . . . . . . . . . . . 43 90 5.4. Other Client Signal Types YANG Code . . . . . . . . . . . 48 91 6. Considerations and Open Issue . . . . . . . . . . . . . . . . 49 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 93 8. Manageability Considerations . . . . . . . . . . . . . . . . 51 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 51 95 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 96 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 98 12.1. Normative References . . . . . . . . . . . . . . . . . . 52 99 12.2. Informative References . . . . . . . . . . . . . . . . . 53 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 102 1. Introduction 104 1.1. Overview 106 A transport network is a server-layer network designed to provide 107 connectivity services for a client-layer network to carry the client 108 traffic transparently across the server-layer network resources. 109 Currently the topology and tunnel models which have been defined for 110 transport networks, such as [I-D.ietf-ccamp-otn-topo-yang] and 111 [I-D.ietf-ccamp-otn-tunnel-model], provide server-layer topology 112 abstraction and tunnel configuration between PEs. However, there is 113 a missing piece for configuring how the PEs should map the client- 114 layer traffic, received from the CE, over the server-layer-tunnels: 115 this gap is expected to be solved in this document. 117 This document defines a data model of all transport network client 118 signals, using YANG language defined in [RFC7950]. The model can be 119 used by applications exposing to a transport network controller via a 120 RESTconf interface. Furthermore, it can be used by an application 121 for the following purposes (but not limited to): 123 o To request/update an end-to-end service by driving a new tunnel to 124 be set up to support this service; 126 o To request/update an end-to-end service by using an existing 127 tunnel; 129 o To receive notification with regard to the information change of 130 the given service; 132 The YANG modules defined in this document conforms to the Network 133 Management Datastore Architecture (NMDA) defined in [RFC8342]. 135 1.2. Prefixs in Model Names 137 In this document, names of data nodes and other data model objects 138 are prefixed using the standard prefix associated with the 139 corresponding YANG imported modules, including [RFC6991], [RFC8294] 140 and [I-D.ietf-ccamp-otn-tunnel-model], which are shown as follow. 142 +-------------+---------------------------+----------------------+ 143 | Prefix | YANG module | Reference | 144 +-------------+---------------------------+----------------------+ 145 | yang | ietf-yang-types | [RFC6991] | 146 | te-types | ietf-te-types |[ietf-teas-yang-te-types]| 147 | rt-types | ietf-routing-types | [RFC8294] | 148 | otn-types | ietf-otn-types |[ietf-ccamp-otn-tunnel-model]| 149 | etht-types | ietf-eth-tran-types | This Document | 150 | clntsvc | ietf-trans-client-service | This Document | 151 | ethtsvc | ietf-eth-tran-service | This Document | 152 |clntsvc-types|ietf-trans-client-svc-types| This Document | 153 +-------------+---------------------------+----------------------+ 155 2. Terminology and Notations 157 A simplified graphical representation of the data model is used in 158 this document. The meaning of the symbols in the YANG data tree 159 presented later in this document is defined in [RFC8340]. They are 160 provided below for reference. 162 o Brackets "[" and "]" enclose list keys. 164 o Abbreviations before data node names: "rw" means configuration 165 (read-write) and "ro" state data (read-only). 167 o Symbols after data node names: "?" means an optional node, "!" 168 means a presence container, and "*" denotes a list and leaf-list. 170 o Parentheses enclose choice and case nodes, and case nodes are also 171 marked with a colon (":"). 173 o Ellipsis ("...") stands for contents of subtrees that are not 174 shown. 176 3. Transport Network Client Signal Overview 178 3.1. Overview of Service Request and Network Configuration Scenarios 180 A global view of a multi-domain service can be described as the 181 Figure 1 . The customer is usually responsible to configure the CE 182 nodes and to request to the provider the service intent, from the CE 183 nodes perspective, while the provider is responsible to configure the 184 whole network (including the PE nodes) to support the customer 185 service intent. Generally speaking, the network configurations 186 required to support a customer service can be split into two 187 different groups: CE-PE and PE-PE. The CE-PE configuration deals 188 with the client layer one-hop access link, while PE-PE configuration 189 deals with the server layer tunnel. In Figure 1 we mark the 190 intermediate nodes as 'P', which has same switching capability of PE 191 but just not the 'end-point'. In this example, the link P-P and PE-P 192 are a server-layer intra-domain or inter-domain link. 194 +----+ +----+ 195 | CE | | CE | 196 +--+-+ +--+-+ 197 | | 198 | ------------- -------------| 199 //|/ \\\\ ///// |\\\\ 200 // | \\ // | \\ 201 | +--+-+ +---+ +---+ | | +---+ +---+ +--+-+ | 202 | | PE +----+ P +--+ P +---+-----+--+ P +---+ P +---+ PE | | 203 | +----+ +---+ +---+ | | +---+ +---+ +----+ | 204 \\ // \\ // 205 \\\\ //// \\\\\ ///// 206 ------------- ------------- 207 Domain 1 Domain 2 209 Figure 1: Global view of Client Service with the Network Provider 211 According to the responsibilities of each controller in [RFC8453], 212 the controllers have different views of the service request and 213 network configuration. The duty of CNC is to give the MDSC a 214 description of the customer service intent: candidate YANG models 215 include L1CSM [I-D.ietf-ccamp-l1csm-yang], L2SM [RFC8466] and L3SM 216 [RFC8299], which are classified as customer service models, according 217 to [RFC8309]. These models provide necessary attributes to describe 218 the customer service intent from the customer/CE perspective, and do 219 not provide any specific network configuration. These models also 220 implies that the customer service description can be considered in a 221 separate manner rather than integratig with network configurations, 222 which also enable the controllers to abstract/virtualize the network 223 resource to make them visible to the customer and also easier to 224 manage. In other words, the network knowledge is not necessary at 225 CNC and CMI, which is seen in an abstracted form as shown in 226 Figure 2. 228 /---------\ 229 /// \\\ 230 +----+ | | +----+ 231 | CE |--------------+ NETWORK +----------------| CE | 232 +----+ | | +----+ 233 \\\ /// 234 \---------/ 236 Figure 2: CNC Viewpoint on the Client Service 238 The functionalities of MDSC have been described in [RFC8453], which 239 include the customer mapping/translation and multi-domain 240 coordination. By receiving the request from CNC, MDSC need to 241 understand what network configuration can support the customer 242 service intent and turn to the corresponding PNCs for configuration. 243 The service request is therefore decomposed by MDSC into a few 244 network configurations and forwarded to one or multiple PNCs 245 respectively in single-domain and multi-domain scenario. In general, 246 the MDSC has the view of both PE and CE nodes and of some abstract 247 information regarding the P nodes, as shown in Figure 3. It is worth 248 noting that this MDSC view is different with Figure 1 at the intra- 249 domain link. Usually these details are hidden, for scalability 250 purposes, and therefore the MDSC has only an abstract view of each 251 domain internal topology. 253 ------ ----- 254 //// \\\\ ///- -\\\ 255 // \\ // \\ 256 +----+ | +----+ +---+ | |+---+ +----+ | +----+ 257 | CE |-----+-| PE |-----| P |-+--+| P |-----| PE |-+-----| CE | 258 +----+ | +----+ +---+ | |+---+ +----+ | +----+ 259 \\ // \\ // 260 \\\\ //// \\\- -/// 261 ------ ----- 262 Domain 1 Domain 2 264 Figure 3: MDSC view of both Client Service and Network Abstraction 266 PNC is the controller that configure the physical devices, based on 267 the network configuration received from the MDSC. Each PNC has the 268 detailed view of its own domain, the example of view from PNC in 269 domain 1 is shown in Figure 4. The PNC has all the detailed topology 270 information on PE and P nodes and on the intra-domain links. The PNC 271 configures the tunnel/tunnel segment within its domain based on the 272 network configuration provided by the MDSC. The PNC also configures 273 the network part of the CE-PE access links as well as the mapping of 274 the client-layer traffic and the server-layer tunnels, based on the 275 network configuration provided by the MDSC. The interaction between 276 PNC and MDSC for the client-layer network configuration is 277 accomplished by the models defined in this draft. 279 | | | 280 | ------------- | -------------| 281 //|/ \\\\ | ///// |\\\\ 282 // | \\ | // | \\ 283 | +--+-+ +---+ +---+ | | | +---+ +---+ +--+-+ | 284 | | PE +----+ P +--+ P +---+--+--+--+ P +---+ P +---+ PE | | 285 | +----+ +---+ +---+ | | | +---+ +---+ +----+ | 286 \\ // | \\ // 287 \\\\ //// | \\\\\ ///// 288 ------------- | ------------- 289 PNC View in Domain 1 | PNC View in Domain 2 290 | 292 Figure 4: PNC view on Network Configuration 294 3.2. Applicability of Proposed Model 296 Existing TE and technology-specific models, such as topology models 297 and tunnel models, support the network configuration among PEs and 298 Ps. The customer service models, such as L1CSM, L2SM and L3SM, focus 299 on describing the attributes among CEs. However, there is a missing 300 piece on how to configure the CE-PE session. The models defined in 301 this document provide the configuration on CE-PE when the provider 302 server-layer network is TE-based technology. 304 In the example of OTN as the server-layer transport network, a full 305 list of G-PID was summarized in [RFC7139], which can be divided into 306 a few categories. The G-PID signals can be categorized into 307 transparent and non-transparent. Examples of transparent signals may 308 include Ethernetphysical interfaces, FC, STM-n and so on. In this 309 approach the OTN devices is not aware of the client signal type, and 310 this information is only necessary among the controllers. Once the 311 OTN tunnel is set up, there is no switching requested on the client 312 layer, and therefore only signal mapping is needed, without a client 313 tunnel set up. The models that supporting the configuration of 314 transparent signals are defined in Section 4.2. The other category 315 would be non-transparent, such as Carrier Ethernet and MPLS-TP, with 316 a switching request on the client layer. Once the OTN tunnel is set 317 up, a corresponding tunnel in the client layer has to be set up to 318 carry services. The models that supporting the configuration of 319 transparent signals are defined in Section 4.1. 321 It is also worth noting that some client signal can be carried over 322 multiple types of networks. For example, the Ethernet services can 323 be carried over either OTN or Ethernet TE tunnels (over optical or 324 microwave networks). The model specified in this document allows the 325 support from networks with different technologies. 327 4. YANG Model for Transport Network Client Signal 329 4.1. YANG Tree for Ethernet Service 331 module: ietf-eth-tran-service 332 +--rw etht-svc 333 +--rw globals 334 | +--rw named-bandwidth-profiles* 335 | [bandwidth-profile-name] 336 | +--rw bandwidth-profile-name string 337 | +--rw bandwidth-profile-type? 338 | | etht-types:bandwidth-profile-type 339 | +--rw CIR? uint64 340 | +--rw CBS? uint64 341 | +--rw EIR? uint64 342 | +--rw EBS? uint64 343 | +--rw color-aware? boolean 344 | +--rw coupling-flag? boolean 345 +--rw etht-svc-instances* [etht-svc-name] 346 +--rw etht-svc-name string 347 +--rw etht-svc-title? string 348 +--rw etht-svc-descr? string 349 +--rw etht-svc-customer? string 350 +--rw etht-svc-type? 351 | etht-types:service-type 352 +--rw etht-svc-lifecycle? 353 | etht-types:lifecycle-status 354 +--rw te-topology-identifier 355 | +--rw provider-id? te-global-id 356 | +--rw client-id? te-global-id 357 | +--rw topology-id? te-topology-id 358 +--rw resilience 359 | +--rw protection 360 | | +--rw enable? boolean 361 | | +--rw protection-type? 362 | | | identityref 363 | | +--rw protection-reversion-disable? boolean 364 | | +--rw hold-off-time? uint32 365 | | +--rw wait-to-revert? uint16 366 | | +--rw aps-signal-id? uint8 367 | +--rw restoration 368 | +--rw enable? boolean 369 | +--rw restoration-type? 370 | | identityref 371 | +--rw restoration-scheme? 372 | | identityref 373 | +--rw restoration-reversion-disable? boolean 374 | +--rw hold-off-time? uint32 375 | +--rw wait-to-restore? uint16 376 | +--rw wait-to-revert? uint16 377 +--rw etht-svc-end-points* [etht-svc-end-point-name] 378 | +--rw etht-svc-end-point-name 379 | | string 380 | +--rw etht-svc-end-point-id? 381 | | string 382 | +--rw etht-svc-end-point-descr? 383 | | string 384 | +--rw topology-role? 385 | | identityref 386 | +--rw resilience 387 | +--rw etht-svc-access-points* [access-point-id] 388 | | +--rw access-point-id string 389 | | +--rw access-node-id? te-types:te-node-id 390 | | +--rw access-ltp-id? te-types:te-tp-id 391 | | +--rw access-role? identityref 392 | | +--rw pm-config 393 | | | +--rw pm-enable? boolean 394 | | | +--rw sending-rate-high? uint64 395 | | | +--rw sending-rate-low? uint64 396 | | | +--rw receiving-rate-high? uint64 397 | | | +--rw receiving-rate-low? uint64 398 | | +--ro state 399 | | | +--ro operational-state? identityref 400 | | | +--ro provisioning-state? identityref 401 | | +--ro performance? identityref 402 | +--rw service-classification-type? 403 | | identityref 404 | +--rw (service-classification)? 405 | | +--:(port-classification) 406 | | +--:(vlan-classification) 407 | | +--rw outer-tag! 408 | | | +--rw tag-type? 409 | | | | etht-types:eth-tag-classify 410 | | | +--rw (individual-bundling-vlan)? 411 | | | +--:(individual-vlan) 412 | | | | +--rw vlan-value? 413 | | | | etht-types:vlanid 414 | | | +--:(vlan-bundling) 415 | | | +--rw vlan-range? 416 | | | etht-types:vid-range-type 417 | | +--rw second-tag! 418 | | +--rw tag-type? 419 | | | etht-types:eth-tag-classify 420 | | +--rw (individual-bundling-vlan)? 421 | | +--:(individual-vlan) 422 | | | +--rw vlan-value? 423 | | | etht-types:vlanid 424 | | +--:(vlan-bundling) 425 | | +--rw vlan-range? 426 | | etht-types:vid-range-type 427 | +--rw split-horizon-group? 428 | | string 429 | +--rw (direction)? 430 | | +--:(symmetrical) 431 | | | +--rw ingress-egress-bandwidth-profile 432 | | | +--rw (style)? 433 | | | +--:(named) 434 | | | | +--rw bandwidth-profile-name? 435 | | | | string 436 | | | +--:(value) 437 | | | +--rw bandwidth-profile-type? 438 | | | | etht-types:bandwidth-profile-type 439 | | | +--rw CIR? 440 | | | | uint64 441 | | | +--rw CBS? 442 | | | | uint64 443 | | | +--rw EIR? 444 | | | | uint64 445 | | | +--rw EBS? 446 | | | | uint64 447 | | | +--rw color-aware? 448 | | | | boolean 449 | | | +--rw coupling-flag? 450 | | | boolean 451 | | +--:(asymmetrical) 452 | | +--rw ingress-bandwidth-profile 453 | | | +--rw (style)? 454 | | | +--:(named) 455 | | | | +--rw bandwidth-profile-name? 456 | | | | string 457 | | | +--:(value) 458 | | | +--rw bandwidth-profile-type? 459 | | | | etht-types:bandwidth-profile-type 460 | | | +--rw CIR? 461 | | | | uint64 462 | | | +--rw CBS? 463 | | | | uint64 464 | | | +--rw EIR? 465 | | | | uint64 466 | | | +--rw EBS? 467 | | | | uint64 468 | | | +--rw color-aware? 469 | | | | boolean 470 | | | +--rw coupling-flag? 471 | | | boolean 472 | | +--rw egress-bandwidth-profile 473 | | +--rw (style)? 474 | | +--:(named) 475 | | | +--rw bandwidth-profile-name? 476 | | | string 477 | | +--:(value) 478 | | +--rw bandwidth-profile-type? 479 | | | etht-types:bandwidth-profile-type 480 | | +--rw CIR? 481 | | | uint64 482 | | +--rw CBS? 483 | | | uint64 484 | | +--rw EIR? 485 | | | uint64 486 | | +--rw EBS? 487 | | | uint64 488 | | +--rw color-aware? 489 | | | boolean 490 | | +--rw coupling-flag? 491 | | boolean 492 | +--rw vlan-operations 493 | +--rw (direction)? 494 | +--:(symmetrical) 495 | | +--rw symmetrical-operation 496 | | +--rw pop-tags? uint8 497 | | +--rw push-tags 498 | | +--rw outer-tag! 499 | | | +--rw tag-type? 500 | | | | etht-types:eth-tag-type 501 | | | +--rw vlan-value? 502 | | | | etht-types:vlanid 503 | | | +--rw default-pcp? uint8 504 | | +--rw second-tag! 505 | | +--rw tag-type? 506 | | | etht-types:eth-tag-type 507 | | +--rw vlan-value? 508 | | | etht-types:vlanid 509 | | +--rw default-pcp? uint8 510 | +--:(asymmetrical) 511 | +--rw asymmetrical-operation 512 | +--rw ingress 513 | | +--rw pop-tags? uint8 514 | | +--rw push-tags 515 | | +--rw outer-tag! 516 | | | +--rw tag-type? 517 | | | | etht-types:eth-tag-type 518 | | | +--rw vlan-value? 519 | | | | etht-types:vlanid 520 | | | +--rw default-pcp? uint8 521 | | +--rw second-tag! 522 | | +--rw tag-type? 523 | | | etht-types:eth-tag-type 524 | | +--rw vlan-value? 525 | | | etht-types:vlanid 526 | | +--rw default-pcp? uint8 527 | +--rw egress 528 | +--rw pop-tags? uint8 529 | +--rw push-tags 530 | +--rw outer-tag! 531 | | +--rw tag-type? 532 | | | etht-types:eth-tag-type 533 | | +--rw vlan-value? 534 | | | etht-types:vlanid 535 | | +--rw default-pcp? uint8 536 | +--rw second-tag! 537 | +--rw tag-type? 538 | | etht-types:eth-tag-type 539 | +--rw vlan-value? 540 | | etht-types:vlanid 541 | +--rw default-pcp? uint8 542 +--rw underlay 543 | +--rw (technology)? 544 | | +--:(native-ethernet) 545 | | | +--rw eth-tunnels* [name] 546 | | | +--rw name 547 | | | | -> /te:te/tunnels/tunnel/name 548 | | | +--rw encoding? identityref 549 | | | +--rw switching-type? identityref 550 | | +--:(frame-base) 551 | | | +--rw otn-tunnels* [name] 552 | | | +--rw name 553 | | | | -> /te:te/tunnels/tunnel/name 554 | | | +--rw encoding? identityref 555 | | | +--rw switching-type? identityref 556 | | +--:(mpls-tp) 557 | | +--rw pw 558 | | +--rw pw-id? 559 | | | string 560 | | +--rw pw-name? 561 | | | string 562 | | +--rw transmit-label? 563 | | | rt-types:mpls-label 564 | | +--rw receive-label? 565 | | | rt-types:mpls-label 566 | | +--rw encapsulation-type? 567 | | | identityref 568 | | +--ro oper-status? 569 | | | identityref 570 | | +--rw ingress-bandwidth-profile 571 | | | +--rw (style)? 572 | | | +--:(named) 573 | | | | +--rw bandwidth-profile-name? leafref 574 | | | +--:(value) 575 | | | +--rw bandwidth-profile-type? 576 | | | | etht-types:bandwidth-profile-type 577 | | | +--rw CIR? 578 | | | | uint64 579 | | | +--rw CBS? 580 | | | | uint64 581 | | | +--rw EIR? 582 | | | | uint64 583 | | | +--rw EBS? 584 | | | uint64 585 | | +--rw pw-paths* [path-id] 586 | | +--rw path-id uint8 587 | | +--rw tp-tunnels* [name] 588 | | +--rw name string 589 | +--rw src-split-horizon-group? string 590 | +--rw dst-split-horizon-group? string 591 +--rw admin-status? identityref 592 +--ro state 593 +--ro operational-state? identityref 594 +--ro provisioning-state? identityref 595 +--ro creation-time? yang:date-and-time 596 +--ro last-updated-time? yang:date-and-time 598 4.2. YANG Tree for other Transport Network Client Signal Model 599 module: ietf-trans-client-service 600 +--rw client-svc 601 +--rw client-svc-instances* [client-svc-name] 602 +--rw client-svc-name string 603 +--rw client-svc-title? string 604 +--rw client-svc-descr? string 605 +--rw client-svc-customer? string 606 +--rw resilience 607 +--rw te-topology-identifier 608 | +--rw provider-id? te-global-id 609 | +--rw client-id? te-global-id 610 | +--rw topology-id? te-topology-id 611 +--rw admin-status? identityref 612 +--rw src-access-ports 613 | +--rw access-node-id? te-types:te-node-id 614 | +--rw access-ltp-id? te-types:te-tp-id 615 | +--rw client-signal? identityref 616 +--rw dst-access-ports 617 | +--rw access-node-id? te-types:te-node-id 618 | +--rw access-ltp-id? te-types:te-tp-id 619 | +--rw client-signal? identityref 620 +--rw direction? identityref 621 +--rw svc-tunnels* [tunnel-name] 622 | +--rw tunnel-name string 623 +--ro operational-state? identityref 624 +--ro provisioning-state? identityref 625 +--ro creation-time? yang:date-and-time 626 +--ro last-updated-time? yang:date-and-time 628 5. YANG Code for Transport Network Client Signal 630 5.1. The ETH Service YANG Code 632 This module imports typedefs and modules from [RFC6991], [RFC8294], 633 [I-D.ietf-teas-yang-te-types]. 635 file "ietf-eth-tran-service@2019-11-03.yang" 636 module ietf-eth-tran-service { 637 yang-version 1.1; 638 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-tran-service"; 640 prefix "ethtsvc"; 642 import ietf-yang-types { 643 prefix "yang"; 644 reference "RFC 6991 - Common YANG Data Types"; 645 } 647 import ietf-te-types { 648 prefix "te-types"; 649 reference "RFC YYYY - Traffic Engineering Common YANG Types"; 650 } 652 import ietf-eth-tran-types { 653 prefix "etht-types"; 654 reference "RFC XXXX - A YANG Data Model for Transport 655 Network Client Signals"; 656 } 658 import ietf-routing-types { 659 prefix "rt-types"; 660 reference "RFC 8294 - Common YANG Data Types for the 661 Routing Area"; 663 } 665 import ietf-te { 666 prefix "te"; 667 reference "RFC YYYY - A YANG Data Model for Traffic 668 Engineering Tunnels and Interfaces"; 669 } 671 organization 672 "Internet Engineering Task Force (IETF) CCAMP WG"; 673 contact 674 " 675 WG List: 677 ID-draft editor: 678 Haomian Zheng (zhenghaomian@huawei.com); 679 Italo Busi (italo.busi@huawei.com); 680 Aihua Guo (aihuaguo.ietf@gmail.com); 681 Anton Snitser (antons@sedonasys.com);0 682 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 683 Yunbin Xu (xuyunbin@caict.ac.cn); 684 Yang Zhao (zhaoyangyjy@chinamobile.com); 685 Xufeng Liu (xufeng.liu.ietf@gmail.com); 686 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 687 "; 689 description 690 "This module defines a YANG data model for describing 691 the Ethernet services. The model fully conforms to the 692 Network Management Datastore Architecture (NMDA). 694 Copyright (c) 2019 IETF Trust and the persons 695 identified as authors of the code. All rights reserved. 697 Redistribution and use in source and binary forms, with or 698 without modification, is permitted pursuant to, and subject 699 to the license terms contained in, the Simplified BSD License 700 set forth in Section 4.c of the IETF Trust's Legal Provisions 701 Relating to IETF Documents 702 (https://trustee.ietf.org/license-info). 703 This version of this YANG module is part of RFC XXXX; see 704 the RFC itself for full legal notices."; 706 revision 2019-11-03 { 707 description 708 "version -01 as an WG document"; 709 reference 710 "draft-ietf-ccamp-client-signal-yang"; 711 } 713 /* 714 * Groupings 715 */ 717 grouping vlan-classification { 718 description 719 "A grouping which represents classification 720 on an 802.1Q VLAN tag."; 722 leaf tag-type { 723 type etht-types:eth-tag-classify; 724 description 725 "The tag type used for VLAN classification."; 726 } 727 choice individual-bundling-vlan { 728 description 729 "VLAN based classification can be individual 730 or bundling."; 732 case individual-vlan { 733 leaf vlan-value { 734 type etht-types:vlanid; 735 description 736 "VLAN ID value."; 737 } 738 } 739 case vlan-bundling { 740 leaf vlan-range { 741 type etht-types:vid-range-type; 742 description 743 "List of VLAN ID values."; 744 } 745 } 746 } 747 } 749 grouping vlan-write { 750 description 751 "A grouping which represents push/pop operations 752 of an 802.1Q VLAN tag."; 754 leaf tag-type { 755 type etht-types:eth-tag-type; 756 description 757 "The VLAN tag type to push/swap."; 758 } 759 leaf vlan-value { 760 type etht-types:vlanid; 761 description 762 "The VLAN ID value to push/swap."; 763 } 764 /* 765 * To be added: this attribute is used when: 766 * a) the ETH service has only one CoS (as in current version) 767 * b) as a default when a mapping between a given CoS value 768 * and the PCP value is not defined (in future versions) 769 */ 770 leaf default-pcp { 771 type uint8 { 772 range "0..7"; 773 } 774 description 775 "The default Priority Code Point (PCP) value to push/swap"; 776 } 777 } 779 grouping vlan-operations { 780 description 781 "A grouping which represents VLAN operations."; 783 leaf pop-tags { 784 type uint8 { 785 range "1..2"; 786 } 787 description 788 "The number of VLAN tags to pop (or swap if used in 789 conjunction with push-tags)"; 790 } 791 container push-tags { 792 description 793 "The VLAN tags to push (or swap if used in 794 conjunction with pop-tags)"; 796 container outer-tag { 797 presence 798 "Indicates existence of the outermost VLAN tag to 799 push/swap"; 801 description 802 "The outermost VLAN tag to push/swap."; 804 uses vlan-write; 805 } 806 container second-tag { 807 must 808 '../outer-tag/tag-type = "etht-types:s-vlan-tag-type" and ' + 809 'tag-type = "etht-types:c-vlan-tag-type"' 810 { 812 error-message 813 " 814 When pushing/swapping two tags, the outermost tag must 815 be specified and of S-VLAN type and the second 816 outermost tag must be of C-VLAN tag type. 817 "; 818 description 819 " 820 For IEEE 802.1Q interoperability, when pushing/swapping 821 two tags, it is required that the outermost tag exists 822 and is an S-VLAN, and the second outermost tag is a 823 C-VLAN. 824 "; 825 } 827 presence 828 "Indicates existence of a second outermost VLAN tag to 829 push/swap"; 831 description 832 "The second outermost VLAN tag to push/swap."; 834 uses vlan-write; 836 } 837 } 838 } 840 grouping named-or-value-bandwidth-profile { 841 description 842 "A grouping to configure a bandwdith profile either by 843 referencing a named bandwidth profile or by 844 configuring the values of the bandwidth profile attributes."; 845 choice style { 846 description 847 "Whether the bandwidth profile is named or defined by value"; 849 case named { 850 description 851 "Named bandwidth profile."; 852 leaf bandwidth-profile-name { 853 type "string"; 854 description 855 "Name of the bandwidth profile."; 856 } 857 } 858 case value { 859 description 860 "Bandwidth profile configured by value."; 861 uses etht-types:etht-bandwidth-profiles; 862 } 863 } 864 } 866 grouping bandwidth-profiles { 867 description 868 "A grouping which represent bandwidth profile configuration."; 870 choice direction { 871 description 872 "Whether the bandwidth profiles are symmetrical or 873 asymmetrical"; 874 case symmetrical { 875 description 876 "The same bandwidth profile is used to describe both 877 the ingress and the egress bandwidth profile."; 878 container ingress-egress-bandwidth-profile { 879 description 880 "The bandwdith profile used in both directions."; 881 uses named-or-value-bandwidth-profile; 882 } 883 } 884 case asymmetrical { 885 description 886 "Ingress and egress bandwidth profiles can be specified."; 887 container ingress-bandwidth-profile { 888 description 889 "The bandwdith profile used in the ingress direction."; 890 uses named-or-value-bandwidth-profile; 891 } 892 container egress-bandwidth-profile { 893 description 894 "The bandwdith profile used in the egress direction."; 895 uses named-or-value-bandwidth-profile; 896 } 897 } 898 } 899 } 901 grouping etht-svc-access-parameters { 902 description 903 "ETH services access parameters"; 905 leaf access-node-id { 906 type te-types:te-node-id; 907 description 908 "The identifier of the access node in 909 the ETH topology."; 910 } 911 leaf access-ltp-id { 912 type te-types:te-tp-id; 913 description 914 "The TE link termination point identifier, used 915 together with access-node-id to identify the 916 access LTP."; 917 } 918 leaf access-role { 919 type identityref { 920 base etht-types:access-role; 921 } 922 description 923 "Indicate the role of access, e.g., working or protection. "; 924 } 926 container pm-config { 927 uses pm-config-grouping; 928 description 929 "This grouping is used to set the threshold value for 930 performance monitoring. "; 931 } 932 container state { 933 config false; 934 description 935 "The state is used to monitor the status of service. "; 936 leaf operational-state { 937 type identityref { 938 base te-types:tunnel-state-type; 939 } 940 description 941 "Indicating the operational state of client signal. "; 942 } 943 leaf provisioning-state { 944 type identityref { 945 base te-types:lsp-state-type; 946 } 947 description 948 "Indicating the provisional state of client signal, 949 especially when there is a change, i.e., revise, create. "; 950 } 951 } 953 leaf performance { 954 type identityref { 955 base etht-types:performance; 956 } 957 config false; 958 description 959 "Performance Monitoring for the service. "; 960 } 962 } 964 grouping etht-svc-tunnel-parameters { 965 description 966 "ETH services tunnel parameters."; 967 choice technology { 968 description 969 "Service multiplexing is optional and flexible."; 971 case native-ethernet { 972 /* 973 placeholder to support proprietary multiplexing 974 (for further discussion) 975 */ 976 list eth-tunnels { 977 key name; 978 description 980 "ETH Tunnel list in native Ethernet scenario."; 981 uses tunnels-grouping; 982 } 983 } 985 case frame-base { 986 list otn-tunnels { 987 key name; 988 description 989 "OTN Tunnel list in Frame-based scenario."; 990 uses tunnels-grouping; 991 } 992 } 994 case mpls-tp { 995 container pw { 996 description 997 "Pseudowire information for Ethernet over MPLS-TP."; 998 uses pw-segment-grouping; 999 } 1000 } 1001 } 1003 /* 1004 * Open issue: can we constraints it to be used only with mp services? 1005 */ 1006 leaf src-split-horizon-group { 1007 type string; 1008 description 1009 "Identify a split horizon group at the Tunnel source TTP"; 1010 } 1011 leaf dst-split-horizon-group { 1012 type string; 1013 description 1014 "Identify a split horizon group at the Tunnel destination TTP"; 1015 } 1016 } 1018 grouping etht-svc-pm-threshold-config { 1019 description 1020 "Configuraiton parameters for Ethernet service PM thresholds."; 1022 leaf sending-rate-high { 1023 type uint64; 1024 description 1025 "High threshold of packet sending rate in kbps."; 1026 } 1027 leaf sending-rate-low { 1028 type uint64; 1029 description 1030 "Low threshold of packet sending rate in kbps."; 1031 } 1032 leaf receiving-rate-high { 1033 type uint64; 1034 description 1035 "High threshold of packet receiving rate in kbps."; 1036 } 1037 leaf receiving-rate-low { 1038 type uint64; 1039 description 1040 "Low threshold of packet receiving rate in kbps."; 1041 } 1042 } 1044 grouping etht-svc-pm-stats { 1045 description 1046 "Ethernet service PM statistics."; 1048 leaf sending-rate-too-high { 1049 type uint32; 1050 description 1051 "Counter that indicates the number of times the sending 1052 rate is above the high threshold"; 1053 } 1054 leaf sending-rate-too-low { 1055 type uint32; 1056 description 1057 "Counter that indicates the number of times the sending 1058 rate is below the low threshold"; 1059 } 1060 leaf receiving-rate-too-high { 1061 type uint32; 1062 description 1063 "Counter that indicates the number of times the receiving 1064 rate is above the high threshold"; 1065 } 1066 leaf receiving-rate-too-low { 1067 type uint32; 1068 description 1069 "Counter that indicates the number of times the receiving 1070 rate is below the low threshold"; 1071 } 1072 } 1074 grouping etht-svc-instance-config { 1075 description 1076 "Configuraiton parameters for Ethernet services."; 1078 leaf etht-svc-name { 1079 type string; 1080 description 1081 "Name of the ETH service."; 1082 } 1084 leaf etht-svc-title { 1085 type string; 1086 description 1087 "The Identifier of the ETH service."; 1088 } 1090 leaf etht-svc-descr { 1091 type string; 1092 description 1093 "Description of the ETH service."; 1094 } 1096 leaf etht-svc-customer { 1097 type string; 1098 description 1099 "Customer of the ETH service."; 1100 } 1102 leaf etht-svc-type { 1103 type etht-types:service-type; 1104 description 1105 "Type of ETH service (p2p, mp2mp or rmp)."; 1106 /* Add default as p2p */ 1107 } 1109 leaf etht-svc-lifecycle { 1110 type etht-types:lifecycle-status; 1111 description 1112 "Lifecycle state of ETH service."; 1113 /* Add default as installed */ 1114 } 1115 uses te-types:te-topology-identifier; 1117 uses resilience-grouping; 1119 list etht-svc-end-points { 1120 key etht-svc-end-point-name; 1121 description 1122 "The logical end point for the ETH service. "; 1123 uses etht-svc-end-point-grouping; 1125 } 1127 container underlay { 1128 description 1129 "The unterlay tunnel information that 1130 carrying the ETH service. "; 1131 uses etht-svc-tunnel-parameters; 1132 } 1134 leaf admin-status { 1135 type identityref { 1136 base te-types:tunnel-admin-state-type; 1137 } 1138 default te-types:tunnel-admin-state-up; 1139 description "ETH service administrative state."; 1140 } 1141 } 1143 grouping etht-svc-instance-state { 1144 description 1145 "State parameters for Ethernet services."; 1147 leaf operational-state { 1148 type identityref { 1149 base te-types:tunnel-state-type; 1150 } 1151 default te-types:tunnel-state-up; 1152 description "ETH service operational state."; 1153 } 1154 leaf provisioning-state { 1155 type identityref { 1156 base te-types:lsp-state-type; 1157 } 1158 description "ETH service provisioning state."; 1159 } 1160 leaf creation-time { 1161 type yang:date-and-time; 1162 description 1163 "Time of ETH service creation."; 1164 } 1165 leaf last-updated-time { 1166 type yang:date-and-time; 1167 description 1168 "Time of ETH service last update."; 1169 } 1171 } 1172 /* 1173 * Data nodes 1174 */ 1176 container etht-svc { 1177 description 1178 "ETH services."; 1180 container globals { 1181 description 1182 "Globals Ethernet configuration data container"; 1183 list named-bandwidth-profiles { 1184 key bandwidth-profile-name; 1185 description 1186 "List of named bandwidth profiles used by 1187 Ethernet services."; 1189 leaf bandwidth-profile-name { 1190 type string; 1191 description 1192 "Name of the bandwidth profile."; 1193 } 1194 uses etht-types:etht-bandwidth-profiles; 1195 } 1196 } 1198 list etht-svc-instances { 1199 key etht-svc-name; 1200 description 1201 "The list of p2p ETH service instances"; 1203 uses etht-svc-instance-config; 1205 container state { 1206 config false; 1207 description 1208 "Ethernet Service states."; 1210 uses etht-svc-instance-state; 1211 } 1212 } 1213 } 1215 grouping resilience-grouping { 1216 description 1217 "Grouping for resilience configuration. "; 1218 container resilience { 1219 description 1220 "To configure the data plane protection parameters, 1221 currently a placeholder only, future candidate attributes 1222 include, Revert, WTR, Hold-off Timer, ..."; 1223 uses te:protection-restoration-properties; 1224 } 1225 } 1227 grouping etht-svc-end-point-grouping { 1228 description 1229 "Grouping for the end point configuration."; 1230 leaf etht-svc-end-point-name { 1231 type string; 1232 description 1233 "The name of the logical end point of ETH service. "; 1234 } 1236 leaf etht-svc-end-point-id { 1237 type string; 1238 description 1239 "The identifier of the logical end point of ETH service."; 1240 } 1242 leaf etht-svc-end-point-descr { 1243 type string; 1244 description 1245 "The description of the logical end point of ETH service. "; 1246 } 1248 leaf topology-role { 1249 type identityref { 1250 base etht-types:topology-role; 1251 } 1252 description 1253 "Indicating the underlay topology role, 1254 e.g., hub,spoke, any-to-any "; 1255 } 1257 container resilience { 1258 description 1259 "Placeholder for resilience configuration, for future study. "; 1260 } 1262 list etht-svc-access-points { 1263 key access-point-id; 1264 min-elements "1"; 1265 /* 1266 Open Issue: 1267 Is it possible to limit the max-elements only for p2p services? 1268 max-elements "2"; 1269 */ 1270 description 1271 "List of the ETH trasport services access point instances."; 1273 leaf access-point-id { 1274 type string; 1275 description 1276 "ID of the service access point instance"; 1277 } 1278 uses etht-svc-access-parameters; 1279 } 1281 leaf service-classification-type { 1282 type identityref { 1283 base etht-types:service-classification-type; 1284 } 1285 description 1286 "Service classification type."; 1287 } 1289 choice service-classification { 1290 description 1291 "Access classification can be port-based or 1292 VLAN based."; 1294 case port-classification { 1295 /* no additional information */ 1296 } 1298 case vlan-classification { 1299 container outer-tag { 1300 presence "The outermost VLAN tag exists"; 1301 description 1302 "Classifies traffic using the outermost VLAN tag."; 1304 uses vlan-classification; 1305 } 1306 container second-tag { 1307 must 1308 '../outer-tag/tag-type = "etht-types:classify-s-vlan" and ' + 1309 'tag-type = "etht-types:classify-c-vlan"' 1310 { 1311 error-message 1312 " 1313 When matching two tags, the outermost tag must be 1314 specified and of S-VLAN type and the second 1315 outermost tag must be of C-VLAN tag type. 1317 "; 1318 description 1319 " 1320 For IEEE 802.1Q interoperability, when matching two 1321 tags, it is required that the outermost tag exists 1322 and is an S-VLAN, and the second outermost tag is a 1323 C-VLAN. 1324 "; 1325 } 1326 presence "The second outermost VLAN tag exists"; 1328 description 1329 "Classifies traffic using the second outermost VLAN tag."; 1331 uses vlan-classification; 1332 } 1333 } 1334 } 1336 /* 1337 * Open issue: can we constraints it to be used only with mp services? 1338 */ 1339 leaf split-horizon-group { 1340 type string; 1341 description "Identify a split horizon group"; 1342 } 1344 uses bandwidth-profiles; 1346 container vlan-operations { 1347 description 1348 "Configuration of VLAN operations."; 1349 choice direction { 1350 description 1351 "Whether the VLAN operations are symmetrical or 1352 asymmetrical"; 1353 case symmetrical { 1354 container symmetrical-operation { 1355 uses vlan-operations; 1356 description 1357 "Symmetrical operations. 1358 Expressed in the ingress direction, but 1359 the reverse operation is applied to egress traffic"; 1360 } 1361 } 1362 case asymmetrical { 1363 container asymmetrical-operation { 1364 description "Asymmetrical operations"; 1365 container ingress { 1366 uses vlan-operations; 1367 description "Ingress operations"; 1368 } 1369 container egress { 1370 uses vlan-operations; 1371 description "Egress operations"; 1372 } 1373 } 1374 } 1375 } 1376 } 1378 } 1380 grouping pm-config-grouping { 1381 description 1382 "Grouping used for Performance Monitoring Configuration. "; 1383 leaf pm-enable { 1384 type boolean; 1385 description 1386 "Whether to enable the performance monitoring."; 1387 } 1389 leaf sending-rate-high { 1390 type uint64; 1391 description 1392 "The upperbound of sending rate."; 1393 } 1395 leaf sending-rate-low { 1396 type uint64; 1397 description 1398 "The lowerbound of sending rate."; 1399 } 1401 leaf receiving-rate-high { 1402 type uint64; 1403 description 1404 "The upperbound of receiving rate."; 1405 } 1407 leaf receiving-rate-low { 1408 type uint64; 1409 description 1410 "The lowerbound of receiving rate."; 1411 } 1412 } 1413 grouping pw-segment-grouping { 1414 description 1415 "Grouping used for PW configuration. "; 1416 leaf pw-id { 1417 type string; 1418 description 1419 "The Identifier information of pseudowire. "; 1420 } 1422 leaf pw-name { 1423 type string; 1424 description 1425 "The name information of pseudowire."; 1426 } 1428 leaf transmit-label { 1429 type rt-types:mpls-label; 1430 description 1431 "Transmit label information in PW. "; 1432 } 1434 leaf receive-label { 1435 type rt-types:mpls-label; 1436 description 1437 "Receive label information in PW. "; 1438 } 1440 leaf encapsulation-type { 1441 type identityref { 1442 base etht-types:encapsulation-type; 1443 } 1444 description 1445 "The encapsulation type, raw or tag. "; 1446 } 1448 leaf oper-status { 1449 type identityref { 1450 base te-types:tunnel-state-type; 1451 } 1452 config false; 1453 description 1454 "The operational state of the PW segment. "; 1455 } 1457 container ingress-bandwidth-profile { 1458 description 1459 "Bandwidth Profile for ingress. "; 1460 uses pw-segment-named-or-value-bandwidth-profile; 1462 } 1464 list pw-paths { 1465 key path-id; 1466 description 1467 "A list of pw paths. "; 1469 leaf path-id { 1470 type uint8; 1471 description 1472 "The identifier of pw paths. "; 1474 } 1476 list tp-tunnels { 1477 key name; 1478 description 1479 "Names of TP Tunnel underlay"; 1480 leaf name { 1481 type string; 1482 description 1483 "Names of TP Tunnel underlay"; 1484 } 1485 } 1486 } 1488 } 1490 grouping pw-segment-named-or-value-bandwidth-profile { 1491 description 1492 "A grouping to configure a bandwdith profile either by 1493 referencing a named bandwidth profile or by 1494 configuring the values of the bandwidth profile attributes."; 1495 choice style { 1496 description 1497 "Whether the bandwidth profile is named or defined by value"; 1498 case named { 1499 description 1500 "Named bandwidth profile."; 1501 leaf bandwidth-profile-name { 1502 type leafref { 1503 path "/ethtsvc:etht-svc/ethtsvc:globals/" 1504 + "ethtsvc:named-bandwidth-profiles/" 1505 + "ethtsvc:bandwidth-profile-name"; 1506 } 1507 description 1508 "Name of the bandwidth profile."; 1509 } 1511 } 1512 case value { 1513 description 1514 "Bandwidth profile configured by value."; 1515 uses etht-types:pw-segement-bandwidth-profile-grouping; 1516 } 1517 } 1518 } 1520 grouping tunnels-grouping { 1521 description 1522 "A group of tunnels. "; 1523 leaf name { 1524 type leafref { 1525 path "/te:te/te:tunnels/te:tunnel/te:name"; 1526 require-instance false; 1527 } 1528 description "Dependency tunnel name"; 1529 } 1530 leaf encoding { 1531 type identityref { 1532 base te-types:lsp-encoding-types; 1533 } 1534 description "LSP encoding type"; 1535 reference "RFC3945"; 1536 } 1537 leaf switching-type { 1538 type identityref { 1539 base te-types:switching-capabilities; 1540 } 1541 description "LSP switching type"; 1542 reference "RFC3945"; 1543 } 1544 } 1545 } 1546 1548 5.2. YANG Code for ETH type 1550 This module references a few documents including [RFC2697], 1551 [RFC2698], [RFC4115], [IEEE802.1ad], [IEEE802.1q] and [MEF10]. 1553 file "ietf-eth-tran-types@2019-11-03.yang" 1554 module ietf-eth-tran-types { 1555 yang-version 1.1; 1556 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-tran-types"; 1557 prefix "etht-types"; 1559 organization 1560 "Internet Engineering Task Force (IETF) CCAMP WG"; 1561 contact 1562 " 1563 WG List: 1565 ID-draft editor: 1566 Haomian Zheng (zhenghaomian@huawei.com); 1567 Italo Busi (italo.busi@huawei.com); 1568 Aihua Guo (aihuaguo.ietf@gmail.com); 1569 Anton Snitser (antons@sedonasys.com);0 1570 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 1571 Yunbin Xu (xuyunbin@caict.ac.cn); 1572 Yang Zhao (zhaoyangyjy@chinamobile.com); 1573 Xufeng Liu (xufeng.liu.ietf@gmail.com); 1574 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 1575 "; 1577 description 1578 "This module defines the ETH types. 1579 The model fully conforms to the Network Management 1580 Datastore Architecture (NMDA). 1582 Copyright (c) 2019 IETF Trust and the persons 1583 identified as authors of the code. All rights reserved. 1585 Redistribution and use in source and binary forms, with or 1586 without modification, is permitted pursuant to, and subject 1587 to the license terms contained in, the Simplified BSD License 1588 set forth in Section 4.c of the IETF Trust's Legal Provisions 1589 Relating to IETF Documents 1590 (https://trustee.ietf.org/license-info). 1591 This version of this YANG module is part of RFC XXXX; see 1592 the RFC itself for full legal notices."; 1594 revision 2019-11-03 { 1595 description 1596 "version -01 as a WG draft"; 1597 reference 1598 "draft-ietf-ccamp-client-signal-yang"; 1599 } 1601 /* 1602 * Identities 1603 */ 1605 identity eth-vlan-tag-type { 1606 description 1607 "ETH VLAN tag type."; 1608 } 1610 identity c-vlan-tag-type { 1611 base eth-vlan-tag-type; 1612 description 1613 "802.1Q Customer VLAN"; 1614 } 1616 identity s-vlan-tag-type { 1617 base eth-vlan-tag-type; 1618 description 1619 "802.1Q Service VLAN (QinQ)"; 1620 } 1622 identity service-classification-type { 1623 description 1624 "Service classification."; 1625 } 1627 identity port-classification { 1628 base service-classification-type; 1629 description 1630 "Port classification."; 1631 } 1633 identity vlan-classification { 1634 base service-classification-type; 1635 description 1636 "VLAN classification."; 1637 } 1639 identity eth-vlan-tag-classify { 1640 description 1641 "VLAN tag classification."; 1642 } 1644 identity classify-c-vlan { 1645 base eth-vlan-tag-classify; 1646 description 1647 "Classify 802.1Q Customer VLAN tag. 1648 Only C-tag type is accepted"; 1649 } 1651 identity classify-s-vlan { 1652 base eth-vlan-tag-classify; 1653 description 1654 "Classify 802.1Q Service VLAN (QinQ) tag. 1655 Only S-tag type is accepted"; 1656 } 1658 identity classify-s-or-c-vlan { 1659 base eth-vlan-tag-classify; 1660 description 1661 "Classify S-VLAN or C-VLAN tag-classify. 1662 Either tag is accepted"; 1663 } 1665 identity bandwidth-profile-type { 1666 description 1667 "Bandwidth Profile Types"; 1668 } 1670 identity mef-10-bwp { 1671 base bandwidth-profile-type; 1672 description 1673 "MEF 10 Bandwidth Profile"; 1674 } 1676 identity rfc-2697-bwp { 1677 base bandwidth-profile-type; 1678 description 1679 "RFC 2697 Bandwidth Profile"; 1680 } 1682 identity rfc-2698-bwp { 1683 base bandwidth-profile-type; 1684 description 1685 "RFC 2698 Bandwidth Profile"; 1686 } 1688 identity rfc-4115-bwp { 1689 base bandwidth-profile-type; 1690 description 1691 "RFC 4115 Bandwidth Profile"; 1692 } 1694 identity service-type { 1695 description 1696 "Type of Ethernet service."; 1697 } 1699 identity p2p-svc { 1700 base service-type; 1701 description 1702 "Ethernet point-to-point service (EPL, EVPL)."; 1703 } 1705 identity rmp-svc { 1706 base service-type; 1707 description 1708 "Ethernet rooted-multitpoint service (E-TREE, EP-TREE)."; 1709 } 1711 identity mp2mp-svc { 1712 base service-type; 1713 description 1714 "Ethernet multipoint-to-multitpoint service (E-LAN, EP-LAN)."; 1715 } 1717 identity lifecycle-status { 1718 description 1719 "Lifecycle Status."; 1720 } 1722 identity installed { 1723 base lifecycle-status; 1724 description 1725 "Installed."; 1726 } 1728 identity planned { 1729 base lifecycle-status; 1730 description 1731 "Planned."; 1732 } 1734 identity pending-removal { 1735 base lifecycle-status; 1736 description 1737 "Pending Removal."; 1738 } 1740 /* 1741 * Type Definitions 1742 */ 1744 typedef eth-tag-type { 1745 type identityref { 1746 base eth-vlan-tag-type; 1747 } 1748 description 1749 "Identifies a specific ETH VLAN tag type."; 1750 } 1752 typedef eth-tag-classify { 1753 type identityref { 1754 base eth-vlan-tag-classify; 1755 } 1756 description 1757 "Identifies a specific VLAN tag classification."; 1758 } 1760 typedef vlanid { 1761 type uint16 { 1762 range "1..4094"; 1763 } 1764 description 1765 "The 12-bit VLAN-ID used in the VLAN Tag header."; 1766 } 1768 typedef vid-range-type { 1769 type string { 1770 pattern "([1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?" + 1771 "(,[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?)*)"; 1772 } 1773 description 1774 "A list of VLAN Ids, or non overlapping VLAN ranges, in 1775 ascending order, between 1 and 4094. 1776 This type is used to match an ordered list of VLAN Ids, or 1777 contiguous ranges of VLAN Ids. Valid VLAN Ids must be in the 1778 range 1 to 4094, and included in the list in non overlapping 1779 ascending order. 1781 For example: 1,10-100,50,500-1000"; 1782 } 1784 typedef bandwidth-profile-type { 1785 type identityref { 1786 base bandwidth-profile-type; 1787 } 1788 description 1789 "Identifies a specific Bandwidth Profile type."; 1790 } 1792 typedef service-type { 1793 type identityref { 1794 base service-type; 1795 } 1796 description 1797 "Identifies the type of Ethernet service."; 1798 } 1800 typedef lifecycle-status { 1801 type identityref { 1802 base lifecycle-status; 1803 } 1804 description 1805 "Identifies the lLifecycle Status ."; 1806 } 1808 /* 1809 * Grouping Definitions 1810 */ 1812 grouping etht-bandwidth-profiles { 1813 description 1814 "Bandwidth profile configuration paramters."; 1816 leaf bandwidth-profile-type { 1817 type etht-types:bandwidth-profile-type; 1818 description 1819 "The type of bandwidth profile."; 1820 } 1821 leaf CIR { 1822 type uint64; 1823 description 1824 "Committed Information Rate in Kbps"; 1825 } 1826 leaf CBS { 1827 type uint64; 1828 description 1829 "Committed Burst Size in in KBytes"; 1830 } 1831 leaf EIR { 1832 type uint64; 1833 /* Need to indicate that EIR is not supported by RFC 2697 1835 must 1836 '../bw-profile-type = "mef-10-bwp" or ' + 1837 '../bw-profile-type = "rfc-2698-bwp" or ' + 1838 '../bw-profile-type = "rfc-4115-bwp"' 1840 must 1841 '../bw-profile-type != "rfc-2697-bwp"' 1842 */ 1843 description 1844 "Excess Information Rate in Kbps 1845 In case of RFC 2698, PIR = CIR + EIR"; 1846 } 1847 leaf EBS { 1848 type uint64; 1849 description 1850 "Excess Burst Size in KBytes. 1851 In case of RFC 2698, PBS = CBS + EBS"; 1852 } 1853 leaf color-aware { 1854 type boolean; 1855 description 1856 "Indicates weather the color-mode is 1857 color-aware or color-blind."; 1858 } 1859 leaf coupling-flag { 1860 type boolean; 1861 /* Need to indicate that Coupling Flag is defined only for MEF 10 1863 must 1864 '../bw-profile-type = "mef-10-bwp"' 1865 */ 1866 description 1867 "Coupling Flag."; 1868 } 1869 } 1871 identity topology-role { 1872 description 1873 "The rold of underlay topology, e.g., 1874 hub, spoke, any-to-any. "; 1875 } 1877 identity resilience { 1878 description 1879 "Placeholder for resilience information in data plane, 1880 for future study. "; 1881 } 1883 identity access-role { 1884 description 1885 "Indicating whether the access is a working or protection access."; 1886 } 1888 identity performance { 1889 description 1890 "Placeholder for performace information, for future study."; 1891 } 1892 identity encapsulation-type { 1893 description 1894 "Indicating how the service is encapsulated (to PW), 1895 e.g, raw or tag. "; 1896 } 1898 grouping pw-segement-bandwidth-profile-grouping { 1899 description 1900 "bandwidth profile grouping for PW segment. "; 1901 leaf bandwidth-profile-type { 1902 type etht-types:bandwidth-profile-type; 1903 description 1904 "The type of bandwidth profile."; 1905 } 1906 leaf CIR { 1907 type uint64; 1908 description 1909 "Committed Information Rate in Kbps"; 1910 } 1911 leaf CBS { 1912 type uint64; 1913 description 1914 "Committed Burst Size in in KBytes"; 1915 } 1916 leaf EIR { 1917 type uint64; 1918 /* Need to indicate that EIR is not supported by RFC 2697 1920 must 1921 '../bw-profile-type = "mef-10-bwp" or ' + 1922 '../bw-profile-type = "rfc-2698-bwp" or ' + 1923 '../bw-profile-type = "rfc-4115-bwp"' 1925 must 1926 '../bw-profile-type != "rfc-2697-bwp"' 1927 */ 1928 description 1929 "Excess Information Rate in Kbps 1930 In case of RFC 2698, PIR = CIR + EIR"; 1931 } 1932 leaf EBS { 1933 type uint64; 1934 description 1935 "Excess Burst Size in KBytes. 1936 In case of RFC 2698, PBS = CBS + EBS"; 1937 } 1938 } 1939 grouping eth-bandwidth { 1940 description 1941 "Available bandwith for ethernet."; 1942 leaf eth-bandwidth { 1943 type uint64{ 1944 range "0..10000000000"; 1945 } 1946 units "Kbps"; 1947 description 1948 "Available bandwith value expressed in kilobits per second"; 1949 } 1950 } 1952 grouping eth-label-restriction { 1953 description 1954 "Label Restriction for ethernet."; 1955 leaf tag-type { 1956 type etht-types:eth-tag-type; 1957 description "VLAN tag type."; 1958 } 1959 leaf priority { 1960 type uint8; 1961 description "priority."; 1962 } 1963 } 1965 grouping eth-label { 1966 description 1967 "Label for ethernet."; 1968 leaf vlanid { 1969 type etht-types:vlanid; 1970 description 1971 "VLAN tag id."; 1972 } 1973 } 1975 grouping eth-label-step { 1976 description "Label step for Ethernet VLAN"; 1977 leaf eth-step { 1978 type uint16 { 1979 range "1..4095"; 1980 } 1981 default 1; 1982 description 1983 "Label step which represent possible increments for 1984 an Ethernet VLAN tag."; 1985 reference 1986 "IEEE 802.1ad: Provider Bridges."; 1987 } 1988 } 1990 } 1992 1994 5.3. Other Client Signal YANG Code 1996 This module imports typedefs and modules from [RFC6991], 1997 [I-D.ietf-ccamp-otn-tunnel-model], [I-D.ietf-teas-yang-te-types]. 1999 file "ietf-trans-client-service@2019-11-03.yang" 2000 module ietf-trans-client-service { 2001 /* TODO: FIXME */ 2002 yang-version 1.1; 2004 namespace "urn:ietf:params:xml:ns:yang:ietf-trans-client-service"; 2005 prefix "clntsvc"; 2007 import ietf-te-types { 2008 prefix "te-types"; 2009 reference "RFC YYYY - Traffic Engineering Common YANG Types"; 2010 } 2012 import ietf-layer1-types { 2013 prefix "layer1-types"; 2014 reference "RFC ZZZZ - A YANG Data Model for Layer 1 Types"; 2015 } 2017 import ietf-yang-types { 2018 prefix "yang"; 2019 reference "RFC 6991 - Common YANG Data Types"; 2020 } 2022 import ietf-trans-client-svc-types { 2023 prefix "clntsvc-types"; 2024 reference "RFC XXXX - A YANG Data Model for 2025 Transport Network Client Signals"; 2026 } 2028 organization 2029 "Internet Engineering Task Force (IETF) CCAMP WG"; 2030 contact 2031 " 2032 ID-draft editor: 2033 Haomian Zheng (zhenghaomian@huawei.com); 2034 Aihua Guo (aihuaguo.ietf@gmail.com); 2035 Italo Busi (italo.busi@huawei.com); 2036 Anton Snitser (antons@sedonasys.com); 2037 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 2038 Yunbin Xu (xuyunbin@caict.ac.cn); 2039 Yang Zhao (zhaoyangyjy@chinamobile.com); 2040 Xufeng Liu (Xufeng_Liu@jabil.com); 2041 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 2042 "; 2044 description 2045 "This module defines a YANG data model for describing 2046 transport network client services. The model fully conforms 2047 to the Network Management Datastore Architecture (NMDA). 2049 Copyright (c) 2019 IETF Trust and the persons 2050 identified as authors of the code. All rights reserved. 2052 Redistribution and use in source and binary forms, with or 2053 without modification, is permitted pursuant to, and subject 2054 to the license terms contained in, the Simplified BSD License 2055 set forth in Section 4.c of the IETF Trust's Legal Provisions 2056 Relating to IETF Documents 2057 (https://trustee.ietf.org/license-info). 2058 This version of this YANG module is part of RFC XXXX; see 2059 the RFC itself for full legal notices."; 2061 revision 2019-11-03 { 2062 description 2063 "version -01 as a WG document"; 2064 reference 2065 "draft-ietf-ccamp-client-signal-yang"; 2066 } 2068 /* 2069 * Groupings 2070 */ 2071 grouping client-svc-access-parameters { 2072 description 2073 "Transport network client signals access parameters"; 2075 leaf access-node-id { 2076 type te-types:te-node-id; 2077 description 2078 "The identifier of the access node in the underlying 2079 transport network topology."; 2080 } 2082 leaf access-ltp-id { 2083 type te-types:te-tp-id; 2084 description 2085 "The TE link termination point identifier, used together with 2086 access-node-id to identify the access LTP."; 2087 } 2089 leaf client-signal { 2090 type identityref { 2091 base layer1-types:client-signal; 2092 } 2093 description 2094 "Identify the client signal type associated with this port"; 2095 } 2097 } 2099 grouping client-svc-tunnel-parameters { 2100 description 2101 "Transport network client signals tunnel parameters"; 2103 leaf tunnel-name { 2104 type string; 2105 description 2106 "TE tunnel instance name."; 2107 } 2108 } 2110 grouping client-svc-instance-config { 2111 description 2112 "Configuration parameters for client services."; 2113 leaf client-svc-name { 2114 type string; 2115 description 2116 "Identifier of the p2p transport network client signals."; 2117 } 2119 leaf client-svc-title { 2120 type string; 2121 description 2122 "Name of the p2p transport network client signals."; 2123 } 2125 leaf client-svc-descr { 2126 type string; 2127 description 2128 "Description of the transport network client signals."; 2129 } 2130 leaf client-svc-customer { 2131 type string; 2132 description 2133 "Customer of the transport network client signals."; 2134 } 2136 container resilience { 2137 description "Place holder for resilience functionalities"; 2138 } 2140 uses te-types:te-topology-identifier; 2142 leaf admin-status { 2143 type identityref { 2144 base te-types:tunnel-admin-state-type; 2145 } 2146 default te-types:tunnel-admin-state-up; 2147 description "Client signals administrative state."; 2148 } 2150 container src-access-ports { 2151 description 2152 "Source access port of a client signal."; 2153 uses client-svc-access-parameters; 2154 } 2156 container dst-access-ports { 2157 description 2158 "Destination access port of a client signal."; 2159 uses client-svc-access-parameters; 2160 } 2162 leaf direction { 2163 type identityref { 2164 base clntsvc-types:direction; 2165 } 2166 description "Uni-dir or Bi-dir for the client signal."; 2167 } 2169 list svc-tunnels { 2170 key tunnel-name; 2171 description 2172 "List of the TE Tunnels supporting the client signal."; 2173 uses client-svc-tunnel-parameters; 2174 } 2175 } 2177 grouping client-svc-instance-state { 2178 description 2179 "State parameters for client services."; 2180 leaf operational-state { 2181 type identityref { 2182 base te-types:tunnel-state-type; 2183 } 2184 config false; 2185 description "Client signal operational state."; 2186 } 2187 leaf provisioning-state { 2188 type identityref { 2189 base te-types:lsp-state-type; 2190 } 2191 config false; 2192 description "Client signal provisioning state."; 2193 } 2194 leaf creation-time { 2195 type yang:date-and-time; 2196 config false; 2197 description "The time of the client signal be created."; 2198 } 2199 leaf last-updated-time { 2200 type yang:date-and-time; 2201 config false; 2202 description "The time of the client signal's latest update."; 2203 } 2205 } 2207 /* 2208 * Data nodes 2209 */ 2211 container client-svc { 2212 description 2213 "Transport client services."; 2215 list client-svc-instances { 2216 key client-svc-name; 2217 description 2218 "The list of p2p transport client service instances"; 2220 uses client-svc-instance-config; 2221 uses client-svc-instance-state; 2222 } 2223 } 2224 } 2226 2228 5.4. Other Client Signal Types YANG Code 2230 This module defines the types for other client signal types. 2232 file "ietf-trans-client-service@2019-11-03.yang" 2234 module ietf-trans-client-svc-types { 2235 namespace "urn:ietf:params:xml:ns:yang:ietf-trans-client-svc-types"; 2236 prefix "clntsvc-types"; 2238 organization 2239 "Internet Engineering Task Force (IETF) CCAMP WG"; 2240 contact 2241 " 2242 ID-draft editor: 2243 Haomian Zheng (zhenghaomian@huawei.com); 2244 Aihua Guo (aihuaguo.ietf@gmail.com); 2245 Italo Busi (italo.busi@huawei.com); 2246 Anton Snitser (antons@sedonasys.com); 2247 Francesco Lazzeri (francesco.lazzeri@ericsson.com); 2248 Yunbin Xu (xuyunbin@caict.ac.cn); 2249 Yang Zhao (zhaoyangyjy@chinamobile.com); 2250 Xufeng Liu (Xufeng_Liu@jabil.com); 2251 Giuseppe Fioccola (giuseppe.fioccola@huawei.com); 2252 "; 2254 description 2255 "This module defines a YANG data model for describing 2256 transport network client types. The model fully conforms 2257 to the Network Management Datastore Architecture (NMDA). 2259 Copyright (c) 2019 IETF Trust and the persons 2260 identified as authors of the code. All rights reserved. 2262 Redistribution and use in source and binary forms, with or 2263 without modification, is permitted pursuant to, and subject 2264 to the license terms contained in, the Simplified BSD License 2265 set forth in Section 4.c of the IETF Trust's Legal Provisions 2266 Relating to IETF Documents 2267 (https://trustee.ietf.org/license-info). 2268 This version of this YANG module is part of RFC XXXX; see 2269 the RFC itself for full legal notices."; 2271 revision 2019-11-03 { 2272 description 2273 "version -01 as a WG document"; 2274 reference 2275 "draft-ietf-ccamp-client-signal-yang"; 2276 } 2278 identity direction { 2279 description 2280 "Direction information of Client Signal."; 2281 } 2283 identity bidirectional { 2284 base direction; 2285 description 2286 "Client Signal is bi-directional."; 2287 } 2289 identity unidirectional { 2290 base direction; 2291 description 2292 "Client Signal is uni-directional."; 2293 } 2295 } 2296 2298 6. Considerations and Open Issue 2300 Editor Notes: This section is used to note temporary discussion/ 2301 conclusion that to be fixed in the future version, and will be 2302 removed before publication. We currently categorize all the client 2303 signal types into transparent and non-transparent, with separate 2304 models. There was consensus that no common model is needed for these 2305 two categories. Further Alignment with RFC8407 would be required 2306 before publication. The RFC Editor will replace XXXX, YYYY and ZZZZ 2307 with the number assigned to the RFC once this draft becomes an RFC. 2309 7. IANA Considerations 2311 It is proposed that IANA should assign new URIs from the "IETF XML 2312 Registry" [RFC3688] as follows: 2314 URI: urn:ietf:params:xml:ns:yang:ietf-eth-tran-service 2315 Registrant Contact: The IESG 2316 XML: N/A; the requested URI is an XML namespace. 2318 URI: urn:ietf:params:xml:ns:yang:ietf-trans-client-service 2319 Registrant Contact: The IESG 2320 XML: N/A; the requested URI is an XML namespace. 2322 URI: urn:ietf:params:xml:ns:yang:ietf-eth-tran-types 2323 Registrant Contact: The IESG 2324 XML: N/A; the requested URI is an XML namespace. 2326 URI: urn:ietf:params:xml:ns:yang:ietf-trans-client-svc-types 2327 Registrant Contact: The IESG 2328 XML: N/A; the requested URI is an XML namespace. 2330 This document registers following YANG modules in the YANG Module 2331 Names registry [RFC6020]. 2333 name: ietf-eth-tran-service 2334 namespace: urn:ietf:params:xml:ns:yang:ietf-eth-tran-service 2335 prefix: ethtsvc 2336 reference: RFC XXXX: A YANG Data Model for Transport 2337 Network Client Signals 2339 name: ietf-eth-tran-types 2340 namespace: urn:ietf:params:xml:ns:yang:ietf-eth-tran-types 2341 prefix: etht-types 2342 reference: RFC XXXX: A YANG Data Model for Transport 2343 Network Client Signals 2345 name: ietf-trans-client-service 2346 namespace: urn:ietf:params:xml:ns:yang:ietf-trans-client-service 2347 prefix: clntsvc 2348 reference: RFC XXXX: A YANG Data Model for Transport 2349 Network Client Signals 2351 name: ietf-trans-client-svc-types 2352 namespace: urn:ietf:params:xml:ns:yang:ietf-trans-client-svc-types 2353 prefix: clntsvc-types 2354 reference: RFC XXXX: A YANG Data Model for Transport 2355 Network Client Signals 2357 8. Manageability Considerations 2359 TBD. 2361 9. Security Considerations 2363 The data following the model defined in this document is exchanged 2364 via, for example, the interface between an orchestrator and a network 2365 domain controller. 2367 The YANG module defined in this document can be accessed via the 2368 RESTCONF protocol defined in [RFC8040], or maybe via the NETCONF 2369 protocol [RFC6241]. 2371 There are a number of data nodes defined in the YANG module which are 2372 writable/creatable/deletable (i.e., config true, which is the 2373 default). These data nodes may be considered sensitive or vulnerable 2374 in some network environments. Write operations (e.g., POST) to these 2375 data nodes without proper protection can have a negative effect on 2376 network operations. 2378 10. Acknowledgements 2380 We would like to thank Igor Bryskin and Daniel King for their 2381 comments and discussions. 2383 11. Contributors 2385 Yanlei Zheng 2386 China Unicom 2387 Email: zhengyl@dimpt.com 2389 Zhe Liu 2390 Huawei Technologies, 2391 Email: liuzhe123@huawei.com 2393 Sergio Belotti 2394 Nokia, 2395 Email: sergio.belotti@nokia.com 2397 Yingxi Yao 2398 Shanghai Bell, 2399 yingxi.yao@nokia-sbell.com 2401 12. References 2403 12.1. Normative References 2405 [I-D.ietf-ccamp-l1csm-yang] 2406 Lee, Y., Lee, K., Zheng, H., Dhody, D., Dios, O., and D. 2407 Ceccarelli, "A YANG Data Model for L1 Connectivity Service 2408 Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-11 (work in 2409 progress), March 2020. 2411 [I-D.ietf-ccamp-otn-topo-yang] 2412 Zheng, H., Busi, I., Liu, X., Belotti, S., and O. Dios, "A 2413 YANG Data Model for Optical Transport Network Topology", 2414 draft-ietf-ccamp-otn-topo-yang-10 (work in progress), 2415 March 2020. 2417 [I-D.ietf-ccamp-otn-tunnel-model] 2418 Zheng, H., Busi, I., Belotti, S., Lopezalvarez, V., and Y. 2419 Xu, "OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel- 2420 model-10 (work in progress), March 2020. 2422 [I-D.ietf-teas-yang-te-topo] 2423 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 2424 O. Dios, "YANG Data Model for Traffic Engineering (TE) 2425 Topologies", draft-ietf-teas-yang-te-topo-22 (work in 2426 progress), June 2019. 2428 [I-D.ietf-teas-yang-te-types] 2429 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 2430 "Traffic Engineering Common YANG Types", draft-ietf-teas- 2431 yang-te-types-13 (work in progress), November 2019. 2433 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2434 the Network Configuration Protocol (NETCONF)", RFC 6020, 2435 DOI 10.17487/RFC6020, October 2010, 2436 . 2438 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2439 and A. Bierman, Ed., "Network Configuration Protocol 2440 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2441 . 2443 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 2444 RFC 6991, DOI 10.17487/RFC6991, July 2013, 2445 . 2447 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 2448 and K. Pithewan, "GMPLS Signaling Extensions for Control 2449 of Evolving G.709 Optical Transport Networks", RFC 7139, 2450 DOI 10.17487/RFC7139, March 2014, 2451 . 2453 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2454 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2455 . 2457 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2458 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2459 . 2461 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 2462 "Common YANG Data Types for the Routing Area", RFC 8294, 2463 DOI 10.17487/RFC8294, December 2017, 2464 . 2466 12.2. Informative References 2468 [IEEE802.1ad] 2469 IEEE, 802., "IEEE 802.1ad - Provider Bridges.", IEEE 2470 802.1ad , May 2006. 2472 [IEEE802.1q] 2473 IEEE, 802., "IEEE 802.1q - Virtual Bridged Local Area 2474 Networks", IEEE 802.1q , June 2005. 2476 [MEF10] MEF, 10., "Ethernet Services Attributes Phase 1", MEF10 , 2477 November 2004. 2479 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 2480 Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, 2481 . 2483 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 2484 Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999, 2485 . 2487 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2488 DOI 10.17487/RFC3688, January 2004, 2489 . 2491 [RFC4115] Aboul-Magd, O. and S. Rabie, "A Differentiated Service 2492 Two-Rate, Three-Color Marker with Efficient Handling of 2493 in-Profile Traffic", RFC 4115, DOI 10.17487/RFC4115, July 2494 2005, . 2496 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 2497 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 2498 DOI 10.17487/RFC8299, January 2018, 2499 . 2501 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 2502 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 2503 . 2505 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2506 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2507 . 2509 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2510 and R. Wilton, "Network Management Datastore Architecture 2511 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 2512 . 2514 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 2515 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 2516 DOI 10.17487/RFC8453, August 2018, 2517 . 2519 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 2520 Data Model for Layer 2 Virtual Private Network (L2VPN) 2521 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2522 2018, . 2524 Authors' Addresses 2526 Haomian Zheng 2527 Huawei Technologies 2528 H1 XiliuBeipo Village, Songshan Lake 2529 Dongguan, Guangdong 2530 China 2532 Email: zhenghaomian@huawei.com 2534 Aihua Guo 2535 Futurewei 2537 Email: aihuaguo.ietf@gmail.com 2538 Italo Busi 2539 Huawei Technologies 2541 Email: Italo.Busi@huawei.com 2543 Anton Snitser 2544 Sedona 2546 Email: antons@sedonasys.com 2548 Francesco Lazzeri 2549 Ericsson 2551 Email: francesco.lazzeri@ericsson.com 2553 Yunbin Xu 2554 CAICT 2556 Email: xuyunbin@caict.ac.cn 2558 Yang Zhao 2559 China Mobile 2561 Email: zhaoyangyjy@chinamobile.com 2563 Xufeng Liu 2564 Volta Networks 2566 Email: xufeng.liu.ietf@gmail.com 2568 Giuseppe Fioccola 2569 Huawei Technologies 2571 Email: giuseppe.fioccola@huawei.com