Network Intent Composition in OpenDaylight

What’s the Intent
David Bainbridge
Ciena

www.opendaylight.org
The following is a mixture of opinion, rough group
consensus, and reality. I will try to differentiate
which is which, but no promises.
If in doubt, ask.
Disclaimer
2

An expression of a desired state that is to be
realized.
Intent
3

 Late 1990’s early 2000’s?
 Intent Based Configuration (EDCS-XXXXX)
 Smart Network Elements
 More Recent
 SDN Interface
 https://wiki.opendaylight.org/view/SDN_Interface
 Specifying desired network state at various levels of
precision
 Most Recent
 ODL Network Intent Composition Project
 Probably why you are here
My History with Intent
4

Intent Based Configuration
5

 Intent is provisioned
to the network and is
distributed
knowledge in the
NEs
6

 Intent is provisioned
to the network and is
distributed
knowledge in the
NEs
 Addition of NE
invokes negotiation
via protocols to
understand services
and self configures
 Routing protocol for
services
7

 Allows client to
specify desired
network state
 Client can specify
constraints that
restrict how desired
state is mapped to
network
 System can reason
over complete set of
desired states
Desired Network State
8

 Loose and Precise, it
is a sliding scale
 Controllers can
provide one or both
 Pure loose
adjacency roughly
defined as “intent” as
per ONF
 Pure precise
adjacency roughly
defined as device
mediation
Loose and Precise Adjacencies
9

 Ciena’s ODL Based Controller (MLWC)
 Service Manager – intent by any other name
 ONOS – Intent framework
 Similar to Ciena’s service manager in terms of “intent”
 Group Based Policy (GBP)
 Seemed like the obvious choice for next iteration of
Ciena’s service manager
 Network Intent Composition (NIC)
 Because a simple choice was too much to ask
ONOS, Group Based Policy and Intent
10

Intent Base
(Network View)
Intent Request
Intent Request
Intent Request
Mediation
Render Influencers
Render Influencers
Render Influencers
Start
Yes
No
More Precistion
Possible?Intent Base
(Network View)Existing Intents
Conflict Detection
Render
(to more precise)
Optimization
Intent Decomposition
11

T - 0 T - 1 T - 2 T - 3
applications
requests
network
model
physical/virtual
network
renders /
compilers
Intent as a Continuous Lifecycle
12

 An Intent is …
 Portable – an intent can be moved between
controller implementations and networks and still be
valid*
 Abstract – should not contain any network specific
details (such as specific network element IDs or port
numbers)
 What – specifies what the client wants not how it
should be delivered
 Not only Network Elements – can specify more than
network connectivity, i.e., could include the
deployment of network functions, business services,
or interactions with business systems
Network Intent Composition
13

 Varied Opinions
 Adjacency / Policy Based
 End point groups and actions
 And I am sure others
 Settled on a structure similar to English grammar
subject verb object predicate
 Not a perfect analogy, but workable
subject(s) action(s) condition(s) constraints(s)
Intent Model
14

Model (Simplified)
15

 Can have multiple, limited to 2 for Lithium
 Left fairly opaque for first release
 Meant to be things like …
 Labels to identify groups of end points
 Development
 Quarantined
 (opinion) Any query against the system that can be
resolved to one or more end point
 Similar to jquery selectors
Subjects
16

 Preliminary or core set derived by use cases
 https://wiki.opendaylight.org/view/Network_Intent_Co
mposition:Use_Cases
Actions
17
ALLOW BLOCK AUDIT
LOG INSPECT BANDWIDTH
REDIRECT INJECT LATENCY
LOSS PROTECT SECURE
QOS
 These all aren’t really actions, some are more
like constraints or a policy to be applied

 Used to constrain “how” the intent is
implemented
 Still should be specified in abstract terms not
deployment or network specifics
 Include-subject – insures that an intent
realization passes through a given subject
 Exclude-subject – insures that an intent
realization does not pass through a given
subject
Constraints
18

 Defines when an intent should be “active”
 For Lithium these are time based conditions, but
could be expanded to state based conditions
 Somewhat overlaps with the idea of end point
groups (i.e. if infected is an EPG then when an
EP is put in that group the intent applies)
 ¿ Should the controller manage the schedule or
should that be above the controller ?
Conditions
19

{
“id” : “57bbf1c8-2f66-4060-a4de-911672f9c6f7”,
“subjects” : [
{
“order” : 0,
“end-point-group” : {
“end-point-group” : “infected”
}
},
{
“order” : 1,
“end-point-group” : {
“end-point-group” : “quarantine”
}
}
],
“actions” : [
{
“order” : 0,
“allow” : {}
}
]
}
Example – Infected Hosts
20
Purpose of the intent to to only
allow traffic from the devices in
the end point group “infected”
to devices in the end point
group “quarantine”.
Would also require a block for
all other connectivity.
There are some “oddities” in the JSON
format that are the result of best
practices and how YANG maps to JSON,
particularly around choices and lists.

