Re: [lisp] LISP EID Block Size

"Joel M. Halpern" <jmh@joelhalpern.com> Sat, 02 November 2013 17:45 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 5535A11E8221 for <lisp@ietfa.amsl.com>; Sat, 2 Nov 2013 10:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 lO6OqDs3qn6c for <lisp@ietfa.amsl.com>; Sat, 2 Nov 2013 10:44:58 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id E08B211E821B for <lisp@ietf.org>; Sat, 2 Nov 2013 10:44:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9E6531C08B8; Sat, 2 Nov 2013 10:44:56 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from dhcp-b83d.meeting.ietf.org (dhcp-b83d.meeting.ietf.org [31.133.184.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 221941C0780; Sat, 2 Nov 2013 10:44:56 -0700 (PDT)
Message-ID: <52753A16.5050906@joelhalpern.com>
Date: Sat, 02 Nov 2013 13:44:54 -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
To: Dino Farinacci <farinacci@gmail.com>
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> <52734FA6.4040003@joelhalpern.com> <FC03B84E-350E-4A52-84A9-44518862B5D7@gmail.com>
In-Reply-To: <FC03B84E-350E-4A52-84A9-44518862B5D7@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: LISP mailing list list <lisp@ietf.org>
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: Sat, 02 Nov 2013 17:45:03 -0000

On the source side, the ITR had better know what EIDs it is working on 
behalf of (otherwise, it is a source for spoofed source address).  So 
none of those cases seem to be affected by the allocation or 
non-allocation of a block.

If we are going to do anything based on a block, we better make sure it 
can handle more than one block.  Which means that at most we need a 
block for the duration of the test period.  We do not need a block for 
the hoped for full success of LISP.  If we really succeed, we can get an 
additional bigger block.

Yours,
Joel

On 11/1/13 10:33 AM, Dino Farinacci wrote:
>> 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:
>
> Many are thinking in this context. It is one but there are other
> things WE COULD DO if we new a prefix was an EID. See below for some
> rough examples. And please don't ask for detail, because this is
> initial thinking.
>
>> Receive packet check cache for destination failing cache match,
>> query for destination.
>
> And there could be a failed match if the destination address was not
> an EID. Meaning this packet is coming to an ITR destined for a
> non-LISP site (regardless if the source address is an EID or not). So
> the ITR would have to query the mapping database.
>
> So let's break this down. If the source was an EID, one could say,
> "okay since I'm doing the new stuff the delay for a lookup to a
> non-LISP destination is the price I pay for getting multihoming for
> packets that come back to me". If the source was not an EID, then the
> old user that expects to go to a non-LISP site expects the packet
> loss or optimal routing path to continue. And if it does not, then
> the new service hurt existing users.
>
> Please note, this is when a site is bifurcated being a site that has
> some partial EID allocations and partial hosts that have not changed.
> And that either could send to EID or non-EID destinations.
>
> Yes, you could have a default PETR configured in the ITR so there is
> 0 packet loss, but then you may get a suboptimal path. And packets
> from a non-EID source to a non-EID destination could be inadvertently
> encapsulated to the PETR. Then the PETR would decap and deliver the
> packet based on a BGP path.
>
> I for one, would like to solve this problem. And I do not know if
> just a well-known, hard-coded, EID-block will do it.
>
>> 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
>
> You are correct, but this box could be configured in way where the
> logic could change:
>
> Receive packet If EID-block strict configured If destination in
> EID-block, send query Else forward natively Else <do what Joel said
> above with no EID-block check> Endif
>
>> 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
>
> Having an EID block could help us in these scenarios as well:
>
> (1) The block or any more specifics should not have a native-forward
> action in a Map-Reply returned by the mapping system. (2) The block
> or any more specifics should not be injected into BGP without a
> special community indicating that only PITRs should be advertising
> it. (3) If a destination that a NAT box receives has a source in this
> block, that translation should not be done (because it is not
> needed). (4) If the source is in this block we know we cannot build
> RPF trees in the core when the source sends multicast packets. (5)
> Maybe a special EID-block should indicate that this source host can
> only talk IPv6 and that stretched layer-2 subnets are prohibited. So
> if you hit a box that does VXLAN and LISP, that layer 3 LISP is used
> and we don't move MAC frames across the underly and we certainly do
> not forward ARP packet, broadcast frames, and link-local multicast.
>
> Now all these things can be put in the mapping database, and give us
> the same answers but if we could keep load off the mapping database,
> this would be a good thing, a scalability feature.
>
> Dino
>
>>
>> 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
>>>
>> _______________________________________________ lisp mailing list
>> lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
>
>