Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services

Michael Hammer <mphmmr@gmail.com> Thu, 16 February 2012 16:11 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 6740021F8843 for <sop@ietfa.amsl.com>; Thu, 16 Feb 2012 08:11:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.369
X-Spam-Level:
X-Spam-Status: No, score=-3.369 tagged_above=-999 required=5 tests=[AWL=0.229, 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 QA1d8cHfO2Lz for <sop@ietfa.amsl.com>; Thu, 16 Feb 2012 08:10:58 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8812B21F8835 for <sop@ietf.org>; Thu, 16 Feb 2012 08:10:44 -0800 (PST)
Received: by eekc41 with SMTP id c41so893574eek.31 for <sop@ietf.org>; Thu, 16 Feb 2012 08:10:43 -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=H6zDZGGGyhq02Y+hKT/QKQeHBW0bKPuuCUTyF68DsVs=; b=Qs+zDVq3iPpvFVwa4b3pZFYS1C2vXyUOckccvNYnFlV+uwMbMwzsLh21pBcnjhBl1+ p60B/RuYA2ISVK8kZYyeJWor0QyuPsdzA0nOcEHbvV2rQMLwQIJbRVjW1swlOI7XkMLy agciIc8EU9zp1tRDiOrDUD8kIJ31mAewCNLwM=
MIME-Version: 1.0
Received: by 10.112.86.106 with SMTP id o10mr1193596lbz.27.1329408641088; Thu, 16 Feb 2012 08:10:41 -0800 (PST)
Received: by 10.112.104.70 with HTTP; Thu, 16 Feb 2012 08:10:40 -0800 (PST)
In-Reply-To: <CAHEV9L1vOOnr4XePym2WLfaYj96o44J9opAPO9aZ76iD5AEzVA@mail.gmail.com>
References: <CB62CCB4.C846D%mmorrow@cisco.com> <470D91CE-5D54-48F8-8889-438DA873A3FA@lucidvision.com> <618BE8B40039924EB9AED233D4A09C5103001E76@XMB-BGL-416.cisco.com> <CAHEV9L3EiCHutLEYHTCbPc0b439k_47mda1y1ONmwthKrQMiYw@mail.gmail.com> <CAA3wLqVpK3pYtdFPiHz7YnBrswNQnOW8R91JXdq-3ndsoL9hkA@mail.gmail.com> <CAHEV9L1vOOnr4XePym2WLfaYj96o44J9opAPO9aZ76iD5AEzVA@mail.gmail.com>
Date: Thu, 16 Feb 2012 11:10:40 -0500
Message-ID: <CAA3wLqW-GNw4hUS8bgpzUDnptyJU2q5i4UjrHxRn9K91vFitwg@mail.gmail.com>
From: Michael Hammer <mphmmr@gmail.com>
To: Ping Pan <ping@pingpan.org>
Content-Type: multipart/alternative; boundary=bcaec554e108d03e7204b917114e
Cc: Thomas Nadeau <tnadeau@lucidvision.com>, "Monique Morrow \(mmorrow\)" <mmorrow@cisco.com>, robert@raszuk.net, "Ashish Dalela \(adalela\)" <adalela@cisco.com>, sop@ietf.org
Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services
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: Thu, 16 Feb 2012 16:11:06 -0000

Ping, (dropped the SDNP list -- let me know if this needs to be on both)

I think we are coming at this space from two different directions.  We were
looking top down, and network focused folks looking bottoms up.  Where they
meet in the middle could very well be complementary and mutually supporting.

I don't think there is anything in the protocol that confines it to just
DC, thought that will often be the basis of cloud services.

Agree this is in early stages.  Probably several years out to sort out the
problem space.  What we are looking at with SOP is that the problem space
should also consider trade-offs between management and signaling and
control protocols (SDNP may be more of the former than the latter, whereas
we are looking at SOP to be the latter.), as well as the overall
architecture that could included OSS/BSS systems and SBCs through which
messages on the wire must transit.

We want the cloud to scale as the number of XaaS goes from a handful to
thousands of services.  That is an issue for any service provider.

I just hope that the same wheel doesn't need to be reinvented and the
network need retrofitting every time a new service shows up.

Make sense?

Mike



On Thu, Feb 16, 2012 at 10:57 AM, Ping Pan <ping@pingpan.org>; wrote:

> Michael,
>
> I would ask the question somewhat differently: what can we do to enable
> more new services and applications to make the best use of the network
> resources? ;-)
>
> We are at the very early stage of cloud networking. We should not limit
> ourselves on what we may accomplish with DC's. There is no hurry to jump
> onto the solution, while the problem space itself is becoming more
> interesting and lucrative at a stunning speed. ;-)
>
> Make sense?
>
> Regards,
>
> Ping
>
>
> On Thu, Feb 16, 2012 at 7:39 AM, Michael Hammer <mphmmr@gmail.com>; wrote:
>
>> All,
>>
>> The question I would ask is how many Cloud services do we think there
>> will be long run.
>> Then ask, how many times the same methods/commands will need to be
>> re-invented:  Create, Update, Delete?
>>
>> Also, ask yourself, if you have to do multiple of those cloud services in
>> synchronized fashion, would a tool designed for just one of those answer
>> the mail?
>> Can we abstract out the common elements and cover and integrate component
>> parts?
>>
>> Cloud seems to be in the state the telephone company found itself 100
>> years ago.  Everything works fine so long as you do it Edison's way, or
>> Tesla's or whomever.  We had to go through a monopoly state before figuring
>> out how to standardize.  Looking to skip the monopoly phase this time
>> around.
>>
>> Mike
>>
>>
>> On Thu, Feb 16, 2012 at 10:23 AM, Ping Pan <ping@pingpan.org>; wrote:
>>
>>> Yeah, I have read all the drafts during the DC BoF discussion. In
>>> general, this makes sense...
>>>
>>> My thinking is that we may not want to standardize the interior DC
>>> management, as each vendor has own solution. But at the same time, we need
>>> to enable applications and services to ride on top of DC resources. In
>>> other words, SDN is in the position to enable Virtual DC's, and create the
>>> interface to communicate with networking resources at abstraction level.
>>> SDN should not be viewed as the NMS for DC's.
>>>
>>> There are a lot of work to be done here, and many parts are moving.
>>> Let's work together.
>>>
>>> Ping
>>>
>>>
>>> On Thu, Feb 16, 2012 at 7:02 AM, Ashish Dalela (adalela) <
>>> adalela@cisco.com>; wrote:
>>>
>>>> ** **
>>>>
>>>> SOP has the following main goals – ****
>>>>
>>>> ** **
>>>>
>>>> **1.  **Fix interoperability issues with cloud services today. Main
>>>> examples are inter-cloud, hybrid-cloud, and multi-vendor cloud. All cloud
>>>> services are being enabled through proprietary APIs today, which don’t
>>>> interoperate. To interoperate across vendors, providers and customers, we
>>>> need an open standard. Ability to go across administrative domains is a
>>>> basic requirement.****
>>>>
>>>> ** **
>>>>
>>>> **2.  **A clear separation between service-independent and
>>>> service-dependent pieces in cloud services. SOP is about
>>>> service-independent pieces. Using SOP, a variety of services could be
>>>> accessed or advertized. Separation between service-independent and
>>>> service-dependent pieces makes the scheme extensible to any type of service
>>>> – current or future.****
>>>>
>>>> ** **
>>>>
>>>> **3.  **Create a common scheme for service orchestration that can be
>>>> used across compute, network, storage, security, applications, etc. A
>>>> common set of constructs that can be applied to any service type whether it
>>>> is infrastructure or application.****
>>>>
>>>> ** **
>>>>
>>>> http://tools.ietf.org/html/draft-dalela-orchestration-00****
>>>>
>>>> ** **
>>>>
>>>> The above draft describes the problems SOP is aimed to address. This is
>>>> the “requirements” draft.****
>>>>
>>>> ** **
>>>>
>>>> The other drafts are:****
>>>>
>>>> ** **
>>>>
>>>> http://tools.ietf.org/html/draft-dalela-sop-architecture-00 -
>>>> describes the use-cases and network deployments with the protocol****
>>>>
>>>> http://tools.ietf.org/html/draft-dalela-sop-00 - describes the
>>>> protocol’s messages ****
>>>>
>>>> http://tools.ietf.org/html/draft-dalela-sdf-00 - describes service
>>>> naming, workflow construction, etc.****
>>>>
>>>> http://tools.ietf.org/html/draft-dalela-sop-flows-00 - describes some
>>>> message flows****
>>>>
>>>> ** **
>>>>
>>>> Thanks, Ashish****
>>>>
>>>> ** **
>>>>
>>>> ** **
>>>>
>>>> *From:* Thomas Nadeau [mailto:tnadeau@lucidvision.com]
>>>> *Sent:* Thursday, February 16, 2012 7:59 PM
>>>> *To:* Monique Morrow (mmorrow)
>>>> *Cc:* Ping Pan; robert@raszuk.net; sdnp; sop@ietf.org
>>>> *Subject:* Re: [Sdnp] FW: New Non-WG Mailing List: sop -- Service
>>>> Orchestration and Desciption for Cloud Services****
>>>>
>>>> ** **
>>>>
>>>> ** **
>>>>
>>>>             Can you please explain what the purpose of SOP is and what
>>>> its goals are?****
>>>>
>>>> People on this list have been also asking how it differs from SDN(p),
>>>> so it****
>>>>
>>>> might be helpful to include that as well. 8)****
>>>>
>>>>             ****
>>>>
>>>>             --Tom****
>>>>
>>>> ** **
>>>>
>>>> ** **
>>>>
>>>> ** **
>>>>
>>>> On Feb 16, 2012, at 9:09 AM, Monique Morrow wrote:****
>>>>
>>>>
>>>>
>>>> ****
>>>>
>>>> Guys
>>>>
>>>> Please join the SOP mailer
>>>>
>>>>
>>>> List address: *sop@ietf.org
>>>> *Archive: *http://www.ietf.org/mail-archive/web/sop/
>>>> *To subscribe: *https://www.ietf.org/mailman/listinfo/sop
>>>> *
>>>>
>>>> TIA
>>>>
>>>> Monique
>>>>
>>>>
>>>> On 2/14/12 10:45 PM, "Ping Pan" <ping@pingpan.org>; wrote:
>>>>
>>>>
>>>> ****
>>>>
>>>> Where does OpenStack Quantum fit?
>>>>
>>>> OpenStack Quantum is to have agents in controllers and networking
>>>> devices for the purpose of better transport. This is well within the goal
>>>> of SDN.
>>>>
>>>> Ping
>>>>
>>>> On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk <robert@raszuk.net>;
>>>> wrote:
>>>>
>>>> ****
>>>>
>>>>
>>>> Actually I think those are quite separate problem spaces.
>>>>
>>>> SOP aim to address the requirement of cloud to cloud communication
>>>> (hybrid or multi-domain). The way I think about this is how to standardize
>>>> and synchronize OpenStack to OpenStack instrumentation signaling. The next
>>>> step would be to actually also provide cloud to cloud communication layer.
>>>> Simple example: How to launch N VMs in various data centers to be part of
>>>> common resources for customer X.
>>>>
>>>> On the contrary SDNx seems to me of totally different caliber. One way
>>>> to look at this is what and how we could use APIs exposed by existing
>>>> network control planes to define and accomplish new network services. I
>>>> quite do not see current network element control planes nor their APIs as
>>>> much relevant to cloud services.
>>>>
>>>> My own personal view ;)
>>>>
>>>> Regards,
>>>> R.
>>>>
>>>>
>>>>
>>>> ****
>>>>
>>>> I'd like to get some clarification (from anyone who might know or
>>>> have an opinion) on how this would interact with/be distinct from any
>>>> of the SDNP (or whatever name we decide upon) proposed work. Is this
>>>> duplication/people striking out on their own from the nascent SDNP
>>>> effort, a companion effort that became clear as we have begun
>>>> segmenting the problem space, or something else entirely? Since this
>>>> is the first I've heard of the list, I'm thinking it's a separate
>>>> effort, but I figured I would raise the topic for discussion.
>>>>
>>>> Thanks,
>>>>
>>>> Wes George
>>>>
>>>> -----Original Message----- From: ietf-announce-bounces@ietf.org
>>>> [mailto:ietf-announce-bounces@ietf.org <ietf-announce-bounces@ietf.org><;
>>>> mailto:ietf-announce-bounces@ietf.org <ietf-announce-bounces@ietf.org>>;
>>>> ] On Behalf Of IETF
>>>> Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF
>>>> Announcement list Cc: sop@ietf.org; Monique Morrow Subject: New
>>>> Non-WG Mailing List: sop -- Service Orchestration and Desciption for
>>>> Cloud Services
>>>>
>>>>
>>>>
>>>> A new IETF non-working group email list has been created.
>>>>
>>>> List address: sop@ietf.org Archive:
>>>> http://www.ietf.org/mail-archive/web/sop/ <
>>>> http://www.ietf.org/mail-archive/web/sop/>  To subscribe:
>>>> https://www.ietf.org/mailman/listinfo/sop <
>>>> https://www.ietf.org/mailman/listinfo/sop>
>>>>
>>>> Purpose: Cloud services need to interoperate across cloud providers,
>>>> service vendors and private/public domains. To enable this
>>>> interoperability, there is need for a standard wire-format for
>>>> exchanging service information. This mailing lists is for discussing
>>>> protocols, data formats and server descriptions formats that allow
>>>> cloud services to be discovered and used across private and public
>>>> domains. Using these, it would be possible to interoperate diverse
>>>> APIs and cloud services across service providers, service vendors and
>>>> service users.
>>>>
>>>> For additional information, please contact the list administrators.
>>>> _______________________________________________ IETF-Announce mailing
>>>> list IETF-Announce@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ietf-announce <
>>>> https://www.ietf.org/mailman/listinfo/ietf-announce>
>>>>
>>>> This E-mail and any of its attachments may contain Time Warner Cable
>>>> proprietary information, which is privileged, confidential, or
>>>> subject to copyright belonging to Time Warner Cable. This E-mail is
>>>> intended solely for the use of the individual or entity to which it
>>>> is addressed. If you are not the intended recipient of this E-mail,
>>>> you are hereby notified that any dissemination, distribution,
>>>> copying, or action taken in relation to the contents of and
>>>> attachments to this E-mail is strictly prohibited and may be
>>>> unlawful. If you have received this E-mail in error, please notify
>>>> the sender immediately and permanently delete the original and any
>>>> copy of this E-mail and any printout.
>>>> _______________________________________________ SDNP mailing list
>>>> SDNP@lucidvision.com http://lucidvision.com/mailman/listinfo/sdnp <
>>>> http://lucidvision.com/mailman/listinfo/sdnp>
>>>>
>>>> ****
>>>>
>>>>
>>>> _______________________________________________
>>>> SDNP mailing list
>>>> SDNP@lucidvision.com
>>>> http://lucidvision.com/mailman/listinfo/sdnp <
>>>> http://lucidvision.com/mailman/listinfo/sdnp> ****
>>>>
>>>> ** **
>>>> ------------------------------
>>>>
>>>> _______________________________________________
>>>> SDNP mailing list
>>>> SDNP@lucidvision.com
>>>> http://lucidvision.com/mailman/listinfo/sdnp****
>>>>
>>>> _______________________________________________
>>>> SDNP mailing list
>>>> SDNP@lucidvision.com
>>>> http://lucidvision.com/mailman/listinfo/sdnp****
>>>>
>>>> ** **
>>>>
>>>> _______________________________________________
>>>> sop mailing list
>>>> sop@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sop
>>>>
>>>>
>>>
>>> _______________________________________________
>>> sop mailing list
>>> sop@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sop
>>>
>>>
>>
>