Subject: [sop] SOP Requirements

From: Vishwas Manral <[email-masked]>
Date: Mon, 20 Feb 2012 15:02:33 -0800

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

---

From: Michael Hammer <[email-masked]>
Date: Tue, 21 Feb 2012 00:46:59 -0500

Vishwas,

Thanks for reviewing.  Inline...

Mike

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

> 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?

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

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

> not mean that all providers need to provide the same services, as it seems

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.

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

> providers should have a clear interoperable means should they wish to

Yes.  We want them to be able to inter-operate.  Whether they want to is a
business decision.

> inter-operation for all models? I would have thought we are focusing on the

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 -

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.

> 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

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

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.

> Will take a look.  Thanks.  Mike

> Thanks,
> Vishwas
>
> _______________________________________________
> sop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sop
>
>

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 27 Feb 2012 11:55:55 -0800

Hi Michael,

Sounds like we agree on most of the things, though I see the draft
contradicting what we agree on.

> the whim of a single company, and perhaps not in a direction that everyone
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.

> INVITEs through it.  Make sense?
The NIST document uses terms and we should try to use similar terms as far
as possible.

> distinct.  "Service" is occurring in levels.
Correct but the draft seems to differ.

> instantiations of those services.  Either may be hierarchically named.
Hmm.

> other when using the same service.
The requirement seems contradictory to what we agree. Similar for points
below.

Thanks,
Vishwas

>> 9. S-5 and S-3 sound like similar services to me. How are they different
>> - vendor versus provider?
>>
>
>> 12. Section 6 seems to be relevent within a cloud too and not just
>> between clouds.
>>
>

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Tue, 28 Feb 2012 18:56:10 +0530

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Vishwas Manral
Sent: Tuesday, February 28, 2012 1:26 AM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [sop] SOP Requirements

Hi Michael,

		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.

	 

		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.

	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.

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

		Thanks,
		Vishwas

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 28 Feb 2012 09:22:59 -0500

Hi Ashish,

On Tue, Feb 28, 2012 at 8:26 AM, Ashish Dalela (adalela)
<[email-masked]> wrote:

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

This an _extremely important detail_  that is often missed by folks
pushing OF for
example as a service creation protocol (or even as a control-datapath protocol).

BTW: Have you looked at ForCES? I didnt see it mentioned in the drafts. To
summarize:
The initial goals were to separate a datapath vs a controller. There are very
few verbs and the entity being controlled/configured can be formally modeled
using an XML language to define logical functional blocks. The blocks (which
could represent services) could be instantiated and hierachy of the different
components/attributes is inherently built.
Although the definitions are in XML, the protocol is binary for
efficiency reasons.
ForCES has discovery, capability discovery, advertisements, transactions, etc.
The underlying transport could be customized for specific problem domains
(I suspect service creation would have slightly different needs than a router's
control/line card transport desires).

cheers,
jamal

---

From: Michael Hammer <[email-masked]>
Date: Tue, 28 Feb 2012 10:31:49 -0500

Vishwas,

I think Ashish responded to most of your comments.  Quick response to
others below:

We could align with the NIST document terms if they coincide.  Could you
point to which document you are referring so I can verify we and they are
defining the same thing.  I was using terms very common in the industry and
would be surprised if NIST is not also.

Provisioning an XaaS versus using an XaaS:  As with all documents it takes
many revisions to get the words to clearly say what we mean.  If you would
point us to the specific text in a 1-1 email, we could work to adjust the
text in the next version.

"users should not know that they may be going to one provider or the other
when using the same service"
Let me elaborate a bit more on that.  I did mean to say "user" and not
"subscriber":
Imagine the UCaaS case.  The customer/subscriber is the operator of the SIP
Proxy or Customer X.  They know they are using CSP Y to host that proxy.
 Once the service is provisioned in the cloud, they could be open for
business to Users A, B, C who get their UC service from X.  A knows X, but
has no clue that their SIP requests may end up at Y.

Second there could be Cloud ecosystem:  Customer X goes to CSP Y who
outsources part of the service to CSP Z.  So, X knows he is going to Y, but
Z may be invisible to him.

Make sense?

Mike

On Mon, Feb 27, 2012 at 2:55 PM, Vishwas Manral <[email-masked]>wrote:

