Subject: [Supa] open daylight network intent composition and group-based policy

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Feb 2015 16:55:28 +0100

Hi,

some background reading perhaps...

https://github.com/stackforge/group-based-policy

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

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

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: JF Tremblay <[email-masked]>
Date: Mon, 16 Feb 2015 14:24:40 -0500

Thanks Juergen. 

Also of interest: 
https://wiki.openstack.org/wiki/Congress
https://www.openstack.org/assets/presentation-media/Congress-OpenStack-Atlanta-2014.pdf
http://www.nemo-project.net

Congress’ policies have some significant similarities with intents. 

Just came across this, looks like even OPNFV has related projects that just started: 
https://wiki.opnfv.org/requirements_projects/nemo
https://wiki.opnfv.org/requirements_projects/virtual_infrastructure_deployment_policies (copper)

This last one cites GBP and Congress as upstreams. 

JF

> On Feb 16, 2015, at 10:55 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Feb 2015 21:28:21 +0100

Thanks. So who can answer what is real and what is not? Is there a
place where I can see say a simple example descibed in all the
different policy approaches?

I try to understand what is technically behind all the fancy terms
that pop up all over the place. So far, it seems that Congress is
based on some form of Datalog (and Datalog I would say is a reasonably
well defined 1st order logic programming language, a cousing of Prolog
so to say). So yes, there is a certain policy execution model defined.

What exactly are Open Daylight intents technically? What is their
execution model?

The same for nemo - what exactly drives the execution of nemo policies
(whatever they are)?

Who can decently explain the _technical_ similarities and differences
behind all these projects?

/js

PS: The fun part is that every project within a project lists N other
    projects within other projects that they will interoperate with
    but then the technical details are difficult to find for me, so
    how can I believe this will all work out?

---

From: JF Tremblay <[email-masked]>
Date: Tue, 17 Feb 2015 15:20:41 -0500

Inline. 

> On Feb 16, 2015, at 3:28 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

I doubt there’s a single point of information for this. 

> so to say). So yes, there is a certain policy execution model defined.

Right. And using datalog has some clear advantages. It’s a well known declarative language, some tools and a body of knowledge exist to support it. 

> What exactly are Open Daylight intents technically? What is their

The intent group is still defining the concept of intents and how they would be process. 
These two pages provide a bit of details. 
https://wiki.opendaylight.org/view/Network_Intent_Composition:Dynamic_Attributes
https://wiki.opendaylight.org/view/Network_Intent_Composition:Use_Cases

> The same for nemo - what exactly drives the execution of nemo policies

Nemo is mostly a project from Huawei research showing a nice high-level configuration API and some basic text-based expression of network policies. 

The work is really nice-looking (you can see Susan Hares presentation from the last IETF), but the language still have very few verbs and attributes defined.  

> behind all these projects?

I’ve been trying to do just that for some time now. I’m not sure my explanations qualify as “decent” yet, but I can take a shot. 

OpenNFV: 
- The work has started recently on that side (inaugural meeting in October 2014). 
- The projects aim specifically at “not re-inventing the wheel”, 15 projects approved so far.
- They use mostly OpenStack and add different technologies to reach a specific goal depending of the group. 
- The overall goal is to provide “packages” or environment to showcase NFV for different purposes (my words here). 
- See https://www.opnfv.org and https://wiki.opnfv.org

Nemo: 
- A Huawei research project: http://www.nemo-project.net
- Declarative syntax, but with a very limited grammar at this point.
- Very nice graphical interface
- See Susan Hares presentation and demo from Honolulu for details. 

GBP
- Cisco-backed policy framework for OpenStack, undergoing for more than a year, I believe (since Dec 2013)
- Also claim to be intent-based (see https://wiki.openstack.org/wiki/GroupBasedPolicy)
- Uses a contract concept as the base for the abstraction
- Takes advantage of existing objects defined in OpenStack. 
- First release in Juno in June 2014. 

Congress
- “Higher-level” framework from OpenStack, policy as a service. (https://wiki.openstack.org/wiki/Congress)
- Meeting since early 2014, but not sure it has been released yet. 
- Aims at being the high level orchestrator framework (my view…)
- Uses the declarative language datalog, a derivative of prolog, which has some history and background research. 
- Could be used as an orchestrator to define policies of other network controllers than Neutron, for example an ODL or ONOS. 

Intents
- New kid on the block, has been discussed publicly for a couple of months (again, my view)
- Has been discussed as an ODL project first: 
(See https://wiki.opendaylight.org/view/Project_Proposals:Network_Intent_Composition)
- Is now being discussed at ONF also (can’t say more, given that ONF isn’t really ‘open’ despite its name)
- The goal is to provide a simpler “most-northbound” interface, in David Lenrow words. 
- Also aims at solving stateless distribution of information through multiple controllers, limiting the needs to synchronize large data sets. 
See: https://www.sdxcentral.com/articles/contributed/network-intent-summit-perspective-david-lenrow/2015/02/
- Based on endpoint groups and constraints (probably no verb involved, not sure)
- Example of constraints include access, isolation, QoS, services, time-related, etc. 
- It’s clear that intents are a subset of policies, but it isn’t clear that an intent-based northbound interface alone is sufficient for all needs. 
- Some argue that a set of more specific (detailed) interfaces are required in the northbound direction, for example to be exposed by a network controller (for example yang model based restconf or other). 
(an example of this is: what happens when an intent go wrong? How to debug it? Or how to configure specific behaviors that are not possible with intents?)  

>    how can I believe this will all work out?

A few projects will know some some success, some others might merge or disappear over time. 

From an open-source perspective, it isn’t new. If you look at the members of each project, you’ll find several names come back. Some people are hedging their bets… ;) 

JF

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Feb 2015 10:52:52 +0100

Thanks, this is helpful.

/js