Mk network programmability-03_en

19 Feb. 2015 Miya Kohno, [email protected]

“Declarative Programming” and a form of SDN

Network Programmability Study Group Workshop #3 http://network-programmability.connpass.com/

About me

•  Miya Kohno, Principal Engineer, Cisco Systems •  Used to be a soDware engineer - Love of Programming style discussion

•  ADer that, I have been a network engineer - Protocol - Network Architecture

•  Official Blog - hPp://gblogs.cisco.com/jp/author/miyakohno/

•  TwiPer @mkohno

Agenda

•  Programming Paradigm Discussion in the Networking Discipline

•  A Form of SDN Open Daylight -‐-‐ BGP-‐LS/PCEP and MD-‐SAL

What is Network Programmability ?!

•  Neutron

I E T F •  NETCONF/YANG •  I2RS •  FORCES •  + and any network protocols !

To be Programmed / Orchestrated by Network Engineers

To Program Network Devices (Virtual, Physical)

Programming Paradigm Trend ��in the Networking Discipline (hypothesis)

•  Not Impera^ve but Declara7ve •  Not Procedural but Model driven •  Not Waterfall but Agile

What’s Declarative Programming ?

•  A program that describes what computaôn should be performed and not how to compute it

•  Any programming language that lacks side effects (or more specifically,

is referenâlly transparent) •  A language with a clear correspondence to mathema^cal logic

http://en.wikipedia.org/wiki/Declarative_programming

Any style of programming that is not impera^ve


http://karari.tumblr.com/post/61067682037/clojure

“Add all the integers from 1 to 10”

Impera^ve code var s = 0;!for(var n=1; n<=10; n++)! {! s = s + n; ! }!console.log(s);!//55!

Declara^ve code

(->> (range 1 11)! (reduce +)! (println)!)!//55!

Flowchart ! Model !!

n <= 10 ?

•  Add •  increment n

1 ... 10

A set of the integers range : 1…10

sum

What’s Declarative Programming ? Lack of side effect : Referenâlly Transparent, Idempotent

Referenâl Transparency A property whereby an expression can be replaced by its value without affec^ng the program e.g. to use global variables makes it referenâlly opaque

Idempotence A quality of an acôn such that repe^ôns of the acôn have no further effect on outcome e.g. n++; (incremen^ng) is not idempotent

à These concepts are important for networking compu^ng / distributed parallel compu^ng, where environment is uncertain and such things like retries or duplicates could more likely happen..

Idempotence

group{'sysadmin':!!ensure=>present!

}!

# First Puppet Run!notice: /Group[sysadmin]/ensure: created!notice: Finished catalog run in 0.08 seconds!!# Second Puppet Run!notice: Finished catalog run in 0.03 seconds!

An example from Puppet

To state the desired status = “present”

The second run is not executed, because it is already “present”

We could do this using Shell Script(Impera^ve), but with condiônal branches..

if["`getentgroupsysadmin|awk-F:'{print$1}'`"==""]!!then!! !groupaddsysadmin!

fi!


[Pros] •  Robustness and Scalability

-‐  In uncertain and complex environments -‐  In distributed parallel systems

•  Reusability, Maintainability

[Cons] •  Tend to be Turing incomplete •  BePer to restrict domain/scope •  Not good at controlling details

To agree on “what” Model

Referenâl Transparence

and Idempotence

Turing completeness? •  Definiôn of Turing completeness -  A computaônal system that can compute every Turing-‐computable

funcôn is called Turing complete (or Turing powerful). Alterna^vely, such a system is one that can simulate a universal Turing machine. hPp://en.wikipedia.org/wiki/Turing_completeness

-  Impera^ve languages are all Turing complete. (e.g. C, Java, Perl, PHP, Python..)

•  Declara^ve languages tend to be Turing incomplete

-  It does not mean Declara^ve languages cannot be Turing complete. -  It’s bePer not to be universally powerful. Instead, by limi^ng the

scope or context, the power of declara^veness would be op^mized. (e.g. SQL, HTML, JSON, YANG..)


Impera^ve Declara^ve

Programming Language

•  Procedural Programming

•  Funcônal Programming •  Domain Specific

Language

Network Control •  Openflow OVS •  DB •  NETCONF/RESTCONF •  Control Plane Protocols

Orchestraôn/Automaôn

