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 <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
