Re: [sop] SOP Requirements

"Ashish Dalela (adalela)" <adalela@cisco.com> Thu, 01 March 2012 02:51 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 0494421E807B for <sop@ietfa.amsl.com>; Wed, 29 Feb 2012 18:51:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.596
X-Spam-Level:
X-Spam-Status: No, score=-7.596 tagged_above=-999 required=5 tests=[AWL=3.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 9IHj7kE9csEP for <sop@ietfa.amsl.com>; Wed, 29 Feb 2012 18:51:30 -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 2E47421E8014 for <sop@ietf.org>; Wed, 29 Feb 2012 18:51:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=53600; q=dns/txt; s=iport; t=1330570281; x=1331779881; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=UQjycJAJDkUZrlw5RRX+cmgw8sf9LLHFnri0DUR5sYw=; b=QxMewwJ9cqCEk142lNZztEA5qAo7ajVZauce+Q0Ljs6KcpEKHd5RIS3F jADy0ayLiPyDRNvUL+yKRA2RN51oJYT1xhor40sWHTVJJXLM1ajz/Hcx6 /Mhr5DQcxZc2n9pX8y9iFoTQIxxS3eAaXF7DC8APXTGU1V5DCZi/75L3b I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqAEABvjTk9Io8UY/2dsb2JhbABDglGyPoF6AQEBAwEBAQEPAQcCEQM+CxACAQgRAQMBAQsGEAEGAQYBIAYfAwYIAQEECwgIFwOHYgULoFQBlyAEiRdnCQaCbgEDAgEBAQECAgECBgMBAQEEAQEBAgIBBQFFhG4BFQoNAREDMwEYBgEYAYJJYwSITYhCj0qHX4FNAQY
X-IronPort-AV: E=Sophos;i="4.73,507,1325462400"; d="scan'208,217";a="6700688"
Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 01 Mar 2012 02:51:18 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q212pI4M026602; Thu, 1 Mar 2012 02:51:18 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); Thu, 1 Mar 2012 08:21:18 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF756.2CF04429"
Date: Thu, 1 Mar 2012 08:21:16 +0530
Message-ID: <618BE8B40039924EB9AED233D4A09C51031BC437@XMB-BGL-416.cisco.com>
In-Reply-To: <CAOyVPHTDaVXJTskXMxQ0MBr+4MbC1St6+YOhOpv6MUww+QbH8w@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sop] SOP Requirements
Thread-Index: Acz3BbVV+ZhyluLGRDqEZd9k/91zOQARiz1Q
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> <CAOyVPHTDaVXJTskXMxQ0MBr+4MbC1St6+YOhOpv6MUww+QbH8w@mail.gmail.com>
From: "Ashish Dalela (adalela)" <adalela@cisco.com>
To: "Vishwas Manral" <vishwas.ietf@gmail.com>
X-OriginalArrivalTime: 01 Mar 2012 02:51:18.0421 (UTC) FILETIME=[2D2F1450:01CCF756]
Cc: 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: Thu, 01 Mar 2012 02:51:38 -0000

Hi Vishwas,

 

What everyone calls API today uses a protocol - HTTP. APIs survive on
the interoperability provided by that protocol, and I don't think anyone
can get away from that. The real question is - what is the right
protocol on top of which to build APIs? That's the question SOP is
raising. Once you do that, then we can talk of one or many APIs.

 

Limitations of using HTTP as the underlying protocol for any API have
been described in detail in the requirements draft. I would like to hear
your comments on that. That section describes what APIs can't do. Some
of the limitations are because API is always unicast, and there are many
things for which you need a manycast and broadcast. Other limitations
because APIs are synchronous and you need to be asynchronous in some
cases. Yet other issues because APIs are single complete transaction,
but some transactions will spread over multiple such APIs. 

 

The total amount of information in a message is unchanged whether you
put it inside a protocol header or the content body. Putting some things
in the protocol header saves you having to reinvent them in the content
for every type of service. In other words, a protocol saves you from
increasing information across various services. As an example in SIP, we
put From and To in the protocol header. Could we not put it in the body?
Sure we could. In that case we would be repeating that for voice and
video and chat content. 

 

To your point, you can have a single API for doing anything. As the
service evolves and complexity grows, the number of parameters to that
API increases. And yes, you can make that backward compatible in terms
of implementation. But, nobody does that - especially when the interface
is end-user facing. If this was an acceptable design, then we would not
have object inheritance and there won't be hundreds of APIs being opened
up by cloud providers today. You might want to suggest one API to Amazon
or other cloud providers. 

 