•  Workflow •  Model-‐driven

Configuraôn Management

•  Script •  Puppet •  CFEngine

•  OVSDB

Transport

Assurance Orchestraôn Control

Infrastructure •  Physical •  Virtual

virtual physical

Service Applicaôn

Forwarding Plane

(Distributed) Control Plane

(Centralized) Control Plane

Domain Orchestraôn

Service Orchestraôn

Service, Applicaôn

Hierarchy in Network Programmability Various forms of Programmability

•  Addiôn of Model Driven SAL(Service Adaptaôn Layer) •  Various Southbound Protocol (BGP-‐LS, PCEP..) •  Supports both physical and virtual devices

E.g. OpenDaylight Controller Architecture http://www.opendaylight.org/

Declara^ve

Impera^ve

•  NFVO (NFV Service Orchestrator) •  VNFM (VNF Manager) •  VIM (Virtual Infrastructure Manager) – Openstack, etc.

E.g. ETSI NFV Orchestration Architecture

Imperative

BSS

EMS1

Virtualizaôn Layer

VNFM

VIM

Virtual Compu^ng

Virtual Storage

Virtual Networ

k

NFVO

NFVI

NFV Management

and Orchestraôn

(Mano)

Compu^ng Hardware

Storage Hardware

Network Hardware

VNF1 VNF2 VNF3

Tail-‐f NCS EMS1 EMS1

OSS

SID

Workflow Script

YANG Model VNF, VNFM

Interface Definiôns

YANG Model Service Definiôns

Declarative

Imperative vs Declarative – which fits where

•  For determinis^c environment 　à Impera^ve

•  For uncertain(*) environment 　　à Declara^ve (*) What causes uncertainty •  Logical and physical distance •  Scale-‐up, Growth •  Various kind of components •  Distributed parallel systems •  Mul^-‐agent system

(Appendix) Programming Paradigm discussion in Computing discipline

Object Oriented Procedural

Declara^ve, Funcônal

Conflict ?!

•  Object Oriented and Funcônal Programming are conflic^ng. •  Due to the difference of the principles?

Impera^ve

Declara^ve

(Appendix) Imperative vs Declarative discussion in Cloud Management area

hPp://docs.oasis-‐open.org/tosca/TOSCA/v1.0/cs01/TOSCA-‐v1.0-‐cs01.pdf

Proceedings of the IEEE Internaônal Conference on Cloud Engineering (IEEE IC2E 2014)} March 2014, p87-‐96, DOI 10.1109/IC2E.2014.56

(Appendix – yet another icing on the cake) ��Human and Machine

Impera^ve Paradigm •  Human who writes program knows everything

Declara^ve Paradigm •  Human may NOT know everything

-‐  Machine learning/Deep Learning -‐  Agent based system

•  Network centric programming -‐  A module to program another module via network

Agenda



“Network” �� from the viewpoint of Network Engineers ?!

Network Engineers’ view

Image source : hPp://www.dreams^me.com/royalty-‐free-‐stock-‐images-‐3d-‐white-‐people-‐system-‐administrator-‐image28585969, hPp://www.sudarshansoDech.com/chnt3.htm

node

link

•  Only if we announce the endpoint informaôn and requirements,

•  Then it will be connected!

GW

•  IP addr/subnet •  vlan •  port

External Network

Internal Network Security

Server Engineers’ view

•  Network consists of nodes and links.

•  Topology maPers, Bandwidth maPers..

•  Cost, Delay, JiPer trade-‐offs..

BGP−LS and PCEP – SDN for Network Engineering

R5

R6

R7

R3

R4

R1

R2

SDN Controller

Programming CollecIon

NB interface

PCEP BGP-‐LS, etc

Congesôn!

TE Path calculaôn and setup Collect informaôn: Topology, Bandwidth, Usage.. •  Path to sa^sfy SLA

•  Disjoint paths based on QoS requirements

•  TCP MD5 Signature Opôn (rfc2385) has become separated from BGPCEP project •  SDNi(SDN interface) depends on BGP implementaôn

Implementation of BGP-LS, PCEP in Open Daylight http://www.opendaylight.org/

Topology Learning by BGP-LS https://wiki.opendaylight.org/images/e/e3/Os2014-md-sal-tutorial.pdf

