Re: [sop] SOP Requirements

["Ashish Dalela (adalela)" <[e-mail]>]

Hi Vishwas,

 

>> What I am saying is we have 2 sets of API's and there are layers used
to bridge the same. 

 

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

 

>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: [e-mail] [mailto:[e-mail]] On Behalf Of
Vishwas Manral
Sent: Tuesday, February 28, 2012 1:26 AM
To: Michael Hammer
Cc: [e-mail]
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
		[e-mail]
		https://www.ietf.org/mailman/listinfo/sop