| Assigning a prefix to a continent wouldn't be a good idea, because | that way every regional ISP has to Well, that's what's been happening for a few years now... But consider this: | announce the very large bitmap for the entire continent, while most of it | contains just zeros. Per metro area would be better. But two ISPs that | have many multi-homing customers in common could use a prefix for just the | two of them, regardless of geography. Instead of a bit-vector with lots of zeros, do run-length encoding of the bits you don't have, or the bits you do have. Now compare that to doing automatic aggregation, so that instead of 16 contiguous 1 bits you introduce a prefix of x.x.x.x/(n-4). See what I mean by your bit-vector just being another representation (possibly more efficient on the wire) of what's already there? That is, you are noticing that for any given abstraction boundary that is non-topological, exception routes (more specifics or described with your bit-vector) have to be introduced when a black hole would otherwise result, and may be desirable to optimize routing. This is why the RIRs' prefixes are announced as relatively long chunks of /20s or so rather than the /8s or shorter as they are gotten from IANA/ICANN/ASO/thin air/whatever. If you try to take the same approach and have a "SRIR" (s = sub), you will see a carving up of the prefixes over time, in the same fashion. The ONLY way to avoid this right now is to have addressing exactly match topology. The problem here of course is that nobody will agree on which N entities are "top level". | I'm mostly trying to solve the memory problem, but it should also help | with (but certaintly not completely solve) the processing problem. It doesn't really do either. You have made a few time-vs-space tradeoffs which move the problems around a bit, but don't actually eliminate them. | Since an updated bitmap is always the same size and it updates many routes | at a time, it should take less CPU power to process the updates. Parsing the received updates is not the major worry, and your fix is targetted on the syntax of the updates, rather than their semantics, which is where the problem lies. | I think the only way to really know what the processing benefits of all of | this are is implementing it, or run detailed simulations, but those | require pretty much an implementation as well. Well, I won't stop you from testing an implementation or two. Write back to the list (or better yet, the IDR list) when you're done. Let me take some of your text out of context and agree with it fully: [A permanently stable holes-in-CIDR-blocks environment exists] | Only if there is a limit on the number of ISPs. I don't think there | is such a [practical rather than absolute] limit The problem with metro-based addressing is that the statement above is equally true for it as for PA addressing. Sean.
Sean M. Doran wrote:
Let me take some of your text out of context and agree with it fully:
[A permanently stable holes-in-CIDR-blocks environment exists] | Only if there is a limit on the number of ISPs. I don't think there | is such a [practical rather than absolute] limit
The problem with metro-based addressing is that the statement above is equally true for it as for PA addressing.
Understanding the truth in that general statement, I would like to know if anyone sees a significant difference in the number of holes created by each approach. Handwaving can go either way, so the question is given real topologies and multi-homing goals, is there enough difference in the number of holes created to bias the approach? Responses should go to multi6@ops.ietf.org Tony
participants (2)
-
smd@clock.org
-
Tony Hain