[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