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

Tom Herbert <> Wed, 17 May 2017 05:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E104E12EAF6 for <>; Tue, 16 May 2017 22:57:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ItgbJGUahsee for <>; Tue, 16 May 2017 22:57:07 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 03CF7129C07 for <>; Tue, 16 May 2017 22:53:12 -0700 (PDT)
Received: by with SMTP id t26so1729461qtg.0 for <>; Tue, 16 May 2017 22:53:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y6T4ljbdHHbrpbJh5gllMS/UOIU7c850+yvk4xIkG/E=; b=ek0osLMqzK97uVP7O8C+14P9hrOGmJ2kWrQYPCr+rROg/yhM87FWd9+d9gYwm/XYXE dfJQ1Lo6c0SjdX/GkYemXkD8yJpAmLTcbndv5BaoIHvhmaBz/BhQSshE+Y48OxU0tbEN 0wI370xkdSmBD+SkxBpD3fTH1bfr/w6W7GxfyQ0jRnbzeJXqoEQl2PFEiliGSmyr9dsN Mp9rC3Y9mGyCHBcmnAW1f2sKRgHxYm2da7wKFIXpB+t5qz9BezR63V1hsxtXml8qacOf kTyl6oW05uCgGnEI93y16pmeaQW2rlNvII37IJR/P9UYHInaHOxXcx3Qahg9hnpsuTKK /jig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y6T4ljbdHHbrpbJh5gllMS/UOIU7c850+yvk4xIkG/E=; b=q5dqpT2+qSx/NQ3swwt61epDNslReRM1ahwkD4zgfeBA4n/dn3igR4k8ENyT4RVr0D YK1BP+JEBOSWu9gV4wnR7ogYo/xRRVslifZ3XO1m6X/B7ZHMobVKufkqZpK51CQMdV02 r66H1pEoZV6W7apvsaTrfF3EOl7v+dNuvkbsXWCSzd/8EPfwl/6sW40+uguXzkwinnqr TL0OYa/ywm0O91+CtT2A1tcIMuwv6qEOCHzcXfdFbALEK5nnMcySLetnKBdORNnwQtHs rq2paMNtNJ0HTyTsZbnx59+pMZ8LuLHddgCDd94Bv+wZl9r3oUYML9bGHTCsH1QVswqC eLmQ==
X-Gm-Message-State: AODbwcBUUmP7ExiC3ysFCdmiBqYSBq6GfbTcUjgvHgdm93flII3z1GVJ ajfbhWwbDk0VJOifgzXh0eR09h8wgfdF
X-Received: by with SMTP id g28mr1338097qtf.279.1495000391078; Tue, 16 May 2017 22:53:11 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 16 May 2017 22:53:10 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Tom Herbert <>
Date: Tue, 16 May 2017 22:53:10 -0700
Message-ID: <>
To: "Joel M. Halpern" <>
Cc: Erik Kline <>, Petr Lapukhov <>, "" <>
Content-Type: text/plain; charset="UTF-8"
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 05:57:09 -0000

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.


> 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.
>>     > 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.