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

From: Monique Morrow <[email-masked]>
Date: Thu, 16 Feb 2012 15:09:40 +0100

Guys 

Please join the SOP mailer

List address: [email-masked]
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" <[email-masked]> 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 <[email-masked]> 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: [email-masked]
>>> [mailto:[email-masked]
>>> <mailto:[email-masked]> ] On Behalf Of IETF
>>> Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF
>>> Announcement list Cc: [email-masked]; 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: [email-masked] 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 [email-masked]
>>> 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
>>> [email-masked] http://lucidvision.com/mailman/listinfo/sdnp
>>> <http://lucidvision.com/mailman/listinfo/sdnp>
>>> 
>>> 
>> 
>> _______________________________________________
>> SDNP mailing list
>> [email-masked]
>> http://lucidvision.com/mailman/listinfo/sdnp
>> <http://lucidvision.com/mailman/listinfo/sdnp>
> 
> 
> 
> _______________________________________________
> SDNP mailing list
> [email-masked]
> http://lucidvision.com/mailman/listinfo/sdnp

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 16 Feb 2012 09:28:52 -0500

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:

>> 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
>> 
>>> 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.
>>> 
>>> 
>>>> [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of IETF
>>>> 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> 
>>>> 
>>>> https://www.ietf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/mailman/listinfo/ietf-announce> 
>>>> 
>>>> [email-masked] http://lucidvision.com/mailman/listinfo/sdnp <http://lucidvision.com/mailman/listinfo/sdnp> 
>>>> 
>>>> 
>>> 
>>> http://lucidvision.com/mailman/listinfo/sdnp <http://lucidvision.com/mailman/listinfo/sdnp> 
>> 
>>

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 16 Feb 2012 09:38:57 -0500

--Tom

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Thu, 16 Feb 2012 20:32:39 +0530

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:[email-masked]] 
Sent: Thursday, February 16, 2012 7:59 PM
To: Monique Morrow (mmorrow)
Cc: Ping Pan; [email-masked]; sdnp; [email-masked]
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

            --Tom

Guys 

List address: [email-masked] <x-msg://551/[email-masked]> 
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" <[email-masked]
<x-msg://551/[email-masked]> > wrote:

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 <[email-masked]
<x-msg://551/[email-masked]> > wrote:

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.

Thanks,

Wes George

-----Original Message----- From: [email-masked]
<x-msg://551/[email-masked]> 
[mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of IETF
Secretariat Sent: Tuesday, February 14, 2012 2:25 PM To: IETF
Announcement list Cc: [email-masked] <x-msg://551/[email-masked]> ; Monique
Morrow Subject: New
Non-WG Mailing List: sop -- Service Orchestration and Desciption for
Cloud Services

List address: [email-masked] <x-msg://551/[email-masked]>  Archive:

list [email-masked] <x-msg://551/[email-masked]> 

[email-masked] <x-msg://551/[email-masked]>

_______________________________________________
SDNP mailing list
[email-masked] <x-msg://551/[email-masked]> 
http://lucidvision.com/mailman/listinfo/sdnp
<http://lucidvision.com/mailman/listinfo/sdnp> 

________________________________

_______________________________________________
SDNP mailing list
[email-masked] <x-msg://551/[email-masked]> 
http://lucidvision.com/mailman/listinfo/sdnp

---

From: Scott Brim <[email-masked]>
Date: Thu, 16 Feb 2012 09:47:29 -0500

> might be helpful to include that as well. 8)

Robert's statement is exactly what I thought.

---

From: Ping Pan <[email-masked]>
Date: Thu, 16 Feb 2012 07:23:43 -0800

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)
<[email-masked]>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 “requirements” draft.****
>
> ** **
>
> The other drafts are:****
>
> ** **
>
> the use-cases and network deployments with the protocol****
>
> http://tools.ietf.org/html/draft-dalela-sop-00 - describes the protocol’s
> messages ****
>
> naming, workflow construction, etc.****
>
> message flows****
> ** **
> Thanks, Ashish****
> ** **
> ** **
> *From:* Thomas Nadeau [mailto:[email-masked]]
> *Sent:* Thursday, February 16, 2012 7:59 PM
> *To:* Monique Morrow (mmorrow)
> *Cc:* Ping Pan; [email-masked]; sdnp; [email-masked]
> *Subject:* Re: [Sdnp] FW: New Non-WG Mailing List: sop -- Service
> Orchestration and Desciption for Cloud Services****
>
> ** **
>
> ** **
>
> its goals are?****
> ****
> might be helpful to include that as well. 8)****
>
>             ****
>
>             --Tom****
>
> ** **
>
> ** **
>
> ** **
>
> On Feb 16, 2012, at 9:09 AM, Monique Morrow wrote:****
>
>
>
> ****
>
> Guys
>
> List address: [email-masked]
> *Archive: *http://www.ietf.org/mail-archive/web/sop/
> *To subscribe: *https://www.ietf.org/mailman/listinfo/sop
> *
>
> TIA
>
> Monique
>
>
> ****
> 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
>
> ****
> 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
> 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.
>
> 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.
>
>
>
> ****
>
> [mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>> ]
> On Behalf Of IETF
> 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>
>
> https://www.ietf.org/mailman/listinfo/ietf-announce <
> https://www.ietf.org/mailman/listinfo/ietf-announce>
>
> [email-masked] http://lucidvision.com/mailman/listinfo/sdnp <
> http://lucidvision.com/mailman/listinfo/sdnp>
>
> ****
>
>
> http://lucidvision.com/mailman/listinfo/sdnp <
> http://lucidvision.com/mailman/listinfo/sdnp> ****
>
> ** **
> ------------------------------
>
> http://lucidvision.com/mailman/listinfo/sdnp****
>
> http://lucidvision.com/mailman/listinfo/sdnp****
>
> ** **
>
> sop mailing list
> [email-masked]

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Thu, 16 Feb 2012 21:08:33 +0530

Well, yes, one of the use-case is to solve interoperability issues between and across clouds.

I also have heard from folks the need for “deep control” in which a customer outside the cloud wants to tweak or control the infrastructure or application at a low granularity. I think that would be hard, although not impossible, if the mechanisms outside and inside were different – as you will have to create mappings.

That is a topic quite open for discussion.

Thanks, Ashish

From: Ping Pan [mailto:[email-masked]] 
Sent: Thursday, February 16, 2012 8:54 PM
To: Ashish Dalela (adalela)
Cc: Thomas Nadeau; Monique Morrow (mmorrow); sdnp; [email-masked]; [email-masked]
Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services

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) <[email-masked]> 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.

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

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

            --Tom

Guys 

TIA

Monique

Ping

My own personal view ;)

Regards,
R.

Thanks,

Wes George

---

From: Michael Hammer <[email-masked]>
Date: Thu, 16 Feb 2012 10:39:39 -0500

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 <[email-masked]> wrote:

>> **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.****
>>
>> ** **
>>
>> protocol’s messages ****
>> it****
>> (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.
>> mailto:[email-masked] <[email-masked]>>
>> ] On Behalf Of IETF

---

From: Ping Pan <[email-masked]>
Date: Thu, 16 Feb 2012 07:51:28 -0800

There are talks on more control from applications to the networks.

IMHO, this is more of a misunderstanding than anything else.

First, many DC operators have leased the circuits or built the network.
They have every right to decide the policy at edge and aggregate traffic
onto the network they lease or own. Second, I think that the service
providers would have no problem to expedite the BW provisioning process
when a customer is asking for more, but no service provider to my best
knowledge would allow the customers to alter the routes inside their
networks.

So deep-control to me means a cleaner, simpler and faster way to
provisioning network resources through a consistent interface.

Ping

On Thu, Feb 16, 2012 at 7:38 AM, Ashish Dalela (adalela)
<[email-masked]>wrote:

> ** **
>
> Well, yes, one of the use-case is to solve interoperability issues between
> and across clouds.****
>
> ** **
>
> I also have heard from folks the need for “deep control” in which a
> customer outside the cloud wants to tweak or control the infrastructure or
> application at a low granularity. I think that would be hard, although not
> impossible, if the mechanisms outside and inside were different – as you
> will have to create mappings.****
>
> ** **
>
> That is a topic quite open for discussion.****
>
> ** **
>
> Thanks, Ashish****
>
> ** **
>
> ** **
>
> *From:* Ping Pan [mailto:[email-masked]]
> *Sent:* Thursday, February 16, 2012 8:54 PM
> *To:* Ashish Dalela (adalela)
> *Cc:* Thomas Nadeau; Monique Morrow (mmorrow); sdnp; [email-masked];
> [email-masked]
> *Subject:* Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service
> this makes sense...****
> SDN should not be viewed as the NMS for DC's.****
>
> ** **
>
> work together.****
> Ping****
> On Thu, Feb 16, 2012 at 7:02 AM, Ashish Dalela (adalela) <
> [email-masked]> wrote:****
>
>  ****
>
> 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.****
>
>  ****
>
> between service-independent and service-dependent pieces makes the scheme
> extensible to any type of service – current or future.****
>
>  ****
>
>             Can you please explain what the purpose of SOP is and what its
> goals are?****
>
> On Tue, Feb 14, 2012 at 1:37 PM, Robert Raszuk <[email-masked]> wrote:*
> ***
>
>
> https://www.ietf.org/mailman/listinfo/sop****
>
> ** **
>

---

From: Ping Pan <[email-masked]>
Date: Thu, 16 Feb 2012 07:57:37 -0800

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 <[email-masked]> wrote:

> 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
>
>
>> [email-masked]> wrote:
>>
>>> ** **
>>>
>>> devices for the purpose of better transport. This is well within the goal
>>> of SDN.
>>>
>>> Ping
>>>
>>> quite do not see current network element control planes nor their APIs as
>>> much relevant to cloud services.
>>>
>>> My own personal view ;)
>>>
>>> Regards,
>>> R.
>>>
>>>
>>>
>>> ****
>>>
>>> [mailto:[email-masked] <[email-masked]><

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Thu, 16 Feb 2012 21:39:45 +0530

Ping,

This isn’t just about the network resources and SOP isn’t only about provisioning network resources. The protocol definition is generalized to support any kind of service – network included.

To your point about changing routes – I agree to that completely. The goal isn’t to replace routing protocols! SOP will use network routes. As you say, it can be used to provision “policies”.

Thanks, Ashish

Sent: Thursday, February 16, 2012 9:21 PM

First, many DC operators have leased the circuits or built the network. They have every right to decide the policy at edge and aggregate traffic onto the network they lease or own. Second, I think that the service providers would have no problem to expedite the BW provisioning process when a customer is asking for more, but no service provider to my best knowledge would allow the customers to alter the routes inside their networks.

So deep-control to me means a cleaner, simpler and faster way to provisioning network resources through a consistent interface.

Ping

On Thu, Feb 16, 2012 at 7:38 AM, Ashish Dalela (adalela) <[email-masked]> wrote:

Thanks, Ashish

Ping

The other drafts are:

Thanks, Ashish

 

            --Tom

Guys 

TIA

Monique

Ping

My own personal view ;)

Regards,
R.

Thanks,

Wes George

---

From: Michael Hammer <[email-masked]>
Date: Thu, 16 Feb 2012 11:10:40 -0500

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 <[email-masked]> wrote:

>> The question I would ask is how many Cloud services do we think there
>> will be long run.
>>>> http://tools.ietf.org/html/draft-dalela-sop-architecture-00 -
>>>> describes the use-cases and network deployments with the protocol****
>>>>
>>>> People on this list have been also asking how it differs from SDN(p),
>>>> so it****
>>>>

---

From: Ping Pan <[email-masked]>
Date: Thu, 16 Feb 2012 08:17:38 -0800

On Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela (adalela)
<[email-masked]>wrote:

> This isn’t just about the network resources and SOP isn’t only about
> provisioning network resources. The protocol definition is generalized to
> support any kind of service – network included.

Be careful. Others have brought up similar proposal before. IETF stands for
Internet Engineering TF... Networking is the name of the game. ;-) If not
networking, I fear it would be wrong place to do the work.

In SDN, our focus is on networking. Further, we are trying to
distance ourselves from the actual DC network fabric design (all
vendor-specific so far).

Regards,

Ping

---

From: Ping Pan <[email-masked]>
Date: Thu, 16 Feb 2012 08:19:56 -0800

Make sense!

Thanks!

Ping

On Thu, Feb 16, 2012 at 8:10 AM, Michael Hammer <[email-masked]> wrote:

> 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.
>
>>> 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?
>>>
>>>>> The above draft describes the problems SOP is aimed to address. This
>>>>> is the “requirements” draft.****
>>>>>
>>>>> ** **
>>>>>
>>>>>             Can you please explain what the purpose of SOP is and
>>>>> what its goals are?****
>>>>>
>>>>> [mailto:[email-masked]<[email-masked]><

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Thu, 16 Feb 2012 21:58:27 +0530

>> Be careful. Others have brought up similar proposal before. IETF stands for Internet Engineering TF... Networking is the name of the game. ;-) If not networking, I fear it would be wrong place to do the work.

That I disagree with because HTTP, SIP, SMTP, SOAP, SNMP are all L7 protocols. I wonder how many people call that networking .. but in a way they are Internet. Certain things like SNMP go beyond networks. SOAP goes even beyond infrastructure. SMTP is totally application, and so is SIP and HTTP.

Did you see the drafts yet? The requirement draft has a section  “Is Cloud Control an Internet Problem?”. The intent of that section is to describe why IETF is the place to do this work.

Thanks, Ashish

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ping Pan
Sent: Thursday, February 16, 2012 9:48 PM
To: Ashish Dalela (adalela)
Cc: [email-masked]
Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services

On Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela (adalela) <[email-masked]> wrote:

Be careful. Others have brought up similar proposal before. IETF stands for Internet Engineering TF... Networking is the name of the game. ;-) If not networking, I fear it would be wrong place to do the work.

In SDN, our focus is on networking. Further, we are trying to distance ourselves from the actual DC network fabric design (all vendor-specific so far).

Regards,

Ping

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Feb 2012 17:29:54 +0100

Hi Michael,

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

May be an interesting challenge especially since it seems that current 
cloud "monopoly phase" is an open source one ;)

Best,
R.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 16 Feb 2012 11:33:23 -0500

Yeah, except open source does not necessarily mean standardized.

Whose open source project are we talking about?  :)

Mike

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 16 Feb 2012 11:36:44 -0500

Good point Ping. That is the question in my mind. Does this belong somewhere else like where OpenStack is being done, or otherwise?

	--Tom

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Thu, 16 Feb 2012 22:16:30 +0530

That point is discussed in the draft -
http://tools.ietf.org/html/draft-dalela-orchestration-00#section-5

Thanks, Ashish

From: Thomas Nadeau [mailto:[email-masked]] 
Sent: Thursday, February 16, 2012 10:07 PM
To: Ping Pan
Cc: Ashish Dalela (adalela); [email-masked]
Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service
Orchestration and Desciption for Cloud Services

            Good point Ping. That is the question in my mind. Does this
belong somewhere else like where OpenStack is being done, or otherwise?

            --Tom

On Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela (adalela)
<[email-masked]> wrote:

This isn't just about the network resources and SOP isn't only about
provisioning network resources. The protocol definition is generalized
to support any kind of service - network included.

Be careful. Others have brought up similar proposal before. IETF stands
for Internet Engineering TF... Networking is the name of the game. ;-)
If not networking, I fear it would be wrong place to do the work.

In SDN, our focus is on networking. Further, we are trying to distance
ourselves from the actual DC network fabric design (all vendor-specific
so far).

Regards,

Ping

---

From: Michael Hammer <[email-masked]>
Date: Thu, 16 Feb 2012 11:47:43 -0500

For interoperability's sake across private and public clouds from different
network providers, we are looking for a protocol to be developed.

The analogy we are making is that on-demand provisioning of a voice/video
 network circuit between two points is done with SIP.  Without interferring
with that effort, and working in parallel, what is the difference with the
on-demand provisioning of network/compute/storage over IP?

Would you also argue that all the SIP work should not have been done in
IETF?
Or that SIP should not have been done because there are open-source
projects?

Mike

On Thu, Feb 16, 2012 at 11:36 AM, Thomas Nadeau <[email-masked]>wrote:

>
> Good point Ping. That is the question in my mind. Does this belong
> somewhere else like where OpenStack is being done, or otherwise?
>
> --Tom
>
>
> for Internet Engineering TF... Networking is the name of the game. ;-) If
> not networking, I fear it would be wrong place to do the work.
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Feb 2012 17:48:33 +0100

> Yeah, except open source does not necessarily mean standardized.

Well history shows that "standardized" usually get's influenced by 
commercialization very quickly and turns into major vendor's battlefield.

Is having two IGPs blessed by IETF as standard a feature or a bug ? Is 
having N ways to accomplish L2VPNs where major vendors do not 
interoperate something we would admire as great success of 
standardization process ? Or IPv6 "progress". I don't know ...

> Whose open source project are we talking about?  :)

http://openstack.org/community/companies/
http://www.eclipse.org/membership/showAllMembers.php

Cheers,
R.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 16 Feb 2012 11:58:36 -0500

Robert,

And that is the *only* open source project?  :)

Yeah, having more than one standard is an issue as well.
Would hope that we could converge early on one, but the IETF is what it is.
But that is not an argument against trying, or you might as well shut down
any effort.

Mike

On Thu, Feb 16, 2012 at 11:48 AM, Robert Raszuk <[email-masked]> wrote:

> having N ways to accomplish L2VPNs where major vendors do not interoperate
> something we would admire as great success of standardization process ? Or
> IPv6 "progress". I don't know ...
>
>
> http://openstack.org/**community/companies/<http://openstack.org/community/companies/>
> http://www.eclipse.org/**membership/showAllMembers.php<http://www.eclipse.org/membership/showAllMembers.php>
>
> Cheers,
> R.
>

---

From: Ping Pan <[email-masked]>
Date: Thu, 16 Feb 2012 09:03:02 -0800

There are two issues here:

1. Open standard vs.open source code: we can argue all we want,
OpenStack/OpenFlow/OpenvSwitch/Hadoop/EC2 are making real impact. IMHO, any
standard without tight-coupling to the running implementation is nothing
but a waste of time - may that be open or close standard. Standards would
help the deployment of the technology, but it's the open source code that
has been the front runner in cloud computing.

You have mentioned SIP and IETF. During the same period of time Skype was
also around. It's not open source code, but free application. At the end of
the day, can anyone argue Skype is making less impact on VoIP because there
is no proper standardization? My point is, let's not put standard and
running code on the opposite side of a scale. Standard can only benefit
from the running code.

2. Layering: IP networking runs on many layers. My point was that anything
to do with IP networking would be investigated and worked on in IETF. But
the non-networking application should not. If we are to support scalable
filesystems in data centers, such as HDFS, should that be standardized in
IETF?

Regards,

Ping

On Thu, Feb 16, 2012 at 8:47 AM, Michael Hammer <[email-masked]> wrote:

> For interoperability's sake across private and public clouds from
> different network providers, we are looking for a protocol to be developed.
>

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 16 Feb 2012 12:04:05 -0500

On Feb 16, 2012, at 11:47 AM, Michael Hammer wrote:

> For interoperability's sake across private and public clouds from different network providers, we are looking for a protocol to be developed.

	Is this a service provider requirement or one from equipment vendors?

> The analogy we are making is that on-demand provisioning of a voice/video  network circuit between two points is done with SIP.  Without interferring with that effort, and working in parallel, what is the difference with the on-demand provisioning of network/compute/storage over IP?
> 
> Would you also argue that all the SIP work should not have been done in IETF?
> Or that SIP should not have been done because there are open-source projects?

	I am not arguing either way; I was asking the question to the wider audience.

	--Tom

> 
> Mike
> 
> 
> On Thu, Feb 16, 2012 at 11:36 AM, Thomas Nadeau <[email-masked]> wrote:
>

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Thu, 16 Feb 2012 22:39:44 +0530

Tom,

I would suggest to read the requirements draft, because number of
questions you and Ping are asking here about the goal, IETF-fit,
relationship to open-source are anticipated and discussed in that draft.
To your point about who needs it - inter-cloud is a service provider
need, hybrid-cloud is a provider and customer need, and
vendor-interoperability is both provider and customer need.

The requirements draft is here -
http://tools.ietf.org/html/draft-dalela-orchestration-00

Thanks, Ashish

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Thomas Nadeau
Sent: Thursday, February 16, 2012 10:34 PM
To: Michael Hammer
Cc: [email-masked]; Ping Pan; Ashish Dalela (adalela)
Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop --
ServiceOrchestration and Desciption for Cloud Services

For interoperability's sake across private and public clouds from
different network providers, we are looking for a protocol to be
developed.

            Is this a service provider requirement or one from equipment
vendors?

The analogy we are making is that on-demand provisioning of a
voice/video  network circuit between two points is done with SIP.
Without interferring with that effort, and working in parallel, what is
the difference with the on-demand provisioning of
network/compute/storage over IP?

            I am not arguing either way; I was asking the question to
the wider audience.

            --Tom

Mike

On Thu, Feb 16, 2012 at 11:36 AM, Thomas Nadeau
<[email-masked]> wrote:

--Tom

	This isn't just about the network resources and SOP isn't only
about provisioning network resources. The protocol definition is
generalized to support any kind of service - network included.

	Be careful. Others have brought up similar proposal before. IETF
stands for Internet Engineering TF... Networking is the name of the
game. ;-) If not networking, I fear it would be wrong place to do the
work.

	Regards,

	Ping

---

From: Michael Hammer <[email-masked]>
Date: Thu, 16 Feb 2012 12:22:44 -0500

Ping,

One of the ideas here is to separate out the service-dependent and
service-independent aspects and hopefully provide a unifying framework to
many disparate projects ongoing.  So, it is not an either-or situation but
how to help unify these efforts.

As Ashish notes, we attempt to address some of these questions in those
drafts.

WRT Skype, this is also another case of lack of interoperability.  As you
probably saw, the EU had concerns about lack of interop with Cisco
vis-a-vis Tandberg in the past, and of course Cisco is bringing this to the
EU attention to keep the playing field level with respect to Skype.
 Whether it is Cisco-Tandberg or Microsoft-Skype, need to apply same rules
to both.

Architecturally, having to go through gateways everywhere is not a good
long-term solution.  It just doesn't scale well and leads to many broken or
Least Common Denominator results.  Not a very rich experience for the user.

I should also point out that governments, who are also very big customers,
do not want to be locked into just one solution.  You don't want to do
fork-lifts every time you move from one service provider to another.

Mike

On Thu, Feb 16, 2012 at 12:09 PM, Ashish Dalela (adalela) <[email-masked]
> wrote:

> Tom,****
> relationship to open-source are anticipated and discussed in that draft. To
> your point about who needs it - inter-cloud is a service provider need,
> hybrid-cloud is a provider and customer need, and vendor-interoperability
> is both provider and customer need.****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Thomas
> Nadeau
> *Sent:* Thursday, February 16, 2012 10:34 PM
> *To:* Michael Hammer
> *Cc:* [email-masked]; Ping Pan; Ashish Dalela (adalela)
> *Subject:* Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop --
> ServiceOrchestration and Desciption for Cloud Services****
>
> ** **
>
> ** **
>
> On Feb 16, 2012, at 11:47 AM, Michael Hammer wrote:****
>
>
>
> ****
>
> vendors?****
> on-demand provisioning of network/compute/storage over IP?****
>
> ** **
>
> IETF?****
> projects?****
>             I am not arguing either way; I was asking the question to the
> wider audience.****
>
> ** **
>
>             --Tom****
>
> ** **
>
>
>
> ****
>
> ** **
>
> Mike****
>
> ** **
>
> On Thu, Feb 16, 2012 at 11:36 AM, Thomas Nadeau <[email-masked]>
> wrote:****
>
> ** **
>
> somewhere else like where OpenStack is being done, or otherwise?****
>
> ** **
>
> --Tom****
>
> ** **
>
> ** **
>
> On Feb 16, 2012, at 11:17 AM, Ping Pan wrote:****
>
> ** **
>
> On Thu, Feb 16, 2012 at 8:09 AM, Ashish Dalela (adalela) <
> support any kind of service – network included.****
>
> ** **
>
> not networking, I fear it would be wrong place to do the work.****
>
> ** **
>
> vendor-specific so far).****
>
> ** **
>
> Regards,****
>
> ** **
>
> Ping****
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Feb 2012 18:24:34 +0100

> But that is not an argument against trying, or you might as well shut
> down any effort.

Actually my only observation here is that openstack community seems to 
be a very health environment where things actually get done well and 
quick (read like IETF was doing in 1980s and 1990s) so I am just trying 
to make sure this effort (or whatever it will be end effect of this 
effort here) will not break it or will be even considered by current 
openstack community.

If someone would ask me I would say that cloud to cloud standardization 
should belong and be done today in openstack community rather then in IETF.

Thx,
R.

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Fri, 17 Feb 2012 05:51:31 +0530

Robert,

You need to go past this argument that OpenStack is healthy and by
implication IETF is not. Or, what we have proposed here will break
OpenStack. 

This effort is not opposed to any open-source effort, including
OpenStack. Its goal is to allow open and closed source to interoperate.
Unless you are mandating that every cloud controller on the planet ought
to be OpenStack, I don't see how this argument is relevant.

The tradeoff should not be between go open source or you can never
interoperate. That hasn't worked in the past, and it won't in the case
of cloud. 

Thanks, Ashish

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: Thursday, February 16, 2012 10:55 PM
To: Michael Hammer
Cc: Thomas Nadeau; sdnp; Ping Pan; Monique Morrow (mmorrow);
[email-masked]; Ashish Dalela (adalela)
Subject: Re: [sop] [Sdnp] FW: New Non-WG Mailing List: sop -- Service
Orchestration and Desciption for Cloud Services

If someone would ask me I would say that cloud to cloud standardization 
should belong and be done today in openstack community rather then in
IETF.

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Feb 2012 09:07:34 +0100

Ashish,

I don't need to go past as I am not stuck :) I see how OS community 
progresses and I am also very heavily involved in IETF standardization 
process and I first hand see how it does not.

It is not the question if it would be nice to have a standard cloud to 
cloud communication. In fact I expressed this already in the first mail 
as reply to Wes.

The questions I see are:

- is IETF right place to standardize it

- if IETF does eventually publish something would that be accepted by 
community (in particular open source one)

Best,
R.

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Sun, 19 Feb 2012 03:27:13 +0530

Robert,

>> - is IETF right place to standardize it

This specific question is discussed in section 6 of the requirements
draft. Most cloud services use HTTP (web-services) today. Limitations of
HTTP for cloud services are described in section 8.

Let's not forget that providers need to differentiate their services
from one another. How will provider services be differentiated if
everyone uses the same open-source software stack? Add proprietary
extensions not published back to open-source?
	
Thanks, Ashish

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: Friday, February 17, 2012 1:38 PM
To: Ashish Dalela (adalela)
Cc: [email-masked]
Subject: Re: [sop] -- Service Orchestration and Desciption for Cloud
Services

Ashish,

The questions I see are:

Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 18 Feb 2012 23:16:56 +0100

> from one another.

You are telling me that ? You - were it takes cisco on average 2 years 
to get any enhancement in then such enhancement is immediately available 
to all service providers as clearly you can not scale with per customer 
development branch. Amazing stuff !

> How will provider services be differentiated if

If such open source license permits it (example apache) .. why not ?

Thx,
R.

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 29 Feb 2012 17:45:19 +0100

Hi,

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

Though I've had no time to make a comparison in depth, I could not avoid noticing that SOP and the Intercloud effort recently started inside the IEEE P2302 Working Group are very much related, if not overlapping. Alignment should be pursued, I think.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Wed, 29 Feb 2012 22:28:52 +0530

Hi Diego,

We are aware of the IEEE work on Intercloud, but I'm not sure if there is a concrete technical proposal in place. I might not have seen it, in which please do point it out to me.

Thanks, Ashish

-----Original Message-----
From: DIEGO LOPEZ GARCIA [mailto:[email-masked]] 
Sent: Wednesday, February 29, 2012 10:15 PM
To: Ashish Dalela (adalela)
Cc: [email-masked]
Subject: Re: [Sdnp] New Non-WG Mailing List: sop -- Service Orchestration and Desciption for Cloud Services

Hi,

On 16 Feb 2012, at 16:02 , Ashish Dalela (adalela) wrote:
> 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.
>

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091