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

[John Zwiebel]

FWIW:
The sub-optimal routing will only be for the LISP map-request.
The reply and all encapsulated data traffic is between RLOCs
The ALT is merely there to provide the correct mapping.

Also, since a map-reply from any ETR for a given site will
provide you with all the RLOCs for that site, there is no
need to advertise any sub-prefix into the ALT.  Rather you
would advertise the most highly aggregated route you have
for your EID-site.  So the ALT table should be considerably smaller.


On Jan 25, 2009, at 11:49 AM, Benson Schliesser wrote:

> Dave-
>
> On Sun, Jan 25, 2009 at 3:26 PM, David Meyer <dmm at 1-4-5.net> wrote:
>>        This is just an artifact of the way I built it. You could
>>        put up a ALT tunnel betwen Savvis and L3 if that was of
>>        interest (and Savvis & L3 wouldn't have to further
>>        advertise those routes to the rest of the ALT). Also,
>> ...
>>        Or am I answering the wrong question?
>
> I think you're answering the right question from the LISP-ALT
> perspective. It theoretically exists for other solutions in the same
> class, too, i.e. solutions that create a stretched path in order to
> follow address-assignment topology instead of underlying forwarding
> topology.
>
> In the LISP-ALT case, however, I'd like to explore your answer a bit
> further. Does this suggest that the answer is for my ALT AS to peer
> with all of my existing Internet peers, if I want to avoid suboptimal
> forwarding? If I did so, how would my ALT routing table size compare
> to my current routing table size? I'm imagining them the same size
> (i.e. comprised of supernets learned by my peers as well as
> less-specifics learned when my peers' customers multihome) but I might
> be missing something.
>
> Cheers,
> -Benson
> _______________________________________________
> lisp mailing list
> lisp at ietf.org
> https://www.ietf.org/mailman/listinfo/lisp