Subject: [sop] SOP and SDN Question

From: Michael Hammer <[email-masked]>
Date: Thu, 23 Feb 2012 11:57:18 -0500

All,

I saw some questions asking what is the difference between SOP and SDN/OF.
So, I did a quick review of the SDN BOF presentations.
Here is some food for thought:

1) The SDN Problem Statement is more narrowly focused on network and
doesn't address
other important cloud elements of compute and storage, nor the additional
layers that make
up PaaS and SaaS.  So, I am thinking that difference is really in the scope
of perspective.
SOP is about how to specify what cloud consumer needs the cloud to
do, while SDN is in
the weeds on how to do the network portion.  What does SDN do for compute
and storage?
Nothing.  SOP provides a means to reference and stitch together those
disparate pieces.

One presentation shows a lack of coordination by hypervisor with the
underlying network,
but then just moves the "solution" to the network layer, without showing
how coordination
between the IT and C (network) is sync'd.  Now imagine if those IT
resources are split
across multiple clouds/DCs.  Isolation of network from the IT side could
lead to disconnect
amongst unified ITC service components.  We believe SOP enables a
coordinated solution.

2)  Some quotes from the BOF presentations:
    "OpenFlow does not configure, boot, or maintain a box".
    "Enabling programmatic automation of configuration, management,
     monitoring, data mining, ... is largely orthogonal to OF/SDN"
Well, SOP is there to boot, configure, and maintain the various layers of
those boxes.
It is about replacing slow-time-scale management etc. with on-demand
signaling and control.
Cloud is about provisioning on-demand, in other words configuring and
booting resources
in the Cloud/DC.  So, something missing here.  I get the feeling that
OpenFlow is more like
assembly-language level execution of a macro-command.  With SOP we are
focused on the
macro-command level, within which an admin domain might get implemented by
low-level
openflow execution.

3)  SDN seems to focus on replacing current generation static network
management configuration
versus focusing on the dynamic on-demand external customer aspects.  Would
love to see security
implications on SDN.  I could see an inter-domain SOP request fanning out
to IT (host) and network (SDN)
control signaling components, where the SDN replaces some existing
management controls.
We are trying to address the cloud-bursting scenarios that cross admin
domains.
The last slide of the operator's perspective gives insight to what we want
SOP to address.

4)  Perhaps the best way of explaining this is by analogy.  The essence of
SDN/OF appears to be
the separation of the control plane from the data (forwarding) plane.  So,
where have I heard that before?
Those working in the VoIP space are probably very familiar with the
separation between the
Media Gateway Controller and the Media Gateways using either MGCP or H.248.

Or how about the Media Resource Control Protocol?  Those are examples of
vertical control protocols,
where a master controller manages multiple slave components within a single
admin domain.
Now contrast that with a signaling and control protocol such as SIP or
H.323 that interoperate
horizontally between admin domains.  Just as SIP and MGCP perform
complementary roles for VoIP,
we see SOP and SDN/OF performing complementary roles in the cloud space.

Finally, imagine what cloud services means in terms of delivery of hardware
and software by vendors
to both customer (enterprise) and cloud SP (e.g. carrier) domains.  If the
blade, disk, bridge, and router hardware
can, like a chameleon, take on a different character depending on the
firmware and software layered on top,
then there needs to be a way to remotely provision and configure those
IaaS, PaaS, SaaS software layers,
be it colored Cisco, Juniper, Dell, HP, IBM, Microsoft, Linux, or whatever.

The nature of communications is that it works best when both ends are fully
interoperable.

So, while a private enterprise cloud will need to push an on-demand service
request  to one or more public clouds,
both those clouds may need to "rent" various layers of cloud software
either prior to or following that cloudburst
from multiple players in the vendor community.
A standardized protocol for service orchestration for all those cloud
layers enables that.

We are already seeing such on-demand ecosystems becoming reality in the
Unified Communications space
with the movement of IP-PBXs onto DCs as well as IMS components.

If those can be provided on-demand to meet the capacity needs of the
customer/carrier,
then what stops any other type of cloud software from doing the same?

Mike

---

From: Michael Hammer <[email-masked]>
Date: Fri, 24 Feb 2012 10:02:02 -0500

Resending.

---------- Forwarded message ----------
From: Michael Hammer <[email-masked]>
Date: Thu, Feb 23, 2012 at 11:57 AM
Subject: SOP and SDN Question
To: [email-masked]

All,

Mike

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 24 Feb 2012 10:12:31 -0500

On Feb 24, 2012, at 10:02 AM, Michael Hammer wrote:

> 1) The SDN Problem Statement is more narrowly focused on network and doesn't address 
> other important cloud elements of compute and storage, nor the additional layers that make 
> up PaaS and SaaS.  So, I am thinking that difference is really in the scope of perspective.  
> SOP is about how to specify what cloud consumer needs the cloud to do, while SDN is in 
> the weeds on how to do the network portion.  What does SDN do for compute and storage?
> Nothing.  SOP provides a means to reference and stitch together those disparate pieces.

	I guess my question is (and I think Ping asked this too) is how/why does SOP differ
from OpenStack, or where does it fit into that model. You can imagine using OpenStack to do 
just what you are describing.  Basically at a high level, you are specifying service management -
which handles most of the XaaS cases I think.

> One presentation shows a lack of coordination by hypervisor with the underlying network, 
> but then just moves the "solution" to the network layer, without showing how coordination
> between the IT and C (network) is sync'd.  Now imagine if those IT resources are split 
> across multiple clouds/DCs.  Isolation of network from the IT side could lead to disconnect 
> amongst unified ITC service components.  We believe SOP enables a coordinated solution.

	Fair point, but again why and how does this differ from what OpenStack gives you today?

> Well, SOP is there to boot, configure, and maintain the various layers of those boxes.
> It is about replacing slow-time-scale management etc. with on-demand signaling and control.
> Cloud is about provisioning on-demand, in other words configuring and booting resources 
> in the Cloud/DC.  So, something missing here.  I get the feeling that OpenFlow is more like 
> assembly-language level execution of a macro-command.  With SOP we are focused on the 
> macro-command level, within which an admin domain might get implemented by low-level 
> openflow execution.
> 
> 3)  SDN seems to focus on replacing current generation static network management configuration 
> versus focusing on the dynamic on-demand external customer aspects.  Would love to see security 
> implications on SDN.  I could see an inter-domain SOP request fanning out to IT (host) and network (SDN) 
> control signaling components, where the SDN replaces some existing management controls.
> We are trying to address the cloud-bursting scenarios that cross admin domains.
> The last slide of the operator's perspective gives insight to what we want SOP to address.

	I would characterize Software Driven Networks (SDrN) as you describe, but Software Defined Networks (SDfN)
(or what we have been working on in the SDNp effort) is not quite that.  Its about manipulation and
interaction with network "entities" which include virtual or real devices, but also network services.

	BTW, I'd ask that as the thread goes forward, that  you clearly state what the "D" in SDN you 
are referring to is as it can mean quite different things. 

> 4)  Perhaps the best way of explaining this is by analogy.  The essence of SDN/OF appears to be
> the separation of the control plane from the data (forwarding) plane.  So, where have I heard that before?
> Those working in the VoIP space are probably very familiar with the separation between the
> Or how about the Media Resource Control Protocol?  Those are examples of vertical control protocols, 
> where a master controller manages multiple slave components within a single admin domain.  
> Now contrast that with a signaling and control protocol such as SIP or H.323 that interoperate 
> horizontally between admin domains.  Just as SIP and MGCP perform complementary roles for VoIP, 

	It is certainly possible that SOP compliments SDrivenNetworks too because they are a
 superset case of Software Defined Networks.  The question is how. There has already been discussion 
of inter-domain SDN orchestrators, which seems to overlap with the intent of SOP. Have you 
considered this?

	--Tom

> Finally, imagine what cloud services means in terms of delivery of hardware and software by vendors
> to both customer (enterprise) and cloud SP (e.g. carrier) domains.  If the blade, disk, bridge, and router hardware
> can, like a chameleon, take on a different character depending on the firmware and software layered on top,
> then there needs to be a way to remotely provision and configure those IaaS, PaaS, SaaS software layers, 
> The nature of communications is that it works best when both ends are fully interoperable.  
> 
> So, while a private enterprise cloud will need to push an on-demand service request  to one or more public clouds,
> both those clouds may need to "rent" various layers of cloud software either prior to or following that cloudburst
> A standardized protocol for service orchestration for all those cloud layers enables that.
> 
> We are already seeing such on-demand ecosystems becoming reality in the Unified Communications space
> If those can be provided on-demand to meet the capacity needs of the customer/carrier, 
> _______________________________________________
> sop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sop

