CNFs vs. VNFs
Dan Kohn
Executive Director, CNCF

Cloud Native Computing Foundation• Non-profit, part of the Linux Foundation; founded Dec 2015
Incubating

Graduated

Orchestration

Distributed
Tracing API

Logging

Monitoring

Distributed
Tracing

SoftwareUpdate Spec

RemoteProcedure Call

Security• Platinum members:

2© 2018 Cloud Native Computing Foundation

Storage

Container
RuntimeSandboxContainer
RuntimeService Discovery

Networking
API

MessagingService Mesh

Service Mesh

Package
Management

Storage

Serverless

IdentitySpec

Tooling

Identity

Registry

PolicyMetrics
Spec

Key/ValueStoreTODAY THE LINUX FOUNDATION IS MUCH MORE THAN LINUXSecurity

NetworkingCloud

Automotive

BlockchainWeb

We are helping
global privacy
and security
through a
program toencrypt theentire internet.

We are creating
ecosystems aroundnetworking toimprove agility in the
evolving softwaredefined datacenter.

We are creating a
portability layer forthe cloud, driving defacto standards anddeveloping theorchestration layer
for all clouds.

We are creating theplatform for
infotainment in theauto industry thatcan be expanded
into instrument
clusters andtelematics systems.

We are creating apermanent, secure
distributed ledger
that makes it easierto create costefficient,decentralizedbusiness networks.

We are providing theapplication
development
framework for next
generation web,mobile, serverless,and IoT applications.

We are regularly adding projects; for the most up-to-date listing of all projects visit tlfprojects.org

33

KubeCon + CloudNativeCon• China– Shanghai: November 14-15, 2018
– Sponsorships open
• North America– Seattle: December 11 - 13, 2018
– Sponsorships open
• Europe– Barcelona: May 21 - 23, 20194

Cloud Native Computing Foundation (CNCF)

Network Architecture Evolution› 1.0: Separate physical boxes for each component (e.g., routers,switches, firewalls)› 2.0: Physical boxes converted to virtual machines called Virtual
Network Functions (VNFs) running on VMware or OpenStack› 3.0: Cloud-native Network Functions (CNFs) running on Kubernetes
on public, private, or hybrid clouds

5

Network Architecture 1.0

6

Network Architecture Evolution› 1.0: Separate physical boxes for each component (e.g., routers,switches, firewalls)› 2.0: Physical boxes converted to virtual machines called Virtual
Network Functions (VNFs) running on VMware or OpenStack7

Network Architecture 2.08

Network Architecture Evolution› 1.0: Separate physical boxes for each component (e.g., routers,switches, firewalls)› 2.0: Physical boxes converted to virtual machines called Virtual
Network Functions (VNFs) running on VMware or OpenStack› 3.0: Cloud-native Network Functions (CNFs) running on Kubernetes
on public, private, or hybrid clouds

9

Network Architecture 3.0(hardware is the same as 2.0)

10

Evolving from VNFs to CNFs
Past
VNFs

Present

ONAP Orchestrator

OpenStack or VMWare
Bare Metal

Azure orRackspace

VNFs
OpenStack

CNFs

FutureONAP
Orchestrator

CNFsKubernetes

VNFs
KubeVirt/Virtlet

ONAP
Orchestrator

Kubernetes
Bare Metal

Any CloudBare Metal

Any Cloud› ONAP Amsterdam (Past) runs on OpenStack, VMware, Azure or Rackspace› ONAP Casablanca (Present) runs on Kubernetes and so works on anypublic, private or hybrid cloud› Virtual Network Functions (VNFs) are virtual machines that run onOpenStack or VMWare, or can be run on K8s via KubeVirt or Virtlet
11

Major Benefits
1. Cost savings (with public, private, and hybrid clouds)
2. Development velocity
3. Resiliency (to failures of individual CNFs, machines, and even datacenters)

12

