The document discusses declarative programming as it relates to network programmability. It provides examples of declarative versus imperative code and explains key concepts of declarative programming like lack of side effects, referential transparency, and idempotence. It also discusses how declarative programming can provide benefits like robustness, scalability, and reusability for network systems, which often operate in uncertain distributed environments. Finally, it outlines some declarative programming approaches being used for network control, orchestration, and automation.

1. 19
Feb.
2015
Miya
Kohno,
miya.kohno@gmail.com
“Declarative Programming” and a form of SDN
Network Programmability Study Group Workshop #3
http://network-programmability.connpass.com/

2. 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

3. Agenda
• Programming
Paradigm
Discussion
in
the
Networking
Discipline
• A
Form
of
SDN
Open
Daylight
-­‐-­‐
BGP-­‐LS/PCEP and
MD-­‐SAL

4. 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)

5. Programming Paradigm Trend
in the Networking Discipline (hypothesis)
• Not
Impera^ve
but
Declara7ve
• Not
Procedural
but
Model
driven
• Not
Waterfall
but
Agile

6. What’s Declarative Programming ?
• A
program
that
describes
what
computa^on
should
be
performed
and
not
how
to
compute
it
• Any
programming
language
that
lacks
side
effects
(or
more
specifically,
is
referen^ally
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

7. What’s Declarative Programming ?
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

8. What’s Declarative Programming ?
Lack
of
side
effect
:
Referen^ally
Transparent,
Idempotent
Referen^al
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^ally
opaque
Idempotence
A
quality
of
an
ac^on
such
that
repe^^ons
of
the
ac^on
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..

9. 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^onal
branches..
if[`getentgroupsysadmin|awk-F:'{print$1}'`==]!
!then!
! !groupaddsysadmin!
fi!

10. What’s Declarative Programming ?
[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^al
Transparence
and
Idempotence

11. Turing completeness?
• Defini^on
of
Turing
completeness
- A
computa^onal
system
that
can
compute
every
Turing-­‐computable
func^on
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..)

12. What’s Declarative Programming ?
Impera^ve
Declara^ve
Programming
Language
• Procedural
Programming
• Func^onal
Programming
• Domain
Specific
Language
Network
Control
• Openflow
OVS
• DB
• NETCONF/RESTCONF
• Control
Plane
Protocols
Orchestra^on/
Automa^on
• Workflow
• Model-­‐driven
Configura^on
Management
• Script
• Puppet
• CFEngine
• OVSDB

13. Transport
Assurance
Orchestra^on
Control
Infrastructure
• Physical
• Virtual
virtual
physical
Service
Applica^on
Forwarding
Plane
(Distributed)
Control
Plane
(Centralized)
Control
Plane
Domain
Orchestra^on
Service
Orchestra^on
Service,
Applica^on
Hierarchy in Network Programmability
Various
forms
of
Programmability

14. • Addi^on
of
Model
Driven
SAL(Service
Adapta^on
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

15. • NFVO
(NFV
Service
Orchestrator)
• VNFM
(VNF
Manager)
• VIM
(Virtual
Infrastructure
Manager)
–
Openstack,
etc.
E.g. ETSI NFV Orchestration Architecture
Imperative
BSS
EMS1
Virtualiza^on
Layer
VNFM
VIM
Virtual
Compu^ng
Virtual
Storage
Virtual
Networ
k
NFVO
NFVI
NFV
Management
and
Orchestra^on
(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^ons
YANG
Model
Service
Defini^ons
Declarative

16. 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

17. (Appendix) Programming Paradigm discussion in
Computing discipline
Object
Oriented
Procedural
Declara^ve,
Func^onal
Conflict
?!
• Object
Oriented
and
Func^onal
Programming
are
conflic^ng.
• Due
to
the
difference
of
the
principles?
Impera^ve
Declara^ve

18. (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^onal
Conference
on
Cloud
Engineering
(IEEE
IC2E
2014)}
March
2014,
p87-­‐96,
DOI
10.1109/IC2E.
2014.56

19. (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

20. Agenda
• Programming
Paradigm
Discussion
in
the
Networking
Discipline
• A
Form
of
SDN
Open
Daylight
-­‐-­‐
BGP-­‐LS/PCEP and
MD-­‐SAL

21. “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^on
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..

22. 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^on!
TE
Path
calcula^on
and
setup
Collect
informa^on:
Topology,
Bandwidth,
Usage..
• Path
to
sa^sfy
SLA
• Disjoint
paths
based
on
QoS
requirements

23. • TCP
MD5
Signature
Op^on
(rfc2385)
has
become
separated
from
BGPCEP
project
• SDNi(SDN
interface)
depends
on
BGP
implementa^on
Implementation of BGP-LS, PCEP in Open Daylight
http://www.opendaylight.org/

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

25. 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^ated-­‐00
• draD-­‐ie|-­‐pce-­‐stateful-­‐pce-­‐07,
draD-­‐ie|-­‐pce-­‐pce-­‐ini^ated-­‐lsp-­‐00
• draD-­‐sivabalan-­‐pce-­‐segment-­‐rou^ng-­‐02
Create
node,
name,
arguments,
endpoints-­‐obj,
ero,
lsp
Update
node,
name,
arguments,
opera^onal,
ero,
lsp
Remove
node,
name

26. (Appendix: Segment Routing)
Controller
DC
Cross
Domain
Orchestra^on
IPv4/IPv6
MPLS
Network
DC
Controller
Segment
RouIng
One
Collector
APIs
MPLS
Segment
RouIng
Control
Plane
LDP
and
RSVP
for
Label
distribu^on
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^on)
Topology-­‐
Independent
FRR
• Simple
• No
extra
control
plane
(RSVP,
LDP)
• No
RSVP
state
in
the
network
• Applica^on
centric

27. Model Driven SAL
http://www.opendaylight.org/
AD-­‐SAL
MD-­‐SAL
• The
Model-­‐driven
approach
to
service
abstrac^on
presents
an
opportunity
to
unify
both
northbound
and
southbound
APIs
and
the
data
structures
used
in
various
services
and
components
of
an
SDN
Controller.

28. 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
rovarga@cisco.com;
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

29. Model-Driven SAL
• Controller
SAL
to
communicate
with
other
controller
components,
applica^ons,
and
plugins.
Controller
SAL

30. Why Model?
• Model
is
a
representa^on
of
a
part
of
the
func^on,
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

31. Agenda
• Programming
Paradigm
Discussion
in
the
Networking
Discipline
• A
Form
of
SDN
Open
Daylight
-­‐-­‐
BGP-­‐LS/PCEP and
MD-­‐SAL
Declara^ve
programming
and
Model-­‐drivenness
has
an
advantage
in
networking
compu^ng,
where
the
environment
is
more
uncertain.

32. Thank you !