Re: [lisp] LISP EID Block Size

"Darrel Lewis (darlewis)" <darlewis@cisco.com> Mon, 04 November 2013 14:47 UTC

Return-Path: <darlewis@cisco.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 3071F21E8195 for <lisp@ietfa.amsl.com>; Mon, 4 Nov 2013 06:47:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.549
X-Spam-Level:
X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 EOMcAyn2f5e1 for <lisp@ietfa.amsl.com>; Mon, 4 Nov 2013 06:47:00 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 163E121E8198 for <lisp@ietf.org>; Mon, 4 Nov 2013 06:46:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8286; q=dns/txt; s=iport; t=1383576402; x=1384786002; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=h52GpJLZRSpmTGR9XvQNKbsBTbp/mZmitsNhHFjllB0=; b=NCJiHcJEZpr/Gn/LSGYC6EnhOsHCtAYAqGiYhUMwFRPpZ/gnxt8Jwd/3 mVoW0Tta2K+EVgot5fHo3WCZ+EGVf3K+vG+ZNuSdxW0GwzO4gx6omG/zN Q17AteTWOxzC4CVSTbO7rYnIp8+inUUokOJKAIexwrUnwLWfHY/5mUPOA o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAEqyd1KtJV2c/2dsb2JhbABZgwc4U789gScWdIIlAQEBAwEBAQFrCwULAgEIGC4hBgslAgQOBRSHWwMJBg20OA2JZwSMaII9MweDIIEOA5QrgXSBa4xShTeDJoIq
X-IronPort-AV: E=Sophos;i="4.93,632,1378857600"; d="scan'208";a="277393791"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 04 Nov 2013 14:46:40 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA4EkdBa004528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Nov 2013 14:46:39 GMT
Received: from xmb-rcd-x15.cisco.com ([169.254.5.54]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 08:46:38 -0600
From: "Darrel Lewis (darlewis)" <darlewis@cisco.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Thread-Topic: [lisp] LISP EID Block Size
Thread-Index: AQHO2WyqC5Jl8rx8B0O7KJbwOz1stw==
Date: Mon, 4 Nov 2013 14:46:38 +0000
Message-ID: <BF718498-0CF1-4FC0-8F14-43F93BA5B3F8@cisco.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> <52753A16.5050906@joelhalpern.com> <98A53C30-74A2-4776-A5C9-8F124D3F74B4@gmail.com> <7B17185A-AE3D-4820-BCC1-B40C1AC6364C@gigix.net> <5276D7D0.1020302@joelhalpern.com>
In-Reply-To: <5276D7D0.1020302@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.91.141]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <07EE529E7342514A8FE6A75CC7D13C76@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Mon, 04 Nov 2013 14:47:09 -0000

As I think Geof pointed out, if we increase the length to /32 we can use existing allocation policies for experimentation.

-Darrel
On Nov 3, 2013, at 3:10 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:

> I believe (although I do not know for certain) that if we increase the length as suggested we will have a much easier time getting a block to experiment with.
> 
> Yours,
> Joel
> 
> On 11/3/13 5:30 PM, Luigi Iannone wrote:
>> Hi,
>> 
>> I agree with Dino,
>> 
>> if the issue is just the size let’s reduce it and do some experiments.
>> 
>> On the other hand, I do not understand we people here are trying to reach a binary conclusion like “EID Block is important and useful” or “EID Block is useless” even before doing any experimentation.
>> 
>> IMHO this is not the most logical order. We should first experiment, then we will have to know-how to make a decision.
>> 
>> Exactly because there are different and opposite opinions let’s the technology itself, through experimentation, make the decision.
>> 
>> Luigi
>> 
>> 
>> On 2 Nov. 2013, at 11:09 , Dino Farinacci <farinacci@gmail.com> wrote:
>> 
>>> So it appears that:
>>> 
>>> (1) People are all for experimenting.
>>> (2) People may be all for allocating a block if it is not too large.
>>> 
>>> So would it be easier to swallow if we just request a /32 or smaller block.
>>> 
>>> Are we just arguing over size?
>>> 
>>> If the experiment proves we need to do something in production, then we go get larger blocks as Joel indicates. And if the experiment is complete and say we don't need a well-known block, we return the /32.
>>> 
>>> Dino
>>> 
>>> On Nov 2, 2013, at 10:44 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>>> 
>>>> 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
>>>>> 
>>>>> 
>>> 
>>> _______________________________________________
>>> lisp mailing list
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp
>> 
>> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp