Re: [lisp] Adding a "Distance Server" to the Map Resolver, to support scalable "anycast" and "disaster recovery"

[Dino Farinacci <[e-mail]>]

>>>>>> "Dino" == Dino Farinacci <[e-mail]> writes:
>
>    Dino> Why not just pick an ETR, watch for return traffic and try
>    Dino> to monitor RTTs between the sites for the data
>    Dino> flow.
> When would you transition to another etr?

I don't know. It would have to be local policy. But we have had to  
make these decision in fast-reroute algorithms as well. That is, if  
it's working and it's not broke, don't touch it.

I think you'll find from sites and ISPs alike that what they want with  
traffic engineering is a smooth usage of all their links. Rather than  
have hot spots on some links when other links are idle.

I really believe we don't have to be perfect and get this right. Best  
effort is really good enough.

> So, its sounds like we're discussing anycast here.  In that space,  
> the following concerns seem to be worth thinking about:

Well, anycast RLOCs are interesting because it's like p2p protocols.  
That is, you just use an address and someone has to be up. So you just  
use it. Of course, your quality may vary.

With LISP, anycast RLOCs can be used by you have to not use the loc- 
reach-bits. Because once someone says the RLOC is down, you obviously  
stop using any ETR that is assigned the anycast address. But you do  
want to switch from an anycast RLOC to another *when the last anycast  
RLOC goes down*. And sine the anycast ETRs really may not talk to each  
other (they can in LISP when the ETRs are deployed at the site), this  
might be more trouble then it is worth.

> * Some anycast protocols only have one round trip
>  ** balancing across all the possible destinatinos is important

Yes, and with the increase in the number of flows at a site, that will  
happen naturally.

>  ** To the extent that closeness for some closeness metric matters,  
> you need to get there on the first packet

If a destination site has RLOCs in the US and Europe and a LISP source  
site in Europe sends a map-request to the destination site, the  
destination site can return a map-reply with the Euro RLOCs with  
better priority then the US ones. So the Euro LISP site uses only the  
Euro RLOCs until they go down, in which case, the Euro site switches  
to the US RLOCs.

This is explained in draft-fuller-lisp-alt.

> * Some anycast protocols care a lot about stability: once you start  
> with one destination you have to keep that destination

I worked on AMT where anycast is used for discovery, but once you  
discover the server you latch on to a non-anycast address that you  
continue to use. This works as well when you use a transport protocol.  
Because the discovery with anycast addressing is done via packets and  
then when you get the latched real address (that doesn't move), you  
open the connection to the latched address.

Dino

> * TCP anycast is one limit of caring about stability