Re: [sop] SOP Requirements

Michael Hammer <mphmmr@gmail.com> Tue, 28 February 2012 15:31 UTC

Return-Path: <mphmmr@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 2197B21F864D for <sop@ietfa.amsl.com>; Tue, 28 Feb 2012 07:31:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.462
X-Spam-Level:
X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.136, 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 9Ti-wFeQ3TV5 for <sop@ietfa.amsl.com>; Tue, 28 Feb 2012 07:31:51 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C27E821F8647 for <sop@ietf.org>; Tue, 28 Feb 2012 07:31:50 -0800 (PST)
Received: by lagj5 with SMTP id j5so3920331lag.31 for <sop@ietf.org>; Tue, 28 Feb 2012 07:31:49 -0800 (PST)
Received-SPF: pass (google.com: domain of mphmmr@gmail.com designates 10.112.23.1 as permitted sender) client-ip=10.112.23.1;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of mphmmr@gmail.com designates 10.112.23.1 as permitted sender) smtp.mail=mphmmr@gmail.com; dkim=pass header.i=mphmmr@gmail.com
Received: from mr.google.com ([10.112.23.1]) by 10.112.23.1 with SMTP id i1mr1635658lbf.21.1330443109854 (num_hops = 1); Tue, 28 Feb 2012 07:31:49 -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=DpKSZ4e7MCbPW/8JVQ+7iH/+ccpNYYPIq9YpGS7NW+Q=; b=mSrzub9NH4PI7hK3Jg7tTzIn55zJoQLddS9VtZBT8wSPBNBlBweJEsGfb1Xag7oIYX 0HaXPSZvJsmRGiDaaHxoa8ofJ8I5LhXDkKUsuvQ5ajojDuuzkHZV+pZwCH7EraOQL7CR Ppy4VPO0Xn5xnlebFLJOnd405lMNjg7RMkcuQ=
MIME-Version: 1.0
Received: by 10.112.23.1 with SMTP id i1mr1327994lbf.21.1330443109733; Tue, 28 Feb 2012 07:31:49 -0800 (PST)
Received: by 10.112.104.70 with HTTP; Tue, 28 Feb 2012 07:31:49 -0800 (PST)
In-Reply-To: <CAOyVPHTXWPyt5aHL2ehd_upS-DEAcfugVMcUpUm_oO5Ov04rUw@mail.gmail.com>
References: <CAOyVPHQ-iESaD2osxsWguTw1Ru92JYacSsqbD+1rECPzy1eGfQ@mail.gmail.com> <CAA3wLqV+YeGJH2pFQ80s=PgQC2RsodPMm8qUw3a-VtCzhETkOg@mail.gmail.com> <CAOyVPHTXWPyt5aHL2ehd_upS-DEAcfugVMcUpUm_oO5Ov04rUw@mail.gmail.com>
Date: Tue, 28 Feb 2012 10:31:49 -0500
Message-ID: <CAA3wLqXy_yeh7DP7mmBUYZd_qzYO0y+AsmTTnmUKcswbQC_6rw@mail.gmail.com>
From: Michael Hammer <mphmmr@gmail.com>
To: Vishwas Manral <vishwas.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=90e6ba308bc8f315ff04ba07ecd3
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: Tue, 28 Feb 2012 15:31:53 -0000

Vishwas,

I think Ashish responded to most of your comments.  Quick response to
others below:

We could align with the NIST document terms if they coincide.  Could you
point to which document you are referring so I can verify we and they are
defining the same thing.  I was using terms very common in the industry and
would be surprised if NIST is not also.

Provisioning an XaaS versus using an XaaS:  As with all documents it takes
many revisions to get the words to clearly say what we mean.  If you would
point us to the specific text in a 1-1 email, we could work to adjust the
text in the next version.

"users should not know that they may be going to one provider or the other
when using the same service"
Let me elaborate a bit more on that.  I did mean to say "user" and not
"subscriber":
Imagine the UCaaS case.  The customer/subscriber is the operator of the SIP
Proxy or Customer X.  They know they are using CSP Y to host that proxy.
 Once the service is provisioned in the cloud, they could be open for
business to Users A, B, C who get their UC service from X.  A knows X, but
has no clue that their SIP requests may end up at Y.

Second there could be Cloud ecosystem:  Customer X goes to CSP Y who
outsources part of the service to CSP Z.  So, X knows he is going to Y, but
Z may be invisible to him.

Make sense?

Mike


On Mon, Feb 27, 2012 at 2:55 PM, Vishwas Manral <vishwas.ietf@gmail.com>wrote:

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