---

From: Michael Hammer <[email-masked]>
Date: Fri, 24 Feb 2012 10:28:46 -0500

Tom,

You seem to suggest that Open Flow can be expanded to include services
besides networking.

But, the key question is this:
Does OF clearly separate out the service-dependent information from
the service-independent methods
such that it can easily be extensible to any service?

Mike

On Fri, Feb 24, 2012 at 10:12 AM, Thomas Nadeau <[email-masked]>wrote:

> So, while a private enterprise cloud will need to push
> an on-demand service request  to one or more public clouds,

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 24 Feb 2012 10:31:45 -0500

On Feb 24, 2012, at 10:28 AM, Michael Hammer wrote:

> Tom,
> 
> You seem to suggest that Open Flow can be expanded to include services besides networking.

	I think you misunderstood what I wrote. Software Defined Networks (i.e.: OpenFlow) is targeted at working 
at the hardware abstraction level only. Software *Driven* Networks is targeted at services and network elements. 
There is a clear difference.

	--Tom

> Does OF clearly separate out the service-dependent information from the service-independent methods 
> On Fri, Feb 24, 2012 at 10:12 AM, Thomas Nadeau <[email-masked]> wrote:
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 24 Feb 2012 16:43:56 +0100

Hi Tom,

> I think you misunderstood what I wrote. Software Defined Networks (i.e.:
> OpenFlow) is targeted at working at the hardware abstraction level only.

That's completely inaccurate.

SDN is all about network applications. You perhaps are confusing it with 
ONF which indeed at this point is focused on defining OpenFlow protocol.

But protocols are not defined just by bunch of hardware enthusiasts. 
They are defined to address specific software defined applications.

Best,
R.

Software *Driven* Networks is
> targeted at services and network elements.

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 24 Feb 2012 10:48:44 -0500

> That's completely inaccurate.

	Not completely. *)
	
> SDN is all about network applications. You perhaps are confusing it with ONF which indeed at this point is focused on defining OpenFlow protocol.

	Software DRIVEN Networks is all about network applications *and* their interaction with network services and elements, of which a
subset is Software *defined* Networks (I.e.: OpenFlow).   We really need to pick a different term for Software Driven Networks because 
it is confusing everyone. People seem to equate "SDN" with OpenFlow without being clear about the "D".

	--Tom

> But protocols are not defined just by bunch of hardware enthusiasts. They are defined to address specific software defined applications.
> 
> Best,
> R.
> 
> 
>

---

From: Michael Hammer <[email-masked]>
Date: Fri, 24 Feb 2012 10:57:52 -0500

Agree there is confusion.

Also, we need more discussion on APIs versus protocols, along with security
implications.
We attempted to address that in the IDs.

Mike

On Fri, Feb 24, 2012 at 10:48 AM, Thomas Nadeau <[email-masked]>wrote:

>         Software DRIVEN Networks is all about network applications *and*
> their interaction with network services and elements, of which a
> subset is Software *defined* Networks (I.e.: OpenFlow).   We really need
> to pick a different term for Software Driven Networks because

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 24 Feb 2012 17:00:06 +0100

Hi Tom,

> 	Software DRIVEN Networks is all about network applications*and*  their interaction with network services and elements, of which a
> subset is Software*defined*  Networks (I.e.: OpenFlow).   We really need to pick a different term for Software Driven Networks because

"Software *defined* Networks (I.e.: OpenFlow)" ... well I see you seems 
to equate it too. That is not correct. Example: I can use OF protocol in 
my app to program the switches, but in the same time API to get the 
routes from bgp route reflectors. In fact I have this running in my lab 
today. How would you call it ? defined ? driven ? hybrid ?

 > We really need to pick a different term for Software Driven Networks
 > because it is confusing everyone.

I think you can debate for months what name to pick. However at the end 
it really does not matter.

