Re: [sop] SOP Requirements

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-----
From: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of
Jamal Hadi Salim
Sent: Wednesday, February 29, 2012 7:54 PM
To: Ashish Dalela (adalela)
Cc: Vishwas Manral; sop@ietf.org; Michael Hammer
Subject: Re: [sop] SOP Requirements

Hi Ashish,

On Tue, Feb 28, 2012 at 9:08 PM, Ashish Dalela (adalela)
<adalela@cisco.com> wrote:
> Hi Jamal,
>
> 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.

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

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

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

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?

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

ok

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

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.

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

Sure.

> Hope I answered you question.

it does with a small caveat above.

cheers,
jamal
_______________________________________________
sop mailing list
sop@ietf.org
https://www.ietf.org/mailman/listinfo/sop