The challenge of transitioning VNFs to CNFs
› Moving from network functionality from physical hardware toencapsulating the software in a virtual machine (P2V) is generally easierthan containerizing the software (P2C or V2C)
› Many network function virtualization VMs rely on kernel hacks or otherwise
do not restrict themselves to just the stable Linux kernel userspace ABI› They also often need to use DPDK or SR-IOV to achieve sufficient performance› Containers provide nearly direct access to the hardware with little or novirtualization overhead› But they expect containerized applications to use the stable userspace Linuxkernel ABI, not to bypass it13

Areas for More Discussion› The strength of no longer being locked into specific OSs› Any version of Linux >3.10 is acceptable› Multi-interface pods vs. Network Service Mesh
› Complete parity for IPv6 functionality and dual-stack support in K8s› Security, and specifically recommendations from Google and Jess thatcome into play when hosting untrusted, user-provided code
› Possible use of isolation layers such as gVisor or Kata
› Scheduling container workloads with network-related hardware
constraints (similar to what’s been done for GPUs)› Network-specific functionality like QOS

14

Demo Plans Underway› VNFs vs. CNFs
› Working on a demo of boot-time and throughput of VNFs onOpenStack vs. CNFs on Kubernetes, where the networking code andunderlying hardware is identical› Will deliver opens source installers and Helm charts› Cloud-native Customer Premises Equipment (CCPE) Project› Modify the ONAP vCPE use case and VNF deployment to show VNF vs.
CNF deployments of chained network functions

15Roll-Out Plans› Open Source Summit NA, Vancouver, August 28: Joint workshop by
CNCF executive director Dan Kohn and LF Networking head Arpit
Joshipura on Cloud-native Network Functions› Open Network Summit Europe, Amsterdam, September 25: Marketinglaunch› KubeCon + CloudNativeCon NA, Seattle, December 11: Planned
demo› Mobile World Congress, Barcelona, February 25: Major roll-out› Ongoing close collaboration with LF Networking and specific carriers
providing feedback (AT&T, Bell Canada, Vodafone, etc.)
16

The Networking aspectsof Cloud NativeArpit Joshipura
GM Networking
The Linux FoundationIndustry Direction: Any Cloud + Portable Apps in Containers› Utilize the best of Cloud with the best of Telecom Networks› Promise of Containers – allow for any cloud portability› Promise of Network – full network automation & zero touch services› Telecom Network Transformation require a hybrid strategy› Migration of VM to containers step by step approach to VNF/Workloads› VM and Container Interworking in a Multi-VIM environment

The Linux Foundation Internal Use Only

8/27/18

18

Two leading de-facto platforms –Networking & Cloud&• Network Automation & Orchestration Platform• Cloud Automation & Orchestration Platform• ONAP has a multi-VIM strategy (Openstack,Vmware, Azure,..)• Project within CNCF looking at ONAP –Cross Cloud CI• Project within ONAP – OOM looking atContainers

Open Source projects at LF can bring the best of both worlds tothe Telecom Industry
The Linux Foundation Internal Use Only

8/27/18

19

Sustainable Innovation: Open Source Networking

Creating De-Facto Platforms to Enable Next Generation Solutions in Telecom, Enterprise & Cloud
Carrier Services
Cloud Services
Enterprise Services
10/10 Top Vendors Active

Network Automation/Zero Touch
New Services in Minutes$576M Shared
Innovation
SDO+OSSHarmonization

ValueSolutions

New Services
5G/IOT/Edge/AI

LF 9/10 Most important projects
De-Facto Platform for ~70% Global SubLF Networking Vision: Automating Cloud, Network, & IOT Services
Services

Cloud Services

Software&Automati
onCloud
Automation

Enterprise

Infrastructure

Software Defined
Data Centers(SDDC)

Residential Services

Enterprise Services(ONAP, OPNFV, ODL,FD.io, SNAS, PNDA)

DataCenters

Carrier
Network

Cloud
Network

IOT Services

IOT Automation

Public/Hybrid
Cloud Service Providers
Cloud Hosting
Private Cloud Providers
Web Service Providers

Service Providers
MSO/CableCo21Bringing It All Together Core to Edge – LF Open Source
Network + Disaggregation + Edge + IOT + AI + Cloud + Blockchain
Standards for Edge

MobileCarrier Cloud
Data Center

CarrierAccess
Edge

Residential

Open Access

Ref Implementation

Internet /Web

