Re: [sop] SOP Requirements

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

Hi Jamal,

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

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

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:[e-mail]] 
Sent: Tuesday, February 28, 2012 11:18 PM
To: Ashish Dalela (adalela)
Cc: Vishwas Manral; [e-mail]; Michael Hammer
Subject: Re: [sop] SOP Requirements

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.

On Tue, Feb 28, 2012 at 12:05 PM, Ashish Dalela (adalela)
<[e-mail]> wrote:
>
> 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.

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

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

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

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

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)

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

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

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


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