Re: [sop] Fwd: SOP and SDN Question

Thomas Nadeau <> Fri, 24 February 2012 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A91221F85B8 for <>; Fri, 24 Feb 2012 07:31:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.546
X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jF1vpfH6vFiv for <>; Fri, 24 Feb 2012 07:31:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9238421F85A1 for <>; Fri, 24 Feb 2012 07:31:43 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTP id CDC0C142794; Fri, 24 Feb 2012 10:31:42 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_F41EC768-662D-4B40-A948-BA1ED41DBC98"
From: Thomas Nadeau <>
In-Reply-To: <>
Date: Fri, 24 Feb 2012 10:31:45 -0500
Message-Id: <>
References: <> <> <> <>
To: Michael Hammer <>
X-Mailer: Apple Mail (2.1257)
Subject: Re: [sop] Fwd: SOP and SDN Question
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Service Orchestration and Desciption for Cloud Services <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Feb 2012 15:31:45 -0000

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.


> 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 <> wrote:
> On Feb 24, 2012, at 10:02 AM, Michael Hammer wrote:
>> Resending.
>> ---------- Forwarded message ----------
>> From: Michael Hammer <>
>> Date: Thu, Feb 23, 2012 at 11:57 AM
>> Subject: SOP and SDN Question
>> To:
>> 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