idnits 2.17.1 draft-shytyi-opsawg-vysm-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There 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 213 has weird spacing: '...Balance vFire...' == Line 403 has weird spacing: '...oint-id stri...' == Line 641 has weird spacing: '...rw link str...' == Line 643 has weird spacing: '...terface str...' == Line 645 has weird spacing: '...rw port str...' == (3 more instances...) -- The document date (November 20, 2019) is 1618 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 607, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-teas-sf-aware-topo-model-03 Summary: 0 errors (**), 0 flaws (~~), 10 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: May 23, 2020 L. Iannone 6 Telecom ParisTech 7 November 20, 2019 9 A YANG Module for uCPE management. 10 draft-shytyi-opsawg-vysm-07 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 May 23, 2020. 36 Copyright Notice 38 Copyright (c) 2019 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. Diagram overview of YANG Data Model tree for uCPE management 8 62 7. Logical Network Elements extension YANG Model . . . . . . . . 10 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 65 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 66 11. Normative References . . . . . . . . . . . . . . . . . . . . 14 67 Appendix A. Example of the uCPE resources management . . . . . . 15 68 Appendix B. Deprecated VNF YANG Model . . . . . . . . . . . . . 16 69 Appendix C. XML example of deprecated YANG model . . . . . . . . 22 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 72 1. Introduction 74 Network Function Virtualization is a technology that allows to 75 virtualize the network services running on dedicaded hardware. This 76 technology became a base for universal Customer-Premises Equipment 77 (uCPE). This document defines the uCPE as harware with x86 78 capabilities that has a hypervisor. In other words, uCPE is a host 79 that may run multiple Virtual Machines with guest OSs, where each 80 Guest OS may represent a Physical Network Function. This document 81 presents the YANG Model (VYSM) to manage from an Orchestrator the 82 infrastructure inside the uCPE. 84 2. Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [RFC2119]. 90 Link - is an entity that enables link layer communication of nodes. 92 Port - node connector to the link. 94 NE - Network Element. 96 NSYM - Network Yang Module. 98 VYSM - VNF YANG Model. 100 3. Universal CPE 102 Firstly, this document defines the platform that is controlled with 103 VYSM - universal CPE (uCPE). The uCPE as harware with x86 104 capabilities that is generally running Linux distibution with 105 additinal virtualisation layer. Virtualization layer provides 106 virtual compute, virtual storage and virtual network resources. Each 107 VNF runnning in the uCPE requires the amount of virtual resources 108 (for example: 4 vCPUs, 4GB RAM, 40GB storege, 4 vPorts). VNFs MAY be 109 interconnected between each other and physical ports via Virtual 110 Networks. Topology construction and VM lifecycle management is 111 allowed via high level interface (Configuration can be done in the 112 same transaction). The figure below presents the uCPE architecture. 114 ----------------------------------------|-------------- 115 VNF1 VNF2 VNF3 | 116 ----------------------------------------| 117 Virtual Virtual Virtual | uCPE software 118 Compute Storage Networks| 119 ----------------------------------------|--------------- 120 PHY x86 RAM+PHY PHYsical| uCPE Hardware 121 processor storage ports | 123 The next elements can be managed in the uCPE: 125 o Virtual Network Funcitons: 127 * Number of assigned vCPUs. 129 * Size of allocated RAM. 131 * VNF day0 config (bootstrap). 133 * vLinks that are attached to the VNF. 135 o Virtual Switches: 137 * vLinks that are attached to the vSW. 139 o Virtual Links(vLinks). 141 o Physical Ports of the uCPE. 143 3.1. uCPE purpose 145 o uCPE replaces multiple types of equipment (Node#1 - Node#5) with 1 146 unit by virtualizing them as Virtual Network Functions on the top 147 of NFVIs: 149 : NODE #1 : NODE #2 : NODE #3 :NODE #4: NODE #5 : 150 : +-----------+ : +------+ : +------+ : +--+ : +-----+ : 151 ...-----|Aggregation|----|CE-L2 |----| CE-L3|----|FW|----|SDWAN|---LAN 152 : | switch | : | | : | | : | | : | | : 153 : +-----------+ : +------+ : +------+ : +--+ : +-----+ : 155 : NODE #1 : NODE #2 : 156 : : +.........................................+ : 157 : +-----------+ : | +------+ +------+ +--+ +-----+ | : 158 ...---|Aggregation|---|--|CE-L2 |----| CE-L3|----|FW|---|SDWAN|-|---LAN 159 : | switch | : | | | | | | | | | | : 160 : +-----------+ : | +------+ +------+ +--+ +-----+ | : 161 : : | universal Customer-Premises Equipment | : 162 : : +-----------------------------------------+ : 164 o uCPE falicitates the interconnection between the Network Funtions 165 (NF) as interconnection between NF is performed via virtual 166 links(that is part of the uCPE management). That meens that no 167 need to hire technichian to cable the equipment, it could be done 168 via orchestrator. 170 o uCPE falicitates the 0day configuration of the VNFs as its 0day 171 configuration can be putted remotely. 173 3.2. uCPE VNF ecosystem example 175 uCPE supports a Virtual Network Funcitons of different type: 177 o SD-WAN 179 o vRouter 181 o vFirewall 183 o vLB(vLoad Balancer) 184 o vCGNAT(vCarrier Grade NAT) 186 o virtual WAN Optimistaion 188 o vWireless LAN controller 190 o Other... 192 3.3. Internal uCPE service example 194 The VNF in the uCPE could be a vRouter or vFirewall or an SD-WAN that 195 is not a default part of virtual network resources of the uCPE. 196 Multiple VNFs MAY be instantiated in the uCPE. With support of links 197 and swithes, VNFs MAY participate a service chains. Example of 198 service chains (Note that virtual switch "vs(WAN)" connected to LAN 199 ports and vSW(WAN) is connected to WAN ports): 201 o vSW(WAN)-l1-vRouter-l2-vSW(LAN). 203 o vSW(WAN)-l1-vRouter-l2-vSW(Service)-l3-vFirewall-l4-vSW(LAN). 205 o vSW(WAN)-l1-vRouter-l2-vSW(Service1)-l3-vFirewall-l4- 206 vSW(Service2)-l5-SD-WAN-l6-vSW(LAN). 208 o vSW(WAN)-l1-SDWAN-l2-vSW(Service)-l3-vFirewall-l4-vSW(LAN). 210 o 212 vSW(WAN1)--vRouter--+ 213 +--vLoadBalance vFirewall--vSW(LAN) 214 vSW(WAN2)--vRouter--+ | | 215 +-vSW(Service1)+ 217 o 219 vSW(WAN1)--vRouter(ISP1)--+ 220 +--SD-WAN vFirewall--vSW(LAN) 221 vSW(WAN2)--vRouter(ISP2)--+ | | 222 +-vSW(Service1)+ 224 4. YANG Model for uCPE management 226 Secondly, this document defines and classifies the YANG Model for 227 uCPE Management. This Module is modeled representation of the 228 specific network requirements. It provides abstraction of network 229 configuration and operations. The YANG Model for uCPE Management 230 does not describe all configuration to be performed on the devices, 231 but provides the configuration that is required for the "Network to 232 Network Element(s)" decomposition process RFC 8199 [RFC8199]. 233 Example of the decomposition is presented in the figure below. 235 The Network YANG module exposes the configuration commands via the 236 Northbound interfaces of the orchestrator. Therefore the set of the 237 commands modeled in the VYSM can be inputed via Notrhbound 238 interfaces(for example CLI). In the example the command "vm VNF1" is 239 passed via Northbound interface to the orchestrator. It defines the 240 virtual machine name. Further the same configuration MAY be 241 transormed to the one or multiple Network Element payloads (for 242 example xml for NETCONF) that carry an equivalent of commands such as 243 "nf nf-name VNF1" 244 +-+-+-+-+-+-+-+-+-+ 245 | | 246 | config t | 247 | vm VNF1 | 248 +-+-+-+-+-+-+-+-+-+ 249 # 250 # 251 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 : : 253 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ : 254 : | Network YANG Module | : 255 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ : 256 : # : 257 : ############################## : 258 : # # # : 259 : '---------' '------------' '-----------' : 260 : 'Module1 ' ' Module 2 ' ' Module3 ' <= Network Element : 261 : '---------' '------------' '-----------' YANG Modules : 262 : # # # : 263 : # # ####################### : 264 : #### ############## # : 265 : # # # : 266 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 # # # 268 Network # element 1 Network # element 2 Network # element3 269 ++-+-+-+-+-+-+-+-+-+-+ -+-+-+-++-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+ 270 | domains domain VNF1| |tenants tenant name VNF1| |nf nf-name VNF1| 271 ++-+-+-+-+-+-+-+-+-+-+ -+-+-+-++-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+ 273 5. Components for uCPE Management 275 This section provides a components overview to manage the uCPE. 277 There are multiple RFCs and drafts produced by the IETF community, 278 that are referenced in the YANG tree to manage the uCPE. Each 279 document produced by the IETF covers a part of uCPE Management. The 280 list of the documents is provided below: 282 o [RFC8530] - logical network elements (VNFs) properties. 284 o [RFC8345] - definition of networks, nodes, node-termination- 285 points: network includes the uCPE with uCPE's physical termination 286 points. 288 o [I-D.ietf-teas-sf-aware-topo-model]physical ports and service 289 functions (VNFs) interconnection matrixes (PhyPort-VNF, VNF-VNF). 291 o This document itself provides yang modules that completes the 292 existing documents produced by IETF. 294 This document introduces yang modules for 'logical network elements 295 properties(VNFs)" part: 297 o day0-info: mapping between variables inside of the bootstap config 298 and required values in the list "day0-info". In the bootstap 299 config the variable could be putted instead value. The value 300 could be set in the day0-info part (check the YANG model) and 301 after the value in the list will be mapped to the variable in the 302 bootstrap config. 304 o vCPU/vRAM/vDisk/VNF-ports leafs and lists. 306 The minimal list of yang models required for compilation of the YANG 307 tree to manage the uCPE is presented below: 309 o ietf-interfaces 311 o ietf-logical-network-element 313 o ietf-ietf-network 315 o ietf-ietf-network-topology 317 o ietf-routing-types 319 o ietf-te-topology 321 o ietf-te-topology-sf 323 o ietf-te-types 325 o ietf-yang-schema-mount 327 o The YANG module introduced in this document 329 6. Diagram overview of YANG Data Model tree for uCPE management 331 This section provides an overview of the Data YANG Model that MAY be 332 made with "pyang" utility. The figure below presents the tree 333 diagram. 335 module: ietf-network 336 +--rw networks 337 +--rw network* [network-id] 338 +--rw network-id network-id 339 +--rw network-types 340 | +--rw tet:te-topology! 341 | +--rw tet-sf:sf! 342 +--rw supporting-network* [network-ref] 343 | +--rw network-ref -> /networks/network/network-id 344 +--rw node* [node-id] 345 +--rw node-id node-id 346 +--rw supporting-node* [network-ref node-ref] 347 | +--rw network-ref -> 348 | | ../../../supporting-network/network-ref 349 | +--rw node-ref -> /networks/network/node/node-id 350 +--rw nt:termination-point* [tp-id] 351 | +--rw nt:tp-id tp-id 352 | +--rw nt:supporting-termination-point* 353 | | [network-ref node-ref tp-ref] 354 | +--rw nt:network-ref 355 | | -> ../../../nw:supporting-node/network-ref 356 | +--rw nt:node-ref 357 | | -> ../../../nw:supporting-node/node-ref 358 | +--rw nt:tp-ref 359 | -> /nw:networks/network[nw:network-id= 360 | current()/../network-ref]/node 361 | [nw:node-id=current()/../node-ref]/ 362 | termination-point/tp-id 363 +--rw tet:te-node-id? te-types:te-node-id 364 +--rw tet:te! 365 +--rw tet:te-node-template* 366 | -> ../../../../te/templates/ 367 | node-template/name {template}? 368 +--rw tet:te-node-attributes 369 | ... 370 +--rw tet-sf:service-function 371 +--rw tet-sf:connectivity-matrices 372 | +--rw tet-sf:connectivity-matrix* [id] 373 | +--rw tet-sf:id uint32 374 | +--rw tet-sf:from 375 | | +--rw tet-sf:service-function-id? string 376 | | +--rw tet-sf:sf-connection-point-id? string 377 | +--rw tet-sf:to 378 | | +--rw tet-sf:service-function-id? string 379 | | +--rw tet-sf:sf-connection-point-id? string 380 | +--rw tet-sf:enabled? boolean 381 | +--rw tet-sf:direction? connectivity-direction 382 | +--rw tet-sf:virtual-link-id? string 383 +--rw tet-sf:link-terminations 384 +--rw tet-sf:link-termination* [id] 385 +--rw tet-sf:id uint32 386 +--rw tet-sf:from 387 | +--rw tet-sf:tp-ref? -> ../../../../ 388 | ../../../nt:termination-point/tp-id 389 +--rw tet-sf:to 390 | +--rw tet-sf:service-function-id? string 391 | +--rw tet-sf:sf-connection-point-id? string 392 +--rw tet-sf:enabled? boolean 393 +--rw tet-sf:direction? connectivity-direction 395 logical-network-elements 396 +--rw logical-network-element* [name] 397 +--rw name string 398 +--rw managed? boolean 399 +--rw description? string 400 +--rw root 401 +--rw logical-network-elements-properties 402 +--rw sf-connection-points* [sf-connection-point-id] 403 | +--rw sf-connection-point-id string 404 +--rw ram? uint64 405 +--rw cpu? uint64 406 +--rw storages* [id] 407 | +--rw id string 408 | +--rw location? string 409 +--rw day0-config 410 +--rw location? string 411 +--rw day0-var-path? string 412 +--rw variable* [name] 413 +--rw name string 414 +--rw value? string 416 7. Logical Network Elements extension YANG Model 418 This section provides a YANG model that addresses the configuration 419 of the uCPE VNF resources. 421 file "ietf-ucpe-lne-properties@2019-11-21.yang" 422 module ietf-ucpe-lne-properties { 423 yang-version 1.1; 424 namespace "urn:ietf:params:xml:ns:yang:ietf-ucpe-lne-properties"; 425 prefix ietf-ucpe; 427 import ietf-logical-network-element { 428 prefix lne; 429 reference 430 "RFC 8530: YANG Model for Logical Network Elements"; 432 } 434 organization 435 "SFR"; 436 contact 437 "Dmytro Shytyi 438 EMail:ietf.dmytro@shytyi.net"; 439 description 440 "This is a Network Function Virtualization (NFV) YANG 441 service model. 443 Copyright (c) 2019 IETF Trust and the persons identified as 444 authors of the code. All rights reserved. 446 Redistribution and use in source and binary forms, with or 447 without modification, is permitted pursuant to, and subject to 448 the license terms contained in, the Simplified BSD License set 449 forth in Section 4.c of the IETF Trust's Legal Provisions 450 Relating to IETF Documents 451 (https://trustee.ietf.org/license-info). 453 This version of this YANG module is part of RFC XXXX 454 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 455 for full legal notices."; 457 revision 2019-11-21 { 458 description 459 "Augmentation of RFC 8530"; 460 reference 461 "draft-shytyi-opsawg-vysm-07"; 462 } 463 revision 2019-10-28 { 464 description 465 "Yang model with vPorts assigned to the interfaces"; 466 reference 467 "draft-shytyi-opsawg-vysm-05"; 468 } 469 revision 2019-10-19 { 470 description 471 "Yang model was cleaned. Interfaces added"; 472 reference 473 "draft-shytyi-opsawg-vysm-04"; 474 } 475 revision 2019-09-16 { 476 description 477 "Added 0day config for VNFs. 478 Yang model modified according 479 to the received comments."; 481 reference 482 "draft-shytyi-opsawg-vysm-00"; 483 } 484 revision 2018-01-07 { 485 description 486 "Initial revision."; 487 reference 488 "draft-shytyi-netmod-vysm-01"; 489 } 491 augment "/lne:logical-network-elements/lne:logical-network-element" { 492 container logical-network-element-properties { 493 list sf-connection-points { 494 key "sf-connection-point-id"; 495 leaf sf-connection-point-id { 496 type string; 497 description 498 "Name of the connector"; 499 } 500 description 501 "Connection points of logical-network-element"; 502 } 503 description 504 "Set of Virtual Network Function connectors"; 505 leaf ram { 506 type uint64; 507 description 508 "Size of RAM to allocate for 509 the Guest OS"; 510 } 511 leaf cpu { 512 type uint64; 513 description 514 "Number of vCPUs to 515 allocate for the Guest OS"; 516 } 517 list storages { 518 key "id"; 519 leaf id { 520 type string; 521 description 522 "Number of 523 vDisk attached to the VM"; 524 } 525 leaf location { 526 type string; 527 description 528 "External location where 529 the image (ex.qcow2) is saved."; 530 } 531 description 532 "Virtual storge/vDisk 533 attached to the Virtual Machine"; 534 } 535 container day0-config { 536 leaf location { 537 type string; 538 description 539 "0day configuration location"; 540 } 541 leaf day0-var-path { 542 type string; 543 description 544 "path of the file 545 that contains the 0day variables"; 546 } 547 list variable { 548 key "name"; 549 leaf name { 550 type string; 551 description 552 "variable name"; 553 } 554 leaf value { 555 type string; 556 description 557 "variable value"; 558 } 559 description 560 "list of variables"; 561 } 562 description 563 "0day configuration:init config"; 564 } 565 } 566 description 567 "Properties of logic-network-element"; 568 } 569 } 571 573 8. Security Considerations 575 At this time, no security considerations are addressed by this memo. 577 9. IANA Considerations 579 No request to IANA at this time. 581 10. Acknowledgements 583 the authors would like to thank: 585 o Mahesh Jethanandani. 587 o Robert Varga. 589 o Bill Wu. 591 o Joe Clarke. 593 o Tom Petch. 595 o Martin Bjorklund. 597 o Schonwalder Jurgen. 599 o Dean Bogdanovic. 601 o Bo Wu. 603 for their valuable comments. 605 11. Normative References 607 [I-D.ietf-teas-sf-aware-topo-model] 608 Bryskin, I., Liu, X., Lee, Y., Guichard, J., Contreras, 609 L., Ceccarelli, D., and J. Tantsura, "SF Aware TE Topology 610 YANG Model", draft-ietf-teas-sf-aware-topo-model-03 (work 611 in progress), March 2019. 613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 614 Requirement Levels", BCP 14, RFC 2119, 615 DOI 10.17487/RFC2119, March 1997, 616 . 618 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 619 Classification", RFC 8199, DOI 10.17487/RFC8199, July 620 2017, . 622 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 623 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 624 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 625 2018, . 627 [RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. 628 Liu, "YANG Model for Logical Network Elements", RFC 8530, 629 DOI 10.17487/RFC8530, March 2019, 630 . 632 Appendix A. Example of the uCPE resources management 634 This section provides an overview of the deprecated YANG Model that 635 MAY give an alternative view on the uCPE management. 637 module: ietf-example-ucpe 638 +--rw ucpe* [name] 639 +--rw name string 640 +--rw links* [link] 641 | +--rw link string 642 +--rw phyInterfaces* [interface] 643 | +--rw interface string 644 | +--rw ports* [port] 645 | +--rw port string 646 | +--rw link? -> ../../../links/link 647 +--rw switches* [switch] 648 | +--rw switch string 649 | +--rw ports* [port] 650 | +--rw port string 651 | +--rw name? string 652 | +--rw link? -> ../../../links/link 653 +--rw vms* [vm] 654 +--rw vm string 655 +--rw ports* [port] 656 | +--rw port string 657 | +--rw name? string 658 | +--rw link? -> ../../../links/link 659 +--rw ram? uint64 660 +--rw cpu? uint64 661 +--rw storages* [id] 662 | +--rw id string 663 | +--rw location? string 664 +--rw day0-config 665 +--rw location? string 666 +--rw day0-var-path? string 667 +--rw variable* [name] 668 +--rw name string 669 +--rw value? string 671 Appendix B. Deprecated VNF YANG Model 673 This section provides a deprecated yang model that addresses the 674 configuration of the uCPE resources presented above. 676 file "ietf-example-ucpe@2019-10-28.yang" 677 module ietf-example-ucpe { 678 namespace "urn:ietf:params:xml:ns:yang:ietf-example-ucpe"; 679 prefix ietf-example-ucpe; 681 organization 682 "SFR"; 684 contact 685 "Dmytro Shytyi 686 EMail:ietf.dmytro@shytyi.net"; 687 description 688 "This is a Network Function Virtualization (NFV) YANG 689 service model. 691 Copyright (c) 2019 IETF Trust and the persons identified as 692 authors of the code. All rights reserved. 694 Redistribution and use in source and binary forms, with or 695 without modification, is permitted pursuant to, and subject to 696 the license terms contained in, the Simplified BSD License set 697 forth in Section 4.c of the IETF Trust's Legal Provisions 698 Relating to IETF Documents 699 (https://trustee.ietf.org/license-info). 701 This version of this YANG module is part of RFC XXXX 702 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 703 for full legal notices."; 705 revision 2019-10-28 { 706 description 707 "Yang model with vPorts assigned to the interfaces"; 708 reference 709 "draft-shytyi-opsawg-vysm-05"; 710 } 711 revision 2019-10-19 { 712 description 713 "Yang model was cleaned. Interfaces added"; 714 reference 715 "draft-shytyi-opsawg-vysm-04"; 716 } 717 revision 2019-09-16 { 718 description 719 "Added 0day config for VNFs. 720 Yang model modified according 721 to the received comments."; 722 reference 723 "draft-shytyi-opsawg-vysm-00"; 724 } 725 revision 2018-01-07 { 726 description 727 "Initial revision."; 728 reference 729 "draft-shytyi-netmod-vysm-01"; 730 } 731 list ucpe { 732 key "name"; 733 leaf name { 734 type string; 735 description 736 "ID of uCPE where 737 a service is instantiated"; 738 } 739 list links { 740 key "link"; 741 leaf link { 742 type string; 743 description 744 "Name of the virtual link from the pool 745 of the links"; 746 } 747 description 748 "Pool of the virtual links that connect VMs and 749 Interfaces"; 750 } 751 list phyInterfaces { 752 key "interface"; 753 leaf interface { 754 type string; 755 description 756 "Name of physical interface"; 757 } 758 list ports { 759 key "port"; 760 leaf port { 761 type string; 762 description 763 "Name of the connector"; 764 } 765 leaf link { 766 type leafref { 767 path "../../../links/link"; 768 } 769 description 770 "Link that is connected to 771 the port via connector"; 772 } 773 description 774 "Set of the connectors the 775 physical interface has"; 776 } 777 description 778 "Set of physical interfaces"; 780 } 781 list switches { 782 key "switch"; 783 leaf switch { 784 type string; 785 description 786 "Name of the forwarding domain"; 787 } 788 list ports { 789 key "port"; 790 leaf port { 791 type string; 792 description 793 "Name of the connector"; 794 } 795 leaf name { 796 type string; 797 description 798 "Name of the 799 subconnector"; 800 } 801 leaf link { 802 type leafref { 803 path "../../../links/link"; 804 } 805 description 806 "Link that is connected to the 807 switch via port"; 808 } 809 description 810 "Set of the connectors the 811 forwarding domain has"; 812 } 813 description 814 "Set of the forwarding domains"; 815 } 816 list vms { 817 key "vm"; 818 leaf vm { 819 type string; 820 description 821 "ID of the Virtual Machine"; 822 } 823 list ports { 824 key "port"; 825 leaf port { 826 type string; 827 description 828 "Name of the connector"; 829 } 830 leaf name { 831 type string; 832 description 833 "Name of 834 the subconnector"; 835 } 836 leaf link { 837 type leafref { 838 path "../../../links/link"; 839 } 840 description 841 "Link that connects the 842 VM with a switch or Interface 843 via connector"; 844 } 845 description 846 "Set of Virtual Machine connectors"; 847 } 848 leaf ram { 849 type uint64; 850 description 851 "Size of RAM to allocate for 852 the Guest OS"; 853 } 854 leaf cpu { 855 type uint64; 856 description 857 "Number of vCPUs to 858 allocate for the Guest OS"; 859 } 860 list storages { 861 key "id"; 862 leaf id { 863 type string; 864 description 865 "Number of 866 vDisk attached to the VM"; 867 } 868 leaf location { 869 type string; 870 description 871 "External location where 872 the image (ex.qcow2) is saved."; 873 } 874 description 875 "Virtual storge/vDisk 876 attached to the Virtual Machine"; 877 } 878 container day0-config { 879 leaf location { 880 type string; 881 description 882 "0day configuration location"; 883 } 884 leaf day0-var-path { 885 type string; 886 description 887 "path of the file 888 that contains the 0day variables"; 889 } 890 list variable { 891 key "name"; 892 leaf name { 893 type string; 894 description 895 "variable name"; 896 } 897 leaf value { 898 type string; 899 description 900 "variable value"; 901 } 902 description 903 "list of variables"; 904 } 905 description 906 "0day configuration:init config"; 907 } 908 description 909 "Set of the Virtual Machines configured 910 on the universal Customer-Premises Equipment"; 911 } 912 description 913 "This is an uCPE management service"; 914 } 915 } 917 919 Appendix C. XML example of deprecated YANG model 921 The XML example below presents the configuration of the next service 922 in the uCPE, where: vSW(LAN), vSW(WAN), vSW(Service) - virtual 923 switches; l1,l2,l3,l4 - virtual links; VMs represent PNFs (Physical 924 Network Fuctions) that could be bootstrapped with 0day config/ 925 license. 927 +--------+ +-------------+ +------------+ 928 |vSW(LAN)|--l2--|VNF-vFirewall|--l3--| | 929 +--------+ +-------------+ | | 930 +--------+ +-------------+ |vSW(Service)| 931 |vSW(WAN)|--l1--| VNF_vRtr |--l4--| | 932 +--------+ +-------------+ +------------+ 934 935 ucpe1 936 937 l1 938 939 940 l2 941 942 943 l3 944 945 946 l4 947 948 949 lan 950 951 10 952 l2p10 953 l2 954 955 956 957 service 958 959 10 960 l3p10 961 l3 962 963 964 11 965 l4p10 966 l4 967 968 969 970 wan 971 972 10 973 l1 974 975 976 977 VNF-vRtr 978 979 1 980 l1p1 981 l1 982 983 984 2 985 l4p2 986 l4 987 988 2048 989 2 990 991 1 992 http://192.168.2.1/vRtr-x86.qcow2 993 994 995 https://192.168.2.1/vRtr-day0.iso 996 /config.rom 997 998 hostname 999 IETF-vRtr 1000 1001 1002 ipaddress 1003 192.168.1.2 255.255.255.0 1004 1005 1006 1007 1008 VNF-vFirewall 1009 1010 1 1011 l3p1 1012 l3 1013 1014 1015 2 1016 l2p2 1017 l2 1018 1019 2048 1020 2 1021 1022 1 1023 http://192.168.2.1/vFirewall-x86.qcow2 1024 1025 1026 https://192.168.2.1/vFirewall-day0.iso 1027 /config.rom 1028 1029 hostname 1030 vFirewall 1031 1032 1033 ipaddress 1034 192.168.1.3 255.255.255.0 1035 1036 1037 1038 1040 Authors' Addresses 1042 Dmytro Shytyi 1043 SFR 1044 Paris , Ile-de-France 1045 France 1047 Email: ietf.dmytro@shytyi.net 1048 URI: https://dmytro.shytyi.net 1050 Laurent Beylier 1051 SFR 1052 Paris , Ile-de-France 1053 France 1055 Email: laurent.beylier@sfr.com 1056 Luigi Iannone 1057 Telecom ParisTech 1058 Paris , Ile-de-France 1059 France 1061 Email: luigi.iannone@telecom-paristech.fr