Re: [sop] Fwd: SOP and SDN Question

[Thomas Nadeau <[e-mail]>]

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

> Resending.
> 
> ---------- Forwarded message ----------
> From: Michael Hammer <[e-mail]>
> Date: Thu, Feb 23, 2012 at 11:57 AM
> Subject: SOP and SDN Question
> To: [e-mail]
> 
> 
> 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.

	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?

> 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.

	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
> 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.

	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, 
> 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
> 
> 
> _______________________________________________
> sop mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sop