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

"Joel M. Halpern" <> Wed, 17 May 2017 13:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A63212EAD5 for <>; Wed, 17 May 2017 06:41:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.702
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KCfb3yVulC77 for <>; Wed, 17 May 2017 06:41:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C501B126C23 for <>; Wed, 17 May 2017 06:35:38 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACC08465138; Wed, 17 May 2017 06:35:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=1.tigertech; t=1495028138; bh=ysgmmRC5Tyvja3yU1UB7YbzMIt0/leCpeHFQ+ronpeM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=P1sGWKBQCi2SZ9s0e6hSJvhN7sBzPDXqfDKZdGryo7lMQA8XEqxJb2aoJtR8v7a61 byrxpkT/60TnTawGQZrmyXbAWEpchwKEdKN2W8/yNWb2pNJP0Z/GUQNBxI9sPInfAe iLVIbyIt1tmJ4sGMfnjSqcvcRCanyDkNb73gGutw=
X-Virus-Scanned: Debian amavisd-new at
Received: from Joels-MacBook-Pro.local (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 96E73465136; Wed, 17 May 2017 06:35:37 -0700 (PDT)
To: Tom Herbert <>, "Joel M. Halpern" <>
References: <> <> <> <> <> <>
Cc: Erik Kline <>, Petr Lapukhov <>, "" <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Wed, 17 May 2017 09:35:36 -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: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Int-area] ILA and int-area
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 May 2017 13:41:08 -0000

I do not think classic Internet tunnels (e.g. IP in IP or GRE) are a 
good comparison for ILA.  The ILA mapping requires dynamic knowledge 
about the remote end.  (One of the things that is important about ILA is 
its ability to hide dynamics.)
GUE at least is proposed specifically for use in data centers.

I think you understand my point, so I will not belabour it.


On 5/17/17 1:53 AM, Tom Herbert wrote:
> On Tue, May 16, 2017 at 8:33 PM, Joel M. Halpern <> wrote:
>> 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.
> Okay, thanks for the clarification. It seems like either experimental
> or standard would be appropriate then. The other aspect that could be
> relevant is there is no change to on the wire protocol, I'm not sure
> how that would impact the track status.
> As far as how to control it, I would point out that neither GRE nor
> IPIP, probably the two most common encapsulations in use, don't
> specify an associated control protocol. We are taking that same
> approach with GUE and I think that same approach is good for ILA. It
> would be great to see a common control plane for tunneling and
> virtualization that solves the larger common problem (this is why
> IDEAS is exciting to me), but even if that existed it would never be
> the only means to control the dataplane. In some deployments simple
> configuration is more than sufficient, for example.
> Thanks,
> Tom
>> Yours,
>> Joel
>> On 5/16/17 11:25 PM, Erik Kline wrote:
>>> On 14 May 2017 at 03:21, Tom Herbert <
>>> <>> wrote:
>>>     On Sat, May 13, 2017 at 11:03 AM, Joel M. Halpern
>>>     < <>> 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.