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

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 20 January 2012 05:28 UTC

Return-Path: <jmh@joelhalpern.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 29F4F21F8573 for <dc@ietfa.amsl.com>; Thu, 19 Jan 2012 21:28:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Level:
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 zBiBWWKlA+dC for <dc@ietfa.amsl.com>; Thu, 19 Jan 2012 21:28:23 -0800 (PST)
Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 72C2621F8572 for <dc@ietf.org>; Thu, 19 Jan 2012 21:28:23 -0800 (PST)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 47C3A103A1E for <dc@ietf.org>; Thu, 19 Jan 2012 21:28:23 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 766A22C244E; Thu, 19 Jan 2012 21:28:22 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 1978F2C244B; Thu, 19 Jan 2012 21:28:22 -0800 (PST)
Message-ID: <4F18FB72.2090900@joelhalpern.com>
Date: Fri, 20 Jan 2012 00:28:18 -0500
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
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> <4F18EF4A.3060308@gmail.com> <618BE8B40039924EB9AED233D4A09C5102CB234C@XMB-BGL-416.cisco.com>
In-Reply-To: <618BE8B40039924EB9AED233D4A09C5102CB234C@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 05:28:24 -0000

While one can construct strawman hypothesis in whcih there are reasons 
to have different tunnel control protocols depepnding upon end-point 
location, equally one can construct reasonably hypothesis in which the 
same protocol mechanisms work whether the end-point is at the VM, the 
Hypervisor, the ToR switch, or an aggregation switch.


Yours,
Joel

On 1/20/2012 12:07 AM, Ashish Dalela (adalela) wrote:
>
> I would not arrive at the conclusion that hypervisor work should or
> should not be done in IETF. That's a separate question. VXLAN and NVGRE
> are hypervisor based approaches. But, they don't have control planes
> (yet). My point is that finding a common map-encap scheme isn't that
> hard. The harder part is how to make the hypervisor and network based
> map-encap *control planes* work the same way.
>
> If they don't work the same way, then L2-in-L2, L2-in-L3, L3-in-L3 has a
> network flavor and a hypervisor flavor.
>
> Thanks, Ashish
>
>
> -----Original Message-----
> From: Melinda Shore [mailto:melinda.shore@gmail.com]
> Sent: Friday, January 20, 2012 10:06 AM
> To: Ashish Dalela (adalela)
> Cc: dc@ietf.org
> Subject: Re: [dc] draft-khasnabish-vmmi-problems-00.txt
>
> 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
> _______________________________________________
> dc mailing list
> dc@ietf.org
> https://www.ietf.org/mailman/listinfo/dc
>