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

Re: Granularity (was Re: [RRG] ALT + NERD is inelegant & inefficient, compared to APT or Ivip)



On 28 jan 2008, at 17:57, Brian Dickson wrote:

I completely disagree. There is no reason to make the assumptions you make.
I think you meant to say, "I *see* no reason...".

The latter follows naturally from the former.  :-)

Sometimes I don't do a good enough job of explaining things, so I'll try again: * As Tony Li pointed out, if you allow host granularity, you need about 10^11 rather than 10^8 map entries - if you keep them in the map database

I hesitate to agree on the numbers, but obviously any number that includes host granularity will be higher than one that doesn't.

* If you want to keep host granularity stuff out of the map database, you have to encode it in the address

What do you mean? Encode the AS in the address? For N > 1 this requires that you can dynamically do a "reachable match first" lookup in your routing tables.

So, there are three possibilities for host granularity:
* No host granularity
* mapping size 10^11 (not suitable for push)
* special case for N=2 only

We already have MIP so no host granualirity would be a completely reasonable choice.

Personally, I'd say: keep the host out of the mapping system, but allow per-host redirects. This makes the first packets always slower and maybe even all of them if the ITR can't spare the state. However, this leaves plenty of opportunities for optimization on the table (including simply obtaining location dependent addresses after a move), while pushing more entries in FIBs will only work for so long, even if the RIB isn't a problem.

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