Re: [sop] Fwd: SOP and SDN Question
Thomas Nadeau <tnadeau@lucidvision.com> Fri, 24 February 2012 15:31 UTC
Return-Path: <tnadeau@lucidvision.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 4A91221F85B8 for <sop@ietfa.amsl.com>; Fri, 24 Feb 2012 07:31:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.546
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jF1vpfH6vFiv for <sop@ietfa.amsl.com>; Fri, 24 Feb 2012 07:31:43 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9238421F85A1 for <sop@ietf.org>; Fri, 24 Feb 2012 07:31:43 -0800 (PST)
Received: from [10.100.68.228] (unknown [141.202.11.155]) by lucidvision.com (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 <tnadeau@lucidvision.com>
In-Reply-To: <CAA3wLqWTkjx4ongiRoK887yOCKB-sMBRLZbVRq8VeUTzz+s_mQ@mail.gmail.com>
Date: Fri, 24 Feb 2012 10:31:45 -0500
Message-Id: <C9AE5879-FD8A-46FA-B08E-D1A2DDB010F3@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> <CAA3wLqWTkjx4ongiRoK887yOCKB-sMBRLZbVRq8VeUTzz+s_mQ@mail.gmail.com>
To: Michael Hammer <mphmmr@gmail.com>
X-Mailer: Apple Mail (2.1257)
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: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. --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 <tnadeau@lucidvision.com> 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 > >
- [sop] SOP and SDN Question Michael Hammer
- [sop] Fwd: SOP and SDN Question Michael Hammer
- Re: [sop] Fwd: SOP and SDN Question Thomas Nadeau
- Re: [sop] Fwd: SOP and SDN Question Michael Hammer
- Re: [sop] Fwd: SOP and SDN Question Thomas Nadeau
- Re: [sop] [Sdnp] Fwd: SOP and SDN Question Robert Raszuk
- Re: [sop] [Sdnp] Fwd: SOP and SDN Question Thomas Nadeau
- Re: [sop] [Sdnp] Fwd: SOP and SDN Question Michael Hammer
- Re: [sop] [Sdnp] Fwd: SOP and SDN Question Robert Raszuk
- Re: [sop] [Sdnp] Fwd: SOP and SDN Question Sam Aldrin
- Re: [sop] [Sdnp] Fwd: SOP and SDN Question Ashish Dalela (adalela)
- Re: [sop] [Sdnp] Fwd: SOP and SDN Question Mach Chen