[sop] SOP Requirements

Vishwas Manral <vishwas.ietf@gmail.com> Mon, 20 February 2012 23:02 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 5F9A921E801A for <sop@ietfa.amsl.com>; Mon, 20 Feb 2012 15:02:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.656
X-Spam-Level:
X-Spam-Status: No, score=-3.656 tagged_above=-999 required=5 tests=[AWL=-0.058, 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 Ov8NOyP3slNa for <sop@ietfa.amsl.com>; Mon, 20 Feb 2012 15:02:38 -0800 (PST)
Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B487521E801B for <sop@ietf.org>; Mon, 20 Feb 2012 15:02:33 -0800 (PST)
Received: by obbwd15 with SMTP id wd15so8964121obb.31 for <sop@ietf.org>; Mon, 20 Feb 2012 15:02:33 -0800 (PST)
Received-SPF: pass (google.com: domain of vishwas.ietf@gmail.com designates 10.182.51.73 as permitted sender) client-ip=10.182.51.73;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of vishwas.ietf@gmail.com designates 10.182.51.73 as permitted sender) smtp.mail=vishwas.ietf@gmail.com; dkim=pass header.i=vishwas.ietf@gmail.com
Received: from mr.google.com ([10.182.51.73]) by 10.182.51.73 with SMTP id i9mr6952587obo.17.1329778953417 (num_hops = 1); Mon, 20 Feb 2012 15:02:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=bIeh1Swurc4HdMeTMiYGCvJvoAd4d6D/FsICFeD5bzI=; b=p/wCKzmaEnlVeJUl8AuA6jrB+nno7XFALo6BcUPjezMB/NC1OpXlWhO+FbyA3j7RVw yfWuqGJY+bSU3LXw3+ic0hXoUgnnHUmCDjvAFriZxtnZOLC8s4lW+j9xdnGw40Wziaf5 FFd9Zi4IxMlJgoXgknIIm5UgBIiwUmdtm9I0g=
MIME-Version: 1.0
Received: by 10.182.51.73 with SMTP id i9mr5951359obo.17.1329778953354; Mon, 20 Feb 2012 15:02:33 -0800 (PST)
Received: by 10.182.165.1 with HTTP; Mon, 20 Feb 2012 15:02:33 -0800 (PST)
Date: Mon, 20 Feb 2012 15:02:33 -0800
Message-ID: <CAOyVPHQ-iESaD2osxsWguTw1Ru92JYacSsqbD+1rECPzy1eGfQ@mail.gmail.com>
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: sop@ietf.org
Content-Type: multipart/alternative; boundary=f46d044470db24fdc504b96d4ab7
Subject: [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, 20 Feb 2012 23:02:39 -0000

Hi authors,

I did a first level pass through the SOP requirements document and my
comments on the same are:

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.
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.
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.
4. How is Service Domain Name different from a URI? Aren't they the same?
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.
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.
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.
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.
9. S-5 and S-3 sound like similar services to me. How are they different -
vendor versus provider?
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.
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.
12. Section 6 seems to be relevent within a cloud too and not just between
clouds.
13. Doesn't CDN provide the ability to separate address and ability already?
14. For Service discovery. management we wrote something quite a while back
https://datatracker.ietf.org/doc/draft-yokota-opsawg-virtnw-service-management/
.

Thanks,
Vishwas