Re: [sop] SOP Requirements

Jamal Hadi Salim <hadi@mojatatu.com> Wed, 29 February 2012 14:24 UTC

Return-Path: <hadi@mojatatu.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 4F6B421F8510 for <sop@ietfa.amsl.com>; Wed, 29 Feb 2012 06:24:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.428
X-Spam-Level:
X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 N5DOvJv2plE1 for <sop@ietfa.amsl.com>; Wed, 29 Feb 2012 06:24:49 -0800 (PST)
Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9191F21F84C5 for <sop@ietf.org>; Wed, 29 Feb 2012 06:24:49 -0800 (PST)
Received: by obbeh20 with SMTP id eh20so4904669obb.31 for <sop@ietf.org>; Wed, 29 Feb 2012 06:24:49 -0800 (PST)
Received-SPF: pass (google.com: domain of hadi@mojatatu.com designates 10.60.12.131 as permitted sender) client-ip=10.60.12.131;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of hadi@mojatatu.com designates 10.60.12.131 as permitted sender) smtp.mail=hadi@mojatatu.com
Received: from mr.google.com ([10.60.12.131]) by 10.60.12.131 with SMTP id y3mr221546oeb.26.1330525489176 (num_hops = 1); Wed, 29 Feb 2012 06:24:49 -0800 (PST)
Received: by 10.60.12.131 with SMTP id y3mr188815oeb.26.1330525489103; Wed, 29 Feb 2012 06:24:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.40.202 with HTTP; Wed, 29 Feb 2012 06:24:29 -0800 (PST)
In-Reply-To: <618BE8B40039924EB9AED233D4A09C51031BC0D4@XMB-BGL-416.cisco.com>
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> <618BE8B40039924EB9AED233D4A09C51031BC083@XMB-BGL-416.cisco.com> <CAAFAkD94ODszZ4D=m0Kyco8CEfE0rs9aLGj36-A7Re2MMQGiZg@mail.gmail.com> <618BE8B40039924EB9AED233D4A09C51031BC0D4@XMB-BGL-416.cisco.com>
From: Jamal Hadi Salim <hadi@mojatatu.com>
Date: Wed, 29 Feb 2012 09:24:29 -0500
Message-ID: <CAAFAkD-yjzhVppSyC058y=TAmOQVoaBmAh6Gr_y0ymrvFr_ydQ@mail.gmail.com>
To: "Ashish Dalela (adalela)" <adalela@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQlAh9n7NpK21YcMyZhsbAHrjAvuRisTiBN/l7OXa5JggXc4BVNI2gcIa9337grnXlEB9/hS
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: Wed, 29 Feb 2012 14:24:50 -0000

Hi Ashish,

On Tue, Feb 28, 2012 at 9:08 PM, Ashish Dalela (adalela)
<adalela@cisco.com>; wrote:
> Hi Jamal,
>
> We will look at ForCES again since you have mentioned similarities.

If you want to take a shortcut and get quick answers, feel free
to email me or post on the ForCES list.

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

Yes, makes sense.
[One thing thats not clear is how discovery of this services happens.
In the ForCES
approach, these services would be akin to LFBs. The node that is providing these
LFBs (analogous to an FE if you are trying to do an NE) would connect
to the controller
(aka CE) and tell it what it can support and what capacities of each service
(aka LFB) it can handle etc.]

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

When you use the term "proxy" i see "Translation" or at least the orchestrator
being intelligent enough to take  iaas.compute.virtual.ovf.instance1.foo
and understand it to be the same thing as  iaas.compute.virtual.xyz.bar
I think thats not what you want to achieve, correct? You want the request
to be explicit for  iaas.compute.virtual.ovf.instance1.foo for an OVF
knowledgeable app and  iaas.compute.virtual.xyz.bar for XYZ standard
app?

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

ok

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

Yes on the "no protocol changes or infrastructure/software". This is where
OF fails miserably.
While we are trying to standardize, what you are talking about is reality.
Unfortunately, it reduces the standardized interface to be the lowest common
denominator.

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

Sure.

> Hope I answered you question.

it does with a small caveat above.

cheers,
jamal