Re: [sop] Fwd: SOP and SDN Question

Michael Hammer <> Fri, 24 February 2012 15:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34B0421F8800 for <>; Fri, 24 Feb 2012 07:28:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.445
X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xmjjyzLk5S4t for <>; Fri, 24 Feb 2012 07:28:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6AB8121F87EB for <>; Fri, 24 Feb 2012 07:28:47 -0800 (PST)
Received: by lahl5 with SMTP id l5so3463000lah.31 for <>; Fri, 24 Feb 2012 07:28:46 -0800 (PST)
Received-SPF: pass ( domain of designates as permitted sender) client-ip=;
Authentication-Results:; spf=pass ( domain of designates as permitted sender); dkim=pass
Received: from ([]) by with SMTP id v8mr1135960lbk.49.1330097326490 (num_hops = 1); Fri, 24 Feb 2012 07:28:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DRCQvGOv+MsSwRkwvI5ciPqSCZepihPWyd4kRHYg9uw=; b=UaebCA4g2QBpKK6/JXNlBC/PLvekOQcCNOZlCno7BsF2kSHhLJH8n5/DDUXVzp42Nm rXR/ib1HLtxUHA/IJg0B//BLFBqcoprQrWTPqQM5opyj/pS5x1HmUre3LA1LQ1J9NOql tnwS0qut1j85n4x/O+jyJuSiS7jWM6glSgDMM=
MIME-Version: 1.0
Received: by with SMTP id v8mr942007lbk.49.1330097326375; Fri, 24 Feb 2012 07:28:46 -0800 (PST)
Received: by with HTTP; Fri, 24 Feb 2012 07:28:46 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Fri, 24 Feb 2012 10:28:46 -0500
Message-ID: <>
From: Michael Hammer <>
To: Thomas Nadeau <>
Content-Type: multipart/alternative; boundary=e0cb4efe2d58a7c4da04b9b76a91
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:28:49 -0000


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?


On Fri, Feb 24, 2012 at 10:12 AM, Thomas Nadeau <>wrote;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