On 5-apr-05, at 15:50, Oliver Bartels wrote:
Would you please invest some time into discovering how grownups use email? The excessive funny interpunction hurts my eyes.
I would appreciate if you could stay with the subject and don't put things on the personal level.
Doing so if arguments are missing is not a good idea.
I think the headache I *get* #from# (/? §reading§ &your& +=$ messages is a good argument. If you choose to take that personal I can't stop you.
And please keep in mind that at least I am not a native English speaker.
So what? Most of us aren't. Does your native language use asterisks and smileys for punctuation?
Still, the routing table size problem is much more pressing than the depletion problem in IPv6 because even if the table size isn't fatal, it can get expensive easily, and when it gets fatal there is no way to fix it (even if we give up autoconfiguration).
Stay with math: There are about 20K AS'es and much less RIPE members.
Again: so what? How exactly is the number of AS numbers in use today relevant to the state of the network in the year 2040?
Thus : How many prefixes will be out caused by the new policy ? ;-)
Nobody knows. And it's irresponsible to adopt a policy if you can't know in advance what the result of adopting that policy is going to be.
Ah, but if you have N * 2 routing table entries, not only do you need 2 times the memory, but all else being equal you're going to see 2 times as many updates, so assuming you need to search N * 2 entries before you can update one (which fortunately isn't the case, the exact math is left as an excercise to the reader) you need 2 * 2 = 4 times as much memory bandwidth.
Believe me (we *developed our own BGP4 route server* down to the BGP packet level):
Updates are not the problem on the memory bandwidth, a typical DRAM doesn't care about 100K memory accesses. We are talking of >>multiple GBit memory bandwidths.
Well, worst case a 10 Gbps router has 67.2 nanoseconds to forward a packet before the next one comes in. At these speeds every single memory cycle is relevant. However, I must admit that I was a bit careless with updating the table and forwarding, things will have to get pretty bad before updating will run into memory bandwidth problems. But if and when that happens, we're in a deep pile of brown stuff as read random access memory bandwidth for large memories hasn't been able to keep up with progress in other areas in the past and it's unlikely that this will happen in the future.
*There is no way* to avoid the any-network-structure shortest-path calculation in a complex network.
Can you please point me to the part in the BGP spec that explains where in BGP the SPF calculations are done?
I'm not sure how having a new techology available before the old technology implodes is a problem.
If old technolgy means 10 year old 2501, then it is good when it implodes and providers are forced to invest into state-of-the-art hardware if they want to offer state-of-the-art services.
Yes, if you sell hardware. Not so much if you're the person who has to foot the bill. Obvously I'm not saying we should be able to run core networks on 15 year old hardware.