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 >> >> >
- [sop] SOP Requirements Vishwas Manral
- Re: [sop] SOP Requirements Michael Hammer
- Re: [sop] SOP Requirements Vishwas Manral
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Jamal Hadi Salim
- Re: [sop] SOP Requirements Michael Hammer
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Jamal Hadi Salim
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Jamal Hadi Salim
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Jamal Hadi Salim
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Jamal Hadi Salim
- Re: [sop] SOP Requirements Vishwas Manral
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Michael Hammer
- Re: [sop] SOP Requirements Jamal Hadi Salim
- Re: [sop] SOP Requirements Vishwas Manral
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Vishwas Manral
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Vishwas Manral
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Michael Hammer
- Re: [sop] SOP Requirements Vishwas Manral
- Re: [sop] SOP Requirements Ashish Dalela (adalela)
- Re: [sop] SOP Requirements Vishwas Manral