Re: [sop] SOP Requirements

[Vishwas Manral <[e-mail]>]

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:* [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-management/
> .
>
> Will take a look.  Thanks.  Mike
>
>
>
> Thanks,
> Vishwas
>
> _______________________________________________
> sop mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sop
>
>
>
>
>