idnits 2.17.1 draft-shytyi-opsawg-vysm-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 215 has weird spacing: '...Balance vFire...' == Line 553 has weird spacing: '...oint-id str...' == Line 564 has weird spacing: '...oint-id str...' == Line 656 has weird spacing: '...oint-id str...' == Line 957 has weird spacing: '...rw link str...' == (5 more instances...) -- The document date (September 9, 2021) is 960 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-teas-sf-aware-topo-model' is defined on line 743, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-netmod-yang-packages-01 == Outdated reference: A later version (-12) exists of draft-ietf-teas-sf-aware-topo-model-03 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Shytyi 3 Internet-Draft L. Beylier 4 Intended status: Informational SFR 5 Expires: March 13, 2022 L. Iannone 6 Telecom ParisTech 7 September 9, 2021 9 A YANG Module for uCPE management. 10 draft-shytyi-opsawg-vysm-10 12 Abstract 14 This document provides a YANG data model for uCPE management (VYSM) 15 and definition of the uCPE equipment. The YANG Model serves as a 16 base framework for managing an universal Customer-Premises Equipment 17 (uCPE) subsystem. The model can be used by a Network Orchestrator. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 13, 2022. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Universal CPE . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. uCPE purpose . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. uCPE VNF ecosystem example . . . . . . . . . . . . . . . 4 58 3.3. Internal uCPE service example . . . . . . . . . . . . . . 5 59 4. YANG Model for uCPE management . . . . . . . . . . . . . . . 6 60 5. Components for uCPE Management . . . . . . . . . . . . . . . 7 61 6. Set of YANG Models . . . . . . . . . . . . . . . . . . . . . 9 62 7. Diagram overview of YANG Data Model tree for uCPE management 12 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 65 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 66 11. Normative References . . . . . . . . . . . . . . . . . . . . 17 67 Appendix A. Example of the uCPE resources management . . . . . . 18 68 Appendix B. Example of the uCPE resources management 69 (deprecated) . . . . . . . . . . . . . . . . . . . . 21 70 Appendix C. Deprecated VNF YANG Model . . . . . . . . . . . . . 22 71 Appendix D. XML example of deprecated YANG model . . . . . . . . 28 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 74 1. Introduction 76 Network Function Virtualization is a technology that allows to 77 virtualize the network services running on dedicated hardware. This 78 technology became a base for universal Customer-Premises Equipment 79 (uCPE). This document defines the uCPE as hardware with x86 80 capabilities that has a hypervisor. In other words, uCPE is a host 81 that may run multiple Virtual Machines with guest OSs, where each 82 Guest OS may represent a Physical Network Function. This document 83 presents the YANG Model (VYSM) to manage from an Orchestrator the 84 infrastructure inside the uCPE. 86 2. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 Link - is an entity that enables link layer communication of nodes. 94 Port - node connector to the link. 96 NE - Network Element. 98 NSYM - Network Yang Module. 100 VYSM - VNF YANG Model. 102 3. Universal CPE 104 Firstly, this document defines the platform that is controlled with 105 VYSM - universal CPE (uCPE). The uCPE as hardware with x86 106 capabilities that is generally running Linux distribution with 107 additional virtualization layer. Virtualization layer provides 108 virtual compute, virtual storage and virtual network resources. Each 109 VNF running in the uCPE requires the amount of virtual resources (for 110 example: 4 vCPUs, 4GB RAM, 40GB storage, 4 vPorts). VNFs MAY be 111 interconnected between each other and physical ports via Virtual 112 Networks. Topology construction and VM life-cycle management is 113 allowed via high level interface (Configuration can be done in the 114 same transaction). The figure below presents the uCPE architecture. 116 ----------------------------------------|-------------- 117 VNF1 VNF2 VNF3 | 118 ----------------------------------------| 119 Virtual Virtual Virtual | uCPE software 120 Compute Storage Networks| 121 ----------------------------------------|--------------- 122 PHY x86 RAM+PHY PHYsical| uCPE Hardware 123 processor storage ports | 125 The next elements can be managed in the uCPE: 127 o Virtual Network Funcitons: 129 * Number of assigned vCPUs. 131 * Size of allocated RAM. 133 * VNF day0 config (bootstrap). 135 * vLinks that are attached to the VNF. 137 o Virtual Switches: 139 * vLinks that are attached to the vSW. 141 o Virtual Links(vLinks). 143 o Physical Ports of the uCPE. 145 3.1. uCPE purpose 147 o uCPE replaces multiple types of equipment (Node#1 - Node#5) with 1 148 unit by virtualizing them as Virtual Network Functions on the top 149 of NFVIs: 151 : NODE #1 : NODE #2 : NODE #3 :NODE #4: NODE #5 : 152 : +-----------+ : +------+ : +------+ : +--+ : +-----+ : 153 .----|Aggregation|----|CE-L2 |----| CE-L3|----|FW|----|SDWAN|---LAN 154 : | switch | : | | : | | : | | : | | : 155 : +-----------+ : +------+ : +------+ : +--+ : +-----+ : 157 : NODE #1 : NODE #2 : 158 : : +.........................................+ : 159 : +-----------+ : | +------+ +------+ +--+ +-----+ | : 160 .--|Aggregation|---|--|CE-L2 |----| CE-L3|----|FW|---|SDWAN|-|---LAN 161 : | switch | : | | | | | | | | | | : 162 : +-----------+ : | +------+ +------+ +--+ +-----+ | : 163 : : | universal Customer-Premises Equipment | : 164 : : +-----------------------------------------+ : 166 o uCPE facilitates the interconnection between the Network Functions 167 (NF) as interconnection between NF is performed via virtual 168 links(that is part of the uCPE management). That means that no 169 need to hire technician to cable the equipment, it could be done 170 via orchestrator. 172 o uCPE facilitates the 0day configuration of the VNFs as its 0day 173 configuration can be putted remotely. 175 3.2. uCPE VNF ecosystem example 177 uCPE supports a Virtual Network Functions of different type: 179 o SD-WAN 181 o vRouter 183 o vFirewall 184 o vLB(vLoad Balancer) 186 o vCGNAT(vCarrier Grade NAT) 188 o virtual WAN Optimistaion 190 o vWireless LAN controller 192 o Other... 194 3.3. Internal uCPE service example 196 The VNF in the uCPE could be a vRouter or vFirewall or an SD-WAN that 197 is not a default part of virtual network resources of the uCPE. 198 Multiple VNFs MAY be instantiated in the uCPE. With support of links 199 and switches, VNFs MAY participate a service chains. Example of 200 service chains (Note that virtual switch "vs(WAN)" connected to LAN 201 ports and vSW(WAN) is connected to WAN ports): 203 o vSW(WAN)-l1-vRouter-l2-vSW(LAN). 205 o vSW(WAN)-l1-vRouter-l2-vSW(Service)-l3-vFirewall-l4-vSW(LAN). 207 o vSW(WAN)-l1-vRouter-l2-vSW(Service1)-l3-vFirewall-l4- 208 vSW(Service2)-l5-SD-WAN-l6-vSW(LAN). 210 o vSW(WAN)-l1-SDWAN-l2-vSW(Service)-l3-vFirewall-l4-vSW(LAN). 212 o 214 vSW(WAN1)--vRouter--+ 215 +--vLoadBalance vFirewall--vSW(LAN) 216 vSW(WAN2)--vRouter--+ | | 217 +-vSW(Service1)+ 219 o 221 vSW(WAN1)--vRouter(ISP1)--+ 222 +--SD-WAN vFirewall--vSW(LAN) 223 vSW(WAN2)--vRouter(ISP2)--+ | | 224 +-vSW(Service1)+ 226 4. YANG Model for uCPE management 228 Secondly, this document defines and classifies the YANG Model for 229 uCPE Management. This Module is modeled representation of the 230 specific network requirements. It provides abstraction of network 231 configuration and operations. The YANG Model for uCPE Management 232 does not describe all configuration to be performed on the devices, 233 but provides the configuration that is required for the "Network to 234 Network Element(s)" decomposition process RFC 8199 [RFC8199]. 235 Example of the decomposition is presented in the figure below. 237 The Network YANG module exposes the configuration commands via the 238 Northbound interfaces of the orchestrator. Therefore the set of the 239 commands modeled in the VYSM can be inputted via Notrhbound 240 interfaces(for example CLI). In the example the command "vm VNF1" is 241 passed via Northbound interface to the orchestrator. It defines the 242 virtual machine name. Further the same configuration MAY be 243 transformed to the one or multiple Network Element payloads (for 244 example xml for NETCONF) that carry an equivalent of commands such as 245 "nf nf-name VNF1" 246 +-+-+-+-+-+-+-+-+-+ 247 | | 248 | config t | 249 | vm VNF1 | 250 +-+-+-+-+-+-+-+-+-+ 251 # 252 # 253 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 : : 255 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ : 256 : | Network YANG Module | <= scope of this document : 257 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ : 258 : # : 259 : ############################## : 260 : # # # : 261 : '---------' '------------' '-----------' : 262 : 'Module1 ' ' Module 2 ' ' Module3 ' : 263 : '---------' '------------' '-----------' : 264 : # # # : 265 : # # ####################### : 266 : #### ############## # : 267 : # # # : 268 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 # # # 270 Network # element 1 Network # element 2 Network # element3 271 ++-+-+-+-+-+-+-+-+-+-+ -+-+-+-++-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+ 272 | domains domain VNF1| |tenants tenant name VNF1| |nf nf-name VNF1| 273 ++-+-+-+-+-+-+-+-+-+-+ -+-+-+-++-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+ 275 5. Components for uCPE Management 277 This section provides a components overview to manage the uCPE. 279 There are multiple RFCs and drafts produced by the IETF community, 280 that are referenced in the YANG tree to manage the uCPE. Each 281 document produced by the IETF covers a part of uCPE Management. The 282 list of the documents is provided below: 284 o [RFC8530] - logical network elements (VNFs) properties. 286 o [RFC8345] - definition of networks, nodes, node-termination- 287 points: network includes the uCPE with uCPE's physical termination 288 points. 290 o [I-D.ietf-teas-sf-aware-topo-model]physical ports and service 291 functions (VNFs) interconnection matrices (PhyPort-VNF, VNF-VNF). 293 o This document itself provides yang modules that completes the 294 existing documents produced by IETF. 296 This document introduces yang modules for 'logical network elements 297 properties(VNFs)" part: 299 o day0-info: mapping between variables inside of the bootstrap 300 config and required values in the list "day0-info". In the 301 bootstrap config the variable could be putted instead value. The 302 value could be set in the day0-info part (check the YANG model) 303 and after the value in the list will be mapped to the variable in 304 the bootstrap config. 306 o vCPU/vRAM/vDisk/VNF-ports leafs and lists. 308 The minimal list of yang models required for compilation of the YANG 309 tree to manage the uCPE is presented below: 311 o ieee-dot1Q-types 313 o ietf-interfaces 315 o ietf-ip 317 o ietf-logical-network-element 319 o ietf-network 321 o ietf-network-instance 323 o ietf-ietf-network-topology 325 o ietf-routing-types 327 o ietf-te-topology 329 o ietf-te-topology-sf 331 o ietf-te-types 333 o ietf-yang-schema-mount 335 o etsi-sol-006-deviation 337 o The YANG modules introduced in this document: 339 o 340 * ietf-ucpe-lne-properties 342 * ietf-ucpe-lt-virtual-link-id 344 * ietf-ucpe-ni-properties 346 * ietf-ucpe-node-type 348 6. Set of YANG Models 350 This section provides a YANG models that address uCPE netowork 351 service resources management oranized according to the ID 352 [I-D.ietf-netmod-yang-packages] 354 file "ietf-ucpe-network-service-pkg.json" 355 ========= NOTE: '\' line wrapping per BCP XX (RFC XXXX) =========== 357 { 358 "ietf-yang-instance-data:instance-data-set": { 359 "name": "ietf-ucpe-network-service-pkg", 360 "pkg-schema": { 361 package: "ietf-yang-package-defn-pkg@0.1.0.json" 362 }, 363 "description": "YANG package for universal CPE network service", 364 "content-data": { 365 "ietf-yang-package-instance:yang-package": { 366 "name": "ietf-ucpe-network-service-pkg", 367 "version": "0.0.1", 368 "timestamp": "2021-09-09T17:00:00Z", 369 "organization": "IETF OPSAWG Working Group", 370 "contact" : "WG Web: , \ 371 WG List: , \ 372 Author: ", 373 "description": "IETF uCPE network service YANG package.\ 374 \ 375 This package defines a small sample set of \ 376 YANG modules that could represent the basic set of \ 377 modules that a standard universal CPE device might be \ 378 expected \ 379 to support.", 381 "reference": "XXX, draft-shytyi-opsawg-vysm-10.xml", 382 "location": [ "https://github.com/dmytroshytyi/ucpe-ietf/\ 383 ietf-ucpe-service@v0.0.1.json" ], 384 "module": [ 385 { 386 "name": "ieee-dot1Q-types, 387 "revision": "2015-08-18", 388 "location": [ "/https://github.com/dmytroshytyi/\ 389 ucpe-ietf/blob/master/ieee-dot1Q-types.yang" ], 390 }, 391 { 392 "name": "ietf-interfaces", 393 "revision": "2018-02-20", 394 "location": [ "https://github.com/dmytroshytyi/\ 395 ucpe-ietf/blob/master/\ 396 ietf-interfaces%402018-02-20.yang" ], 397 }, 398 { 399 "name": "ietf-ip", 400 "revision": "2018-02-22", 401 "location": [ "https://github.com/dmytroshytyi/ucpe-ietf\ 402 /blob/master/ietf-ip%402018-02-22.yang" ], 403 }, 404 { 405 "name": "ietf-logical-network-element", 406 "revision": "2019-01-25", 407 "location": [ "https://github.com/dmytroshytyi/\ 408 ucpe-ietf/blob/master/\ 409 ietf-logical-network-element%402019-01-25.yang" ], 410 }, 411 { 412 "name": "ietf-network", 413 "revision": "2018-02-26", 414 "location": [ "https://github.com/dmytroshytyi/\ 415 ucpe-ietf/blob/master/\ 416 ietf-network%402018-02-26.yang" ], 417 }, 418 { 419 "name": "ietf-network-instance", 420 "revision": "2019-01-21", 421 "location": [ "https://github.com/dmytroshytyi/\ 422 ucpe-ietf/blob/master/\ 423 ietf-network-instance%402019-01-21.yang" ], 424 }, 425 { 426 "name": "ietf-network-topology", 427 "revision": "2018-02-26", 428 "location": [ "https://github.com/dmytroshytyi/\ 429 ucpe-ietf/blob/master/\ 430 ietf-network-topology%402018-02-26.yang" ], 431 }, 432 { 433 "name": "ietf-routing-types", 434 "revision": "2017-12-04", 435 "location": [ "https://github.com/dmytroshytyi/\ 436 ucpe-ietf/blob/master/\ 437 ietf-routing-types%402017-12-04.yang" ], 438 }, 439 { 440 "name": "ietf-te-topology", 441 "revision": "2019-02-07", 442 "location": [ "https://github.com/dmytroshytyi/\ 443 ucpe-ietf/blob/master/\ 444 ietf-te-topology%402019-02-07.yang" ], 445 }, 446 { 447 "name": "ietf-te-topology-sf", 448 "revision": "2019-11-03", 449 "location": [ "https://github.com/dmytroshytyi/\ 450 ucpe-ietf/blob/master/\ 451 ietf-te-topology-sf%402019-11-03.yang" ], 452 }, 453 { 454 "name": "ietf-te-types", 455 "revision": "2019-11-18", 456 "location": [ "https://github.com/dmytroshytyi/\ 457 ucpe-ietf/blob/master/\ 458 ietf-te-types%402019-11-18.yang" ], 459 }, 460 { 461 "name": "ietf-ucpe-lne-properties", 462 "revision": "2019-11-21", 463 "location": [ "https://github.com/dmytroshytyi/\ 464 ucpe-ietf/blob/master/\ 465 ietf-ucpe-lne-properties%402019-11-21.yang" ], 466 }, 467 { 468 "name": "ietf-ucpe-lt-virtual-link-id", 469 "revision": "2020-02-14", 470 "location": [ "https://github.com/dmytroshytyi/\ 471 ucpe-ietf/blob/master/\ 472 ietf-ucpe-lt-virtual-link-id%402020-02-14.yang" ], 473 }, 474 { 475 "name": "ietf-ucpe-ni-properties", 476 "revision": "2019-11-27", 477 "location": [ "https://github.com/dmytroshytyi/\ 478 ucpe-ietf/blob/master/\ 479 ietf-ucpe-ni-properties%402019-11-27.yang" ], 480 }, 481 { 482 "name": "ietf-ucpe-node-type", 483 "revision": "2020-02-14", 484 "location": [ "https://github.com/dmytroshytyi/\ 485 ucpe-ietf/blob/master/\ 486 ietf-ucpe-node-type%402020-02-14.yang" ], 487 }, 488 { 489 "name": "ietf-ucpe-ni-properties", 490 "revision": "2019-11-27", 491 "location": [ "https://github.com/dmytroshytyi/\ 492 ucpe-ietf/blob/master/\ 493 ietf-ucpe-ni-properties%402019-11-27.yang" ], 494 }, 495 { 496 "name": "ietf-yang-schema-mount", 497 "revision": "2019-01-14", 498 "location": [ "https://github.com/dmytroshytyi/\ 499 ucpe-ietf/blob/master/\ 500 ietf-yang-schema-mount%402019-01-14.yang" ], 501 }, 502 { 503 "name": "etsi-nfv-common-deviation", 504 "revision": "2020-06-10", 505 "location": [ "https://github.com/dmytroshytyi/\ 506 ucpe-ietf/blob/master/\ 507 submodules/etsi-nfv-common-deviation.yang" ], 508 }, 509 { 510 "name": "etsi-nfv-vnf-deviation", 511 "revision": "2020-06-10", 512 "location": [ "https://github.com/dmytroshytyi/\ 513 ucpe-ietf/blob/master/\ 514 submodules/etsi-nfv-vnf-deviation.yang" ], 515 } 516 ] 517 } 518 } 519 } 520 } 521 523 7. Diagram overview of YANG Data Model tree for uCPE management 525 This section provides an overview of the Data YANG Model that MAY be 526 made with "pyang" utility. The figure below presents the tree 527 diagram. 529 module: ietf-logical-network-element 530 +--rw logical-network-elements 531 +--rw logical-network-element* [name] 532 +--rw name string 533 +--rw managed? boolean 534 +--rw description? string 535 +--rw root 536 +--rw ietf-ucpe:logical-network-element-properties 537 +--rw ietf-ucpe:etsi 538 | +--rw ietf-ucpe:vnfd? -> /nfv/vnfd/id 539 | +--rw ietf-ucpe:vdu? -> /nfv/vnfd[id=current()\ 540 /../vnfd]/vdu/id 541 +--rw ietf-ucpe:supporting-node? -> /nw:networks\ 542 /network/node/node-id 543 +--rw ietf-ucpe:uuid? enumeration 544 +--rw ietf-ucpe:uuid-custom-value? string 545 +--rw ietf-ucpe:persistance-id? string 546 +--rw ietf-ucpe:pci-passthrough 547 | +--rw ietf-ucpe:device* [device-name] 548 | +--rw ietf-ucpe:device-name string 549 | +--rw ietf-ucpe:vendor-id? string 550 | +--rw ietf-ucpe:device-id? string 551 | +--rw ietf-ucpe:device-index? int64 552 +--rw ietf-ucpe:sf-cp-params* [sf-connection-point-id] 553 | +--rw ietf-ucpe:sf-connection-point-id string 554 | +--rw ietf-ucpe:io-acceleration 555 | | +--rw ietf-ucpe:interface-type? enumeration 556 | | +--rw ietf-ucpe:interface-model? enumeration 557 | | +--rw ietf-ucpe:number-of-queues? uint64 558 | +--rw ietf-ucpe:mac-params 559 | +--rw ietf-ucpe:mac-type? enumeration 560 | +--rw ietf-ucpe:custom-mac-address? string 561 +--rw ietf-ucpe:simplified-lne-props 562 | +--rw ietf-ucpe:sf-connection-points* \ 563 [sf-connection-point-id] 564 | | +--rw ietf-ucpe:sf-connection-point-id string 565 | +--rw ietf-ucpe:ram? uint64 566 | +--rw ietf-ucpe:cpu? uint64 567 | +--rw ietf-ucpe:storages* [id] 568 | +--rw ietf-ucpe:id string 569 | +--rw ietf-ucpe:location? string 570 +--rw ietf-ucpe:day0-config 571 +--rw ietf-ucpe:location? string 572 +--rw ietf-ucpe:day0-var-path? string 573 +--rw ietf-ucpe:variable* [name] 574 +--rw ietf-ucpe:name string 575 +--rw ietf-ucpe:value? string 576 module: ietf-network 577 +--rw networks 578 +--rw network* [network-id] 579 | +--rw network-id network-id 580 | +--rw network-types 581 | | +--rw tet:te-topology! 582 | | +--rw tet-sf:sf! 583 | +--rw supporting-network* [network-ref] 584 | | +--rw network-ref -> /networks/network\ 585 /network-id 586 | +--rw node* [node-id] 587 | | +--rw node-id node-id 588 | | +--rw supporting-node* [network-ref node-ref] 589 | | | +--rw network-ref -> ../../../supporting\ 590 -network/network-ref 591 | | | +--rw node-ref -> /networks/network\ 592 /node/node-id 593 | | +--rw nt:termination-point* [tp-id] 594 | | | +--rw nt:tp-id tp-id 595 | | | +--rw nt:supporting-termination-point* \ 596 [network-ref node-ref tp-ref] 597 | | | | +--rw nt:network-ref -> ../../../\ 598 nw:supporting-node/network-ref 599 | | | | +--rw nt:node-ref -> ../../../\ 600 nw:supporting-node/node-ref 601 | | | | +--rw nt:tp-ref -> \ 602 /nw:networks/network[nw:network-id=current()/ \ 603 ../network-ref]/node[nw:node-id=current()/\ 604 ../node-ref]/termination-point/tp-id 605 | | +--rw tet:te-node-id? te-types:te-node-id 606 | | +--rw tet:te! 607 | | | +--rw tet:te-node-template* -> ../../../..\ 608 /te/templates/node-template\ 609 /name {template}? 610 | | | +--rw tet:te-node-attributes 611 | | | | +--rw tet-sf:service-function 612 | | | | +--rw tet-sf:connectivity-matrices 613 | | | | | +--rw tet-sf:connectivity-matrix* [id] 614 | | | | | +--rw tet-sf:id uint32 615 | | | | | +--rw tet-sf:from 616 | | | | | | +--rw tet-sf:service-function-id? string 617 | | | | | | +--rw tet-sf:sf-connection-point-id? string 618 | | | | | +--rw tet-sf:to 619 | | | | | | +--rw tet-sf:service-function-id? string 620 | | | | | | +--rw tet-sf:sf-connection-point-id? string 621 | | | | | +--rw tet-sf:enabled? boolean 622 | | | | | +--rw tet-sf:direction? \ 623 connectivity-direction 624 | | | | | +--rw tet-sf:virtual-link-id? string 625 | | | | +--rw tet-sf:link-terminations 626 | | | | +--rw tet-sf:link-termination* [id] 627 | | | | +--rw tet-sf:id uint32 628 | | | | +--rw tet-sf:from 629 | | | | | +--rw tet-sf:tp-ref? -> ../../../../../\ 630 ../../nt:termination-point/tp-id 631 | | | | +--rw tet-sf:to 632 | | | | | +--rw tet-sf:service-function-id? \ 633 string 634 | | | | | +--rw tet-sf:sf-connection-point-id? \ 635 string 636 | | | | +--rw tet-sf:enabled? boolean 637 | | | | +--rw tet-sf:direction? \ 638 connectivity-direction 639 | | | | +--rw lt-vlink-id:virtual-link-id? string 641 module: ietf-network-instance 642 +--rw network-instances 643 +--rw network-instance* [name] 644 +--rw name string 645 +--rw enabled? boolean 646 +--rw description? string 647 +--rw (ni-type)? 648 +--rw (root-type) 649 +--:(vrf-root) 650 | +--rw vrf-root 651 +--:(vsi-root) 652 | +--rw vsi-root 653 | +--rw ietf-ucpe-ni:network-instance-properties 654 | +--rw ietf-ucpe-ni:sf-connection-points* \ 655 [sf-connection-point-id] 656 | | +--rw ietf-ucpe-ni:sf-connection-point-id string 657 | | +--rw ietf-ucpe-ni:stacked-vlans 658 | | | +--rw ietf-ucpe-ni:outer-VLAN-0x8100? \ 659 d1q:vid-range 660 | | | +--rw ietf-ucpe-ni:inner-VLANs-0x8100* uint16 661 | | +--rw ietf-ucpe-ni:QinQ 662 | | | +--rw ietf-ucpe-ni:svlan-0x88a8? d1q:vid-range 663 | | | +--rw ietf-ucpe-ni:cvlans-0x8100* uint16 664 | | +--rw ietf-ucpe-ni:dot1q-vlan 665 | | +--rw ietf-ucpe-ni:access-tag? \ 666 d1q:vid-range 667 | | +--rw ietf-ucpe-ni:trunk-allowed-vlans* \ 668 uint16 669 | | +--rw ietf-ucpe-ni:port-mode? \ 670 enumeration 671 | +--rw ietf-ucpe-ni:io-acceleration 672 | | +--rw ietf-ucpe-ni:dpdk 673 | | | +--rw ietf-ucpe-ni:rx-queues? uint16 674 | | | +--rw ietf-ucpe-ni:tx-queues? uint16 675 | | | +--rw ietf-ucpe-ni:cpu-mask? uint16 676 | | +--rw ietf-ucpe-ni:ebpf-xdp 677 | +--rw ietf-ucpe-ni:ni-area? identityref 678 | +--rw ietf-ucpe-ni:supporting-node? -> \ 679 /nw:networks\ 680 /network/node/node-id 681 +--:(vv-root) 682 +--rw vv-root 684 module: ietf-ucpe-lne-properties 685 +--rw nfv 686 +--rw vnfd* [id] 687 +--rw id string 688 +--rw provider string 689 +--rw product-name string 690 +--rw software-version string 691 +--rw version string 692 +--rw product-info-name? string 693 +--rw product-info-description? string 694 +--rw vnfm-info* string 695 +--rw localization-language? string 696 +--rw default-localization-language? string 697 +--rw vdu* [id] 698 | +--rw id string 699 | +--rw name string 700 | +--rw description? string 701 | +--rw int-cpd* [id] 702 etc... Following ETSI SOL006 704 8. Security Considerations 706 At this time, no security considerations are addressed by this memo. 708 9. IANA Considerations 710 No request to IANA at this time. 712 10. Acknowledgements 714 the authors would like to thank: 716 o Mahesh Jethanandani. 718 o Robert Varga. 720 o Bill Wu. 722 o Joe Clarke. 724 o Tom Petch. 726 o Martin Bjorklund. 728 o Schonwalder Jurgen. 730 o Dean Bogdanovic. 732 o Bo Wu. 734 for their valuable comments. 736 11. Normative References 738 [I-D.ietf-netmod-yang-packages] 739 Wilton, R., Rahman, R., Clarke, J., Sterne, J., and B. Wu, 740 "YANG Packages", draft-ietf-netmod-yang-packages-01 (work 741 in progress), November 2020. 743 [I-D.ietf-teas-sf-aware-topo-model] 744 Bryskin, I., Liu, X., Lee, Y., Guichard, J., Contreras, 745 L., Ceccarelli, D., and J. Tantsura, "SF Aware TE Topology 746 YANG Model", draft-ietf-teas-sf-aware-topo-model-03 (work 747 in progress), March 2019. 749 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 750 Requirement Levels", BCP 14, RFC 2119, 751 DOI 10.17487/RFC2119, March 1997, 752 . 754 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 755 Classification", RFC 8199, DOI 10.17487/RFC8199, July 756 2017, . 758 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 759 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 760 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 761 2018, . 763 [RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 764 Liu, "YANG Model for Logical Network Elements", RFC 8530, 765 DOI 10.17487/RFC8530, March 2019, 766 . 768 Appendix A. Example of the uCPE resources management 770 This section provides an overview of the YIN format. 772 773 774 network-1 775 776 777 778 779 780 781 ucpe1 782 0.0.0.0 784 785 786 788 789 790 1 791 792 VMone 793 1 794 795 796 SwitchOne 797 11 798 799 l11 800 801 802 2 803 804 VMtwo 805 1 806 807 808 SwitchOne 809 12 811 812 l12 813 814 815 3 816 817 VMthree 818 1 819 820 821 SwitchOne 822 13 823 824 l13 825 826 827 4 828 829 VMfour 830 1 831 832 833 SwitchOne 834 14 835 836 l14 837 838 839 840 841 842 843 844 846 848 849 VMfour 850 852 853 1 854 855 ucpe1 856 1024 857 4 858 859 1 860 vm4.qcow2 861 862 863 864 865 VMone 866 868 869 1 870 871 ucpe1 872 1024 873 4 874 875 1 876 vm1.qcow2 877 878 879 880 881 VMthree 882 884 885 1 886 887 ucpe 888 1024 889 4 890 891 1 892 vm3qcow2 893 894 895 896 897 VMtwo 898 900 901 1 902 903 ucpe1 904 1024 905 4 906 907 1 908 vm4.iso 909 910 911 912 913 915 916 SwitchOne 917 919 920 10 921 922 112 923 113 924 114 925 trunk 926 927 928 929 11 930 931 932 111 933 934 935 12 936 937 938 13 939 940 941 14 942 943 ucpe1 944 945 946 948 Appendix B. Example of the uCPE resources management (deprecated) 950 This section provides an overview of the deprecated YANG Model that 951 MAY give an alternative view on the uCPE management. 953 module: ietf-example-ucpe 954 +--rw ucpe* [name] 955 +--rw name string 956 +--rw links* [link] 957 | +--rw link string 958 +--rw phyInterfaces* [interface] 959 | +--rw interface string 960 | +--rw ports* [port] 961 | +--rw port string 962 | +--rw link? -> ../../../links/link 963 +--rw switches* [switch] 964 | +--rw switch string 965 | +--rw ports* [port] 966 | +--rw port string 967 | +--rw name? string 968 | +--rw link? -> ../../../links/link 969 +--rw vms* [vm] 970 +--rw vm string 971 +--rw ports* [port] 972 | +--rw port string 973 | +--rw name? string 974 | +--rw link? -> ../../../links/link 975 +--rw ram? uint64 976 +--rw cpu? uint64 977 +--rw storages* [id] 978 | +--rw id string 979 | +--rw location? string 980 +--rw day0-config 981 +--rw location? string 982 +--rw day0-var-path? string 983 +--rw variable* [name] 984 +--rw name string 985 +--rw value? string 987 Appendix C. Deprecated VNF YANG Model 989 This section provides a deprecated yang model that addresses the 990 configuration of the uCPE resources presented above. 992 file "ietf-example-ucpe@2019-10-28.yang" 993 module ietf-example-ucpe { 994 namespace "urn:ietf:params:xml:ns:yang:ietf-example-ucpe"; 995 prefix ietf-example-ucpe; 997 organization 998 "SFR"; 1000 contact 1001 "Dmytro Shytyi 1002 EMail:ietf.dmytro@shytyi.net"; 1003 description 1004 "This is a Network Function Virtualization (NFV) YANG 1005 service model. 1007 Copyright (c) 2019 IETF Trust and the persons identified as 1008 authors of the code. All rights reserved. 1010 Redistribution and use in source and binary forms, with or 1011 without modification, is permitted pursuant to, and subject to 1012 the license terms contained in, the Simplified BSD License set 1013 forth in Section 4.c of the IETF Trust's Legal Provisions 1014 Relating to IETF Documents 1015 (https://trustee.ietf.org/license-info). 1017 This version of this YANG module is part of RFC XXXX 1018 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 1019 for full legal notices."; 1021 revision 2019-10-28 { 1022 description 1023 "Yang model with vPorts assigned to the interfaces"; 1024 reference 1025 "draft-shytyi-opsawg-vysm-05"; 1026 } 1027 revision 2019-10-19 { 1028 description 1029 "Yang model was cleaned. Interfaces added"; 1030 reference 1031 "draft-shytyi-opsawg-vysm-04"; 1032 } 1033 revision 2019-09-16 { 1034 description 1035 "Added 0day config for VNFs. 1036 Yang model modified according 1037 to the received comments."; 1038 reference 1039 "draft-shytyi-opsawg-vysm-00"; 1040 } 1041 revision 2018-01-07 { 1042 description 1043 "Initial revision."; 1044 reference 1045 "draft-shytyi-netmod-vysm-01"; 1046 } 1047 list ucpe { 1048 key "name"; 1049 leaf name { 1050 type string; 1051 description 1052 "ID of uCPE where 1053 a service is instantiated"; 1054 } 1055 list links { 1056 key "link"; 1057 leaf link { 1058 type string; 1059 description 1060 "Name of the virtual link from the pool 1061 of the links"; 1062 } 1063 description 1064 "Pool of the virtual links that connect VMs and 1065 Interfaces"; 1066 } 1067 list phyInterfaces { 1068 key "interface"; 1069 leaf interface { 1070 type string; 1071 description 1072 "Name of physical interface"; 1073 } 1074 list ports { 1075 key "port"; 1076 leaf port { 1077 type string; 1078 description 1079 "Name of the connector"; 1080 } 1081 leaf link { 1082 type leafref { 1083 path "../../../links/link"; 1084 } 1085 description 1086 "Link that is connected to 1087 the port via connector"; 1088 } 1089 description 1090 "Set of the connectors the 1091 physical interface has"; 1092 } 1093 description 1094 "Set of physical interfaces"; 1096 } 1097 list switches { 1098 key "switch"; 1099 leaf switch { 1100 type string; 1101 description 1102 "Name of the forwarding domain"; 1103 } 1104 list ports { 1105 key "port"; 1106 leaf port { 1107 type string; 1108 description 1109 "Name of the connector"; 1110 } 1111 leaf name { 1112 type string; 1113 description 1114 "Name of the 1115 subconnector"; 1116 } 1117 leaf link { 1118 type leafref { 1119 path "../../../links/link"; 1120 } 1121 description 1122 "Link that is connected to the 1123 switch via port"; 1124 } 1125 description 1126 "Set of the connectors the 1127 forwarding domain has"; 1128 } 1129 description 1130 "Set of the forwarding domains"; 1131 } 1132 list vms { 1133 key "vm"; 1134 leaf vm { 1135 type string; 1136 description 1137 "ID of the Virtual Machine"; 1138 } 1139 list ports { 1140 key "port"; 1141 leaf port { 1142 type string; 1143 description 1144 "Name of the connector"; 1145 } 1146 leaf name { 1147 type string; 1148 description 1149 "Name of 1150 the subconnector"; 1151 } 1152 leaf link { 1153 type leafref { 1154 path "../../../links/link"; 1155 } 1156 description 1157 "Link that connects the 1158 VM with a switch or Interface 1159 via connector"; 1160 } 1161 description 1162 "Set of Virtual Machine connectors"; 1163 } 1164 leaf ram { 1165 type uint64; 1166 description 1167 "Size of RAM to allocate for 1168 the Guest OS"; 1169 } 1170 leaf cpu { 1171 type uint64; 1172 description 1173 "Number of vCPUs to 1174 allocate for the Guest OS"; 1175 } 1176 list storages { 1177 key "id"; 1178 leaf id { 1179 type string; 1180 description 1181 "Number of 1182 vDisk attached to the VM"; 1183 } 1184 leaf location { 1185 type string; 1186 description 1187 "External location where 1188 the image (ex.qcow2) is saved."; 1189 } 1190 description 1191 "Virtual storge/vDisk 1192 attached to the Virtual Machine"; 1193 } 1194 container day0-config { 1195 leaf location { 1196 type string; 1197 description 1198 "0day configuration location"; 1199 } 1200 leaf day0-var-path { 1201 type string; 1202 description 1203 "path of the file 1204 that contains the 0day variables"; 1205 } 1206 list variable { 1207 key "name"; 1208 leaf name { 1209 type string; 1210 description 1211 "variable name"; 1212 } 1213 leaf value { 1214 type string; 1215 description 1216 "variable value"; 1217 } 1218 description 1219 "list of variables"; 1220 } 1221 description 1222 "0day configuration:init config"; 1223 } 1224 description 1225 "Set of the Virtual Machines configured 1226 on the universal Customer-Premises Equipment"; 1227 } 1228 description 1229 "This is an uCPE management service"; 1230 } 1231 } 1233 1235 Appendix D. XML example of deprecated YANG model 1237 The XML example below presents the configuration of the next service 1238 in the uCPE, where: vSW(LAN), vSW(WAN), vSW(Service) - virtual 1239 switches; l1,l2,l3,l4 - virtual links; VMs represent PNFs (Physical 1240 Network Fuctions) that could be bootstrapped with 0day config/ 1241 license. 1243 +--------+ +-------------+ +------------+ 1244 |vSW(LAN)|--l2--|VNF-vFirewall|--l3--| | 1245 +--------+ +-------------+ | | 1246 +--------+ +-------------+ |vSW(Service)| 1247 |vSW(WAN)|--l1--| VNF_vRtr |--l4--| | 1248 +--------+ +-------------+ +------------+ 1250 1251 ucpe1 1252 1253 l1 1254 1255 1256 l2 1257 1258 1259 l3 1260 1261 1262 l4 1263 1264 1265 lan 1266 1267 10 1268 l2p10 1269 l2 1270 1271 1272 1273 service 1274 1275 10 1276 l3p10 1277 l3 1278 1279 1280 11 1281 l4p10 1282 l4 1283 1284 1285 1286 wan 1287 1288 10 1289 l1 1290 1291 1292 1293 VNF-vRtr 1294 1295 1 1296 l1p1 1297 l1 1298 1299 1300 2 1301 l4p2 1302 l4 1303 1304 2048 1305 2 1306 1307 1 1308 http://192.168.2.1/vRtr-x86.qcow2 1309 1310 1311 https://192.168.2.1/vRtr-day0.iso 1312 /config.rom 1313 1314 hostname 1315 IETF-vRtr 1316 1317 1318 ipaddress 1319 192.168.1.2 255.255.255.0 1320 1321 1322 1323 1324 VNF-vFirewall 1325 1326 1 1327 l3p1 1328 l3 1329 1330 1331 2 1332 l2p2 1333 l2 1334 1335 2048 1336 2 1337 1338 1 1339 http://192.168.2.1/vFirewall-x86.qcow2 1340 1341 1342 https://192.168.2.1/vFirewall-day0.iso 1343 /config.rom 1344 1345 hostname 1346 vFirewall 1347 1348 1349 ipaddress 1350 192.168.1.3 255.255.255.0 1351 1352 1353 1354 1356 Authors' Addresses 1358 Dmytro Shytyi 1359 SFR 1360 Paris , Ile-de-France 1361 France 1363 Email: ietf.dmytro@shytyi.net 1364 URI: https://dmytro.shytyi.net 1366 Laurent Beylier 1367 SFR 1368 Paris , Ile-de-France 1369 France 1371 Email: laurent.beylier@sfr.com 1372 Luigi Iannone 1373 Telecom ParisTech 1374 Paris , Ile-de-France 1375 France 1377 Email: luigi.iannone@telecom-paristech.fr