Re: [lisp] LISP EID Block Size

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 01 November 2013 06:52 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7AB11E8215 for <lisp@ietfa.amsl.com>; Thu, 31 Oct 2013 23:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.307
X-Spam-Level:
X-Spam-Status: No, score=-101.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, USER_IN_WHITELIST=-100]
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 6hZev640E6K3 for <lisp@ietfa.amsl.com>; Thu, 31 Oct 2013 23:52:24 -0700 (PDT)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 26B5211E8246 for <lisp@ietf.org>; Thu, 31 Oct 2013 23:52:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 01ED3126CBE for <lisp@ietf.org>; Thu, 31 Oct 2013 23:52:23 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [192.36.80.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 83707126CA9 for <lisp@ietf.org>; Thu, 31 Oct 2013 23:52:22 -0700 (PDT)
Message-ID: <52734FA6.4040003@joelhalpern.com>
Date: Fri, 01 Nov 2013 02:52:22 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
CC: LISP mailing list list <lisp@ietf.org>
References: <20131031151830.55F9618C168@mercury.lcs.mit.edu> <EA0CEAB9-BD0F-4278-BE30-6D6DB7E7B624@steffann.nl> <FC33A2A0-45EA-424B-8F37-D479131AEDD4@gmail.com> <52728FCF.2060603@joelhalpern.com> <A3459787-CCEB-4037-9005-81F51C6ABFCC@gmail.com>
In-Reply-To: <A3459787-CCEB-4037-9005-81F51C6ABFCC@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [lisp] LISP EID Block Size
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Nov 2013 06:52:30 -0000

I understand the importance of experimenting.  But I am having trouble 
getting my head around the possible value we want to explore.  Color me 
naive and stubborn, but individually so.

Thinking about the ITR code path, if there is no block:
Receive packet
check cache for destination
failing cache match, query for destination.

And the ITR code path if there is a block:
Receive packet
check cache for destiantion
failing cache match, check for destination in EID block
If in EID block, query
If not in EID block, query

Now, if everything is in the EID block, I understand that the last step 
above becomes "just send".  But that appears to be a counter-factual 
assumption.

Yours,
Joel

On 10/31/13 7:19 PM, Dino Farinacci wrote:
>>
>> Actually, that use case is only helped by the EID block if you can
>> be sure that ALL the destination EIDs it will see will come from
>> the block.
>
> I don't believe so. It could just an efficiency play for one versus
> the other.
>
>> Which seems to be impossible to ensure in the general case.  And
>> easy to achieve without an allocated block in many of the special
>> cases.
>
> Well the EID could mean it is behind a NAT and that ITRs should
> encapsulate to an RTR. Maybe one that is used by a default map-cache
> entry or a distinguished key on the mapping database.
>
> See there are sorts of things we could try. Again, "try" here means
> experimentation.
>
> Look how the pilot network was easier to debug since we had
> 153.16.0.0/16 generically donated by Andrew Partan and how cisco has
> been renting 2610:d0::/32.
>
> Dino
>