Re: [dc] draft-khasnabish-vmmi-problems-00.txt

Melinda Shore <melinda.shore@gmail.com> Fri, 20 January 2012 04:36 UTC

Return-Path: <melinda.shore@gmail.com>
X-Original-To: dc@ietfa.amsl.com
Delivered-To: dc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB51921F8497 for <dc@ietfa.amsl.com>; Thu, 19 Jan 2012 20:36:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 3qaya4i8hVau for <dc@ietfa.amsl.com>; Thu, 19 Jan 2012 20:36:30 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0F5621F8495 for <dc@ietf.org>; Thu, 19 Jan 2012 20:36:30 -0800 (PST)
Received: by yenm3 with SMTP id m3so91947yen.31 for <dc@ietf.org>; Thu, 19 Jan 2012 20:36:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WQxoEDwY3RWKcfql8M7aXxPomoxcCjv8/z6L5DMnGzE=; b=VPut1IOr/5VNgrUZy7BG/u5VH5NXWZrClzm5yV/6ywHEKU1xmwze5ir10aBd79GN6a p1m8Wn7JdA0NVH7rjm8WfTSFwL3WsJKpUzu2TPJ+hH/+LJlQz/hdZdsZuEXWtcX4BVER 31Zc8J8qFWIzjTygqtmuKBzekSiyg+IWrppKw=
Received: by 10.236.131.12 with SMTP id l12mr41607692yhi.111.1327034190444; Thu, 19 Jan 2012 20:36:30 -0800 (PST)
Received: from polypro.local (66-230-87-211-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.87.211]) by mx.google.com with ESMTPS id w28sm3108709yhi.21.2012.01.19.20.36.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jan 2012 20:36:29 -0800 (PST)
Message-ID: <4F18EF4A.3060308@gmail.com>
Date: Thu, 19 Jan 2012 19:36:26 -0900
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.25) Gecko/20111213 Lightning/1.0b2 Thunderbird/3.1.17
MIME-Version: 1.0
To: "Ashish Dalela (adalela)" <adalela@cisco.com>
References: <CAH==cJxfmae0u0bSF4cn_haLgY1T-vnw2102PApzYtj5Aty=GQ@mail.gmail.com><CANtnpwhFJ746ooi9GUCxfBqsOXu14hDka0D9inhh5pPq3U_ZTA@mail.gmail.com><201201171540.q0HFeNan008591@cichlid.raleigh.ibm.com><CANtnpwjexDPazOXLYHHjn3+JDi-o49Bv5ptDExAZHAA8Ra2m-A@mail.gmail.com><201201191419.q0JEJTLF010649@cichlid.raleigh.ibm.com> <1326989277.2513.4.camel@ecliptic.extremenetworks.com> <618BE8B40039924EB9AED233D4A09C5102CB2291@XMB-BGL-416.cisco.com><406B8B5D-E1E5-4DF4-8DE2-D7D2A699430A@asgaard.org> <4F18CE61.6030002@gmail.com> <618BE8B40039924EB9AED233D4A09C5102CB2330@XMB-BGL-416.cisco.com>
In-Reply-To: <618BE8B40039924EB9AED233D4A09C5102CB2330@XMB-BGL-416.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: dc@ietf.org
Subject: Re: [dc] draft-khasnabish-vmmi-problems-00.txt
X-BeenThere: dc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Data Center Mailing List <dc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dc>, <mailto:dc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dc>
List-Post: <mailto:dc@ietf.org>
List-Help: <mailto:dc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dc>, <mailto:dc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jan 2012 04:36:31 -0000

On 1/19/12 7:26 PM, Ashish Dalela (adalela) wrote:
>Bandwidth needs, but they have the
> same tunnel. How do I distinguish between them based on the tunnel? In
> fact, if the tenant isolation is in the hypervisor, then the underlying
> network has no clue which tenant needs what policy.

Well, that's not true.  In the case of IPSec we've got SPIs, and
there are similar demultiplexing mechanisms in other technologies.

But frankly I think that if you're going to distinguish between
tunnel endpoints in the hypervisor and tunnel endpoints in other
sorts of network devices I think you're going to be somewhat
hard-pressed to make the case for working on the former in
the IETF.

Melinda