Re: [sop] SOP Requirements

Jamal Hadi Salim <> Tue, 28 February 2012 17:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6097B21F86DB for <>; Tue, 28 Feb 2012 09:48:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.373
X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0tzR2R5yk2YG for <>; Tue, 28 Feb 2012 09:48:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9845A21F86AB for <>; Tue, 28 Feb 2012 09:48:49 -0800 (PST)
Received: by obbeh20 with SMTP id eh20so3514792obb.31 for <>; Tue, 28 Feb 2012 09:48:49 -0800 (PST)
Received-SPF: pass ( domain of designates as permitted sender) client-ip=;
Authentication-Results:; spf=pass ( domain of designates as permitted sender)
Received: from ([]) by with SMTP id x15mr7009872obh.76.1330451329321 (num_hops = 1); Tue, 28 Feb 2012 09:48:49 -0800 (PST)
Received: by with SMTP id x15mr6214597obh.76.1330451329220; Tue, 28 Feb 2012 09:48:49 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 Feb 2012 09:48:29 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Jamal Hadi Salim <>
Date: Tue, 28 Feb 2012 12:48:29 -0500
Message-ID: <>
To: "Ashish Dalela (adalela)" <>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQlFRr4zaLKsUCGNTCvhxwtK8reV9kPf7pLzL6WSenW8zYNnorqR7x2s3+30YOV+FJhXggER
Cc: Vishwas Manral <>,, Michael Hammer <>
Subject: Re: [sop] SOP Requirements
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Service Orchestration and Desciption for Cloud Services <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Feb 2012 17:48:50 -0000

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