>> 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.
>>
>> I would go further to say that even a user not in the enterprise should
>> be unaware where the service is coming from.
>>
>>
>> Yes.  We want them to be able to inter-operate.  Whether they want to is
>> a business decision.
>>
>>

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Tue, 28 Feb 2012 22:35:33 +0530

Hi Jamal,

The intent of ForCES is decomposition of a network element, and the goal
of SOP is how to integrate network planes into a larger useful system. 

When we decompose, the intent is that the decomposed pieces can be built
by anyone. That means a vendor is no longer a NE vendor but a component
vendor. It plays out differently. E.g. if we look outside network, can
we say that ForCES type of protocol could be used to separate the
storage controller from the disk? Technically that is feasible, but the
challenges in getting it done are high.

On the other hand, when we are trying to integrate already disparate
systems, we are creating a new level of value. It allows every vendor to
control the value in their product, but opening up a management
interface - similar to how devices have been managed through MIBs. 

You don't lose anything by supporting a standard MIB, but there is a
value in the network management system if it can manage many diverse
devices (beyond the element manager). The goal of SOP is to meet that
value point, which is addressing some real problems today.  

The complexity of the systems is becoming high, to the point that
configuring / managing / monitoring these systems is becoming harder and
much more expensive. The complexity is specially high for cloud. We need
an approach that reduces the cost of provisioning and monitoring these
islands and build a level of intelligence that sees these islands as
part of a single system. 

SOP is basically service independent protocol. In that respect, we can
compare it to SNMP, SIP, HTTP, SMTP, etc. It has the verbs and
constructs we need for virtual services. But we don't want to bundle
this with service-dependent things - counterparts of MIBs, Codecs, HTML
or MIME in the earlier cases. If we look at this historically, HTML was
done in W3C and Codecs in various places including ITU. Independent
evolution of these things just makes it easier and more manageable. The
goal is to separate service-independent and service-dependent pieces and
do them separately.

Many service-dependent pieces already exist - e.g. OVF for virtual
machines done by DMTF or the effort that SNIA is putting to define
virtual storage. My view is that cloud standards will not and cannot
happen in one place. We need the right level of decoupling to allow
different SDOs to do their part, and be able to integrate that. SOP is
just a service-independent vehicle to carry service-dependent
information.

Thanks, Ashish

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jamal Hadi Salim
Sent: Tuesday, February 28, 2012 7:53 PM
To: Ashish Dalela (adalela)
Cc: Vishwas Manral; [email-masked]; Michael Hammer
Subject: Re: [sop] SOP Requirements

Hi Ashish,

> individually. Then permutations and combination of these parameters
create
> hundreds of more APIs. That's just API bloat. And if you have to
semantic
> From an operational standpoint, every new API introduction requires
software

This an _extremely important detail_  that is often missed by folks
pushing OF for
example as a service creation protocol (or even as a control-datapath
protocol).

BTW: Have you looked at ForCES? I didnt see it mentioned in the drafts.
To
summarize:
The initial goals were to separate a datapath vs a controller. There are
very
few verbs and the entity being controlled/configured can be formally
modeled
using an XML language to define logical functional blocks. The blocks
(which
could represent services) could be instantiated and hierachy of the
different
components/attributes is inherently built.
Although the definitions are in XML, the protocol is binary for
efficiency reasons.
ForCES has discovery, capability discovery, advertisements,
transactions, etc.
The underlying transport could be customized for specific problem
domains
(I suspect service creation would have slightly different needs than a
router's
control/line card transport desires).

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 28 Feb 2012 12:48:29 -0500

Hi Ashish,

You are probably more familiar with ForCES than i read in between
the lines in your response, but i just wanted to clarify to be sure.

> of SOP is how to integrate network planes into a larger useful system.

If you look at ForCES from originally-intended-use, you are right.  That is
not what i meant since the architecture is more generic.
[Example we use it to configure/manage many non-network element specific
attributes across disparate NEs.]

> challenges in getting it done are high.

It shouldnt be hard: You would need to describe the disk attributes.
The protocol _never_ has to change.

> interface - similar to how devices have been managed through MIBs.

ForCES allows you to do that. The XML definitions are equivalent to MIBS.
The general semantics of operation for forces are unix like:
command [path] [args]
path and args are specific on the object instance being referenced
and command is part of the few verbs defined (SET/GET/DEL etc)

> constructs we need for virtual services.

