[rrg] [lisp] Economic issues of long-path / stretched routing

[Dino Farinacci]

> My single-homed xTR (savvis) has one ALT peer right now (asp) and he  
> announces an aggregate net that covers my EID prefix. That's great  
> from a routing scale perspective. However if I were to multihome to  
> another net (dmm, for example) wouldn't I have to announce my EID  
> into the ALT via that path if I wanted to continue serving that EID  
> during an outage of my primary (asp) connectivity?
>

Yes, you would. And you would peer at the level before the aggregation  
level router. So in the real world, you would peer with sub-parts of  
your region's registry.

> At the very least it has to be announced such that my primary  
> upstream sees it and can divert map-requests to my secondary path.  
> So do all of my xTRs need to have ALT tunnels to all of my EID
>

Not divert, but you want the shortest path to your site for Map- 
Requests. So each of your xTRs will have GRE tunnels where their  
"tunnel source <foo>" configuration will have <foo> be the locator  
address from each attached upstream.

> allocators in order to avoid de-aggregation in the ALT tables while  
> maintaining fault tolerant connectivity? What happens if an AS-wide  
> fault takes down all of my allocator's ALT routers? I understand  
> that my RLOCs are still aggregated by the underlying network's  
> routing regardless.
>

Right, no deaggregation anywhere. You don't have to TE with more  
specific injection on the ALT, you use your tunnel locators for this.

Also, we want you to have a low opex xTRs, so when *you do not run BGP  
on your xTRs*, it will be your upstreams will "redistribute static tag  
<foo>". And they won't need to deaggregate as well because you will be  
*within* their aggregation level.

> It would be good to discuss what all of this looks like for network  
> engineering purposes. For instance from the perspective of ALT  
> traffic engineering, an end-site xTR with end users surfing the web  
> will probably have a moderate collection of EID mappings that stay  
> refreshed (Google, Twitter, corp intranet, etc) and a small  
> collection of mappings that get used and expire (my blog, which  
> nobody reads twice). This is different from an xTR in front of a  
> public website, which will basically build a huge collection of  
> mappings and have to worry more about the database size than  
> anything else.
>

Mappings get refreshed locally in the xTR based on data flow. So you  
don't need to continually Map-Request the site. Plus, you can use the  
old ARP trick. That is, give yourself enough time before the entry  
times out, to request to see if the mapping is still current. And only  
do that when there is data flow against the entry.

Dino