|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: multi-homing fixes
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 would...) I'm pretty sure I need further explanation to "get it"./ Sean.
|