Re: [sop] Fwd: SOP and SDN Question

[Thomas Nadeau <[e-mail]>]

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


> 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 <[e-mail]> wrote:
> 
> 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
> 
>