This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] IPv6 PI for profit, webhosting and route deaggregation
- Previous message (by thread): [address-policy-wg] IPv6 PI for profit, webhosting and route deaggregation
- Next message (by thread): [address-policy-wg] IPv6 PI for profit, webhosting and route deaggregation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nick Hilliard
nick at inex.ie
Thu Mar 3 12:55:00 CET 2011
On 03/03/2011 09:30, Florian Weimer wrote: > With IPv4, you can aggregate routes before installing them into the > FIB (because only few of the routing decisions are semantically > meaningful), at least if the CPU which computes the FIB is a bit more > beefy than what is built into your smartphone. If your vendor still > isn't doing that, it might make sense to consider switching vendors, > or at least use it as a negotiating tool for getting better deals on > upgrades. You can certainly do this with lookup engines. Problem is that if you do it, you're breaking the deterministic rib->fib relationship model and replacing it with a nondeterministic system, which will probably work very well in almost all situations, but which has corner cases which fail catastrophically once you run out of lookup engine bits. Looking at it another way, automatic route aggregation creates overcommit between the RIB and the FIB. If that overcommit charge is exercised, things will break horribly. Nick
- Previous message (by thread): [address-policy-wg] IPv6 PI for profit, webhosting and route deaggregation
- Next message (by thread): [address-policy-wg] IPv6 PI for profit, webhosting and route deaggregation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]