multi-homing fixes
Sean M. Doran
smd at clock.org
Thu Aug 30 01:39:41 UTC 2001
Iljitsch van Beijnum <iljitsch at muada.com> 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
would...)
I'm pretty sure I need further explanation to "get it"./
Sean.
More information about the NANOG
mailing list