Re: [sop] SOP Requirements

"Ashish Dalela (adalela)" <adalela@cisco.com> Tue, 28 February 2012 17:05 UTC

Return-Path: <adalela@cisco.com>
X-Original-To: sop@ietfa.amsl.com
Delivered-To: sop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EC621F8643 for <sop@ietfa.amsl.com>; Tue, 28 Feb 2012 09:05:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.394
X-Spam-Level:
X-Spam-Status: No, score=-7.394 tagged_above=-999 required=5 tests=[AWL=3.205, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U42BZFEwiJN3 for <sop@ietfa.amsl.com>; Tue, 28 Feb 2012 09:05:38 -0800 (PST)
Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC9921F8566 for <sop@ietf.org>; Tue, 28 Feb 2012 09:05:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=4871; q=dns/txt; s=iport; t=1330448737; x=1331658337; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Avk2xQWQ9oaD/GopnBUswVCmhTMnoF6uwI3liDy6lfc=; b=GMfLtfU2qGqvBs6k62qmd4IDq4/0FNnIiz5nRhXJ9UOMoovjyc6zwKJs ZSy+Mj2UD3zu238Mc+7FacCjd6aM78gSzXOa2vlsERDX8MUgwEEw8BZ/2 VIzrKyP2laiyiJ4AzF3snTMIA7VRi4WboJtCsDKVD/KFoiee3lju2xxgi 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap8EAFIITU9Io8UY/2dsb2JhbABCtFmBdwEBAQMBAQEBDwEdCjQLDAQCAQgRBAEBCwYXAQYBJh8JCAEBBAsICBqHYQULmkEBnxEEiggGgnIDAQECBAMFAQQGAgIJAwJAFQuFDQMzAQ4KBgUVgkljBIhNn2qBTQE
X-IronPort-AV: E=Sophos;i="4.73,497,1325462400"; d="scan'208";a="6584149"
Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 28 Feb 2012 17:05:35 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1SH5ZQ5017698; Tue, 28 Feb 2012 17:05:35 GMT
Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 22:35:35 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 28 Feb 2012 22:35:33 +0530
Message-ID: <618BE8B40039924EB9AED233D4A09C51031BC083@XMB-BGL-416.cisco.com>
In-Reply-To: <CAAFAkD-pheMmSQoUZzup_DHQceyXU=1Aq+oQZWEMXA_5pTNayg@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sop] SOP Requirements
Thread-Index: Acz2JIkOfqcR4SKhSEi+JU5PZkuBygADroCw
References: <CAOyVPHQ-iESaD2osxsWguTw1Ru92JYacSsqbD+1rECPzy1eGfQ@mail.gmail.com><CAA3wLqV+YeGJH2pFQ80s=PgQC2RsodPMm8qUw3a-VtCzhETkOg@mail.gmail.com><CAOyVPHTXWPyt5aHL2ehd_upS-DEAcfugVMcUpUm_oO5Ov04rUw@mail.gmail.com><618BE8B40039924EB9AED233D4A09C51030E1263@XMB-BGL-416.cisco.com> <CAAFAkD-pheMmSQoUZzup_DHQceyXU=1Aq+oQZWEMXA_5pTNayg@mail.gmail.com>
From: "Ashish Dalela (adalela)" <adalela@cisco.com>
To: "Jamal Hadi Salim" <hadi@mojatatu.com>
X-OriginalArrivalTime: 28 Feb 2012 17:05:35.0312 (UTC) FILETIME=[2FD87500:01CCF63B]
Cc: Vishwas Manral <vishwas.ietf@gmail.com>, sop@ietf.org, Michael Hammer <mphmmr@gmail.com>
Subject: Re: [sop] SOP Requirements
X-BeenThere: sop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Service Orchestration and Desciption for Cloud Services <sop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sop>, <mailto:sop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sop>
List-Post: <mailto:sop@ietf.org>
List-Help: <mailto:sop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sop>, <mailto:sop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Feb 2012 17:05:39 -0000

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. 

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.

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. 

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

Thanks, Ashish



-----Original Message-----
From: sop-bounces@ietf.org [mailto:sop-bounces@ietf.org] On Behalf Of
Jamal Hadi Salim
Sent: Tuesday, February 28, 2012 7:53 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 8:26 AM, Ashish Dalela (adalela)
<adalela@cisco.com>; 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
summarize:
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).

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