On 2/6/12 06:48 , Glen Kent wrote:
One example that comes to my mind is that a few existing routers cant do line rate routing for IPv6 traffic as long as the netmask is < 65.
I'm sorry that's bs. It's trivial to partition a cam in order to do /128s in a single lookup. that's actually the worst case scenario, a more efficient packing will result in lower power consumption and memory use. potentially that results in multiple lookups which in no way implies you're not going to meet your pps target.
Also routers have a limited TCAM size for storing routes with masks
64. These routers were primarily designed for IPv4 and also support IPv6.
All routers don't use tcams for fib lookups. M T MX devices do not use cams for fib for example. limited cam partitioning schemes exist in ip4 as well, big cams have a cost power wise, and bom wise, parititioning them in a way that meets the developers view of the distribution of route lengths can be beneficial and be used to build products suitable for lots of roles but probably not being a internet core router. standard juniper ex8200 line cards for example are just peachy for a datacenter but not so much for a internet core device and the bom feature set and price reflect that.
I was wondering what we could optimize on if we only design an IPv6 router (assume an extreme case where it does not even support IPv4).
right now if I take a platform that uses a large CAM like a force 10 e1200i ej line card, I can adjust the cam allocation to do basically nothing but ipv6, given the default balance between ipv4 and ipv6 doing so more that doubles the number of ipv6 routes I can expect to hold.
Glen
Best regards, Daniel
-- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0