Public Cloud

IoT, Gateway &Cloud Ref ArchEnterpris
e& IIOTEnterprise

Carrier Core

Hosted Private
Cloud

SMB

CarrierInterconnect

Open Edge

Other Edge Activities

Open Source Networking LandscapeLF Networking
HarmonizedLinux Foundation hosts 9/10 Top projects
Network Data Analytics

SoftwareOrchestration, Management, Policy
Cloud & Virtual Management

Infrastructure

Network Control

Network Operating Systems

Outside LinuxFoundation

Standards

Product, Services & Workloads

System Integration & Test Automation

Services

Application Layer / App Server

atpd
U ed 8120Linux Foundation
HostedSONiCIO Abstraction & Data PathDisaggregated Hardware

CI/CDAutomation of Network + Infrastructure + Cloud + Apps + IOT
23

Linux Foundation Path to Open Source Harmonization 2.0
Edge

Analytics/AI/BlockchainAutomation.
Control& Orchestration

Carrier Cloud & Enterprise

AcumosAI / Deep Learning / Blockchain

AI & Marketplace/By Vertical X Projects

LFN / ONAP+ODL+OPNFV+FD.io

Core to Edge Zero Touch Automation

CNCF / Kubernetes

VM to Container Migration, Portability
Integrated Edge Stack – Zero Touch

Akraino Edge Stack

Infrastructur
eDevices/IIOTServices
The Linux Foundation Internal Use Only

Key Drivers of Each Layer

HybridOrchestration/ VIMs

Include OpenStack, Azure, RS, VMware…

Any Cloud(Public, Hybrid, Service Provider Core, Edge…)

Apps, Location and Service Portability

EdgeX Foundry

IIOT Framework For Core Services

8/27/18

24

The deep dive – VNFs on ONAP & Cloud Native journey

The Linux Foundation Board Confidential

25

VNF Validation Program

VNF Requirements

Integration

Modeling (Utilities)

ONAP Beijing Architecture

A Day in the Life of an ONAP ServiceVNF

DesignRunTime

12Vendor provided VNF(cloud-hosted,optimized or native)

Vendor packages VNF
as per ONAP
requirements;
can use VNF SDK

34

Design/test teams
onboard VNFs

Designers create
products, services, recipes

5

6

OSS/BSS system triggers
service deployment

Service lifecycle
management

7
ClosedLoop

Constant data collection,analytics, event monitoring;
S3P

Credit: Aarna Networks, ONAP Training course
27

Kubernetes Gap Analysis & Transition plans
Top 3 Areas of Investigation1.

Support for VNFs/Apps from different vendors (Ref guest OS and VNF ecosystem alignment)

2.

Security – Access rights and privileges, known rules for admins etc

3.

Network Specific Requirements – focus on performance, scale and capabilities›››››

Enabling scheduling container workloads with network-related hardware constraints (similar to what’s been done for GPUs)
Multi-homed containers (Multis, a CNI plugin is working on this)Functional parity when deployed with IPv6
Network-specific functionality like QOS
multiple vNIC for a given container, which is currently not supported.

Transition plan
› Demo of Any app, Any cloud with ONAP running on Kubernetes @ ONS opening keynote› Kubernetes as the Virtual Infrastructure Manager (VIM) for running the ONAP Orchestrator› Consider Kubernetes as the ONAP Application Controller (AppC)› As VNFs can be containerized, do so and manage them with Kubernetes – prioritize use cases (eg CDN, DNS)

The Linux Foundation Internal Use Only

8/27/1828

Evolving from VNFs to CNFs
Past
VNFs

Present

ONAP Orchestrator

OpenStack or VMWare
Bare Metal

Azure orRackspace

VNFs
OpenStack

CNFs

FutureONAPOrchestrator

CNFs

Kubernetes

VNFs
KubeVirt/Virtlet

ONAPOrchestrator

Kubernetes
Bare Metal

Any CloudBare Metal

