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

https://wiki.opendaylight.org/view/SDN_Interface






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 Decomposition

11


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_Composition: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

https://wiki.opendaylight.org/view/Network_Intent_Composition:Use_Cases

https://wiki.opendaylight.org/view/Network_Intent_Composition:Use_Cases


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 Pagehttps://wiki.opendaylight.org/view/Network_Intent_Composition:Main

Mailing [email protected]

Trello Boardhttps://trello.com/b/L4GssBld/opendaylight-nic

More Information

33

https://wiki.opendaylight.org/view/Network_Intent_Composition:Main



mailto:[email protected]

mailto:[email protected]

https://trello.com/b/L4GssBld/opendaylight-nic

https://trello.com/b/L4GssBld/opendaylight-nic

Questions

Avèk RespèMèsi

network intent composition in opendaylight

Software