Subject: [Sdn] NeMo Demo after SDNrg meeting

From: "Susan Hares" <[email-masked]>
Date: Mon, 10 Nov 2014 12:02:26 -0500

The Nemo project team will be providing a demo just after the end of SDNrg
on Monday 11/10/14 from 11:30am-12:30pm.  Join us right after SDNrg ends for
a demonstration of NeMo - a API for Intent driven networks.  Snacks will be
provided for those who want a bite to eat while they watch the demo. 

 A short description of Nemo is below, and full details are described on the
project page at:  http://www.hickoryhill-consulting.com/nemo/. 

What's Nemo - A Network Modeling Language? 

Nemo is an intent oriented North Bound (NB) interface which allows
applications to use intent-based primitives to create virtual networks
comprised of nodes with policy-controlled flows. Intent oriented policy is
prescriptive ("go to the store") rather than descriptive ("follow this route
to the store"), leaving the details to the network.  Nemo's NB interface
connects the application to a controller and operates using 10 commands
which include 4 basic network commands (Node, Link, Flow, Policy) and 6
basic controller communication commands (connect, disconnect, transact,
commit, notification, query).  Nemo sends these 10 commands using the REST
protocol to exchange the commands with the controller.  These command
operate as transactions allowing the process to have clear checkpoints.    

Why Nemo? 

Software Defined Networking (SDN) and Network Function Virtualization (NFV)
are moving the IT world from a network-centric view to an
application-centric view.  Google considers a datacenter to be the computer
comprised of compute device, storage devices, and network. Applications
running on the Google Cloud must be rewritten to run within this Cloud, an
environment that takes care of placing applications on compute devices that
have the appropriate amount of storage and network connectivity. Nemo
provides a simple NB API which gives the applications on any platform the
power to setup and take down virtual networks between virtual nodes.

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Mon, 10 Nov 2014 17:38:35 +0000

Can't be there, but hopefully someone will ask "why?" in the light of GBP being available in OpenStack and OpenDaylight (and maybe eat a sandwich for me – anything but tuna).

From: Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 10, 2014 1:02 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: David Meyer <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Sdn] NeMo Demo after SDNrg meeting

The Nemo project team will be providing a demo just after the end of SDNrg on Monday 11/10/14 from 11:30am-12:30pm.  Join us right after SDNrg ends for a demonstration of NeMo – a API for Intent driven networks.  Snacks will be provided for those who want a bite to eat while they watch the demo.
 A short description of Nemo is below, and full details are described on the project page at:  http://www.hickoryhill-consulting.com/nemo/.
What’s Nemo – A Network Modeling Language?
Nemo is an intent oriented North Bound (NB) interface which allows applications to use intent-based primitives to create virtual networks comprised of nodes with policy-controlled flows. Intent oriented policy is prescriptive (“go to the store”) rather than descriptive (“follow this route to the store”), leaving the details to the network.  Nemo’s NB interface connects the application to a controller and operates using 10 commands which include 4 basic network commands (Node, Link, Flow, Policy) and 6 basic controller communication commands (connect, disconnect, transact, commit, notification, query).  Nemo sends these 10 commands using the REST protocol to exchange the commands with the controller.  These command operate as transactions allowing the process to have clear checkpoints.
Why Nemo?
Software Defined Networking (SDN) and Network Function Virtualization (NFV) are moving the IT world from a network-centric view to an application-centric view.  Google considers a datacenter to be the computer comprised of compute device, storage devices, and network. Applications running on the Google Cloud must be rewritten to run within this Cloud, an environment that takes care of placing applications on compute devices that have the appropriate amount of storage and network connectivity. Nemo provides a simple NB API which gives the applications on any platform the power to setup and take down virtual networks between virtual nodes.

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 10 Nov 2014 14:59:05 -0500

Ken:

Thank you for the great question. 

