Subject: Re: [lisp] LISP EID Block Size

From: Dino Farinacci <[email-masked]>
Date: Fri, 1 Nov 2013 07:33:33 -0700

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 02 Nov 2013 13:44:54 -0400

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.
>>
> 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
>
> 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
>
> (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
>
>>
>>>> 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.
>>>
>>> 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.
>>>
>>> 153.16.0.0/16 generically donated by Andrew Partan and how cisco
>>> has been renting 2610:d0::/32.
>>>
>>> Dino
>>>
>> _______________________________________________ lisp mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/lisp
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 2 Nov 2013 11:09:17 -0700

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 <[email-masked]> 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
>

---

From: Luigi Iannone <[email-masked]>
Date: Sun, 3 Nov 2013 14:30:10 -0800

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

---

From: Luigi Iannone <[email-masked]>
Date: Sun, 3 Nov 2013 14:43:43 -0800

>    <do what Joel said above with no EID-block check>

You  can also do more complex thing. During the resolution delay (the time a map-reply comes back) you can have different policies depending on the destination. 

For instance, if it is an EID block you can send toward a PITR or drop if you think that PITR adds too much path stretch. 
Or during the resolution delay of a non-EID block destination you forward toward a PETR or just natively.

Luigi

---

From: Luigi Iannone <[email-masked]>
Date: Sun, 3 Nov 2013 14:52:29 -0800

Hi,

On 31 Oct. 2013, at 09:31 , Sander Steffann <[email-masked]> wrote:

>> I'll explain one experiment and will be crystal ear about it. 
>> 
>> (1) We want to have a LISP site send to both LISP sites and not LISP sites. 
>> (2) We want an ITR to do mapping database lookups when the destination address is an EID. 
>> (3) We want the ITR to forward packet s by doing a traditional FIB lookup when the destination is not an EID. 
> 
> I understand what the technical idea is. There are already EIDs out there (including my own network) that are not in any special prefix. Therefore "address is in special prefix" != "address is an EID”.

That is not correct. With an EID block you would have:

Address in special prefix == address is an EID

Address not in special prefix != is not an EID

Basically if it is n the special block you know it is an EID, if it is not in the special block you have no idea and you have to check.

Luigi

> Unless you break LISP for already existing sites I don't see how having a special prefix is going to help in (correctly) determining whether an address is an EID.
> 
>> Good Zen?
> 
> Sorry, still not (yet?) liking this idea.
> Sander
>

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 3 Nov 2013 15:05:15 -0800

> Or during the resolution delay of a non-EID block destination you forward toward a PETR or just natively.

This is a good point, becasue if you just look in the BGP RIB to determine if something is NOT an EID, then one could be mistaken if PITRs are injecing EID-prefixes into the BGP RIB.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 3 Nov 2013 15:06:39 -0800

> Address not in special prefix != is not an EID

Luigi, I would say if Address is not a special prefix, it may be an EID but you can only find out by doing a mapping database lookup.

> Basically if it is n the special block you know it is an EID, if it is not in the special block you have no idea and you have to check.

Right, true.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 03 Nov 2013 18:10:08 -0500

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

---

From: Geoff Huston <[email-masked]>
Date: Mon, 4 Nov 2013 10:34:39 +1100

> Are we just arguing over size?

(speaking personally) Yes.

> 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…

And that is something that I would be perfectly comfortable with.

Geoff

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 3 Nov 2013 15:58:51 -0800

Thanks for reply Geoff. 

Closer to rough consensus,
Dino

> On Nov 3, 2013, at 3:34 PM, Geoff Huston <[email-masked]> wrote:
> 
>

---

From: Paul Vinciguerra <[email-masked]>
Date: Mon, 4 Nov 2013 13:30:11 +0000

I think this issue here is that the request is for a solution without a problem.

If you want to do experiments, lobby cisco to create a configuration option of a list of, say "known-EID 153.16.224.0/20".    

That can be configured for these experiments.

I have unused EID space, I am sure Sander and Cisco do as well. I have offered address space since we met back  in Orlando.

Once there is a track record and a real need for a block, then we have that much more evidence to support a future request.  If the experiments can be done this way, then the block wasn't actually needed in the first place.

But the way this is positioned, "LISP" wants an address block.  I am not sure what that means. Is it the working group? Is it Cisco? Who is going to be the gatekeeper? Who will decide what experiments have or do not have merit to use part of the block.

To float a real life LISP example:

We are part of another LISP experiment, the DDT.  DDT is a great technology enhancement, not for the database indexing aspect, but for map-server peering that allows for a more resilient topology.  I am all for experimentation.  

The public DDT roots experiment is a great example of such gating.  Cisco is the gatekeeper here.  Their DDT clients only allow for 4 roots per AFI.  And its filled by the gang of four: Cisco, InTouch, Us (Vinci Consulting/VXNet), and Verisign.  I was there when Mike Gibbs identified this over a year and a half ago and was assured it would be expanded.  It's still the same today.  Whether this is intentional control being influenced by the vendor, or just a lack of resources, the outcome to the end user is the same.  Depending on your relationship to the vendor, you can choose your position as to the reasons why.  

So I come back to my original question:  Why do you need this block?

Is is that you don't want to "rent" addresses?  
I would submit that this debate has cost all our employers more than any block would cost for a decade.  

Is it that the group doesn't want to renumber in the future?  
State it.  I think the group gets credibility for admitting it.

Is it going to minimize changes to the code?
Any experiment _is_ a code change, no?

Is the performance of a single large prefix orders of magnitude better that a handful of configured prefixes?  
You all would know that much better than I would.  

I personally think that more will get done with small agile groups that would be empowered to try something on their own and succeed or fail quickly, rather than this large command/control structure that requires merit to be proven before the experiment to show the merit of the experiment being tried.

Paul

________________________________________
From: [email-masked] [[email-masked]] on behalf of Luigi Iannone [[email-masked]]
Sent: Sunday, November 03, 2013 5:30 PM
To: Dino Farinacci
Cc: LISP mailing list list
Subject: Re: [lisp] LISP EID Block Size

Hi,

I agree with Dino,

Luigi

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Mon, 4 Nov 2013 14:46:38 +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 <[email-masked]> 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
>