[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