Re: [sop] SOP Requirements

Jamal Hadi Salim <hadi@mojatatu.com> Wed, 29 February 2012 16:18 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 4F4DF21F8790 for <sop@ietfa.amsl.com>; Wed, 29 Feb 2012 08:18:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.474
X-Spam-Level:
X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.503, 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 ugIKCEayvCvs for <sop@ietfa.amsl.com>; Wed, 29 Feb 2012 08:18:20 -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 7AA7521F8744 for <sop@ietf.org>; Wed, 29 Feb 2012 08:18:20 -0800 (PST)
Received: by obbeh20 with SMTP id eh20so5041185obb.31 for <sop@ietf.org>; Wed, 29 Feb 2012 08:18:20 -0800 (PST)
Received-SPF: pass (google.com: domain of hadi@mojatatu.com designates 10.182.127.20 as permitted sender) client-ip=10.182.127.20;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of hadi@mojatatu.com designates 10.182.127.20 as permitted sender) smtp.mail=hadi@mojatatu.com
Received: from mr.google.com ([10.182.127.20]) by 10.182.127.20 with SMTP id nc20mr330543obb.66.1330532300215 (num_hops = 1); Wed, 29 Feb 2012 08:18:20 -0800 (PST)
Received: by 10.182.127.20 with SMTP id nc20mr285041obb.66.1330532300127; Wed, 29 Feb 2012 08:18:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.40.202 with HTTP; Wed, 29 Feb 2012 08:17:59 -0800 (PST)
In-Reply-To: <618BE8B40039924EB9AED233D4A09C51031BC382@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> <CAAFAkD-yjzhVppSyC058y=TAmOQVoaBmAh6Gr_y0ymrvFr_ydQ@mail.gmail.com> <618BE8B40039924EB9AED233D4A09C51031BC382@XMB-BGL-416.cisco.com>
From: Jamal Hadi Salim <hadi@mojatatu.com>
Date: Wed, 29 Feb 2012 11:17:59 -0500
Message-ID: <CAAFAkD_8nKOnRf+BhRWiAmxkGByjZDBP6cU2i5ZhnpPA-OGt0Q@mail.gmail.com>
To: "Ashish Dalela (adalela)" <adalela@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQlXuea+mQEzVYckYfk1QYLNNVbPCkdi1NpkNuMCiEcq1FMgoO7w51QtLXf1jtZGsPW98QRq
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:18:21 -0000

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