The only reason i brought up ForCES is because the verbs you need
look similar.

>But we don't want to bundle

So this is the part i may be missing, please help me understand.
You want a protocol that is capable of working with all above definitions
of a specific service?
i.e , if i defined a specific object blah using OVF definition or DMTF
definition or a MIB etc, that your protocol will be able to interop between
two service providers with two different languages used to define that
object?

cheers,
jamal

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Wed, 29 Feb 2012 07:38:02 +0530

Hi Jamal,

We will look at ForCES again since you have mentioned similarities.

>> two service providers with two different languages used to define
that

The short answer is "no", and a long answer as follows:
	
Each device advertizes its capabilities - which means advertizes a set
of "service names". In this case, the "service name" can be
iaas.compute.virtual.ovf, which can stand for OVF capable servers.
Another server can advertize a "service name" iaas.compute.virtual.xyz,
which can stand for XYZ standard for VMs. When a request for VM arrives,
it carries the "service name" aside from the service parameters. The
orchestrator maps the target device to the request based on this service
name, and a whole bunch of other policies (location, bandwidth,
security, ...).

Ideally, we should not have competing standards for the same service
name - e.g. virtual machines, but if there are, then this is how you
would do it.

The goal is not to translate between OVF and XYZ, because that is so
buggy and brittle (precisely the problem with mapping APIs). We map OVF
requests to OVF capable servers and XYZ to XYZ capable servers. SOP
Proxy acts to do the routing and policy application of requests to
targets. 

The "service names" are hierarchical, which means that the child domain
inherits properties of the parent domain (like objects). That allows you
to incrementally extend domains by adding new attributes or features. A
device, may, for example, advertize
iaas.compute.virtual.ovf.proprietary-extensions, and a user can request
a VM based on OVF and/or proprietary-extensions.

This allows, a provider to support a new type of service with "value
additions", while remaining compatible with standard. No protocol
changes or changes to infrastructure / software are needed to achieve
these things. 

The Proxy may be configured with defaults for this service, or
configured to reject requests that don't conform to what the provider
wants to support or with rules on how a proprietary / standard service
interacts with other services. So, the Proxy becomes an important point
at which to enforce variety of controls. The Proxy can be at customer
and provider and service boundaries. So, there are many points where
different rules can be applied.
	
Hope I answered you question.

Thanks, Ashish

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
Sent: Tuesday, February 28, 2012 11:18 PM
To: Ashish Dalela (adalela)
Cc: Vishwas Manral; [email-masked]; Michael Hammer
Subject: Re: [sop] SOP Requirements

Hi Ashish,

> of SOP is how to integrate network planes into a larger useful system.

If you look at ForCES from originally-intended-use, you are right.  That
is
not what i meant since the architecture is more generic.
[Example we use it to configure/manage many non-network element specific
attributes across disparate NEs.]

> interface - similar to how devices have been managed through MIBs.

ForCES allows you to do that. The XML definitions are equivalent to
MIBS.
The general semantics of operation for forces are unix like:
command [path] [args]
path and args are specific on the object instance being referenced
and command is part of the few verbs defined (SET/GET/DEL etc)

So this is the part i may be missing, please help me understand.
You want a protocol that is capable of working with all above
definitions
of a specific service?
i.e , if i defined a specific object blah using OVF definition or DMTF
definition or a MIB etc, that your protocol will be able to interop
between
two service providers with two different languages used to define that
object?

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 29 Feb 2012 09:24:29 -0500

Hi Ashish,

> We will look at ForCES again since you have mentioned similarities.

If you want to take a shortcut and get quick answers, feel free
to email me or post on the ForCES list.

> name - e.g. virtual machines, but if there are, then this is how you

Yes, makes sense.
[One thing thats not clear is how discovery of this services happens.
In the ForCES
approach, these services would be akin to LFBs. The node that is providing these
LFBs (analogous to an FE if you are trying to do an NE) would connect
to the controller
(aka CE) and tell it what it can support and what capacities of each service
(aka LFB) it can handle etc.]

> Proxy acts to do the routing and policy application of requests to

When you use the term "proxy" i see "Translation" or at least the orchestrator
being intelligent enough to take  iaas.compute.virtual.ovf.instance1.foo
and understand it to be the same thing as  iaas.compute.virtual.xyz.bar
I think thats not what you want to achieve, correct? You want the request
to be explicit for  iaas.compute.virtual.ovf.instance1.foo for an OVF
knowledgeable app and  iaas.compute.virtual.xyz.bar for XYZ standard
app?

