Re: [sop] SOP Requirements

[Jamal Hadi Salim <[e-mail]>]

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