Re: addition of TLV to locator ID or locator ID set

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 22-sep-2005, at 18:14, Jason Schiller (schiller@uu.net) wrote:

> I think the biggest problem is doing something analogous to current  
> IPv4
> BGP "best" path.

I still don't know what you mean here. These days, 85% of the  
internet is reachable over either two or three hops. So "best" is  
largely meaningless here.

Also note that in BGP we only get to use the "best" path, while the  
shim allows using different paths in quick succession or at the same  
time.

> At a glance this seems to have all of the
> same problems that path failure detection has, with some additional
> problems thrown in because you may have to test multiple paths to  
> make a
> compairson instead of only one.

Testing a large number of paths is exactly the situation we're  
desperately trying to avoid. _Especially_ when there is no failure in  
the first place. That's also the reason why the current assumption is  
that we don't start rewriting addresses until there is a failure.  
However, if there is a good case for doing this, we can reconsider.  
But in this case, it becomes even more important that we don't add  
overhead to packets.

An interesting option would be for a large service to publish  
addresses for intermediate boxes in the DNS. When these intermediate  
boxes then receive a TCP SYN, they first try to set up shim state  
toward the _real_ addresses for the service (at which time  
sophisticated load balancing decisions can be made) and then the  
initiator repeats the SYN.

(PS. I'm glad I left UUNET before they started handing out @mci.com  
email addresses...)