Re: [sop] SOP Requirements

Jamal Hadi Salim <> Tue, 28 February 2012 14:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3977B21F8697 for <>; Tue, 28 Feb 2012 06:23:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.306
X-Spam-Status: No, score=-102.306 tagged_above=-999 required=5 tests=[AWL=0.671, 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 g9qQMyq5oVA9 for <>; Tue, 28 Feb 2012 06:23:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 69E9C21F8699 for <>; Tue, 28 Feb 2012 06:23:20 -0800 (PST)
Received: by bkuw5 with SMTP id w5so1677573bku.31 for <>; Tue, 28 Feb 2012 06:23:19 -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 g20mr6845981bkt.71.1330438999578 (num_hops = 1); Tue, 28 Feb 2012 06:23:19 -0800 (PST)
Received: by with SMTP id g20mr5484371bkt.71.1330438999333; Tue, 28 Feb 2012 06:23:19 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 Feb 2012 06:22:59 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Jamal Hadi Salim <>
Date: Tue, 28 Feb 2012 09:22:59 -0500
Message-ID: <>
To: "Ashish Dalela (adalela)" <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnH0un2han7UXTzwIzyJJ0tS8uL1rgy+ODw7OR8DC2htI5aiacadIydUFBlk5fcb25zJemz
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 14:23:21 -0000

Hi Ashish,

On Tue, Feb 28, 2012 at 8:26 AM, Ashish Dalela (adalela)
<> wrote:

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

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