John- I agree, in LISP the volume of ALT traffic is very small versus the volume of encapsulated data traffic. This is one of the primary reasons I like LISP-ALT as a near-term solution, to be honest.
The ALT peering, though, isn't 100% clear to me yet. Sorry if I'm just slow today or have forgotten something that's already been discussed. (The recent holiday seems to have effectively cleared my mind.) 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? 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 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. 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. Cheers, -Benson PS - I hate to say this, but I will volunteer to edit a draft covering this topic if one or more LISP researchers will help write it. On Jan 25, 2009 4:22 PM, "John Zwiebel" <[email protected]> wrote: 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 ... > > > _______________________________________________ > lisp mailing list > > [email protected] > https://www.... >
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