{
“id” : “57bbf1c8-2f66-4060-a4de-911672f9c6f7”,
“subjects” : [
{
“order” : 0,
“end-point-selector” : {
“end-point-selector” : “#OTNA/1ODU2Client”
}
},
{
“order” : 1,
“end-point-selector” : {
“end-point-selector” : “#OTNZ/1ODU2Client”
}
}
],
“actions” : [
{ “order” : 0,
“allow” : {}},
{ “order” : 1,
“protect” : {}}
]
}
Example – Optical Ports
21
Purpose of the intent to to only
allow traffic between the ports.
Assumes a path will be
computed between the ports.
Protect action implies that a
protection path will also be
provisioned.
There are some “oddities” in the JSON
format that are the result of best
practices and how YANG maps to JSON,
particularly around choices and lists.

 intent.yang
 intent-types.yang
 intent-subjects.yang
 intent-actions.yang
 intent-constraints.yang
 intent-conditions.yang
YANG File Structure
22

 Data based interactions
 Configuration tree is desired intents
 Operational tree is realized intents
 POST/PUT – Create intents
 PUT – Update intents
 DELETE – Remove intents
 GET – Fetch / list intents
 Karaf based console CLI
 Operational intent has a status value which can
be used to track processing of intent
 i.e. in process, provisioned
Working with Intents
23

 NIC project not meant to house all things intent
 Core NIC project is a model and some glue code
 Will likely be expanded to contain other common code
such as conflict resolution
 Modules can augment
 Subjects, actions, constraints, conditions
 Modules can implement
 Render intents to network model changes
Designed to be Augmented
24

grouping intent {
list subjects {
choice subject {
case end-point-selector {
container end-point-selector {
uses subjects:end-point-selector;
}}
case end-point-group-selector {
container end-point-group-selector {
uses subjects:end-point-group-selector;
}}
case end-point-group {
container end-point-group {
uses subjects:end-point-group;
}}
}
}
}
Common Pattern – Choices
25
*Simplifications made and details removed

grouping subject {
}
grouping end-point-selector {
uses subject;
leaf end-point-selector {
type string;
}
}
grouping end-point-group-selector {
uses subject;
leaf end-point-group-selector {
type string;
}
}
Common Pattern – Derivation
26

 Supports a single “renderer” feature installed at
a time
 Triggered by data change notifications
 Transforms intent into network changes
 VTN Renderer
 Uses VTN API to implement intent
 GBP Renderer
 Transforms intent into GBP, which in turn renders the
intent to the network
Lithium Implementation
27

 Contribution model
 Modules can augment intent model
 Subject resolution, action types, constraints, conditions
 Renderers can support rendering one or more
“action”
 Map to renderer based on intent characteristics
 Subject type(s)
 Action
 Conflict resolution
 Reason across all intents configured to
 Optimize network utilization / performance
 Prevent one intent from stomping on another
Post Lithium Implementation
28

 Deployment Specific Influence
 Either as part of the intent (optional argument)
 Deployment policy definitions (FAST = 10Gbps)
 Non-Exact Constraint Values
 I want FAST, but I will take MEDIUM
 I want 10GB bandwidth, but will take 5 to 8GB
Post Lithium Considerations
29

 Loose and precise intents
 Better understand how to inject policy sideways into
an intent rendering
 How is this this exposed via the model / API
 Recursive decomposition
 Renderer may be more of a compilation processes
with several iterations
 What is the “machine language” of an intent or is that
simply a delta to a network model
 ONF NB API WG
 How is this really going to fit together
 Ownership / control issues
What Keeps me Up at Night
30

 How do GBP and NIC work together?
 Are they after the same?
 Is this a what v. how discussion?
 Portability is a great idea, but until all controllers
speak the same API with the same results it is
just an idea
 ODL, ONOS, others?
 Commoditization of controllers
Pondering the Imponderables
31

 Duane Mentze
 Devon Dawson
 Shaun Wackerly
 Rex Pugh
 Uyen Chau
 Dave Lenrow
 Masashi Kudo
 Hideyuki Tai
 Shigeru Yasuda
 Cathy Zhang
 Louis Fourie
 Kanika Gupta
 Mallik Kore
 Mathieu Lemay
 Colin Dixon
 Helen Chen
 George Zhao
 Raphael Amorim
 Vinothkumar
 Alexis de Talhouët
 Gabriel Robitaille-Montpetit
 Benjamin Eze
 Himal Kumar
 Keith Burns
 Ed Warnicke
 Luis Gomez
Acknowledgments
32

 Project Page
https://wiki.opendaylight.org/view/Network_Intent_Composition:Main
 Mailing list
nic-dev@lists.opendaylight.org
 Trello Board
https://trello.com/b/L4GssBld/opendaylight-nic
More Information
33

Network Intent Composition in OpenDaylight

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Network Intent Composition in OpenDaylight

Similar to Network Intent Composition in OpenDaylight (20)

Recently uploaded

Recently uploaded (20)

Network Intent Composition in OpenDaylight