idnits 2.17.1 draft-shytyi-opsawg-vysm-01.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 182 has weird spacing: '...Balance vFire...' == Line 254 has weird spacing: '...rw link str...' == Line 256 has weird spacing: '...terface str...' == Line 258 has weird spacing: '...rw port str...' == Line 261 has weird spacing: '... switch str...' == (2 more instances...) -- The document date (September 26, 2019) is 1672 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: March 29, 2020 L. IANNONE 6 Telecom ParisTech 7 September 26, 2019 9 A YANG Module for uCPE management. 10 draft-shytyi-opsawg-vysm-01 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 March 29, 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 VNF ecosystem example . . . . . . . . . . . . . . . 4 58 3.2. Internal uCPE service example . . . . . . . . . . . . . . 4 59 4. YANG Service Model for uCPE management . . . . . . . . . . . 5 60 5. uCPE YANG Service Model tree diagram overview . . . . . . . . 6 61 6. Specification of the VNF YANG Service Model . . . . . . . . . 7 62 7. XML example . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 65 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 66 11. Normative References . . . . . . . . . . . . . . . . . . . . 14 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 69 1. Introduction 71 Network Function Virtualization is a technology that allows to 72 virtualize the network services running on dedicaded hardware. This 73 technology became a base for universal Customer-Premises Equipment 74 (uCPE). This document defines the uCPE as harware with x86 75 capabilities that has a hypervisor. In other words, uCPE is a host 76 that may run multiple Virtual Machines with guest OSs, where each 77 Guest OS may represent a Physical Network Function. This document 78 presents the YANG Service Model (VYSM) to manage from an Orchestrator 79 the infrastructure inside the uCPE. 81 2. Terminology 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [RFC2119]. 87 Link - is an entity that enables link layer communication of nodes. 89 Port - node connector to the link. 91 NE - Network Element. 93 NSYM - Network Service Yang Module. 95 VYSM - VNF YANG Service Model. 97 3. Universal CPE 99 Firstly, this document defines the platform that is controlled with 100 VYSM - universal CPE (uCPE). The uCPE as harware with x86 101 capabilities that is generally running Linux distibution with 102 additinal virtualisation layer. Virtualization layer provides 103 virtual compute, virtual storage and virtual network resources. Each 104 VNF runnning in the uCPE requires the amount of virtual resources 105 (for example: 4 vCPUs, 4GB RAM, 40GB storege, 4 vPorts). VNFs MAY be 106 interconnected between each other and physical ports via Virtual 107 Networks. Topology construction and VM lifecycle management is 108 allowed via high level interface (Configuration can be done in the 109 same transaction). The figure below presents the uCPE architecture. 111 ----------------------------------------|-------------- 112 VNF1 VNF2 VNF3 | 113 ----------------------------------------| 114 Virtual Virtual Virtual | uCPE software 115 Compute Storage Networks| 116 ----------------------------------------|--------------- 117 PHY x86 RAM+PHY PHYsical| uCPE Hardware 118 processor storage ports | 120 The next elements can be managed in the uCPE: 122 o Virtual Network Funcitons: 124 * Number of assigned vCPUs. 126 * Size of allocated RAM. 128 * VNF day0 config (bootstrap). 130 * vLinks that are attached to the VNF. 132 o Virtual Switches: 134 * vLinks that are attached to the vSW. 136 o Virtual Links(vLinks). 138 o Physical Ports of the uCPE. 140 3.1. uCPE VNF ecosystem example 142 uCPE supports a Virtual Network Funcitons of different type: 144 o SD-WAN 146 o vRouter(vCPE) 148 o vFirewall 150 o vLB(vLoad Balancer) 152 o vCGNAT(vCarrier Grade NAT) 154 o virtual WAN Optimistaion 156 o vWireless LAN controller 158 o Other... 160 3.2. Internal uCPE service example 162 The VNF in the uCPE could be a vRouter or vFirewall or an SD-WAN that 163 is not a default part of virtual network resources of the uCPE. 164 Multiple VNFs MAY be instantiated in the uCPE. With support of links 165 and swithes, VNFs MAY participate a service chains. Example of 166 service chains (Note that virtual switch "vs(WAN)" connected to LAN 167 ports and vSW(WAN) is connected to WAN ports): 169 o vSW(WAN)-l1-vRouter(vCPE)-l2-vSW(LAN). 171 o vSW(WAN)-l1-vRouter(vCPE)-l2-vSW(Service)-l3-vFirewall- 172 l4-vSW(LAN). 174 o vSW(WAN)-l1-vRouter(vCPE)-l2-vSW(Service1)-l3-vFirewall-l4- 175 vSW(Service2)-l5-SD-WAN-l6-vSW(LAN). 177 o vSW(WAN)-l1-SDWAN-l2-vSW(Service)-l3-vFirewall-l4-vSW(LAN). 179 o 181 vSW(WAN1)--vRouter--+ 182 +--vLoadBalance vFirewall--vSW(LAN) 183 vSW(WAN2)--vRouter--+ | | 184 +-vSW(Service1)+ 186 o 188 vSW(WAN1)--vRouter(ISP1)--+ 189 +--SD-WAN vFirewall--vSW(LAN) 190 vSW(WAN2)--vRouter(ISP2)--+ | | 191 +-vSW(Service1)+ 193 4. YANG Service Model for uCPE management 195 Secondly, this document defines and classifies the VYSM as Network 196 Service YANG Module(NSYM) layer component RFC 8199 [RFC8199]. Thus 197 it inherits the characteristics of the NSYM Layer. VYSM is a modeled 198 representation of the specific service requirements. It provides 199 abstraction of services configuration and operations that MAY be 200 implemented in Network Elemets (NEs). Thus VYSM does not describe 201 all configuration to be performed on the devices, but provides the 202 configuration that is required for the "Network Service to Network 203 Element(s)" decomposition process RFC 8199 [RFC8199]. Example of the 204 decomposition is presented in the figure below. 206 The Network Service YANG module exposes the configuration commands 207 via the Northbound interfaces of the orchestrator. Therefore the set 208 of the commands modeled in the VYSM can be inputed via Notrhbound 209 interfaces(for example CLI). In the example the command "vm VNF1" is 210 passed via Northbound interface to the orchestrator. It defines the 211 virtual machine name. Further the same configuration MAY be 212 transormed to the one or multiple Network Element payloads (for 213 example xml for NETCONF) that carry an equivalent of commands such as 214 "nf nf-name VNF1" 215 +-+-+-+-+-+-+-+-+-+ 216 | | 217 | config t | 218 | vm VNF1 | 219 +-+-+-+-+-+-+-+-+-+ 220 # 221 # 222 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 : : 224 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ : 225 : | Network Service YANG Module | : 226 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ : 227 : # : 228 : ############################## orchestrator : 229 : # # # : 230 : '---------' '------------' '-----------' : 231 : 'Module1 ' ' Module 2 ' ' Module3 ' <= Network Element : 232 : '---------' '------------' '-----------' YANG Modules : 233 : # # # : 234 : # # ####################### : 235 : #### ############## # : 236 : # # # : 237 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 # # # 239 Network # element 1 Network # element 2 Network # element3 240 ++-+-+-+-+-+-+-+-+-+-+ -+-+-+-++-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+ 241 | domains domain VNF1| |tenants tenant name VNF1| |nf nf-name VNF1| 242 ++-+-+-+-+-+-+-+-+-+-+ -+-+-+-++-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+ 244 5. uCPE YANG Service Model tree diagram overview 246 This section provides an overview of the Service YANG Model (VSYM) 247 that MAY be made with "pyang" utility. The figure below presents the 248 tree diagram of VYSM. 250 module: ietf-ucpe 251 +--rw ucpe* [name] 252 +--rw name string 253 +--rw links* [link] 254 | +--rw link string 255 +--rw phyInterfaces* [interface] 256 | +--rw interface string 257 | +--rw ports* [port] 258 | +--rw port string 259 | +--rw link? -> ../../../links/link 260 +--rw switches* [switch] 261 | +--rw switch string 262 | +--rw ports* [port] 263 | +--rw port string 264 | +--rw name? string 265 | +--rw link? -> ../../../links/link 266 +--rw vms* [vm] 267 +--rw vm string 268 +--rw ports* [port] 269 | +--rw port string 270 | +--rw name? string 271 | +--rw link? -> ../../../links/link 272 +--rw ram? uint64 273 +--rw cpu? uint64 274 +--rw storages* [id] 275 | +--rw id string 276 | +--rw location? string 277 +--rw day0-config 278 +--rw location? string 279 +--rw day0-var-path? string 280 +--rw variable* [name] 281 +--rw name string 282 +--rw value? string 284 6. Specification of the VNF YANG Service Model 286 This section presents the specification of the VYSM. 288 file "ietf-ucpe@2019-09-16.yang" 289 module ietf-ucpe { 290 namespace "urn:ietf:params:xml:ns:yang:ietf-ucpe"; 291 prefix ietf-ucpe; 292 organization 293 "SFR"; 294 contact 295 "Dmytro Shytyi 296 EMail:ietf.dmytro@shytyi.net"; 297 description 298 "This YANG Service Model for uCPE management."; 299 revision 2018-07-01 { 300 description 301 "Initial revision."; 302 reference 303 "draft-shytyi-netmod-vysm-01"; 304 } 305 revision 2019-09-16{ 306 description 307 "Added 0day config for VNFs. 308 Yang model modified according 309 to the received comments."; 310 reference 311 "draft-shytyi-opsawg-vysm-00"; 312 } 314 list ucpe{ 315 key name; 316 leaf name { 317 type string; 318 description "ID of uCPE where 319 a service is instantiated"; 320 } 321 list links{ 322 key link; 323 leaf link{ 324 type string; 325 description "Name of the virtual link from the pool 326 of the links"; 327 } 328 description "Pool of the virtual links that connect VMs and 329 Interfaces"; 330 } 331 list phyInterfaces{ 332 key interface; 333 leaf interface{ 334 type string; 335 description "Name of physical interface"; 336 } 337 list ports{ 338 key port; 339 leaf port{ 340 type string; 341 description "Name of the connector"; 342 } 343 leaf link{ 344 type leafref{ 345 path "../../../links/link"; 346 } 347 description "Link that is connected to 348 the port via connector"; 349 } 350 description "Set of the connectors the 351 physical interface has"; 352 } 353 description "Set of physical interfaces"; 354 } 355 list switches{ 356 key switch; 357 leaf switch{ 358 type string; 359 description "Name of the forwarding domain"; 360 } 361 list ports{ 362 key port; 363 leaf port{ 364 type string; 365 description "Name of the connector"; 366 } 367 leaf name{ 368 type string; 369 description "Name of the 370 subconnector"; 371 } 372 leaf link{ 373 type leafref{ 374 path "../../../links/link"; 375 } 376 description "Link that is connected to the 377 switch via port"; 378 } 379 description "Set of the connectors the 380 forwarding domain has"; 381 } 382 description "Set of the forwarding domains"; 384 } 386 list vms{ 387 key vm; 388 leaf vm{ 389 type string; 390 description "ID of the Virtual Machine"; 391 } 392 list ports{ 393 key port; 394 leaf port{ 395 type string; 396 description "Name of the connector"; 397 } 398 leaf name{ 399 type string; 400 description "Name of 401 the subconnector"; 402 } 403 leaf link{ 404 type leafref{ 405 path "../../../links/link"; 406 } 407 description "Link that connects the 408 VM with a switch or Interface 409 via connector"; 410 } 411 description "Set of Virtual Machine connectors"; 412 } 414 leaf ram{ 415 type uint64; 416 description "Size of RAM to allocate for 417 the Guest OS"; 418 } 419 leaf cpu{ 420 type uint64; 421 description "Number of vCPUs to 422 allocate for the Guest OS"; 423 } 424 list storages{ 425 key id; 426 leaf id{ 427 type string; 428 description "Number of 429 vDisk attached to the VM"; 430 } 431 leaf location{ 432 type string; 433 description "External location where 434 the image (ex.qcow2) is saved."; 435 } 436 description "Virtual storge/vDisk 437 attached to the Virtual Machine"; 438 } 439 container day0-config{ 440 leaf location{ 441 type string; 442 description "0day configuration location"; 443 } 444 leaf day0-var-path{ 445 type string; 446 description "path of the file 447 that contains the 0day variables"; 448 } 449 list variable{ 450 key name; 451 leaf name{ 452 type string; 453 description "variable name"; 454 } 455 leaf value{ 456 type string; 457 description "variable value"; 458 } 459 description "list of variables"; 460 } 461 description "0day configuration:init config"; 463 } 464 description "Set of the Virtual Machines configured 465 on the universal Customer-Premises Equipment"; 466 } 467 description "This is an uCPE management service"; 468 } 469 } 470 472 7. XML example 474 The XML example below presents the configuration of the next service 475 in the uCPE, where: vSW(LAN), vSW(WAN), vSW(Service) - virtual 476 switches; l1,l2,l3,l4 - virtual links; VMs represent PNFs (Physical 477 Network Fuctions) that could be bootstrapped with 0day config/ 478 license. 480 +--------+ +-------------+ +------------+ 481 |vSW(LAN)|--l2--|VNF-vFirewall|--l3--| | 482 +--------+ +-------------+ | | 483 +--------+ +-------------+ |vSW(Service)| 484 |vSW(WAN)|--l1--| VNF_vCPE |--l4--| | 485 +--------+ +-------------+ +------------+ 487 488 ucpe1 489 490 l1 491 492 493 l2 494 495 496 l3 497 498 499 l4 500 501 502 lan 503 504 10 505 l2p10 506 l2 507 508 509 510 service 511 512 10 513 l3p10 514 l3 515 516 517 11 518 l4p10 519 l4 520 521 522 523 wan 524 525 10 526 l1 527 528 529 530 VNF-vCPE 531 532 1 533 l1p1 534 l1 535 536 537 2 538 l4p2 539 l4 540 541 2048 542 2 543 544 1 545 http://192.168.2.1/vCPE-x86.qcow2 546 547 548 https://192.168.2.1/vCPE-day0.iso 549 /config.rom 550 551 hostname 552 IETF-vCPE 553 554 555 ipaddress 556 192.168.1.2 255.255.255.0 557 558 559 560 561 VNF-vFirewall 562 563 1 564 l3p1 565 l3 566 567 568 2 569 l2p2 570 l2 571 572 2048 573 2 574 575 1 576 http://192.168.2.1/vFirewall-x86.qcow2 577 578 579 https://192.168.2.1/vFirewall-day0.iso 580 /config.rom 581 582 hostname 583 vFirewall 584 585 586 ipaddress 587 192.168.1.3 255.255.255.0 588 589 590 591 593 8. Security Considerations 595 At this time, no security considerations are addressed by this memo. 597 9. IANA Considerations 599 No request to IANA at this time. 601 10. Acknowledgements 603 The authors would like to thank: 605 o Mahesh Jethanandani. 607 o Robert Varga. 609 o Bill Wu. 611 o Joe Clarke. 613 for their valuable comments. 615 11. Normative References 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, 619 DOI 10.17487/RFC2119, March 1997, 620 . 622 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 623 Classification", RFC 8199, DOI 10.17487/RFC8199, July 624 2017, . 626 Authors' Addresses 628 Dmytro Shytyi 629 SFR 630 Paris , Ile-de-France 631 France 633 Email: ietf.dmytro@shytyi.net 634 URI: https://dmytro.shytyi.net 636 Laurent Beylier 637 SFR 638 Paris , Ile-de-France 639 France 641 LUIGI IANNONE 642 Telecom ParisTech 643 Paris , Ile-de-France 644 France