I don't know which of the lists this is going to should be trimmed, or I would gladly do so.
Excerpts from Benson Schliesser on Sun, Jan 25, 2009 05:53:49PM -0600: > 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? You peer with your upstream ALT routers based on prefixes they are responsible for, and where the ALT routers are doesn't (necessarily) follow physical topology. For any prefix there will probably be more than one upstream ALT router. Yes, you announce your prefix to all upstream ALT routers responsible for the shorter including prefix. Table size should be minimal, depending on how things are configured in your neighborhood. It could just be default from each. At most it would be a set of highest-level prefixes, maybe some special ones, and some longer ones for local efficiency. > 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. Allocation is decoupled from ALT routers. RIRs may run high-level ALT routers but there may be intermediate ones too. For a particular prefix there should be multiple redundant ALT routers. For the most part they need to be within the region in which they are most used, even though some prefixes may be allocated and then move to completely different continents. > 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. Right. The range in possible tactics is huge, and they all work as long as they speak the same protocol. Scott _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