A practical operational issue with APIs is that users don't understand
all the details. A user understands a server memory and CPU, but don't
understand VLAN and LUN, and zillions of other complicated things.
Exposing them through APIs is useless because they can't use it. Why
would a user buy an expensive TV when they can't use most of the
features, because the remote is too complicated? The need is to reduce
complexity through automation, not expose it all to the user via APIs.
In other words, you need a more sophisticated policy engine not a
sophisticated API system. 

 

For any problem there is a cure and there is a prevention. Building API
bridges is a cure to diverse APIs, it's not a prevention. Once you
recognize a problem, you build a short-term cure and a long-term
prevention (at least ideally). Then, a single API is neither a cure nor
prevention; its side-effects are so severe that we might be living with
the original problem as well. 

 

APIs have always existed and will continue to exist. The goal is to
interoperate diverse APIs without a translation bridge. That happens all
the time with network protocols, when one vendor's APIs works with
another vendor's APIs without a translation bridge. I think not having a
bridge is always better than having a bridge. Agree?

 

Thanks, Ashish

 

 

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] 
Sent: Wednesday, February 29, 2012 10:45 PM
To: Ashish Dalela (adalela)
Cc: Michael Hammer; sop@ietf.org
Subject: Re: [sop] SOP Requirements

 

Hi Ashish,

	 

	As the number of services increase or the complexity in a given
service grows, this becomes very hard. Assume there is a service with N
tunable parameters. You need at least N APIs that modify these
parameters individually. Then permutations and combination of these
parameters create hundreds of more APIs. That's just API bloat. And if
you have to interoperate multiple instances of these APIs through
bridges, it's just inviting more complexity. Another limitation is that
when APIs have semantic incompatibilities, it becomes even harder to
interoperate (syntax incompatibility is easier).

Not true at all.For N parameters you can have one API. The API can be
made forward compatible by using simple things like unions. Having
worked in a software company, where we have to extend our software
without breaking previous API's I am well aware of the fact.

If you give an exact example I can try to help you see how we can make
an extensible API for the same.

Thanks,
Vishwas 

	 

	From an operational standpoint, every new API introduction
requires software upgrades to the controllers. That eventually hinders
the rate of service creation.

	 

	>> I know as services proliferate there could be a proliferation
of distict API's but the same is true of the protocol layer too.
	 

	That won't happen if we separate service-independent and
service-dependent pieces. An example of that is SNMP. SNMP is
device/service independent. MIB defines the specific service/device. If
you have a standard protocol to manage a device, then you just have to
add a new MIB to start managing it. You don't need to upgrade all the
intermediate systems - hardware or software. 

	 

	BTW, I'm not advocating SNMP here because SNMP has many
shortcomings in terms of network discovery, capability discovery,
advertisements, transactions, etc. But, we need to keep in mind that API
proliferation is inevitable as services proliferate. Protocol
proliferation is not inevitable. Similar separation has been done in the
past in SIP/SDP, HTTP/HTML, SMTP/MIME. That separation allows anyone to
send any content in email to anyone. Or download any web-page, or have
any type of codec (voice or video) use the same protocol.

	 

	If you compare the success and widespread use of above mentioned
protocols the value of separation between service-independent and
service-dependent seems pretty convincing.

	 

	>> Correct but the draft seems to differ.

	 

	Service and instance of service are (and can be) interchangeably
used. Is bandwidth a service or an instance of a service? I think this
is more semantics.

	 

	>> The requirement seems contradictory to what we agree. Similar
for points below.

	 

	The requirement is really that services are portable across
providers. I think it is fair to say (as you also agree) that a user
must know where they are going for a service. After all, they will have
to pay for the service and they ought to know in advance who are they
going to receive a monthly check from. 

	 

	Thanks, Ashish

	 

	 

	From: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On
Behalf Of Vishwas Manral
	Sent: Tuesday, February 28, 2012 1:26 AM
	To: Michael Hammer
	Cc: sop@ietf.org
	Subject: Re: [sop] SOP Requirements

	 

	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-mana
gement/.

		Will take a look.  Thanks.  Mike

		 

			Thanks,
			Vishwas
			
			_______________________________________________
			sop mailing list
			sop@ietf.org
			https://www.ietf.org/mailman/listinfo/sop