Hi, Most routers today are basically IPv4 routers, with IPv6 thrown in. They are however designed keeping IPv4 in mind. With IPv6 growing, if we were to design a native IPv6 router, with IPv4 functionality thrown in, then is it possible to design a more optimal IPv6 router, than what exists today? Glen
On 2/5/12 17:20 , Glen Kent wrote:
Hi,
Most routers today are basically IPv4 routers, with IPv6 thrown in. They are however designed keeping IPv4 in mind.
With IPv6 growing, if we were to design a native IPv6 router, with IPv4 functionality thrown in, then is it possible to design a more optimal IPv6 router, than what exists today?
Asic based forwarding engines with ipv6 support are more than a decade old at this point. If one looks at an asr9000 or an MX or T that looks like an ipv6 router to me.
Glen
On Mon, 06 Feb 2012 06:50:54 +0530, Glen Kent said:
Most routers today are basically IPv4 routers, with IPv6 thrown in. Not sure if this statement is troll bait or flame bate. Probably both. ;)
I see Joel has already confirmed my memory that vendors had ASICs doing IPv6 forwarding last century.
With IPv6 growing, if we were to design a native IPv6 router, with IPv4 functionality thrown in, then is it possible to design a more optimal IPv6 router, than what exists today?
OK, I'll bite. What would qualify as a "native IPv6" router? Is this another concept as silly as "hardware vs software based" routers? And whaqt would be the definition of "more optimal"? Just fixing the current feature parity mismatch with the IPv4 side, or you got some new routing paradigm in mind or something?
On Sun, Feb 05, 2012 at 09:07:57PM -0500, Valdis.Kletnieks@vt.edu wrote:
OK, I'll bite. What would qualify as a "native IPv6" router?
Perhaps those which were designed with IPv4+IPv6 in mind from day 1, both in hardware and software - like Juniper/JUNOS. In contrast to other the gear where IPv6 was always an aftermath, which shows in both hardware (limits of performance, functionality and scaling) as well as software (every feature gets implemented twice, even if the feature itself is completely AFI-agnostic - see e.g. IOS/IOS-XE [can't comment on XR]). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
In a message written on Mon, Feb 06, 2012 at 08:34:26AM +0100, Daniel Roesen wrote:
itself is completely AFI-agnostic - see e.g. IOS/IOS-XE [can't comment on XR]).
IOS-XR is fully AFI-agnostic, as far as I can tell. It also updated the CLI to be consistently "ipv4 ..." or "ipv6 ..." with similar syntax. I think also that all of the platforms on which IOS-XR runs (GSR, CRS-1/3, ASR9000) can all run full line rate IPv6 in hardware, with features. While much of the IOS-XR vrs JunOS is personal preference, IOS-XR has one very cool feature. You can pass parameters in route policy. Many networks maintain slightly different versions of policies like "peer-in/peer-out" due to various load balancing or preference needs, with a 5-15 stanza policy repeated over and over. When you have to update one of the stanzas in all policies it becomes a big mess. In IOS-XR, you can write a generic policy and then call with with parameters: route-policy generic-out($routeCommunity) ... ! Do all the common things if community matches-any $routeCommunity then accept endif drop end-policy community-set send-to-private-peers 1234:5678 end-set route-policy private-peer-out apply generic-out(send-to-private-peers) end-policy community-set send-to-public-peers 1234:4321 end-set route-policy public-peer-out apply generic-out(send-to-public-peers) end-policy With a little bit of careful thought you can really collapse down the policy to be much shorter, easier to understand, and have almost no cut-and-paste in it, which should reduce errors when updating in the future. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
You can do the same with Junos (calling a 'generic' policy as a sub-routine). Sent from my iPhone On Feb 6, 2012, at 6:18, Leo Bicknell <bicknell@ufp.org> wrote:
In a message written on Mon, Feb 06, 2012 at 08:34:26AM +0100, Daniel Roesen wrote:
itself is completely AFI-agnostic - see e.g. IOS/IOS-XE [can't comment on XR]).
IOS-XR is fully AFI-agnostic, as far as I can tell. It also updated the CLI to be consistently "ipv4 ..." or "ipv6 ..." with similar syntax. I think also that all of the platforms on which IOS-XR runs (GSR, CRS-1/3, ASR9000) can all run full line rate IPv6 in hardware, with features.
While much of the IOS-XR vrs JunOS is personal preference, IOS-XR has one very cool feature. You can pass parameters in route policy. Many networks maintain slightly different versions of policies like "peer-in/peer-out" due to various load balancing or preference needs, with a 5-15 stanza policy repeated over and over. When you have to update one of the stanzas in all policies it becomes a big mess. In IOS-XR, you can write a generic policy and then call with with parameters:
route-policy generic-out($routeCommunity) ... ! Do all the common things if community matches-any $routeCommunity then accept endif drop end-policy
community-set send-to-private-peers 1234:5678 end-set
route-policy private-peer-out apply generic-out(send-to-private-peers) end-policy
community-set send-to-public-peers 1234:4321 end-set
route-policy public-peer-out apply generic-out(send-to-public-peers) end-policy
With a little bit of careful thought you can really collapse down the policy to be much shorter, easier to understand, and have almost no cut-and-paste in it, which should reduce errors when updating in the future.
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Mon, Feb 6, 2012 at 1:04 PM, Daniel Roesen <dr@cluenet.de> wrote:
On Sun, Feb 05, 2012 at 09:07:57PM -0500, Valdis.Kletnieks@vt.edu wrote:
OK, I'll bite. What would qualify as a "native IPv6" router?
Perhaps those which were designed with IPv4+IPv6 in mind from day 1, both in hardware and software - like Juniper/JUNOS. In contrast to other
Not just that. I had meant that the HW is optimized for IPv6 and also as a side effect does IPv4. This router could be designed assuming that you'll have more IPv6 traffic to forward than IPv4.
the gear where IPv6 was always an aftermath, which shows in both hardware (limits of performance, functionality and scaling) as well as software (every feature gets implemented twice, even if the feature itself is completely AFI-agnostic - see e.g. IOS/IOS-XE [can't comment on XR]).
Yes, thats what i had in mind. 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. Also routers have a limited TCAM size for storing routes with masks > 64. These routers were primarily designed for IPv4 and also support IPv6. 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). Glen
Best regards, Daniel
-- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
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
With IPv6 growing, if we were to design a native IPv6 router, with IPv4 functionality thrown in, then is it possible to design a more optimal IPv6 router, than what exists today?
OK, I'll bite. What would qualify as a "native IPv6" router? Is this another concept as silly as "hardware vs software based" routers?
Join them and create a router where IPv6 is ASIC-forwarded and IPv4 gets to use a CPU. Market perspectives for such a product are very shy, but would fit the description. Rubens
With IPv6 growing, if we were to design a native IPv6 router, with IPv4 functionality thrown in, then is it possible to design a more optimal IPv6 router, than what exists today?
OK, I'll bite. What would qualify as a "native IPv6" router? Is this another concept as silly as "hardware vs software based" routers?
Join them and create a router where IPv6 is ASIC-forwarded and IPv4 gets to use a CPU. Market perspectives for such a product are very shy, but would fit the description.
And where half the useful features just don't support IPv6. Make it support draft-ietf-mpls-ldp-ipv6 and we're away :) -- Leigh Porter ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
Glen Kent wrote:
With IPv6 growing, if we were to design a native IPv6 router, with IPv4 functionality thrown in, then is it possible to design a more optimal IPv6 router, than what exists today?
It depends on what you want routers to do. As I am working on Tbps photonic routers with fiber delay lines, the bottleneck is at constant time (nano seconds order) electric route look up. There, several simple 4M*16bit SRAMs is fine for IPv4 with mostly /24 routing table entries. IPv6 was better because TLA had was merely 13bit long with only 8192 entries. However, as the idea of TLA was abandoned long before and a lot more than /24 is, seemingly, necessary for route look up of IPv6 backbone, I'm afraid IPv6 needs large amount of power consuming content addressable memories. Without any (defacto) standard prefix length at the IPv6 backbone, it is simply impossible to say "optimal". Masataka Ohta
participants (9)
-
Daniel Roesen -
Glen Kent -
Joel jaeggli -
Leigh Porter -
Leo Bicknell -
Masataka Ohta -
Rafael Rodriguez -
Rubens Kuhl -
Valdis.Kletnieks＠vt.edu