Re: [armd] address resolution requirement from hosts to overlay edge nodes. Any opinion?

Anoop Ghanwani <anoop@alumni.duke.edu> Tue, 14 February 2012 19:36 UTC

Return-Path: <ghanwani@gmail.com>
X-Original-To: armd@ietfa.amsl.com
Delivered-To: armd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2099821E8023 for <armd@ietfa.amsl.com>; Tue, 14 Feb 2012 11:36:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.457
X-Spam-Level:
X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 bTNHOqIYv8M1 for <armd@ietfa.amsl.com>; Tue, 14 Feb 2012 11:36:01 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7212821E801B for <armd@ietf.org>; Tue, 14 Feb 2012 11:36:01 -0800 (PST)
Received: by qafi29 with SMTP id i29so2471685qaf.10 for <armd@ietf.org>; Tue, 14 Feb 2012 11:36:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NFSimr/YZavjtnTnkT+AIuNQ6oQ6qBcDu6hnizH2ScU=; b=UDhk1Gy8lFpobIzlXM4Vmm5xF3awReUD37uz1EOcQn6O3cOgukETwWmc1+FMMD5Cwe xKH4thy46uCHVEoJPwbcjlknzO8xcUKpMHY8CcxjMSN7MjhpkedYoK+T4MMZVjnEhl78 xmQECT59HJWI6O+Du0aFBWQtoQVnkfp9SM7uo=
MIME-Version: 1.0
Received: by 10.229.135.10 with SMTP id l10mr13141379qct.14.1329248160993; Tue, 14 Feb 2012 11:36:00 -0800 (PST)
Sender: ghanwani@gmail.com
Received: by 10.229.155.206 with HTTP; Tue, 14 Feb 2012 11:36:00 -0800 (PST)
In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD522A9BE1F1@EUSAACMS0703.eamcs.ericsson.se>
References: <CA+-tSzzNeLP4N=Nv1EeBML51KTpmxPP3NWut+vnaWFy8RtUViA@mail.gmail.com> <7AE6A4247B044C4ABE0A5B6BF427F8E291E1A5@dfweml503-mbx> <CA+-tSzyvoDfwnKc7Yt65abQWSqMg2jF0iQax=wcYkmwtNGxZng@mail.gmail.com> <60C093A41B5E45409A19D42CF7786DFD522A9BE1F1@EUSAACMS0703.eamcs.ericsson.se>
Date: Tue, 14 Feb 2012 11:36:00 -0800
X-Google-Sender-Auth: YWYtQFkAO18alOLctIqmFsZirio
Message-ID: <CA+-tSzwZVYyEO62ngYGojwSrkSBBY2SWr93PDQmAp7a3y_7TMQ@mail.gmail.com>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
To: David Allan I <david.i.allan@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Thomas Narten <narten@us.ibm.com>, Igor Gashinsky <igor@yahoo-inc.com>, "armd@ietf.org" <armd@ietf.org>
Subject: Re: [armd] address resolution requirement from hosts to overlay edge nodes. Any opinion?
X-BeenThere: armd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." <armd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/armd>, <mailto:armd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/armd>
List-Post: <mailto:armd@ietf.org>
List-Help: <mailto:armd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/armd>, <mailto:armd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Feb 2012 19:36:02 -0000

On Tue, Feb 14, 2012 at 11:05 AM, David Allan I
<david.i.allan@ericsson.com> wrote:
> I have to admit I am a bit confused by the direction this is going.
>
> There seems to be a view that multicast is bad, yet it is a useful tool to permit a significant amount of functionality to be delegated to end systems, and is a part of useful address aggregation in the form of the subnet. IMO virtualized broadcast domains are good things, not something to be avoided, and they permit a trusted resource community to do a lot of self-organizing.
>
> Perhaps you should be thinking about improving multicast, not evicerating everything else. And as a general design principle, I believe that applies to most areas where the tail is wagging the dog in these deliberations.

Theoretically speaking, it is easy to brush this off and say "let's just improve
multicast", and if we do nothing then that is pretty much what will happen.
However, as a practical matter, there is a lot of hardware out there that
has significant problems with multicast.  This means we delay the deployment
of such solutions until the hardware catches up (if it ever does), or let smart
people who don't care about standards figure out ways around it that are
non-interoperable, and worry about about the standardization aspect later.

Anoop