Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures

[Brian Dickson <briand@ca.afilias.info>]

Tony Li wrote:
> On Jan 9, 2008, at 6:27 AM, Eliot Lear wrote:
>
> > This discussion about CEF perhaps should spur some research.  What 
> > percentage of the world's networks would need to be cached AT THE 
> > EDGES today?
>
>
> Better yet, we should simply morph this into a more general discussion 
> about properties of mapping solutions.
>
> Presumably, the set of identifiers in the world is going to be very, 
> very large.
There are quantifiers that we may want to place on this, including 
discussing granularity of mappings.

How long will it take to reach specific (arbitrary) size(s), for 
instance? E.g., to reach the current level of multihoming sites, which 
is roughly the number of 16-bit ASNs (65k)?

What do we think the growth curve will look like, and what the maximum 
rate of growth will be in, for example, 3 years' time?
(My guess is the curve will look like a disease propagation curve, with 
the rate being about C*(x)*(1-x) where x is the percentage "with" 
multihoming, and C is some constant.
> 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.

The scaling issue is going to hit ITRs, almost exclusively.

ETRs will only need to know about RLOC->EID mappings (either popping off 
the outer tunnel header, or a deterministic transmogrification, possibly 
statically configured), which are very local in scope.

I think one question that might be helpful is, are there ways to scale 
things somewhat arbitrarily (possibly at modest hardware cost)?

Consider the following:

host -> mini-ITR -> (set of ITRs) -> (Internet) -> ETR -> host

I.e., the map is split across a set of ITRs, and front-ended with a box 
that knew how the EID space was partitioned across those ITRs.
The upper limit on per-ITR capacity (for push or pull of map contents) 
doesn't affect the size limit of the whole map. It scales arbitrarily.
(The specific mechanism choices of how to accomplish this are details 
that don't affect the concept.)

The scaling issue then becomes economic rather than technical.

As for map data propagation - the map data *should* be relatively 
static, since it won't contain reachability info (ideally).
Any combination of technologies (BitTorrent, AXFR/IXFR (DNS concept), 
multicast, ftp, LDAP) can be considered.
Scoping and localizing the data, authentication, delegation, and 
synchronization, are the major issues or trade-offs.

Brian D



--
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