Re: [sop] SOP Requirements

Vishwas Manral <vishwas.ietf@gmail.com> Mon, 27 February 2012 19:55 UTC

Return-Path: <vishwas.ietf@gmail.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 C139621F87DF for <sop@ietfa.amsl.com>; Mon, 27 Feb 2012 11:55:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.816
X-Spam-Level:
X-Spam-Status: No, score=-3.816 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 zvlqTruMWa2n for <sop@ietfa.amsl.com>; Mon, 27 Feb 2012 11:55:56 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5062E21F87D7 for <sop@ietf.org>; Mon, 27 Feb 2012 11:55:56 -0800 (PST)
Received: by ggnp2 with SMTP id p2so585601ggn.31 for <sop@ietf.org>; Mon, 27 Feb 2012 11:55:55 -0800 (PST)
Received-SPF: pass (google.com: domain of vishwas.ietf@gmail.com designates 10.60.27.6 as permitted sender) client-ip=10.60.27.6;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of vishwas.ietf@gmail.com designates 10.60.27.6 as permitted sender) smtp.mail=vishwas.ietf@gmail.com; dkim=pass header.i=vishwas.ietf@gmail.com
Received: from mr.google.com ([10.60.27.6]) by 10.60.27.6 with SMTP id p6mr6592399oeg.36.1330372555849 (num_hops = 1); Mon, 27 Feb 2012 11:55:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rtsl8YagJs0rCY7O2iiMF+dHGjokCCx5H1p9YqHUrME=; b=h4OKDn5LWm5Rlvnn/551shzku8A+aCHUfpQhiFnZjYNkE8ztwNR+9xhWbdTPsd2Dst ZdyppH46G5gJn3SGMRKl/Qpwg1J87b9uqD+S7eEvkRKaJqc6BdEwUtw6p5akxPTFhTl3 1Z6lNUHLqBPJDGSeU1Yxp4EltNOrKK0jFkudU=
MIME-Version: 1.0
Received: by 10.60.27.6 with SMTP id p6mr5759927oeg.36.1330372555766; Mon, 27 Feb 2012 11:55:55 -0800 (PST)
Received: by 10.182.165.1 with HTTP; Mon, 27 Feb 2012 11:55:55 -0800 (PST)
In-Reply-To: <CAA3wLqV+YeGJH2pFQ80s=PgQC2RsodPMm8qUw3a-VtCzhETkOg@mail.gmail.com>
References: <CAOyVPHQ-iESaD2osxsWguTw1Ru92JYacSsqbD+1rECPzy1eGfQ@mail.gmail.com> <CAA3wLqV+YeGJH2pFQ80s=PgQC2RsodPMm8qUw3a-VtCzhETkOg@mail.gmail.com>
Date: Mon, 27 Feb 2012 11:55:55 -0800
Message-ID: <CAOyVPHTXWPyt5aHL2ehd_upS-DEAcfugVMcUpUm_oO5Ov04rUw@mail.gmail.com>
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Michael Hammer <mphmmr@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8fb1ef189afa3e04b9f77fbe
Cc: sop@ietf.org
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: Mon, 27 Feb 2012 19:55:57 -0000

Hi Michael,

Sounds like we agree on most of the things, though I see the draft
contradicting what we agree on.

1. Do we really see incompatibilities in the API's soar for say IaaS? The
>> AWS API's seem to be the default standard adopted by most providers. From
>> the little I know OpenStack based API's may be the alternative way and
>> companies have built bridging layers to inter-operate between the same.
>>
>
>
> Seem?  May be?  Bridging layers?  I think you are making the case for us.
> :)
> I'm sure Ashish will have more to say about APIs, but I would prefer there
> be a de jure than a default, which in the long run is likely to change at
> the whim of a single company, and perhaps not in a direction that everyone
> would like.
>
What I am saying is we have 2 sets of API's and there are layers used to
bridge the same. I know as services proliferate there could be a
proliferation of distict API's but the same is true of the protocol layer
too.


>
>
>> 2. Instead of the term customer/ user can we instead use the term
>> "consumer". Something like "cloud subscriber" etc could be used. All I am
>> saying is can we use standard terms here.
>>
>
> We can settle on specific terms to use, just so long as we keep the
> distinction between the entity (enterprise?) that provisions the software
> in the cloud, and the user of that software, which could be an employee or
> a user in the general public.  Using a SIP Proxy as a Service, the operator
> of the Proxy provisions it with a CREATE, but the user is the one sending
> INVITEs through it.  Make sense?
>
The NIST document uses terms and we should try to use similar terms as far
as possible.


