Re: [sop] Fwd: SOP and SDN Question

Michael Hammer <mphmmr@gmail.com> Fri, 24 February 2012 15:28 UTC

Return-Path: <mphmmr@gmail.com>
X-Original-To: sop@ietfa.amsl.com
Delivered-To: sop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B0421F8800 for <sop@ietfa.amsl.com>; Fri, 24 Feb 2012 07:28:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.445
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmjjyzLk5S4t for <sop@ietfa.amsl.com>; Fri, 24 Feb 2012 07:28:48 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB8121F87EB for <sop@ietf.org>; Fri, 24 Feb 2012 07:28:47 -0800 (PST)
Received: by lahl5 with SMTP id l5so3463000lah.31 for <sop@ietf.org>; Fri, 24 Feb 2012 07:28:46 -0800 (PST)
Received-SPF: pass (google.com: domain of mphmmr@gmail.com designates 10.112.40.72 as permitted sender) client-ip=10.112.40.72;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of mphmmr@gmail.com designates 10.112.40.72 as permitted sender) smtp.mail=mphmmr@gmail.com; dkim=pass header.i=mphmmr@gmail.com
Received: from mr.google.com ([10.112.40.72]) by 10.112.40.72 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; d=gmail.com; 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 10.112.40.72 with SMTP id v8mr942007lbk.49.1330097326375; Fri, 24 Feb 2012 07:28:46 -0800 (PST)
Received: by 10.112.104.70 with HTTP; Fri, 24 Feb 2012 07:28:46 -0800 (PST)
In-Reply-To: <353D9CCB-2576-4A88-AAFC-DCE82FAF1101@lucidvision.com>
References: <CAA3wLqUZNK1XpMm8bZuXK4UcLxy4fKbjLvYK6iX537bWWEfqpw@mail.gmail.com> <CAA3wLqW3y5_ucz+P5+be1+Js-56TnbJGNRQ=sB1p=SWyVZZt3Q@mail.gmail.com> <353D9CCB-2576-4A88-AAFC-DCE82FAF1101@lucidvision.com>
Date: Fri, 24 Feb 2012 10:28:46 -0500
Message-ID: <CAA3wLqWTkjx4ongiRoK887yOCKB-sMBRLZbVRq8VeUTzz+s_mQ@mail.gmail.com>
From: Michael Hammer <mphmmr@gmail.com>
To: Thomas Nadeau <tnadeau@lucidvision.com>
Content-Type: multipart/alternative; boundary=e0cb4efe2d58a7c4da04b9b76a91
Cc: sdnp@lucidvision.com, sop@ietf.org
Subject: Re: [sop] Fwd: SOP and SDN Question
X-BeenThere: sop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Service Orchestration and Desciption for Cloud Services <sop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sop>, <mailto:sop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sop>
List-Post: <mailto:sop@ietf.org>
List-Help: <mailto:sop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sop>, <mailto:sop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Feb 2012 15:28:49 -0000

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 <tnadeau@lucidvision.com>wrote;wrote:

>
> On Feb 24, 2012, at 10:02 AM, Michael Hammer wrote:
>
> Resending.
>
> ---------- Forwarded message ----------
> From: Michael Hammer <mphmmr@gmail.com>
> Date: Thu, Feb 23, 2012 at 11:57 AM
> Subject: SOP and SDN Question
> To: sop@ietf.org
>
>
> 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
> sop@ietf.org
> https://www.ietf.org/mailman/listinfo/sop
>
>
>