Re: [sop] SOP Requirements

"Ashish Dalela (adalela)" <> Thu, 01 March 2012 18:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7F6621E8117 for <>; Thu, 1 Mar 2012 10:08:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.671
X-Spam-Status: No, score=-7.671 tagged_above=-999 required=5 tests=[AWL=2.928, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h2Q1OtFeHx86 for <>; Thu, 1 Mar 2012 10:08:10 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C713321E80CF for <>; Thu, 1 Mar 2012 10:08:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3955; q=dns/txt; s=iport; t=1330625289; x=1331834889; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=S00ScMDoG5JGaboEQpv0VVcm15JMqZ4HPz9NuVn49vs=; b=AzY+Ky5vnNAJjZ+oask38J2R04qSJ2hVp+kU7Ghd9Le6SGze7To4VwLy RwvsWWHYydKNF6mDG3g34S6W4AngLh+oADjAwWabgGPJW04RHXsGmu2yT ndsZddmSnmJPiDSiCI5RN5tpL2167K83e8jCQsmUWnLKoytBJM7NWRBif k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.73,512,1325462400"; d="scan'208";a="6835492"
Received: from (HELO ([]) by with ESMTP; 01 Mar 2012 18:08:07 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id q21I87Li026985; Thu, 1 Mar 2012 18:08:07 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 23:38:06 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 1 Mar 2012 23:38:05 +0530
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [sop] SOP Requirements
Thread-Index: Acz3BPK5UjSopdPrSj2rGDzrWNz61gAz30oQ
References: <><><><><><><><><><><><> <>
From: "Ashish Dalela (adalela)" <>
To: "Jamal Hadi Salim" <>
X-OriginalArrivalTime: 01 Mar 2012 18:08:06.0974 (UTC) FILETIME=[40D625E0:01CCF7D6]
Cc: Vishwas Manral <>,, Michael Hammer <>
Subject: Re: [sop] SOP Requirements
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Service Orchestration and Desciption for Cloud Services <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Mar 2012 18:08:10 -0000

Hi Jamal,

>> I presume theres an operation to say "create abc.vm" which
>> returns me some ID. And going forward i can refer to that
>> abc.vm.someID and be able to reference attribute
>>, no?

Please note that the resources we create and the names we assign them
have to be DNS accessible. That's because from a user standpoint cloud
and non-cloud services must work just the same. Hence, you don't want to
give a name like - abc.vm.someID. You want to give a name that will be
resolved by a DNS server so that the user can reach that server in the
same way, transparent to the fact that it is cloud created.

To make cloud work incrementally, we need a separate name space for
"types", and not mix it with existing names in DNS. So, we end up with
two name spaces - one for types and another for instances. The
properties of an instance are really properties of a "type" but
referenced by an instance. The "type" can have a "name" attribute that
references an instance, without loss of generality. That way, if we
change the name, we are still consistent.

>> Is the requirements one the best one to focus one (that is the one i
have looked at).

Requirements is certainly the place to start at. Many of the questions
you have raise also touch upon architecture, and specifics are in the
protocol draft. Look forward to your comments.

Thanks, Ashish

-----Original Message-----
From: [] On Behalf Of
Jamal Hadi Salim
Sent: Wednesday, February 29, 2012 10:39 PM
To: Ashish Dalela (adalela)
Cc: Vishwas Manral;; Michael Hammer
Subject: Re: [sop] SOP Requirements

Hi Ashish,

On Wed, Feb 29, 2012 at 11:44 AM, Ashish Dalela (adalela)
<> wrote:

> I understand the ForCES background - the idea is aligned with ATCA and
> the notion that any node can be given any "personality". That may not
> true in general where certain types of devices are "capable" of doing
> certain things. E.g. you can't trivially make a switch a firewall or a
> load-balancer. You certainly can't make a network device a storage
> device or a server trivially. It is true for x86 servers maybe, but as
> you get a wide variety of hardware capabilities or move up the
> stack into a middleware or a specific type of application, the
> generalized view disappears. Until we get to a point where a common
> of hardware can enact any type of functionality that view is limited.

I dont need to know a node's "personality" - if it exists, it tells me.
The creation or booting of the node is considered a setup process.
[Once create/booted - the node becomes part of my resource pool.
I may not use it at all if i choose not to.]
In your case, you may consider the creation aspect part of the

> The reality with virtualized services is that the instance doesn't
> *exist* when you ask for it. E.g. when I request a VM, the VM that I
> will be allocated doesn't exist. It will be created on-demand. So,
> is no way I can request the specific "instance". I have to only
> a "type". The type has to be mapped to a capability source, and then
> converted into an instance. Once you have an instance, sure, you refer
> to it both by type and instance.

Then no conflict there.
I presume theres an operation to say "create abc.vm" which
returns me some ID. And going forward i can refer to that
abc.vm.someID and be able to reference attribute, no?

> Sure, that can be clarified. I thought the definition was clear in the
> drafts, but if not, that can be clarified.

I will read the drafts closely and comment. Is the requirements one the
one to focus one (that is the one i have looked at).

sop mailing list