Re: [sop] SOP Requirements

"Ashish Dalela (adalela)" <adalela@cisco.com> Wed, 29 February 2012 16:44 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 BAA9021F85A2 for <sop@ietfa.amsl.com>; Wed, 29 Feb 2012 08:44:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.518
X-Spam-Level:
X-Spam-Status: No, score=-7.518 tagged_above=-999 required=5 tests=[AWL=3.081, 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 yOs3gxpfkdks for <sop@ietfa.amsl.com>; Wed, 29 Feb 2012 08:44:49 -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 5076921F8584 for <sop@ietf.org>; Wed, 29 Feb 2012 08:44:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=adalela@cisco.com; l=5248; q=dns/txt; s=iport; t=1330533888; x=1331743488; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=apCh4dhIE+dzBr7hW85AQRBYS9+FYRAG9uKuZKFKC5Y=; b=OoGjMKv+RLiaIEJhddk63b/jZ1rBEHd8AjI3sWLcm9hXQJpKW/R9fjJ5 UPxdTG44RJNxnLsiljgVeZ/NW2pFAWd4f1juUysqvwehwPNP9gzKRQOJS 8Qvo7VNT4G3r/qWN2xGJV6kiR3+kMa4oOFq/WFBRD6G70Guz3wuKPAxBR 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap8EAAJVTk9Io8UY/2dsb2JhbABEtGSBegEBAQMBEgEdCisUBQcEAgEIEQQBAQEKBhcBBgFFCQgBAQQLCAgah2IFmkEBnxqJfQUFgwMBBQIBBBYCQBWFGAM0Dg4HA4JbYwSITZ9rgUwBBw
X-IronPort-AV: E=Sophos;i="4.73,503,1325462400"; d="scan'208";a="6677040"
Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 29 Feb 2012 16:44:46 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1TGikvl011969; Wed, 29 Feb 2012 16:44:46 GMT
Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Feb 2012 22:14:46 +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: Wed, 29 Feb 2012 22:14:45 +0530
Message-ID: <618BE8B40039924EB9AED233D4A09C51031BC3B4@XMB-BGL-416.cisco.com>
In-Reply-To: <CAAFAkD_8nKOnRf+BhRWiAmxkGByjZDBP6cU2i5ZhnpPA-OGt0Q@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sop] SOP Requirements
Thread-Index: Acz2/cSyk2ozb4b+TaCGFgb9gxfTiQAAhX3w
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> <CAAFAkD-yjzhVppSyC058y=TAmOQVoaBmAh6Gr_y0ymrvFr_ydQ@mail.gmail.com> <618BE8B40039924EB9AED233D4A09C51031BC382@XMB-BGL-416.cisco.com> <CAAFAkD_8nKOnRf+BhRWiAmxkGByjZDBP6cU2i5ZhnpPA-OGt0Q@mail.gmail.com>
From: "Ashish Dalela (adalela)" <adalela@cisco.com>
To: Jamal Hadi Salim <hadi@mojatatu.com>
X-OriginalArrivalTime: 29 Feb 2012 16:44:46.0439 (UTC) FILETIME=[71DF4F70:01CCF701]
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 16:44:50 -0000

Hi Jamal,

>> Sorry - I was using ForCES speak.
>> A node like abc.provider.com can have a car - the only time
>> you can use it is if you instantiate it (to use your analogy,
>> give it a number plate). So the _instance_ in that view is not
>> abc.provider.com rather explicit abc.provider.com/cars/plateXXXX

I understand the ForCES background - the idea is aligned with ATCA and
the notion that any node can be given any "personality". That may not be
true in general where certain types of devices are "capable" of doing
certain things. E.g. you can't trivially make a switch a firewall or a
load-balancer. You certainly can't make a network device a storage
device or a server trivially. It is true for x86 servers maybe, but as
you get a wide variety of hardware capabilities or move up the software
stack into a middleware or a specific type of application, the
generalized view disappears. Until we get to a point where a common type
of hardware can enact any type of functionality that view is limited.

>> So you essentially dont need to have the user to be aware
>> of the instance? So if i wanted >1 instances how do i distinguish
>> between them? I am assuming at some point after creation one would
>> need refer to a specific instance (and instance IDs of some form play
a role).

The reality with virtualized services is that the instance doesn't
*exist* when you ask for it. E.g. when I request a VM, the VM that I
will be allocated doesn't exist. It will be created on-demand. So, there
is no way I can request the specific "instance". I have to only request
a "type". The type has to be mapped to a capability source, and then
converted into an instance. Once you have an instance, sure, you refer
to it both by type and instance.

>> That definition may need to well described.
>> There are a lot of "transparent" email/HTTP proxies that translate at
>> least at the protocol packet level.

Sure, that can be clarified. I thought the definition was clear in the
drafts, but if not, that can be clarified.

Thanks, Ashish


-----Original Message-----
From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] 
Sent: Wednesday, February 29, 2012 9:48 PM
To: Ashish Dalela (adalela)
Cc: Vishwas Manral; sop@ietf.org; Michael Hammer
Subject: Re: [sop] SOP Requirements

Hi Ashish,

On Wed, Feb 29, 2012 at 10:05 AM, Ashish Dalela (adalela)
<adalela@cisco.com> wrote:
> Hi Jamal,
>
> I think there may be some confusion here.
>
> There are two types of names we deal with - "types" and "instances". A
> "car" is a type and car with a specific number plate is an "instance".
> These are two separate things.

Sorry - I was using ForCES speak.
A node like abc.provider.com can have a car - the only time
you can use it is if you instantiate it (to use your analogy,
give it a number plate). So the _instance_ in that view is not
abc.provider.com rather explicit abc.provider.com/cars/plateXXXX.

>Likewise, iaas.compute.virtual.ovf is
> "type", and abc.provider.com is an instance of a server that is OVF
> capable. We won't merge these two names. A packet is generally routed
in
> IP world based on "instance" addresses. In SOP, a packet is routed
based
> on "types".
>
> That means that a user requests a "type" and the provider routes the
> request to the "instance" based on policy constraints.

Ok - got it; but still unclear.
So you essentially dont need to have the user to be aware
of the instance? So if i wanted >1 instances how do i distinguish
between them? I am assuming at some point after creation one would
need refer to a specific instance (and instance IDs of some form play a
role).

> The proxy is *not* a translator. In SIP, the term Proxy is used,
because
> the Proxy executes a task on behalf of the requestor. The Proxy
> "proxies" on behalf of the requestor. There is no translation
involved.
> Likewise, terms like HTTP proxy, mail proxy etc are used. These are
not
> translators.

That definition may need to well described.
There are a lot of "transparent" email/HTTP proxies that translate at
least at the protocol packet level.


> I think people have gotten really confused with OF way of thinking
about
> a standard. We need to take a step back and see how we have built
> standards in the past.

I am not preaching OF at all. While it serves a purpose and has
brought excitement
to the SDN aspect, sometimes i look  at OF and think of the Emperors
New clothes.

> Take example of a MIB and SNMP. SNMP is standard for all MIBs. That
> doesn't preclude thousands of MIBs to be created. Likewise SOP is like
> SNMP. Service descriptions are like MIBs. Standard SOP doesn't
preclude
> thousands of service types. When you create a new MIB, you just load
the
> MIB in the network manager and start managing. You don't have to
upgrade
> the manager. That means a network manager can manage innumerable types
> of services, without a software upgrade. It is made possible by
> separation between SNMP and the MIB.
>
> We want to create the same separation between SOP and
service-dependent
> descriptions like OVF ..
>
> Makes sense?

Indeed (and in total agreement).

cheers,
jamal