Re: [Int-area] ILA and int-area

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 17 May 2017 03:36 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FB712EBE6 for <int-area@ietfa.amsl.com>; Tue, 16 May 2017 20:36:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6d_VI9S5Fl6P for <int-area@ietfa.amsl.com>; Tue, 16 May 2017 20:36:56 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7026912EC59 for <int-area@ietf.org>; Tue, 16 May 2017 20:33:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 57225DC078A; Tue, 16 May 2017 20:33:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1494992036; bh=BLAfgGWYKWm/OMy1oO7V7wGVlmknh+ouM7OikaFG3uI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=A4TVpzNJXMbktUxD6qRy6wN7bGG0dsxsRXTxFPDZ92TBUbeU9pl7EK+BGZWgAhhN9 un1I/+/NCmvVQGpT1Z6/zMsGg1o779WNhKTo6K7izNoPMlZD/CYuzX34OJOAEV7NE0 o04kK64tr3B8yH6AMmpe8/uLOerbvm0ayq+sSv8U=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 64197DC0765; Tue, 16 May 2017 20:33:55 -0700 (PDT)
To: Erik Kline <ek@google.com>, Tom Herbert <tom@herbertland.com>
References: <CALx6S34A5k_DtEb7YWQs=Y79p4rCpe-9Hg3_YiqbOSyWzqepYA@mail.gmail.com> <813a6560-4513-958a-0898-d42133285a34@joelhalpern.com> <CALx6S35bMXCrVuH-8+oNCuq+Aw0Fw4cL-hGpVfX9E3QHaxGG7w@mail.gmail.com> <CAAedzxox77q+u5XpjSX3_UwLfrNoUymdO0TvDZYYD2adb9NfiQ@mail.gmail.com>
Cc: Petr Lapukhov <petr@fb.com>, "int-area@ietf.org" <int-area@ietf.org>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <c508e974-b979-a1e3-8fa9-a53d5840e730@joelhalpern.com>
Date: Tue, 16 May 2017 23:33:54 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAAedzxox77q+u5XpjSX3_UwLfrNoUymdO0TvDZYYD2adb9NfiQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/J1PezuVT5QcSl-7OPXW6i2rxL0w>
Subject: Re: [Int-area] ILA and int-area
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 May 2017 03:36:58 -0000

If we want the documents to be informational, then it should be about a 
context where we understand how to build the surrounding infrastructure. 
  For example, if it were documented for data centers, based on 
Facebook's experience, I would have trouble objecting to informational 
publication.

If we do not know where it applies, and what to try it out in various 
contexts with various control setups, then that sounds like experimental 
RFCs.  While I have my doubts about some of the applicability, that 
should not stop useful experimentation.

But an informational document that says that this can be used (roughly 
speaking) ~anywhere you can figure out a way to control it~ seems a bit odd.

Yours,
Joel

On 5/16/17 11:25 PM, Erik Kline wrote:
>
>
> On 14 May 2017 at 03:21, Tom Herbert <tom@herbertland.com
> <mailto:tom@herbertland.com>> wrote:
>
>     On Sat, May 13, 2017 at 11:03 AM, Joel M. Halpern
>     <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> wrote:
>     > It appears to me that there are contexts in which it is likely that ILA is
>     > useful.
>     >
>     > Using the example of the progression of LISP, I have concern with the
>     > current approach of NOT spelling out how and where it would be used. LISP
>     > started out as experimental in significant part because it was not clear
>     > where it would be useful.  We re now progressing it to PS with a clear
>     > context.  And that context is NOT Internet-wide deployment for Internet
>     > scaling.  Because that deployment problem is REALLY challenging.
>     >
>     > As such, if ILA wants to either be developed for the data center context or
>     > be developed as an interesting experiment across a range of potential uses,
>     > I can not object.
>     >
>     > I do have problems moving it forward towards standards track for some
>     > unspecified but general use in its current form.  The dependence of the data
>     > plane protocol on the information distribution is so strong that I do not
>     > see how the general case can be treated.
>     >
>     Hi Joel,
>
>     Intended status is listed as informational if that helps.
>
>     I tend to think that the relationship between an ILA data plane and
>     control plane is analogous to the relationship between the IP protocol
>     and routing protocols. Yes, there is a strong dependency on having a
>     control plane, but mandating a specific control plane as part of the
>     core protocol reduces flexibility and extensibility.
>
>
> Put another way: the domain of applicability is the same as the
> domain(s) over which the control plane operates.  Any ILA packets
> outside that/ose domain/s should just look like vanilla IPv6.