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?
Yes, you would. And you would peer at the level before the aggregation level router. So in the real world, you would peer with sub-parts of your region's registry.
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
Not divert, but you want the shortest path to your site for Map- Requests. So each of your xTRs will have GRE tunnels where their "tunnel source <foo>" configuration will have <foo> be the locator address from each attached upstream.
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.
Right, no deaggregation anywhere. You don't have to TE with more specific injection on the ALT, you use your tunnel locators for this.
Also, we want you to have a low opex xTRs, so when *you do not run BGP on your xTRs*, it will be your upstreams will "redistribute static tag <foo>". And they won't need to deaggregate as well because you will be *within* their aggregation level.
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.
Mappings get refreshed locally in the xTR based on data flow. So you don't need to continually Map-Request the site. Plus, you can use the old ARP trick. That is, give yourself enough time before the entry times out, to request to see if the mapping is still current. And only do that when there is data flow against the entry.
Dino _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