Any Cloud› ONAP Amsterdam (Past) runs on OpenStack, VMware, Azure or Rackspace› ONAP Casablanca (Present) runs on Kubernetes and so works on any public, private or hybridcloud› Virtual Network Functions (VNFs) are virtual machines that run on OpenStack or VMWare, or
can be run on K8s via KubeVirt or VirtletToday’s Agenda
BACKGROUND AND VISION
1:30 Introduction to VNFs and CNFs & Cross-cloud Dan Kohn
2:00 Networking & Telecom Automation: VNF to CNF journey Arpit JoshipuraREQUIREMENTS
2:15 Cloud Native lessons and requirement: A view from end user - Telus, Sanah Tariq
2:30 (Dan/Arpit facilitate) Why Telecom and Cloud Native technologies are coming together – discuss challenges and requirements
BREAK

PROJECTS AND ROADMAP
3:30 Overview of projects solving the migration Roadmap to Cloud Native
3:50 Network Service Mesh (VPP/Ligato) Ed Warnicke
4:10 Cross-Cloud CI working group Taylor
4:30 Wrap up and How to get involved

The Linux Foundation Board Confidential

30Envoy&Istio
overview
Ihor Dvoretskyi, @idvoretskyi,
Developer Advocate, CNCFHistory / Community●●●●Inception May ‘15Open sourced September ‘16: https://github.com/envoyproxy/envoy
Joined CNCF September’17: https://www.envoyproxy.io/
Users/contributors (partial list): Lyft, Google, IBM, Verizon, Apple, Microsoft,
Pivotal, Red Hat, EBay, Stripe, VSCO, Tencent QQ, Twilio, Yelp … and more
all the time.
● Integrations (partial list): Istio (Google/IBM), Nomad (Verizon), Tigera,Covalent, Turbine Labs, Datawire … more on the way.
● Lyft deployment: 10s of thousands of hosts, 100s of services, 3M + meshRPS.State of Service-Oriented Architecture networking●●●●●Protocols (HTTP/1, HTTP/2, gRPC, databases, caching, etc.).
Infrastructures (IaaS, CaaS, on premise, etc.).
Intermediate load balancers (AWS ELB, F5, etc.).
Observability output (stats, tracing, and logging).
Implementations (often partial) of retry, circuit breaking, rate limiting,timeouts, and other distributed systems best practices.
● Authentication and Authorization.
● Per language libraries for service calls.

Envoy overview● Out of process architecture: Let’s do a lot of really hard stuff in one place andallow application developers to focus on business logic.
● Modern C++ code base: Fast and productive.
● L3/L4 filter architecture: A byte proxy at its core. Can be used for things otherthan HTTP (e.g., MongoDB, redis, stunnel replacement, TCP rate limiter, etc.).
● HTTP L7 filter architecture: Make it easy to plug in different functionality.
● HTTP/2 first! (Including gRPC and a nifty gRPC HTTP/1.1 bridge).
● Service discovery and active/passive health checking.
● Advanced load balancing: Retry, timeouts, circuit breaking, rate limiting,shadowing, outlier detection, etc.
● Best in class observability: stats, logging, and tracing.
● Edge proxy: routing and TLS.

Istio overview
Connect, manage and secure microservices
Separation of concerns: developer and operations
For both containerized and non-containerized workloads
Leverage great functionality in Envoy, adding pluggable management andcontrol planes● Intelligent routing, load balancing, metrics collection, policy enforcement,
end-to-end authentication● Istio 1.0 announced in July’2018●●●●

Istio components● Mixer - Central component that is leveraged by the proxies andmicroservices to enforce policies such as authorization, rate limits,quotas, authentication, request tracing and telemetry collection.
● Pilot - A component responsible for configuring the proxies at runtime.
● Citadel - A centralized component responsible for certificate issuanceand rotation.
● Node Agent - A per-node component responsible for certificate issuanceand rotation.

Istio and Envoy● Envoy - Sidecar proxies per microservice to handle ingress/egress traffic
between services in the cluster and from a service to external services● Providing a rich set of functions like:○ discovery○ l7 routing○ circuit breakers○ policy enforcement○ telemetry recording/reporting functions.

More details••41

Envoy:– https://www.envoyproxy.io/– https://github.com/envoyproxy/envoy
Istio:– https://istio.io/– https://github.com/istio/istio© 2018 Cloud Native Computing Foundation

