[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RRG] Properties of mapping solutions



On 9 jan 2008, at 20:05, Tony Li wrote:

Better yet, we should simply morph this into a more general discussion about properties of mapping solutions.

I'll change the subject line accordingly.

Presumably, the set of identifiers in the world is going to be very, very large. Simply pushing a full map to everywhere is going to be expensive, both in space and time. Pulling has latency issues. Reducing the number of places that have a full map seems like an attractive solution, but still leaves the push scalability problem, albeit with one less order of magnitude of an issue. For the places that have only a cache, how do you deal with cache misses?

What's the right approach here? Let's have a conceptual discussion and leave out the mechanisms, please.

Whatever we choose, we'll have to live with the unintended consequences. In the case of caching with dropping packets if there is a cache miss this will mean tightening the timing of the whole mechanism to reduce the number of lost packets from those misses as much as possible. It may even be bad enough that the transport people are forced to work around dropped TCP SYNs etc.

If we want reachability when there are cache misses, we essentially have to create a third infrastructure. (BGP/locators being the first and the caching ITR/ETR mechanism being the second.) I used to think this was an attractive solution, but now that I've seen the LISP variant that does this using GRE tunnels I'm having second thoughts. Additional issues are the QoS differences between packets that benefit from the cache and ones that don't, the potential for DoS attacks on the third infrastructure and the issue that we don't know how large the cache is going to need to be.

If we push out the static mapping info (EID prefix -> RLOCs) as well as the dynamic mapping info (which RLOCs are reachable) we're basically reinventing BGP. It's fairly obvious that we can achieve a single order of magnitude better scaling than we have currently for IPv4 by working per-AS rather than per-prefix, but the question is if we can do much better than that, and if not, whether a single order of magnitude is worth the trouble, especially as this only addresses the RIB issue and not the FIB issue.

We can also push out the static mapping info but use a pull model for the dynamic info. Although this doesn't affect the amount of data that needs to be pushed out significantly, it does make this data many orders of magnitude less volatile, making RIB processing a lot easier. This does import some of the downsides from the pull model, except that we can observe that today, most links are up most of the time, so we can probably assume that any RLOC that we choose is reachable and be correct 98% of the time or more, so there is probably no need for a third infrastructure to avoid lost packets on cache misses. (Especially considering that a good part of all prefixes isn't multihomed, anyway.) This model also requires just a bare minimum of signaling between ITRs and ETRs.

Last but not least, any model where the work can be done in parallel rather than serially gives us at least a fighting chance to get back on the commodity price curve. With some really hard work it's probably possible to make a BGP implementation that runs on loosely coupled parallel processors, but a protocol designed with this in mind will make this much easier. Part of this is that you can make an operational tradeoff between bringing the routing information to where the packets are and bringing the packets to where the routing information is.

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg