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

Thomas Nadeau <tnadeau@lucidvision.com> Thu, 16 February 2012 14:39 UTC

Return-Path: <tnadeau@lucidvision.com>
X-Original-To: sop@ietfa.amsl.com
Delivered-To: sop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D48521F8678 for <sop@ietfa.amsl.com>; Thu, 16 Feb 2012 06:39:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.445
X-Spam-Level:
X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FW6Q39vkmZ1s for <sop@ietfa.amsl.com>; Thu, 16 Feb 2012 06:39:02 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 03B0E21F86AA for <sop@ietf.org>; Thu, 16 Feb 2012 06:39:01 -0800 (PST)
Received: from [192.168.1.94] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 5C5E9208D698; Thu, 16 Feb 2012 09:39:01 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CB323D56-4BF0-4833-BC59-121BC2B714DC"
From: Thomas Nadeau <tnadeau@lucidvision.com>
In-Reply-To: <CB62CCB4.C846D%mmorrow@cisco.com>
Date: Thu, 16 Feb 2012 09:38:57 -0500
Message-Id: <CB34DC8D-0EE9-4472-B734-063C0536D215@lucidvision.com>
References: <CB62CCB4.C846D%mmorrow@cisco.com>
To: Monique Morrow <mmorrow@cisco.com>
X-Mailer: Apple Mail (2.1257)
Cc: sdnp <sdnp@lucidvision.com>, sop@ietf.org, Ping Pan <ping@pingpan.org>, robert@raszuk.net
Subject: Re: [sop] FW: [Sdnp] 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 14:39:07 -0000

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