ExtraEnvoy overview

Service Cluster

Service Cluster

ServiceService

Envoy

HTTP/2REST / gRPC

External Services

DiscoveryEnvoy

Architectural overview
Control Plane APIPilotMixer

Istio-AuthRouting & loadbalancing info

Telemetry

TLS certs
to Envoy
Policy checks,
telemetry

PodEnvoy

Traffic is transparently interceptedand proxied. Application is unawareof Envoy’s presence

Secured w/mTLS

Envoy

svcA

svcB

Service A

Service B

Bookinfo application sample

Cross-Cloud CI Overview
Cloud-native Network Functions Seminar
August 28, 2018

Presented by:
Taylor Carpenter, Vulk Coop
taylor@vulk.coop

Cross-Cloud CI Project Overview
Why?

48

© 2018 Cloud Native Computing Foundation

Cross-Cloud CI Project Overview
Why?

49

CNCF ecosystem is growing rapidly with new projects and cloud providers!

© 2018 Cloud Native Computing Foundation

Cross-Cloud CI Project Overview
Why?
•50

The CNCF ecosystem is large, diverse and continues to grow. CNCF would like to ensure
cross-project interoperability and cross-cloud deployments of all cloud nativetechnologies and show the daily status of builds and deployments on a status
dashboard.

© 2018 Cloud Native Computing Foundation

Cross-Cloud CI Project Overview
Why?
•The CNCF ecosystem is large, diverse and continues to grow. CNCF would like to ensure
cross-project interoperability and cross-cloud deployments of all cloud nativetechnologies and show the daily status of builds and deployments on a status
dashboard.

What?
•••

51

Cross-cloud testing system
Status repository server
Status dashboard© 2018 Cloud Native Computing Foundation

Build and provision CNCF projects
Graduated
IncubatingSandbox

52© 2018 Cloud Native Computing Foundation

Project CI artifacts and non-CNCF projects
Implemented

53© 2018 Cloud Native Computing Foundation

Deploy to public/bare metal/private clouds
Implemented

In Progress

54© 2018 Cloud Native Computing Foundation

55© 2018 Cloud Native Computing Foundation

56© 2018 Cloud Native Computing Foundation

57© 2018 Cloud Native Computing Foundation

58© 2018 Cloud Native Computing Foundation

59© 2018 Cloud Native Computing Foundation

60© 2018 Cloud Native Computing Foundation

61© 2018 Cloud Native Computing Foundation

62© 2018 Cloud Native Computing Foundation

63© 2018 Cloud Native Computing Foundation

64© 2018 Cloud Native Computing Foundation

Technology Overview

CI System Technology Overview
Unified CI/CD platform:•GitLab

Cross-cloud provisioning:•Terraform, Cloud-init, and per cloud K8s configuration

App deployments:•K8s manifest management with Helm

E2e tests:•Custom containers + Helm

Automated builds and deployments:•66

Git + per project yaml configuration© 2018 Cloud Native Computing FoundationDashboard Technology Overview
Frontend:• Vue.js
Status repository:•Elixir and Erlang

Automated builds and deployments:• Git + per project yaml configuration

67© 2018 Cloud Native Computing Foundation

Q&A

How to Collaborate
Attend CI WG meetings:•••

https://github.com/cncf/wg-ci
4th Tuesday of the month at 11:00am Pacific Time
Next Meeting is on Tuesday, Sept 28th

Subscribe to the CNCF CI public mailing list:•

https://lists.cncf.io/g/cncf-ci-public

Create issues on GitHub:•

https://github.com/crosscloudci/cross-cloud/issues

Join the #cncf-ci channel on slack:••69

Request invite at https://slack.cncf.io/
Cloud-native.slack.com© 2018 Cloud Native Computing Foundation

Connect with Cross-Cloud CI@crosscloudci@crosscloudcicrosscloudci@vulk.coop70© 2018 Cloud Native Computing Foundation

For more details and an in-depth
demo, please contact Dan Kohn& Cross-Cloud CI teamat CNCF booth at #OSSNA18
Also presenting at:● KubeCon + CloudNativeCon China○ November 13-14, Shanghai