> a VM based on OVF and/or proprietary-extensions.

ok

> changes or changes to infrastructure / software are needed to achieve

Yes on the "no protocol changes or infrastructure/software". This is where
OF fails miserably.
While we are trying to standardize, what you are talking about is reality.
Unfortunately, it reduces the standardized interface to be the lowest common
denominator.

> different rules can be applied.

Sure.

> Hope I answered you question.

it does with a small caveat above.

cheers,
jamal

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Wed, 29 Feb 2012 20:35:04 +0530

Hi Jamal,

I think there may be some confusion here.

There are two types of names we deal with - "types" and "instances". A
"car" is a type and car with a specific number plate is an "instance".
These are two separate things. Likewise, iaas.compute.virtual.ovf is
"type", and abc.provider.com is an instance of a server that is OVF
capable. We won't merge these two names. A packet is generally routed in
IP world based on "instance" addresses. In SOP, a packet is routed based
on "types".

That means that a user requests a "type" and the provider routes the
request to the "instance" based on policy constraints. 

The proxy is *not* a translator. In SIP, the term Proxy is used, because
the Proxy executes a task on behalf of the requestor. The Proxy
"proxies" on behalf of the requestor. There is no translation involved.
Likewise, terms like HTTP proxy, mail proxy etc are used. These are not
translators.

>> Unfortunately, it reduces the standardized interface to be the lowest
common denominator.

I think people have gotten really confused with OF way of thinking about
a standard. We need to take a step back and see how we have built
standards in the past.
	
Take example of a MIB and SNMP. SNMP is standard for all MIBs. That
doesn't preclude thousands of MIBs to be created. Likewise SOP is like
SNMP. Service descriptions are like MIBs. Standard SOP doesn't preclude
thousands of service types. When you create a new MIB, you just load the
MIB in the network manager and start managing. You don't have to upgrade
the manager. That means a network manager can manage innumerable types
of services, without a software upgrade. It is made possible by
separation between SNMP and the MIB. 

We want to create the same separation between SOP and service-dependent
descriptions like OVF ..

Makes sense?

Thanks, Ashish

-----Original Message-----
Sent: Wednesday, February 29, 2012 7:54 PM

Hi Ashish,

Yes, makes sense.
[One thing thats not clear is how discovery of this services happens.
In the ForCES
approach, these services would be akin to LFBs. The node that is
providing these
LFBs (analogous to an FE if you are trying to do an NE) would connect
to the controller
(aka CE) and tell it what it can support and what capacities of each
service
(aka LFB) it can handle etc.]

> Proxy acts to do the routing and policy application of requests to

When you use the term "proxy" i see "Translation" or at least the
orchestrator
being intelligent enough to take  iaas.compute.virtual.ovf.instance1.foo
and understand it to be the same thing as  iaas.compute.virtual.xyz.bar
I think thats not what you want to achieve, correct? You want the
request
to be explicit for  iaas.compute.virtual.ovf.instance1.foo for an OVF
knowledgeable app and  iaas.compute.virtual.xyz.bar for XYZ standard
app?

ok

> changes or changes to infrastructure / software are needed to achieve

Yes on the "no protocol changes or infrastructure/software". This is
where
OF fails miserably.
While we are trying to standardize, what you are talking about is
reality.
Unfortunately, it reduces the standardized interface to be the lowest
common
denominator.

Sure.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 29 Feb 2012 11:17:59 -0500

Hi Ashish,

On Wed, Feb 29, 2012 at 10:05 AM, Ashish Dalela (adalela)
<[email-masked]> wrote:
> These are two separate things.

Sorry - I was using ForCES speak.
A node like abc.provider.com can have a car - the only time
you can use it is if you instantiate it (to use your analogy,
give it a number plate). So the _instance_ in that view is not
abc.provider.com rather explicit abc.provider.com/cars/plateXXXX.

>Likewise, iaas.compute.virtual.ovf is

Ok - got it; but still unclear.
So you essentially dont need to have the user to be aware
of the instance? So if i wanted >1 instances how do i distinguish
between them? I am assuming at some point after creation one would
need refer to a specific instance (and instance IDs of some form play a role).

