North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: multi-homing fixes

  • From: Sean M. Doran
  • Date: Wed Aug 29 21:42:00 2001

Iljitsch van Beijnum <[email protected]> writes:

| If we remove all non-essential
| information from a route, we finally arrive at the single thing that must
| always be encoded for each route individually: whether it is reachable or
| not. If we assign a bit of memory to every possible route

Is this a novel way of doing RIP and solving the split-horizon problem
by eliminating the "D" in "DV"?

Sorry for being obtuse, but what does this bit-vector really represent?
That neighbour A (a MAC address on a LAN, or a p2p interface or a 
VP/VC/DLCI/blah on an NMBA interface) is an OK next-hop towards 
prefix X?

Variations upon Random Routing will give you better results and
significantly reduce your storage requirements!

Or is it associated with a next-hop address with a recursive
lookup into another database (e.g. your IGP), such that each
known next-hop has one of these bit vectors associated with it?

Or do you mean something else by "reachability" than I do?

| An idea would be to assign /16s to geographic areas. Each ISP that has
| customers in that area would announce the /16, just like they would do
| now, but with an attached bitmap that indicates for which /24s this
| announcement is valid and for which it isn't. So 10 ISPs in one area would
| all announce the /16 with a 256 bit bitmap, so just 10 routes end up in
| the default-free zone instead of 500.

So, a per-prefix "holes" attribute in the form of a flattened Patricia Tree?    Where is the savings here?  Indeed, how do you avoid unflattening the bit-vector
when eventually building your Adj_RIB/Loc_RIB/FIB?   (Although admittedly
you probably save more space on the line than gzipping the data stream

I'm pretty sure I need further explanation to "get it"./