Re: [lisp] LISP EID Block Size

["Joel M. Halpern" <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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
>>>>> [e-mail] https://www.ietf.org/mailman/listinfo/lisp
>>>>
>>>>
>>
>> _______________________________________________
>> lisp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lisp
>
>