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

Ping Pan <ping@pingpan.org> Thu, 16 February 2012 16:20 UTC

Return-Path: <ping@pingpan.org>
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 2C93D21F881F for <sop@ietfa.amsl.com>; Thu, 16 Feb 2012 08:20:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level:
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 oCwEXkyzRpEF for <sop@ietfa.amsl.com>; Thu, 16 Feb 2012 08:20:39 -0800 (PST)
Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with SMTP id CE77921F87FA for <sop@ietf.org>; Thu, 16 Feb 2012 08:20:38 -0800 (PST)
Received: from mail-qw0-f41.google.com ([209.85.216.41]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTz0s1umEaB13K8g4YI9grzWblTHs0VPH@postini.com; Thu, 16 Feb 2012 08:20:38 PST
Received: by qadz32 with SMTP id z32so4522774qad.7 for <sop@ietf.org>; Thu, 16 Feb 2012 08:20:37 -0800 (PST)
Received: by 10.229.102.137 with SMTP id g9mr2068851qco.128.1329409237745; Thu, 16 Feb 2012 08:20:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.80.200 with HTTP; Thu, 16 Feb 2012 08:19:56 -0800 (PST)
In-Reply-To: <CAA3wLqW-GNw4hUS8bgpzUDnptyJU2q5i4UjrHxRn9K91vFitwg@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> <CAA3wLqW-GNw4hUS8bgpzUDnptyJU2q5i4UjrHxRn9K91vFitwg@mail.gmail.com>
From: Ping Pan <ping@pingpan.org>
Date: Thu, 16 Feb 2012 08:19:56 -0800
Message-ID: <CAHEV9L0tXCBvBuHCK=EfRtASL0-OoroV3vtv+XNq=_wKL=1bzg@mail.gmail.com>
To: Michael Hammer <mphmmr@gmail.com>
Content-Type: multipart/alternative; boundary=002354470f7860829d04b9173585
X-Gm-Message-State: ALoCoQn2zG1rlbG+oYAG8Ovso9EAtRUswekJlsnYVJauuY30ZnGs1OkTThwsA3sHwO33tOCcDOTD
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:20:44 -0000

Make sense!

Thanks!

Ping

On Thu, Feb 16, 2012 at 8:10 AM, Michael Hammer <mphmmr@gmail.com> wrote:

> 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
>>>>
>>>>
>>>
>>
>