Nemo specifies a set of commands to pass from an application to Neutron  via
a RESTFUL interface to signal to signal the desired network for its
application. This is a higher level than the OpenDaylight group policy
engine which works below the Neutron level.  Both Nemo and ODL group policy
use intent-driven policy APIs (what Apps wants) rather than descriptive
policy (how to do it). A comparison of the OpenDaylight Group Policy and
Nemo is at:

http://www.hickoryhill-consulting.com/nemo/nemo-vs-ODL-group-policy-v1.pdf.

We think NeMo provides a simple interface that supports virtual network
creation via transaction based.  One potential direction could be to utilize
the Nemo RESTful commands to set Group Policy.  

Additional documentation on Nemo is at
http://www.hickoryhill-consulting.com/nemo.

Sue 

From: Ken Gray (kegray) [mailto:[email-masked]] 
Sent: Monday, November 10, 2014 12:39 PM
To: Susan Hares; [email-masked]
Cc: David Meyer; [email-masked]
Subject: Re: [Sdn] NeMo Demo after SDNrg meeting

Can't be there, but hopefully someone will ask "why?" in the light of GBP
being available in OpenStack and OpenDaylight (and maybe eat a sandwich for
me - anything but tuna).

From: Susan Hares <[email-masked]>
Date: Monday, November 10, 2014 1:02 PM
To: "[email-masked]" <[email-masked]>
Cc: David Meyer <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: [Sdn] NeMo Demo after SDNrg meeting

Why Nemo?

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 10 Nov 2014 21:19:16 +0100

Hi Sue,

I must say that I like the simplicity and lightness of NeMo as compared to
ODL GBP (as example).

Let's see how far you will manage to push it forward :)

Great proposal !

Best regards and all the best,
Robert.

On Mon, Nov 10, 2014 at 8:59 PM, Susan Hares <[email-masked]> wrote:

> Nemo specifies a set of commands to pass from an application to Neutron
>  via a RESTFUL interface to signal to signal the desired network for its
> creation via transaction based.  One potential direction could be to
> utilize the Nemo RESTful commands to set Group Policy.
>
> *From:* Ken Gray (kegray) [mailto:[email-masked]]
> *Sent:* Monday, November 10, 2014 12:39 PM
> *To:* Susan Hares; [email-masked]
> *Cc:* David Meyer; [email-masked]
> *Subject:* Re: [Sdn] NeMo Demo after SDNrg meeting
>
>
>
> me – anything but tuna).
> *From: *Susan Hares <[email-masked]>
> *Date: *Monday, November 10, 2014 1:02 PM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *David Meyer <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *[Sdn] NeMo Demo after SDNrg meeting
>
>
>
> on Monday 11/10/14 from 11:30am-12:30pm.  Join us right after SDNrg ends
> for a demonstration of NeMo – a API for Intent driven networks.  Snacks
> will be provided for those who want a bite to eat while they watch the
> demo.
>
>  A short description of Nemo is below, and full details are described on
> the project page at:  http://www.hickoryhill-consulting.com/nemo/.
>
> *What’s Nemo – A Network Modeling Language? *
>
> prescriptive (“go to the store”) rather than descriptive (“follow this
> route to the store”), leaving the details to the network.  Nemo’s NB
> interface connects the application to a controller and operates using 10
> commands which include 4 basic network commands (Node, Link, Flow, Policy)
> and 6 basic controller communication commands (connect, disconnect,
> transact, commit, notification, query).  Nemo sends these 10 commands using
> the REST protocol to exchange the commands with the controller.  These
> command operate as transactions allowing the process to have clear
> checkpoints.
>
> *Why Nemo? *
>
> Software Defined Networking (SDN) and Network Function Virtualization
> (NFV) are moving the IT world from a network-centric view to an
> _______________________________________________
> sdn mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/sdn
>
>

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 10 Nov 2014 20:36:15 +0000

There are a lot of us on jabber, but no-one in the room to field questions to the mike
or help with technical issues.

