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

"Joel M. Halpern" <> Sat, 13 May 2017 18:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EEAAD129411 for <>; Sat, 13 May 2017 11:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 I7gHqj8fdvFs for <>; Sat, 13 May 2017 11:06:15 -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 CF0A8129ADC for <>; Sat, 13 May 2017 11:03:12 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2289D40329; Sat, 13 May 2017 11:03:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=1.tigertech; t=1494698592; bh=221/jjz0SEzOEY0jFS9fRasvKmET9GihEuNe43gB/m0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=A5V9n3UHphcYNb4J9Ov7SAx87L+1YcHnkjXcZhm4+VUPFijxBnlWZH4bzpOD+nvSN Ol10kQ76ZPZkzlnOg+XceOf2IL36gwtek39XIW0KeSje2NKe+XV/RZigXOEcXmIF7T CND5OOrXyiyVxyySZjwsOoCLzJ1U5LVMmeETjkSk=
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 1A83DD401AE; Sat, 13 May 2017 11:03:11 -0700 (PDT)
To: Tom Herbert <>, "" <>
References: <>
Cc: Petr Lapukhov <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Sat, 13 May 2017 14:03:10 -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=windows-1252; 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: Sat, 13 May 2017 18:06:17 -0000

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.


On 5/13/17 1:42 PM, Tom Herbert wrote:
> Hello,
> At the Chicago WG meeting I made a request that ILA be taken up as a
> WG item in int-area. The WG chairs and AD requested that we raise a
> discussion on the list about what else is needed to be done for ILA
> (Identifier Locator Addressing draft-herbert-nvo3-ila-04). The
> question was also raised if int-area is the right WG for ILA or if it
> should have a BOF.
> The current draft of ILA describes the data plane and addressing, a
> model for ILA for ILA routing and network topology, several use case
> scenarios on how ILA might be applied, a format for identifiers to
> allow different types of identifiers and checksum neutral mapping. As
> I mentioned we intend to make the last one optional so that
> administrators can choose how structure the 64 bit identifiers as they
> see fit-- this will be reflected in the next version of the draft.
> The draft explicitly does not define a specific control plane (e.g.
> routing protocol) for ILA and I don't think that it should. IMO ILA
> would be better served to allow various methods that are protocol
> generic where ILA could be a use case of those mechanisms. For
> instance, draft-lapukhov-bgp-ila-afi-02 describes and extension for
> BGP. Similarly, if a protocol agnostic control plane is developed in
> IDEAS or in nvo3, then ILA could be one use case for those. I would
> think the control plane seems more appropriate to be in routing area
> than int-area.
> As for what is still missing in the core ILA draft, besides making
> typed identifiers optional, I think it is fairly complete for the data
> plane description. It is being deployed in a least on datacenter for
> network virtualization, and it is being discussed as part of a
> solution to support IP mobility (see 5GandIP discussions).
> Tom
> _______________________________________________
> Int-area mailing list