Path (Tunnel) setup by PCEP https://wiki.opendaylight.org/view/BGP_LS_PCEP:Programmer_Guide

R5

R6

R7

R3

R4

R1

R2

SDN Controller

Programming CollecIon

NB interface

PCEP BGP-‐LS, etc

•  draD-‐ie|-‐pce-‐stateful-‐pce-‐02 and draD-‐crabbe-‐iniâted-‐00 •  draD-‐ie|-‐pce-‐stateful-‐pce-‐07, draD-‐ie|-‐pce-‐pce-‐iniâted-‐lsp-‐00 •  draD-‐sivabalan-‐pce-‐segment-‐rou^ng-‐02

Create <node>, <name>, <arguments>, <endpoints-‐obj>, <ero>, <lsp>

Update <node>, <name>, <arguments>, <operaônal>, <ero>, lsp>

Remove <node>, <name>

(Appendix: Segment Routing)

Controller

DC

Cross Domain Orchestraôn

IPv4/IPv6 MPLS

Network

DC Controller

Segment RouIng

One Collector

APIs

MPLS Segment RouIng

Control Plane LDP and RSVP for Label distribuôn

IGP extension to distribute Segment ID

Traffic Engineering

RSVP TE signaling Explicit path is expressed by header stack

ProtecIon RSVP TE FRR (IP FRR/LFA has topology restricôn)

Topology-‐Independent FRR

•  Simple •  No extra control plane (RSVP, LDP) •  No RSVP state in the network

•  Applicaôn centric

Model Driven SAL http://www.opendaylight.org/

AD-‐SAL MD-‐SAL

•  The Model-‐driven approach to service abstracôn presents an opportunity to unify both northbound and southbound APIs and the data structures used in various services and components of an SDN Controller.

Model-Driven SAL

28

module topology-‐tunnel-‐pcep-‐programming { yang-‐version 1; namespace "urn:opendaylight:params:xml:ns:yang:topology:tunnel:pcep:programming"; prefix "ttpp"; import pcep-‐types { prefix pcep; revision-‐date 2013-‐10-‐05; } import topology-‐tunnel-‐programming { prefix ttp; revision-‐date 2013-‐09-‐30; } import topology-‐tunnel-‐p2p { prefix p2p; revision-‐date 2013-‐08-‐19; } import topology-‐tunnel-‐pcep { prefix ptp; revision-‐date 2013-‐08-‐20; } organization "Cisco Systems, Inc."; contact "Robert Varga <[email protected]>"; description "This module contains the programming extensions for tunnel topologies. Copyright (c)2013 Cisco Systems, Inc. All rights reserved. This program and the accompanying materials are made available under the terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at http://www.eclipse.org/legal/epl-‐v10.html"; rpc pcep-‐create-‐p2p-‐tunnel { input { uses ttp:create-‐p2p-‐tunnel-‐input; uses p2p:tunnel-‐p2p-‐path-‐cfg-‐attributes; uses ptp:tunnel-‐pcep-‐link-‐cfg-‐attributes; } output { uses ttp:create-‐p2p-‐tunnel-‐output; } } rpc pcep-‐destroy-‐tunnel { input { uses ttp:destroy-‐tunnel-‐input; } output { uses ttp:destroy-‐tunnel-‐output; } } rpc pcep-‐update-‐tunnel { input { uses ttp:base-‐tunnel-‐input; uses p2p:tunnel-‐p2p-‐path-‐cfg-‐attributes; uses ptp:tunnel-‐pcep-‐link-‐cfg-‐attributes; } output { uses ttp:base-‐tunnel-‐output; } } !} !

Yang Tools

Plugin Plugin

Model topology-tunnel-pcep-programming.yang

APIs

Model-Driven SAL •  Controller SAL to communicate with other controller components,

applicaôns, and plugins.

Controller SAL

Why Model?

•  Model is a representaôn of a part of the funcôn, structure and/or behavior of a system (*)

(*) Architectural Board ORMSC, “Model Driven Architecture”, July 2001

•  Advantage of Model •  Declara^ve 　　Agree on “what”, not “how” •  Commonality 　Abstract diversity

•  Reusability, Maintainability, Portability 　　Conversion from model to model •  Robustness in uncertain environment

Agenda



Declara^ve programming and Model-‐drivenness has an advantage in networking compu^ng, where the environment is more uncertain.

Thank you !