What matters are actual network applications for network engineers to 
download, test and use to enhance their services to the users. And so 
far I see many more of them growing using fully or partially OpenFlow 
soil then purely on proprietary per vendor mixed API grounds.

Cheers,
R.

---

From: Sam Aldrin <[email-masked]>
Date: Fri, 24 Feb 2012 08:09:16 -0800

I think SDN is being over loaded and confusion exists, not just between Driven and Defined, but also what each of those does. The way i understood and also being presented is, ONF SDN encompasses not just openflow, but network applications with the help of northbound API between controller and applications. Where SDNP plays pivotal role in defining protocol elements  and api to interconnect network elements and applications. It is high time to gets the terms identified along with clear definition of what it does, and more importantly, start using them in future conversations could alleviate the confusion.

Cheers
Sam

Sent from my iPad

On Feb 24, 2012, at 7:48 AM, Thomas Nadeau <[email-masked]> wrote:

> SDNP mailing list
> [email-masked]
> http://lucidvision.com/mailman/listinfo/sdnp

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Fri, 24 Feb 2012 21:48:32 +0530

One of the questions I had on an earlier thread was a comparison /
contrast between the Application <--> Controller <--> Infrastructure
model versus the Controller <--> {Application / Infrastructure} model.
As an example, what happens if the application that is supposed to
provision the network for its purposes fails (because of software or
underlying infrastructure failures)? Who bootstraps the infrastructure
and then the application?

The second issue I wonder is the nature of the control SDN (D being
whatever it is) wants to exercise over the network. As an example, one
blog recently talked about why OF not good for solving the distributed
forwarding state problem, but good solution for solving global
optimization issues.

http://networkheresy.wordpress.com/2011/11/17/is-openflowsdn-good-at-for
warding/

What stand does SDNP take regarding this?

Thanks, Ashish

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sam Aldrin
Sent: Friday, February 24, 2012 9:39 PM
To: Thomas Nadeau
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sop] [Sdnp] Fwd: SOP and SDN Question

I think SDN is being over loaded and confusion exists, not just between
Driven and Defined, but also what each of those does. The way i
understood and also being presented is, ONF SDN encompasses not just
openflow, but network applications with the help of northbound API
between controller and applications. Where SDNP plays pivotal role in
defining protocol elements  and api to interconnect network elements and
applications. It is high time to gets the terms identified along with
clear definition of what it does, and more importantly, start using them
in future conversations could alleviate the confusion.

Cheers
Sam

Sent from my iPad

On Feb 24, 2012, at 7:48 AM, Thomas Nadeau <[email-masked]>
wrote:

>> SDN is all about network applications. You perhaps are confusing it
with ONF which indeed at this point is focused on defining OpenFlow
protocol.
> subset is Software *defined* Networks (I.e.: OpenFlow).   We really
need to pick a different term for Software Driven Networks because

---

From: Mach Chen <[email-masked]>
Date: Sat, 25 Feb 2012 01:14:19 +0000

Fully agree with Sam here!

Best regards,
Mach

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam
> Aldrin
> Sent: Saturday, February 25, 2012 12:09 AM
> To: Thomas Nadeau
> I think SDN is being over loaded and confusion exists, not just between Driven
> and Defined, but also what each of those does. The way i understood and also
> being presented is, ONF SDN encompasses not just openflow, but network
> applications with the help of northbound API between controller and
> applications. Where SDNP plays pivotal role in defining protocol elements  and
> api to interconnect network elements and applications. It is high time to gets
> the terms identified along with clear definition of what it does, and more
> importantly, start using them in future conversations could alleviate the
> confusion.
> 
> Cheers
> Sam
> 
> Sent from my iPad
> 
> >> SDN is all about network applications. You perhaps are confusing it with ONF
> which indeed at this point is focused on defining OpenFlow protocol.
> >
> >    Software DRIVEN Networks is all about network applications *and* their
> interaction with network services and elements, of which a
> > subset is Software *defined* Networks (I.e.: OpenFlow).   We really need to
> pick a different term for Software Driven Networks because
> >> But protocols are not defined just by bunch of hardware enthusiasts. They
> are defined to address specific software defined applications.
> >>
> >> Best,
> >> R.
> >>
> >>
> >>