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

[Ping Pan <[e-mail]>]

Make sense!

Thanks!

Ping

On Thu, Feb 16, 2012 at 8:10 AM, Michael Hammer <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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) <
>>>> [e-mail]> 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:[e-mail]]
>>>>> *Sent:* Thursday, February 16, 2012 7:59 PM
>>>>> *To:* Monique Morrow (mmorrow)
>>>>> *Cc:* Ping Pan; [e-mail]; sdnp; [e-mail]
>>>>> *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: *[e-mail]
>>>>> *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" <[e-mail]> 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 <[e-mail]>
>>>>> 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: [e-mail]
>>>>> [mailto:[e-mail]<[e-mail]><
>>>>> mailto:[e-mail] <[e-mail]>>
>>>>> ] On Behalf Of IETF
>>>>> Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF
>>>>> Announcement list Cc: [e-mail]; 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: [e-mail] 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 [e-mail]
>>>>> 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
>>>>> [e-mail] http://lucidvision.com/mailman/listinfo/sdnp <
>>>>> http://lucidvision.com/mailman/listinfo/sdnp>
>>>>>
>>>>> ****
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SDNP mailing list
>>>>> [e-mail]
>>>>> http://lucidvision.com/mailman/listinfo/sdnp <
>>>>> http://lucidvision.com/mailman/listinfo/sdnp> ****
>>>>>
>>>>> ** **
>>>>> ------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> SDNP mailing list
>>>>> [e-mail]
>>>>> http://lucidvision.com/mailman/listinfo/sdnp****
>>>>>
>>>>> _______________________________________________
>>>>> SDNP mailing list
>>>>> [e-mail]
>>>>> http://lucidvision.com/mailman/listinfo/sdnp****
>>>>>
>>>>> ** **
>>>>>
>>>>> _______________________________________________
>>>>> sop mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/sop
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> sop mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/sop
>>>>
>>>>
>>>
>>
>