Next time - please arrange for a jabber scribe in the room.

Y(J)S

---

From: David Meyer <[email-masked]>
Date: Mon, 10 Nov 2014 11:21:13 -1000

Will do..  --dmm

Sent from my iPhone

> On Nov 10, 2014, at 10:36, Yaakov Stein <[email-masked]> wrote:
> 
> Next time – please arrange for a jabber scribe in the room.
>  
> Y(J)S

---

From: David Meyer <[email-masked]>
Date: Mon, 10 Nov 2014 11:28:50 -1000

Did you hear the answer to your question? (communicating with the remote
controller is out of scope)...

--dmm

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 10 Nov 2014 21:30:52 +0000

Yes, thanks.

Leaving something out of scope is always legitimate,
but if it turns out that there is no effective way of reliably communicating with a controller
the whole exercise may be purely academic.

Y(J)S

From: David Meyer [mailto:[email-masked]]
Sent: 10 November, 2014 23:29
To: Yaakov Stein
Cc: [email-masked]
Subject: Re: Can someone in the physical room come up on jabber ?

Did you hear the answer to your question? (communicating with the remote controller is out of scope)...

--dmm

On Mon, Nov 10, 2014 at 10:36 AM, Yaakov Stein <[email-masked]<mailto:[email-masked]>> wrote:
There are a lot of us on jabber, but no-one in the room to field questions to the mike
or help with technical issues.

Y(J)S

---

From: JF Tremblay <[email-masked]>
Date: Mon, 10 Nov 2014 15:35:10 -1000

> On Nov 10, 2014, at 9:59 AM, Susan Hares <[email-masked]> wrote:

> Nemo specifies a set of commands to pass from an application to Neutron  via a RESTFUL interface to signal to signal the desired network for its application. This is a higher level than the OpenDaylight group policy engine which works below the Neutron level.  Both Nemo and ODL group policy use intent-driven policy APIs (what Apps wants) rather than descriptive policy (how to do it). A comparison of the OpenDaylight Group Policy and Nemo is at:
> 
> http://www.hickoryhill-consulting.com/nemo/nemo-vs-ODL-group-policy-v1.pdf <http://www.hickoryhill-consulting.com/nemo/nemo-vs-ODL-group-policy-v1.pdf>.
> 
Thanks for the pointer, interesting read. 

Suggestion: it would be great if the next version of this document also compared NeMo to Congress, which seems to have a similar approach. A discussion of how “intent-based” policing differs from “declarative” policing might also be useful. (just an idea!)

JF

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 10 Nov 2014 21:30:10 -0500

We’ll create another comparison for Congress.   Can you provide a pointer to Congress work? 

Sue 

From: sdn [mailto:[email-masked]] On Behalf Of JF Tremblay
Sent: Monday, November 10, 2014 8:35 PM
To: [email-masked]
Subject: Re: [Sdn] NeMo Demo after SDNrg meeting

 <http://www.hickoryhill-consulting.com/nemo/nemo-vs-ODL-group-policy-v1.pdf> http://www.hickoryhill-consulting.com/nemo/nemo-vs-ODL-group-policy-v1.pdf.

JF

---

From: JF Tremblay <[email-masked]>
Date: Mon, 10 Nov 2014 18:08:41 -1000

> On Nov 10, 2014, at 4:30 PM, Susan Hares <[email-masked]> wrote:
> 

The main page would be there (it’s another openstack subgroup): 
https://wiki.openstack.org/wiki/Congress <https://wiki.openstack.org/wiki/Congress>

I found the design document interesting:
http://goo.gl/YFd2Fr <http://goo.gl/YFd2Fr>

Also in presentation format:
https://www.openstack.org/assets/presentation-media/Congress-OpenStack-Atlanta-2014.pdf <https://www.openstack.org/assets/presentation-media/Congress-OpenStack-Atlanta-2014.pdf>

JF