> Likewise, terms like HTTP proxy, mail proxy etc are used. These are not

That definition may need to well described.
There are a lot of "transparent" email/HTTP proxies that translate at
least at the protocol packet level.

> a standard. We need to take a step back and see how we have built

I am not preaching OF at all. While it serves a purpose and has
brought excitement
to the SDN aspect, sometimes i look  at OF and think of the Emperors
New clothes.

> We want to create the same separation between SOP and service-dependent

Indeed (and in total agreement).

cheers,
jamal

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Wed, 29 Feb 2012 22:14:45 +0530

Hi Jamal,

>> abc.provider.com rather explicit abc.provider.com/cars/plateXXXX

I understand the ForCES background - the idea is aligned with ATCA and
the notion that any node can be given any "personality". That may not be
true in general where certain types of devices are "capable" of doing
certain things. E.g. you can't trivially make a switch a firewall or a
load-balancer. You certainly can't make a network device a storage
device or a server trivially. It is true for x86 servers maybe, but as
you get a wide variety of hardware capabilities or move up the software
stack into a middleware or a specific type of application, the
generalized view disappears. Until we get to a point where a common type
of hardware can enact any type of functionality that view is limited.

>> need refer to a specific instance (and instance IDs of some form play
a role).

The reality with virtualized services is that the instance doesn't
*exist* when you ask for it. E.g. when I request a VM, the VM that I
will be allocated doesn't exist. It will be created on-demand. So, there
is no way I can request the specific "instance". I have to only request
a "type". The type has to be mapped to a capability source, and then
converted into an instance. Once you have an instance, sure, you refer
to it both by type and instance.

>> least at the protocol packet level.

Sure, that can be clarified. I thought the definition was clear in the
drafts, but if not, that can be clarified.

Thanks, Ashish

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
Sent: Wednesday, February 29, 2012 9:48 PM
To: Ashish Dalela (adalela)
Cc: Vishwas Manral; [email-masked]; Michael Hammer
Subject: Re: [sop] SOP Requirements

Hi Ashish,

need refer to a specific instance (and instance IDs of some form play a
role).

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 29 Feb 2012 12:09:17 -0500

Hi Ashish,

> of hardware can enact any type of functionality that view is limited.

I dont need to know a node's "personality" - if it exists, it tells me.
The creation or booting of the node is considered a setup process.
[Once create/booted - the node becomes part of my resource pool.
I may not use it at all if i choose not to.]
In your case, you may consider the creation aspect part of the
process.

> to it both by type and instance.

Then no conflict there.
I presume theres an operation to say "create abc.vm" which
returns me some ID. And going forward i can refer to that
abc.vm.someID and be able to reference attribute
abc.vm.someID.foo, no?

> drafts, but if not, that can be clarified.

I will read the drafts closely and comment. Is the requirements one the best
one to focus one (that is the one i have looked at).

cheers,
jamal

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 29 Feb 2012 09:15:06 -0800

Hi Ashish,

> semantic incompatibilities, it becomes even harder to interoperate (syntax
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

> software upgrades to the controllers. That eventually hinders the rate of
> service creation.
>
>
>
> 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
> transactions, etc. But, we need to keep in mind that API proliferation is
> inevitable as services proliferate. Protocol proliferation is not
> 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.
>
>
>
> 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.
>
>
>
> service and they ought to know in advance who are they going to receive a
> monthly check from.
>
>
>
> Thanks, Ashish
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Vishwas
> Manral
> *Sent:* Tuesday, February 28, 2012 1:26 AM
> *To:* Michael Hammer
> *Cc:* [email-masked]
> *Subject:* Re: [sop] SOP Requirements
>
>
>
> Hi Michael,
>

---

From: "Ashish Dalela (adalela)" <[email-masked]>
Date: Thu, 1 Mar 2012 08:21:16 +0530

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:[email-masked]] 
Sent: Wednesday, February 29, 2012 10:45 PM
To: Ashish Dalela (adalela)
Cc: Michael Hammer; [email-masked]
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.

	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.

	>> 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: [email-masked] [mailto:[email-masked]] On
Behalf Of Vishwas Manral
	Sent: Tuesday, February 28, 2012 1:26 AM
	To: Michael Hammer
	Cc: [email-masked]
	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.

		 

			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.

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

			Thanks,
			Vishwas