>
>
>> 3. Is orchestration about creating services (from the cloud providers
>> perspective), or an instance of a service (for a particular user)? I think
>> it is the latter, but doesn't sound so from the definition.
>>
>
> Orchestration is about the on-demand provisioning of the
> compute/storage/network/XaaS in the cloud by the subscriber/customer.  Once
> provisioned, the service can provide services to the intended user.  We are
> trying to be general here.  Need to keep provisioning and operations
> distinct.  "Service" is occurring in levels.
>
Correct but the draft seems to differ.


>
>
>> 4. How is Service Domain Name different from a URI? Aren't they the same?
>>
>
> There is a distinction here between a class of services and running
> instantiations of those services.  Either may be hierarchically named.
>
Hmm.


>
>
>> 5. Is Scenario -1 talking about all providers should provide the same
>> services? I guess not. I think the idea should be the same set of services
>> should be accessible from a cloud provider the same way. It however does
>> not mean that all providers need to provide the same services, as it seems
>> from the requirement.
>>
>
> Agree.  All providers may not provide the same set of services.
> But, if two providers offer the same service, it should not require a new
> customer protocol stack to do so.
> And users should not know that they may be going to one provider or the
> other when using the same service.
>
The requirement seems contradictory to what we agree. Similar for points
below.

Thanks,
Vishwas


>
>
>> 6. It seems for most purposes you are talking about users, but as such a
>> user in an enterprise should be unaware of where the service is coming
>> from. It is the role of the customer to actually provide clear demarcation
>> so a user is unaware of the same. Interoperability with virtual provider is
>> how companies achieve the same.
>>
>
> Agree, and we would like that to be true for multi-provider cases as well.
> I would go further to say that even a user not in the enterprise should be
> unaware where the service is coming from.
>
>
>> 7. I don't think you should mention providers should inter-operate with
>> each other. That is a business decision. I think what you mean here is that
>> providers should have a clear interoperable means should they wish to
>> inter-operate.
>>
>
> Yes.  We want them to be able to inter-operate.  Whether they want to is a
> business decision.
>
>
>> 8. Is it really a requirement for the Orchestration to allow
>> inter-operation for all models? I would have thought we are focusing on the
>> IaaS alone.
>>
>
> We don't see a reason to limit it to just IaaS.  We are looking several
> years down the road here.
>
>
>> 9. S-5 and S-3 sound like similar services to me. How are they different
>> - vendor versus provider?
>>
>
> We were considering cases where multiple companies are involved in
> providing all the capabilities needed.  One involved coordination within an
> administrative domain, while the other involves independent administrative
> domains.  We didn't want to limit this to single company operations.  Large
> global providers may involve many companies.
>
>
>> 10. I think one of the key requirements for SOP, is the ability to work
>> across only a sub-set of the base services and allow for extensible
>> services on top. There could be so many variants of the SaaS or even PaaS I
>> am not sure how you would make every service inter-operate.
>>
>
> There needs to be several layers of standards involved.  This is an onion
> not a single layer orange-peel.
> Here we are trying to provide structure that allows easy extension,
> substitution, and innovation at the more service-specific granular levels.
>
>
>> 11. I think when a VM is moved the biggest issue is the ability to move
>> the storage along with it. All other state is minor and minimal.
>>
>
> I would say the networking is the biggest issue, but that is my bias.  :0
>
>
>> 12. Section 6 seems to be relevent within a cloud too and not just
>> between clouds.
>>
>
> Agree.  Internal to a cloud and from the customer to the cloud are the
> simple cases.
> We emphasize the inter-cloud cases to test the architecture for the worst
> cases.
>
>
>> 13. Doesn't CDN provide the ability to separate address and ability
>> already?
>>
>
> Probably needs more discussion.  I see content as a specific scenario.
>  There you don't care which copy of data is accessed so long as you reach
> it.  In other types of services, a lot more control over who accesses what
> is needed.
>
>
>> 14. For Service discovery. management we wrote something quite a while
>> back
>> https://datatracker.ietf.org/doc/draft-yokota-opsawg-virtnw-service-management/
>> .
>>
>> Will take a look.  Thanks.  Mike
>
>
>> Thanks,
>> Vishwas
>>
>> _______________________________________________
>> sop mailing list
>> sop@ietf.org
>> https://www.ietf.org/mailman/listinfo/sop
>>
>>
>