Re: [sop] SOP Requirements

"Ashish Dalela (adalela)" <adalela@cisco.com> Sat, 03 March 2012 03:04 UTC

Return-Path: <adalela@cisco.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 748BB11E8074 for <sop@ietfa.amsl.com>; Fri, 2 Mar 2012 19:04:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.706
X-Spam-Level:
X-Spam-Status: No, score=-7.706 tagged_above=-999 required=5 tests=[AWL=2.893, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 OhU4xh492X30 for <sop@ietfa.amsl.com>; Fri, 2 Mar 2012 19:04:55 -0800 (PST)
Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id A2B8711E8073 for <sop@ietf.org>; Fri, 2 Mar 2012 19:04:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=4688; q=dns/txt; s=iport; t=1330743894; x=1331953494; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=3s7Ce/o5N/19hZXdhGK+Hb42HHO4Z1rY2JVoitFLnSU=; b=KfXmOHPm8Ti6lHXYIx3dLPwKSetS365j5zMcrHHKbyALXO6mDH3Jmd2C 1pKELVsvtrz/YUfxd/njKTH0IkKHChEYRu5XnbBr357ZqxA6iTU/L84fa ++5859JXHb6rOVOx55F1WqDobxT3KXyYsM1YePCQjrrAn2wppnQv/0bvq c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqAEALuJUU9Io8UY/2dsb2JhbABDtUSBfQEBAQMBAQEBDwEdCisJCwUHBAIBCBEBAwEBAQoGFwEGASYfAwYIAQEECwgIEweHXwULmjYBnm4EiggKhVpjBIhOn22BTAE
X-IronPort-AV: E=Sophos;i="4.73,523,1325462400"; d="scan'208";a="7021201"
Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 03 Mar 2012 03:04:52 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2334lja016384; Sat, 3 Mar 2012 03:04:47 GMT
Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 3 Mar 2012 08:34:47 +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: Sat, 3 Mar 2012 08:34:38 +0530
Message-ID: <618BE8B40039924EB9AED233D4A09C51031BC9CA@XMB-BGL-416.cisco.com>
In-Reply-To: <CAAFAkD_nSSyXRGfVL36imdeR+hHWB1OX_t54MF4i6OamnAJiVA@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sop] SOP Requirements
Thread-Index: Acz4oXXyJoJkw3QDQ8i71IRIF641YgASKWww
References: <CAOyVPHQ-iESaD2osxsWguTw1Ru92JYacSsqbD+1rECPzy1eGfQ@mail.gmail.com> <CAA3wLqV+YeGJH2pFQ80s=PgQC2RsodPMm8qUw3a-VtCzhETkOg@mail.gmail.com> <CAOyVPHTXWPyt5aHL2ehd_upS-DEAcfugVMcUpUm_oO5Ov04rUw@mail.gmail.com> <618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> <CAAFAkD-pheMmSQoUZzup_DHQceyXU=1Aq+oQZWEMXA_5pTNayg@mail.gmail.com> <618BE8B40039924EB9AED233D4A09C51031BC083@XMB-BGL-416.cisco.com> <CAAFAkD94ODszZ4D=m0Kyco8CEfE0rs9aLGj36-A7Re2MMQGiZg@mail.gmail.com> <618BE8B40039924EB9AED233D4A09C51031BC0D4@XMB-BGL-416.cisco.com> <CAAFAkD-yjzhVppSyC058y=TAmOQVoaBmAh6Gr_y0ymrvFr_ydQ@mail.gmail.com> <618BE8B40039924EB9AED233D4A09C51031BC382@XMB-BGL-416.cisco.com> <CAAFAkD_8nKOnRf+BhRWiAmxkGByjZDBP6cU2i5ZhnpPA-OGt0Q@mail.gmail.com> <618BE8B40039924EB9AED233D4A09C51031BC3B4@XMB-BGL-416.cisco.com> <CAAFAkD8g497EArRo7CWMyAkxRNM4ArMJh_Ru-oYDC4+dqaLRRQ@mail.gmail.com> <618BE8B40039924EB9AED233D4A09C51031BC6F5@XMB-BGL-416.cisco.com> <CAAFAkD_nSSyXRGfVL36imdeR+hHWB1OX_t 54MF4i6O amnAJiVA@mail.gmail.com>
From: "Ashish Dalela (adalela)" <adalela@cisco.com>
To: "Jamal Hadi Salim" <hadi@mojatatu.com>
X-OriginalArrivalTime: 03 Mar 2012 03:04:47.0202 (UTC) FILETIME=[6414C420:01CCF8EA]
Cc: Vishwas Manral <vishwas.ietf@gmail.com>, sop@ietf.org, Michael Hammer <mphmmr@gmail.com>
Subject: Re: [sop] SOP Requirements
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: Sat, 03 Mar 2012 03:04:56 -0000

Hi Jamal,

Yes, the IETF format is to describe requirements and/or problem
statements before you put out a solution. So, we have put both a problem
statement and a solution.

Thanks, Ashish

-----Original Message-----
From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] 
Sent: Friday, March 02, 2012 11:52 PM
To: Ashish Dalela (adalela)
Cc: Vishwas Manral; sop@ietf.org; Michael Hammer
Subject: Re: [sop] SOP Requirements

Hi Ashish,

I will read the drafts and provide better comments. I guess
the point i was missing was you put out requirements to
look for a protocol and it turns out you already have a protocol
which suits your needs.

cheers,
jamal


On Thu, Mar 1, 2012 at 1:08 PM, Ashish Dalela (adalela)
<adalela@cisco.com>; wrote:

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

Ok - didnt realize that angle.

> 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: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of
> Jamal Hadi Salim
> Sent: Wednesday, February 29, 2012 10:39 PM
> To: Ashish Dalela (adalela)
> Cc: Vishwas Manral; sop@ietf.org; Michael Hammer
> Subject: Re: [sop] SOP Requirements
>
> Hi Ashish,
>
> On Wed, Feb 29, 2012 at 11:44 AM, Ashish Dalela (adalela)
> <adalela@cisco.com>; 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
> be
>> 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
> software
>> stack into a middleware or a specific type of application, the
>> generalized view disappears. Until we get to a point where a common
> type
>> 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
> process.
>
>> 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,
> there
>> is no way I can request the specific "instance". I have to only
> request
>> 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
> abc.vm.someID.foo, 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
> best
> one to focus one (that is the one i have looked at).
>
> cheers,
> jamal
> _______________________________________________
> sop mailing list
> sop@ietf.org
> https://www.ietf.org/mailman/listinfo/sop