Subject: [lisp] Control Plane Load (was RE: #27: ETR may claim a larger prefix than is delegated to it)

From: Ross Callon <[email-masked]>
Date: Tue, 7 Jun 2011 16:55:39 -0400

Dino recently said: 

> In practice the implementation test mask-lengths and don't install  
> coarse routes.

Which caused me to wonder: Is there a fixed prefix length (such as perhaps /24) which is the minimum prefix length that the implementation will install? If you get a shorter prefix length than this, then what do you do?

This is just one example (the one that happened to hit my mind today, I noticed others in re-reading the LISP spec this past weekend) of something that has been bothering me for a long time: We have no clue what the control plane load would actually be if LISP were widely deployed on a worldwide basis. I have seen a few papers which have tried to measure this, but all of the papers that I have seen (which I admit might not be all papers that exist) make an assumption such as: 

      The database is used to group 
	EID-to-RLOCs mappings with the granularity of existing BGP prefixes, 
	because, as for today, there is no sufficient information to predict 
	what will be the granularity of mappings in a LISP-enabled Internet. **

But it seems to be quite clear that the granularity of the EID-to-RLOC Database will be quite a bit finer than the current top-level Internet routing table. 

If we are serious about ever deploying LISP on a broad scale, then it would seem to me that we should try to get a rough upper bound on the potential cache thrashing and control plane load, rather than trying to measure optimistic lower bounds on what this might be. To me this implies that any study that is trying to measure the potential cache size, cache thrashing, or control plane load should assume that the granularity of the EID-to-RLOC database may be host routes (since "host routes" is the only thing that we can come up with that we can be moderately confident is a worst case scenario, rather than an optimistic scenario). 

Ross

** Note: This is a excerpt taken from "A Deep Dive into the LISP Cache" from "Networking 2011", 9-13 May 2011 in Valencia, Spain (http://www.networking2011.org/index.html).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Thursday, March 31, 2011 11:24 AM
To: Yakov Rekhter
Cc: lisp issue tracker; [email-masked]
Subject: Re: [lisp] #27: ETR may claim a larger prefix than is delegated to it

> Dino,
>
>> We did in -11. Here is the text at the end of section 12.
>>
>>    There is a potential security risk implicit in the fact that ETRs
>>    generate the EID prefix to which they are responding.  In  
>> theory, an
>>    ETR can claim a shorter prefix than it is actually responsible  
>> for.
>>    Various mechanisms to ameliorate or resolve this issue will be
>>    examined in the future, [LISP-SEC].
>
> The text should elaborate a bit on what  is exactly the "potential
> security risk", and specifically what are some of the implications
> of that risk.

"ETR can claim a shorter prefix than it is actually responsible for".

> Also, replace "In theory" with "Thus" (as the ETR can do this not just
> "in theory", but in practice as well).

In practice the implementation test mask-lengths and don't install  
coarse routes.

Dino

>
> Yakov.
>
>>
>> Dino
>>
>> On Mar 30, 2011, at 8:18 AM, lisp issue tracker wrote:
>>
>>> #27: ETR may claim a larger prefix than is delegated to it
>>>
>>>
>>> Comment(by yakov@...):
>>>
>>> If the base LISP spec is not going to have additional mechanisms to
>>> address over-claiming, then I would suggest to add to the base LISP
>>> spec
>>> some text that would just describe the issue of over-claiming, and
>>> state
>>> that handling this issue is outside the scope of the document.
>>>
>>> -- 
>>> ----------------------------------
>>> +-----------------------------------------
>>> Reporter:  hartmans-ietf@...        |        Owner:
>>>   Type:  technical              |       Status:  resolved
>>> Priority:  major                  |    Component:  draft-ietf-lisp
>>> Severity:  -                      |   Resolution:  fixed
>>> Keywords:                         |
>>> ----------------------------------
>>> +-----------------------------------------
>>>
>>> Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/27#comment 
>>> :5
>>>>
>>> lisp <http://tools.ietf.org/lisp/>
>>> LISP WG document issues
>>> _______________________________________________
>>> lisp mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/lisp
>>
>>

_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 7 Jun 2011 15:15:53 -0700

> Which caused me to wonder: Is there a fixed prefix length (such as  
> perhaps /24) which is the minimum prefix length that the  
> implementation will install? If you get a shorter prefix length than  
> this, then what do you do?

Do not put the EID-prefix in the map-cache.

> This is just one example (the one that happened to hit my mind  
> today, I noticed others in re-reading the LISP spec this past  
> weekend) of something that has been bothering me for a long time: We  
> have no clue what the control plane load would actually be if LISP  
> were widely deployed on a worldwide basis. I have seen a few papers  
> which have tried to measure this, but all of the papers that I have  
> seen (which I admit might not be all papers that exist) make an  
> assumption such as:

How about if I venture to say the same as the DNS query load? How  
would that make you feel?

> But it seems to be quite clear that the granularity of the EID-to- 
> RLOC Database will be quite a bit finer than the current top-level  
> Internet routing table.

Could be, but what determines the granularity is the locator-set that  
you associate with a prefix. But note the EID-prefix is only stored  
where it is being used and not everywhere. So that is the tradeoff.

If you are of the sort that doesn't care about packet stretch, then  
you could implement LISP like VA where must of the leafs would have a  
0.0.0.0/0 map-cache entry (we are doing this with our LISP-MN  
experiments for NAT-traversal reasons). And then that level would have  
more specifics (maybe like 4 /4s and so on), like Paul Francis has  
presented on a number of occasions.

Now please don't take this as a recommendation because I'm a fan of  
stretch equal to 1 in almost all cases.

> If we are serious about ever deploying LISP on a broad scale, then  
> it would seem to me that we should try to

Yes, we are serious.

> get a rough upper bound on the potential cache thrashing and control  
> plane load, rather than trying to measure optimistic lower bounds on  
> what this might be. To me this implies that any study that is trying  
> to measure the

That is why the drafts are experimental. We are gathering the data via  
the experiments.

> potential cache size, cache thrashing, or control plane load should  
> assume that the granularity of the EID-to-RLOC database may be host  
> routes (since "host routes" is the only thing that we can come up  
> with that we can be moderately confident is a worst case scenario,  
> rather than an optimistic scenario).

We see a lot of cache activity on the PITRs, even DOS attacks and in  
both a PC and router-based platforms, they seem to hold up but I agree  
we should get more data.

The mapping database system only has host routes when /32s map to a  
locator-set. This can happen in a variety of use-cases. But the /32s  
are not sent around the ALT, they are kept local to the registering  
Map-Server.

Think of the Map-Server as a "control-plane home agent".

Dino

>
> Ross
>
> ** Note: This is a excerpt taken from "A Deep Dive into the LISP  
> Cache" from "Networking 2011", 9-13 May 2011 in Valencia, Spain (http://www.networking2011.org/index.html 
> ).
>

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 8 Jun 2011 10:40:24 +0200

Hi Ross,

> 	what will be the granularity of mappings in a LISP-enabled Internet. **

As we state in that paper we do not have sufficient information to venture a different granularity. IMHO, the assumption we made is a valid starting point and we do not claim this is the future. LISP introduces new ways to perform TE and the way these features will be used is difficult to predict. 

If you have any idea for a different set of measurement/evaluation let's have a chat offline, may be I can help in evaluate different evolution assumptions/ideas.  

Luigi

p.s. thanks for reading our paper

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 8 Jun 2011 10:49:10 +0200

On Jun 8, 2011, at 00:15 , Dino Farinacci wrote:

> How about if I venture to say the same as the DNS query load? How would that make you feel?
> 

In the paper "On the cost of caching locator/ID mapping" (http://portal.acm.org/citation.cfm?id=1364663) there is a direct comparison with the DNS traffic, showing that DNS queries and  Map-Request have similar dynamics, with the latter generating less traffic. There are two things to consider: a) that study still assumes BGP granularity; b) measurements are done from a single vantage point (but using a different dataset would not change the general behavior that much IMO).

Luigi

---

From: Ross Callon <[email-masked]>
Date: Wed, 8 Jun 2011 12:05:19 -0400

> As we state in that paper we do not have sufficient information to venture a different
> granularity. IMHO, the assumption we made is a valid starting point and we do not claim
> this is the future. LISP introduces new ways to perform TE and the way these features
> will be used is difficult to predict. 

The paper does indeed clearly state that we don't currently have sufficient information to 
know what the granularity will be. 

> If you have any idea for a different set of measurement/evaluation let's have a chat
> offline, may be I can help in evaluate different evolution assumptions/ideas.  
>
> Luigi

Okay, will do. 

Thanks, Ross

---

From: Ross Callon <[email-masked]>
Date: Wed, 8 Jun 2011 12:14:17 -0400

> would that make you feel?

For a host, it would not worry me at all. If it had to be handled by the control plane of a PE router with a terabit data plane, it would scare me. 

>...

that was my impression...

>> to measure the...

The issue that concerns me relates to scaling. I have no doubt that this would work between 1,000 sites. Between 1,000,000,000 sites I have concerns. 

It seems fine to me to start with experiments, as long as we are clear that these are experiments and that we don't (currently) have any complete plan for LISP deployment that we agree will scale to cover the full Internet.

>> ...potential cache size, cache thrashing, or control plane load should  

My point was not that I actually expect the EID-to-RLOC Database to be primarily made up of /32's. My point is that this would give us an approximate worse case measure of the potential cache thrashing and control plane load (or at least some aspects thereof). This seems safer than having only an optimistic "much better than we expect to be realistic" measurement. Of course if the "better than best case" estimate says that we are fine, and the  "worse than worst case" estimate says that we are in trouble, then more thought and/or experiments would be needed to figure out which is more accurate. 

Ross

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: Tuesday, June 07, 2011 6:16 PM
To: Ross Callon
Cc: Yakov Rekhter; lisp issue tracker; [email-masked]
Subject: Re: Control Plane Load (was RE: [lisp] #27: ETR may claim a larger prefix than is delegated to it)

Yes, we are serious.

Dino