Open Source as Reference Implementation for Next Gen Network Services

Charles Eckel, Cisco DevNet

Red Hat Summit and DevNation, June 27-30, 2016

Open Source as Reference Implementation for Next Gen Network Services

[email protected]

• Open Source and Open Standards

• MEF Third Network

• LSO Hackathons

• Results

• Next Steps

Agenda

• Internet Engineering Task Force

• Make the Internet work better

• Founded in 1986

• Networking protocols and software

• No formal membership or fees

• Produces RFCs

• E.g. TCP/IP, HTTP, TLS, …

• Multi vendor interoperablity is key

• Global Deployment of Carrier Ethernet Networks Services

• Found in 2001

• 200+ member companies

• Service Orchestration

• Certification Programs

• Multi carrier interworking is key

Image source: http://www.edensunshine.com/

An "open standard" must not prohibit conforming implementations in open source software

1. No Intentional Secrets: MUST NOT withhold any detail necessary for interoperable implementation

2. Availability: MUST be freely and publicly available under royalty-free terms at reasonable and non-discriminatory cost

3. Patents: All patents essential to implementation of the standard MUST be licensed under royalty-free terms or be covered by a promise of non-assertion when practiced by open source software

4. No Agreements: MUST NOT be any requirement for execution of a license agreement, NDA, grant, etc, to deploy conforming implementations

5. No OSR-Incompatible Dependencies: Implementation of the standard MUST NOT require any other technology that fails to meet these criteria

Open Standards Requirement for Software

• Complex set of pieces:

• New projects often start quickly, then slowly fade away

• Fragments, many OSS projects that solve 20% of problem but cannot easily be used together

• Hidden gaps, missing functionality, due to lack of overall architecture

• But which manages to:

• Leverage a vast community

• Innovating at a very fast pace

• Sometimes resulting in de facto standard

Open Source Software (OSS)

MEF Third Network

• Network as a Service

• Revolution in service provider networking

• Combines Internet agility and ubiquity with service assurance

• Offers unprecedented levels of user control of the network

• Services orchestrated across network domains between physical or virtual service endpoints

• Cultural event

• Community building

• Implement and validate early versions of specs

• Improve usability and applicability of open source project for use case

• Contribute changes upstream

MEF LSO Hackathons

OpenStack

• Cloud computing platform for public/private clouds

• Abstracts data centers into pools of resources

• Provides management layer for efficient, automated allocation of resources

• Empowers operators, admins, users via self service portals

• Provides APIs to develop cloud-aware applications

- Lithium

Service Abstraction Layer/Corea.k.a. MD-SAL

Base Network Functions

OpenFlow Enabled

Devices

DLUXVTN

CoordinatorOpenStack

NeutronSDNI

Wrapper

Network Applications

Orchestrations &

Services

Open vSwitchesAdditional Virtual &

Physical Devices

Data Plane Elements

(Virtual Switches,

Physical Device

Interfaces)

Controller Platform

Services/Applications

OpenFlow Stats Manager

OVSDB NETCONF PCMM/CO

PSSNBILISP BGP PCEP SNMPSXP

Southbound

Interfaces &

Protocol Plugins

OpenFlow

OpenFlow Switch Manager

USCCAPWAP OPFLEX CoAPHTTP

OpenFlow Forwarding Rules Mgr

L2 Switch

Host Tracker

Topology Processing

AAA AuthN Filter

OpenDaylight APIs REST/RESTCONF/NETCONF

Data Store (Config & Operational) Messaging (Notifications / RPCs)

LACP

Network Services

Service Function Chaining

Reservation

Virtual Private Network

Virtual Tenant Network Mgr.

Unified Secure Channel Mgr

OVSDB Neutron

Device Discovery, Identification

& Driver Management

LISP Service

DOCSIS Abstraction

SNMP4SDN

Network Abstractions

(Policy/Intent)

ALTO Protocol Manager

Network Intent Composition

Group Based Policy Service

Platform Services

Authentication, Authorization &

Accounting

Neutron Northbound

Persistence

SDN Integration Aggregator

Time Series Data RepositoryLink Aggregation Ctl Protocol

Compute NetworkStorage

Open DaylightOpenStack

Neu

tro

n A

PI

Neu

tro

n M

L2

plu

gin

GB

P

VNFs

NFV Orchestration and Management

OPNFV: ContinuousIntegration and Deployment

OPNFV: ContinuousTesting

OPNFV:Requirements

Integration Testing Requirements

General Architecture

Value add for

NFV vendor

Value of OPNFV

Open

Infrastructure

Open Source Platform- e.g. OPNFV

• Participants from Cisco, HPE, Amartus, Microsemi, Ericsson

• Add support for Presto I/F to OpenDaylight - UniMgr project

• I/F defined by Network Resource Provisioning (NRP) UML model

• xmi2yang used to produce YANG model - ONF Eagle project

• Generated code for the Presto interface within OpenDaylight

• Started work on interface activation drivers for OpenDaylight to configure underlying network elements, e.g. Cisco IOS-XR, Microsemi, and others

OpenCS SDN Packet WAN Project

• Uncovered issues with:

• NRP model

• ONF Core Model core model on which it is based

• xmi2yang tool

• Highlighted code generation from generated YANG models NOT straightforward, partly because ONF Core models and derived MEF YANG models are information models and code generation requires data models

• Code contributed upstream into UniMgr project

• Issues with models and tools being addressed in MEF and ONF

• Complete summary: https://communities.cisco.com/community/developer/opensource/blog/2016/05/05/euro16-hackathon-transforms-mefs-lso-architecture-into-code

OpenCS SDN Packet WAN Project Results

• Speed and spirit of open source

• Rigor and stability and of open standards

• Each has positive impact on the other

• Running code validates evolving standards

• Standards unify and guide open source implementations

Combine Open Source and Standards

Certification

Test-Suite

Standards

Open Source

• Be active, ask questions, learn about efforts around you

• Don’t reinvent the wheel

• Reinvent = time wasted + community building opportunity lost

• Contribute upstream

• Don’t fork it up

• IETF 96 Hackathon

• July 16-17, Berlin

• MEF16 Hackathon

• November 7-9, Baltimore

Call to Action

Thank you