idnits 2.17.1 draft-shytyi-opsawg-vysm-05.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 212 has weird spacing: '...Balance vFire...' == Line 284 has weird spacing: '...rw link str...' == Line 286 has weird spacing: '...terface str...' == Line 288 has weird spacing: '...rw port str...' == Line 291 has weird spacing: '... switch str...' == (2 more instances...) -- The document date (October 29, 2019) is 1631 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 ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 8 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 1, 2020 L. Iannone 6 Telecom ParisTech 7 October 29, 2019 9 A YANG Module for uCPE management. 10 draft-shytyi-opsawg-vysm-05 12 Abstract 14 This document provides a YANG data model for uCPE management (VYSM) 15 and definition of the uCPE equipment. The YANG Service Model serves 16 as a base framework for managing an universal Customer-Premises 17 Equipment (uCPE) subsystem. The model can be used by a Network 18 Service Orchestrator. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 1, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Universal CPE . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. uCPE purpose . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. uCPE VNF ecosystem example . . . . . . . . . . . . . . . 4 59 3.3. Internal uCPE service example . . . . . . . . . . . . . . 5 60 4. YANG Service Model for uCPE management . . . . . . . . . . . 5 61 5. uCPE YANG Service Model tree diagram overview . . . . . . . . 7 62 6. Specification of the VNF YANG Service Model . . . . . . . . . 8 63 7. XML example . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 66 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 67 11. Normative References . . . . . . . . . . . . . . . . . . . . 17 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 70 1. Introduction 72 Network Function Virtualization is a technology that allows to 73 virtualize the network services running on dedicaded hardware. This 74 technology became a base for universal Customer-Premises Equipment 75 (uCPE). This document defines the uCPE as harware with x86 76 capabilities that has a hypervisor. In other words, uCPE is a host 77 that may run multiple Virtual Machines with guest OSs, where each 78 Guest OS may represent a Physical Network Function. This document 79 presents the YANG Service Model (VYSM) to manage from an Orchestrator 80 the infrastructure inside the uCPE. 82 2. Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [RFC2119]. 88 Link - is an entity that enables link layer communication of nodes. 90 Port - node connector to the link. 92 NE - Network Element. 94 NSYM - Network Service Yang Module. 96 VYSM - VNF YANG Service Model. 98 3. Universal CPE 100 Firstly, this document defines the platform that is controlled with 101 VYSM - universal CPE (uCPE). The uCPE as harware with x86 102 capabilities that is generally running Linux distibution with 103 additinal virtualisation layer. Virtualization layer provides 104 virtual compute, virtual storage and virtual network resources. Each 105 VNF runnning in the uCPE requires the amount of virtual resources 106 (for example: 4 vCPUs, 4GB RAM, 40GB storege, 4 vPorts). VNFs MAY be 107 interconnected between each other and physical ports via Virtual 108 Networks. Topology construction and VM lifecycle management is 109 allowed via high level interface (Configuration can be done in the 110 same transaction). The figure below presents the uCPE architecture. 112 ----------------------------------------|-------------- 113 VNF1 VNF2 VNF3 | 114 ----------------------------------------| 115 Virtual Virtual Virtual | uCPE software 116 Compute Storage Networks| 117 ----------------------------------------|--------------- 118 PHY x86 RAM+PHY PHYsical| uCPE Hardware 119 processor storage ports | 121 The next elements can be managed in the uCPE: 123 o Virtual Network Funcitons: 125 * Number of assigned vCPUs. 127 * Size of allocated RAM. 129 * VNF day0 config (bootstrap). 131 * vLinks that are attached to the VNF. 133 o Virtual Switches: 135 * vLinks that are attached to the vSW. 137 o Virtual Links(vLinks). 139 o Physical Ports of the uCPE. 141 3.1. uCPE purpose 143 o uCPE replaces multiple types of equipment (Node#1 - Node#5) with 1 144 unit by virtualizing them as Virtual Network Functions on the top 145 of NFVIs: 147 : NODE #1 : NODE #2 : NODE #3 :NODE #4: NODE #5 : 148 : +-----------+ : +------+ : +------+ : +--+ : +-----+ : 149 ...-----|Aggregation|----|CE-L2 |----| CE-L3|----|FW|----|SDWAN|---LAN 150 : | switch | : | | : | | : | | : | | : 151 : +-----------+ : +------+ : +------+ : +--+ : +-----+ : 153 : NODE #1 : NODE #2 : 154 : : +.........................................+ : 155 : +-----------+ : | +------+ +------+ +--+ +-----+ | : 156 ...---|Aggregation|---|--|CE-L2 |----| CE-L3|----|FW|---|SDWAN|-|---LAN 157 : | switch | : | | | | | | | | | | : 158 : +-----------+ : | +------+ +------+ +--+ +-----+ | : 159 : : | universal Customer-Premises Equipment | : 160 : : +-----------------------------------------+ : 162 o uCPE falicitates the interconnection between the Network Funtions 163 (NF) as interconnection between NF is performed via virtual 164 links(that is part of the uCPE management). That meens that no 165 need to hire technichian to cable the equipment, it could be done 166 via orchestrator. 168 o uCPE falicitates the 0day configuration of the VNFs as its 0day 169 configuration can be putted remotely. 171 3.2. uCPE VNF ecosystem example 173 uCPE supports a Virtual Network Funcitons of different type: 175 o SD-WAN 177 o vRouter(vCPE) 179 o vFirewall 181 o vLB(vLoad Balancer) 183 o vCGNAT(vCarrier Grade NAT) 184 o virtual WAN Optimistaion 186 o vWireless LAN controller 188 o Other... 190 3.3. Internal uCPE service example 192 The VNF in the uCPE could be a vRouter or vFirewall or an SD-WAN that 193 is not a default part of virtual network resources of the uCPE. 194 Multiple VNFs MAY be instantiated in the uCPE. With support of links 195 and swithes, VNFs MAY participate a service chains. Example of 196 service chains (Note that virtual switch "vs(WAN)" connected to LAN 197 ports and vSW(WAN) is connected to WAN ports): 199 o vSW(WAN)-l1-vRouter(vCPE)-l2-vSW(LAN). 201 o vSW(WAN)-l1-vRouter(vCPE)-l2-vSW(Service)-l3-vFirewall- 202 l4-vSW(LAN). 204 o vSW(WAN)-l1-vRouter(vCPE)-l2-vSW(Service1)-l3-vFirewall-l4- 205 vSW(Service2)-l5-SD-WAN-l6-vSW(LAN). 207 o vSW(WAN)-l1-SDWAN-l2-vSW(Service)-l3-vFirewall-l4-vSW(LAN). 209 o 211 vSW(WAN1)--vRouter--+ 212 +--vLoadBalance vFirewall--vSW(LAN) 213 vSW(WAN2)--vRouter--+ | | 214 +-vSW(Service1)+ 216 o 218 vSW(WAN1)--vRouter(ISP1)--+ 219 +--SD-WAN vFirewall--vSW(LAN) 220 vSW(WAN2)--vRouter(ISP2)--+ | | 221 +-vSW(Service1)+ 223 4. YANG Service Model for uCPE management 225 Secondly, this document defines and classifies the VYSM as Network 226 Service YANG Module(NSYM) layer component RFC 8199 [RFC8199]. Thus 227 it inherits the characteristics of the NSYM Layer. VYSM is a modeled 228 representation of the specific service requirements. It provides 229 abstraction of services configuration and operations that MAY be 230 implemented in Network Elemets (NEs). Thus VYSM does not describe 231 all configuration to be performed on the devices, but provides the 232 configuration that is required for the "Network Service to Network 233 Element(s)" decomposition process RFC 8199 [RFC8199]. Example of the 234 decomposition is presented in the figure below. 236 The Network Service YANG module exposes the configuration commands 237 via the Northbound interfaces of the orchestrator. Therefore the set 238 of the commands modeled in the VYSM can be inputed via Notrhbound 239 interfaces(for example CLI). In the example the command "vm VNF1" is 240 passed via Northbound interface to the orchestrator. It defines the 241 virtual machine name. Further the same configuration MAY be 242 transormed to the one or multiple Network Element payloads (for 243 example xml for NETCONF) that carry an equivalent of commands such as 244 "nf nf-name VNF1" 245 +-+-+-+-+-+-+-+-+-+ 246 | | 247 | config t | 248 | vm VNF1 | 249 +-+-+-+-+-+-+-+-+-+ 250 # 251 # 252 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 : : 254 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ : 255 : | Network Service YANG Module | : 256 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ : 257 : # : 258 : ############################## orchestrator : 259 : # # # : 260 : '---------' '------------' '-----------' : 261 : 'Module1 ' ' Module 2 ' ' Module3 ' <= Network Element : 262 : '---------' '------------' '-----------' YANG Modules : 263 : # # # : 264 : # # ####################### : 265 : #### ############## # : 266 : # # # : 267 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 # # # 269 Network # element 1 Network # element 2 Network # element3 270 ++-+-+-+-+-+-+-+-+-+-+ -+-+-+-++-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+ 271 | domains domain VNF1| |tenants tenant name VNF1| |nf nf-name VNF1| 272 ++-+-+-+-+-+-+-+-+-+-+ -+-+-+-++-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+ 274 5. uCPE YANG Service Model tree diagram overview 276 This section provides an overview of the Service YANG Model (VSYM) 277 that MAY be made with "pyang" utility. The figure below presents the 278 tree diagram of VYSM. 280 module: ietf-ucpe 281 +--rw ucpe* [name] 282 +--rw name string 283 +--rw links* [link] 284 | +--rw link string 285 +--rw phyInterfaces* [interface] 286 | +--rw interface string 287 | +--rw ports* [port] 288 | +--rw port string 289 | +--rw link? -> ../../../links/link 290 +--rw switches* [switch] 291 | +--rw switch string 292 | +--rw ports* [port] 293 | +--rw port string 294 | +--rw name? string 295 | +--rw link? -> ../../../links/link 296 +--rw vms* [vm] 297 +--rw vm string 298 +--rw ports* [port] 299 | +--rw port string 300 | +--rw name? string 301 | +--rw link? -> ../../../links/link 302 +--rw ram? uint64 303 +--rw cpu? uint64 304 +--rw storages* [id] 305 | +--rw id string 306 | +--rw location? string 307 +--rw day0-config 308 +--rw location? string 309 +--rw day0-var-path? string 310 +--rw variable* [name] 311 +--rw name string 312 +--rw value? string 314 6. Specification of the VNF YANG Service Model 316 This section presents the specification of the VYSM. 318 file "ietf-ucpe@2019-10-28.yang" 319 module ietf-ucpe { 320 namespace "urn:ietf:params:xml:ns:yang:ietf-ucpe"; 321 prefix ietf-ucpe; 323 organization 324 "SFR"; 325 contact 326 "Dmytro Shytyi 327 EMail:ietf.dmytro@shytyi.net"; 328 description 329 "This is a Network Function Virtualization (NFV) YANG 330 service model. 332 Copyright (c) 2019 IETF Trust and the persons identified as 333 authors of the code. All rights reserved. 335 Redistribution and use in source and binary forms, with or 336 without modification, is permitted pursuant to, and subject to 337 the license terms contained in, the Simplified BSD License set 338 forth in Section 4.c of the IETF Trust's Legal Provisions 339 Relating to IETF Documents 340 (https://trustee.ietf.org/license-info). 342 This version of this YANG module is part of RFC XXXX 343 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 344 for full legal notices."; 346 revision 2019-10-28 { 347 description 348 "Yang model with vPorts assigned to the interfaces"; 349 reference 350 "draft-shytyi-opsawg-vysm-05"; 351 } 352 revision 2019-10-19 { 353 description 354 "Yang model was cleaned. Interfaces added"; 355 reference 356 "draft-shytyi-opsawg-vysm-04"; 357 } 358 revision 2019-09-16 { 359 description 360 "Added 0day config for VNFs. 361 Yang model modified according 362 to the received comments."; 363 reference 364 "draft-shytyi-opsawg-vysm-00"; 365 } 366 revision 2018-01-07 { 367 description 368 "Initial revision."; 369 reference 370 "draft-shytyi-netmod-vysm-01"; 371 } 373 list ucpe { 374 key "name"; 375 leaf name { 376 type string; 377 description 378 "ID of uCPE where 379 a service is instantiated"; 380 } 381 list links { 382 key "link"; 383 leaf link { 384 type string; 385 description 386 "Name of the virtual link from the pool 387 of the links"; 388 } 389 description 390 "Pool of the virtual links that connect VMs and 391 Interfaces"; 392 } 393 list phyInterfaces { 394 key "interface"; 395 leaf interface { 396 type string; 397 description 398 "Name of physical interface"; 399 } 400 list ports { 401 key "port"; 402 leaf port { 403 type string; 404 description 405 "Name of the connector"; 406 } 407 leaf link { 408 type leafref { 409 path "../../../links/link"; 410 } 411 description 412 "Link that is connected to 413 the port via connector"; 414 } 415 description 416 "Set of the connectors the 417 physical interface has"; 418 } 419 description 420 "Set of physical interfaces"; 421 } 422 list switches { 423 key "switch"; 424 leaf switch { 425 type string; 426 description 427 "Name of the forwarding domain"; 428 } 429 list ports { 430 key "port"; 431 leaf port { 432 type string; 433 description 434 "Name of the connector"; 435 } 436 leaf name { 437 type string; 438 description 439 "Name of the 440 subconnector"; 441 } 442 leaf link { 443 type leafref { 444 path "../../../links/link"; 445 } 446 description 447 "Link that is connected to the 448 switch via port"; 449 } 450 description 451 "Set of the connectors the 452 forwarding domain has"; 453 } 454 description 455 "Set of the forwarding domains"; 456 } 457 list vms { 458 key "vm"; 459 leaf vm { 460 type string; 461 description 462 "ID of the Virtual Machine"; 463 } 464 list ports { 465 key "port"; 466 leaf port { 467 type string; 468 description 469 "Name of the connector"; 471 } 472 leaf name { 473 type string; 474 description 475 "Name of 476 the subconnector"; 477 } 478 leaf link { 479 type leafref { 480 path "../../../links/link"; 481 } 482 description 483 "Link that connects the 484 VM with a switch or Interface 485 via connector"; 486 } 487 description 488 "Set of Virtual Machine connectors"; 489 } 490 leaf ram { 491 type uint64; 492 description 493 "Size of RAM to allocate for 494 the Guest OS"; 495 } 496 leaf cpu { 497 type uint64; 498 description 499 "Number of vCPUs to 500 allocate for the Guest OS"; 501 } 502 list storages { 503 key "id"; 504 leaf id { 505 type string; 506 description 507 "Number of 508 vDisk attached to the VM"; 509 } 510 leaf location { 511 type string; 512 description 513 "External location where 514 the image (ex.qcow2) is saved."; 515 } 516 description 517 "Virtual storge/vDisk 518 attached to the Virtual Machine"; 520 } 521 container day0-config { 522 leaf location { 523 type string; 524 description 525 "0day configuration location"; 526 } 527 leaf day0-var-path { 528 type string; 529 description 530 "path of the file 531 that contains the 0day variables"; 532 } 533 list variable { 534 key "name"; 535 leaf name { 536 type string; 537 description 538 "variable name"; 539 } 540 leaf value { 541 type string; 542 description 543 "variable value"; 544 } 545 description 546 "list of variables"; 547 } 548 description 549 "0day configuration:init config"; 550 } 551 description 552 "Set of the Virtual Machines configured 553 on the universal Customer-Premises Equipment"; 554 } 555 description 556 "This is an uCPE management service"; 557 } 558 } 560 562 7. XML example 564 The XML example below presents the configuration of the next service 565 in the uCPE, where: vSW(LAN), vSW(WAN), vSW(Service) - virtual 566 switches; l1,l2,l3,l4 - virtual links; VMs represent PNFs (Physical 567 Network Fuctions) that could be bootstrapped with 0day config/ 568 license. 570 +--------+ +-------------+ +------------+ 571 |vSW(LAN)|--l2--|VNF-vFirewall|--l3--| | 572 +--------+ +-------------+ | | 573 +--------+ +-------------+ |vSW(Service)| 574 |vSW(WAN)|--l1--| VNF_vCPE |--l4--| | 575 +--------+ +-------------+ +------------+ 577 578 ucpe1 579 580 l1 581 582 583 l2 584 585 586 l3 587 588 589 l4 590 591 592 lan 593 594 10 595 l2p10 596 l2 597 598 599 600 service 601 602 10 603 l3p10 604 l3 605 606 607 11 608 l4p10 609 l4 610 611 612 613 wan 614 615 10 616 l1 617 618 619 620 VNF-vCPE 621 622 1 623 l1p1 624 l1 625 626 627 2 628 l4p2 629 l4 630 631 2048 632 2 633 634 1 635 http://192.168.2.1/vCPE-x86.qcow2 636 637 638 https://192.168.2.1/vCPE-day0.iso 639 /config.rom 640 641 hostname 642 IETF-vCPE 643 644 645 ipaddress 646 192.168.1.2 255.255.255.0 647 648 649 650 651 VNF-vFirewall 652 653 1 654 l3p1 655 l3 656 657 658 2 659 l2p2 660 l2 661 662 2048 663 2 664 665 1 666 http://192.168.2.1/vFirewall-x86.qcow2 667 668 669 https://192.168.2.1/vFirewall-day0.iso 670 /config.rom 671 672 hostname 673 vFirewall 674 675 676 ipaddress 677 192.168.1.3 255.255.255.0 678 679 680 681 683 8. Security Considerations 685 At this time, no security considerations are addressed by this memo. 687 9. IANA Considerations 689 No request to IANA at this time. 691 10. Acknowledgements 693 The authors would like to thank: 695 o Mahesh Jethanandani. 697 o Robert Varga. 699 o Bill Wu. 701 o Joe Clarke. 703 o Tom Petch. 705 o Martin Bjorklund. 707 o SchAP.nwA[currency units]lder JA1/4rgen. 709 for their valuable comments. 711 11. Normative References 713 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 714 Requirement Levels", BCP 14, RFC 2119, 715 DOI 10.17487/RFC2119, March 1997, 716 . 718 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 719 Classification", RFC 8199, DOI 10.17487/RFC8199, July 720 2017, . 722 Authors' Addresses 724 Dmytro Shytyi 725 SFR 726 Paris , Ile-de-France 727 France 729 Email: ietf.dmytro@shytyi.net 730 URI: https://dmytro.shytyi.net 732 Laurent Beylier 733 SFR 734 Paris , Ile-de-France 735 France 737 Email: laurent.beylier@sfr.com 739 Luigi Iannone 740 Telecom ParisTech 741 Paris , Ile-de-France 742 France 744 Email: luigi.iannone@telecom-paristech.fr