Are SW upgrades needed in MPLS core networks?
Hi, Just taking a quick poll, as we don't use MPLS and I think this is an interesting thing to know. One of the many (maybe misguided) arguments for MPLS is that you don't need to perform softwqare (or other similar) upgrades in the core network, and the "intelligence" is pushed to the to the edges of the MPLS cloud. I'd like to get a feel how correct this "argument" is in practice. So, if you have had to upgrade the core equipment, please tell. If you haven't (due to the "MPLS design"), that might be interesting as well. If you had to upgrade, please also indicate the reason for that (fixing bugs ("minor upgrade")? providing new features, if so which features? etc.?) Please respond off-list if you feel so. Thanks. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Hi, Ok, let me summarize this off-list poll (7 answers). Every single responder testified that upgrades are still needed. No news. The type of upgrades can be separated in two: bugfixes (like bugs in MPLS forwarding, tags, security vulnerabilities, etc.), and feature additions. (About) everyone also seemed to state that upgrades have been made to get new features. These often included e.g.: - to support newer hardware, - to make interfaces accept higher MTU (e.g., 1536 instead of 1500), - to support new features, like Class-of-Service + AQM - to facilitate changes and evolution in RSVP, LDP, etc. As one responder stated, the true advantage is MPLS VPNs, the rest is hype. (My note: even though the VPNs can be achieved differently at little pain, as one other responder stated.) The reasoning for this poll was to try to gauge the willingness of the operators to make SW upgrades to support new features in the MPLS core networks. I had one feature in particular in mind, IPv6. Based on the results it seems to be easy to conclude that about the only reason to put IPv6 over [v4 over] MPLS on the networks (rather than directly on top of the physical infrastructure) is due to the other reason, because some vendors have sold crappy hardware which does not support IPv6, or does not offer sufficiently good IPv6 performance. On Mon, 26 Jan 2004, Pekka Savola wrote:
Just taking a quick poll, as we don't use MPLS and I think this is an interesting thing to know.
One of the many (maybe misguided) arguments for MPLS is that you don't need to perform softwqare (or other similar) upgrades in the core network, and the "intelligence" is pushed to the to the edges of the MPLS cloud.
I'd like to get a feel how correct this "argument" is in practice. So, if you have had to upgrade the core equipment, please tell. If you haven't (due to the "MPLS design"), that might be interesting as well. If you had to upgrade, please also indicate the reason for that (fixing bugs ("minor upgrade")? providing new features, if so which features? etc.?)
Please respond off-list if you feel so. Thanks.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
----- Original Message -----
Based on the results it seems to be easy to conclude that about the only reason to put IPv6 over [v4 over] MPLS on the networks (rather than directly on top of the physical infrastructure) is due to the other reason, because some vendors have sold crappy hardware which does not support IPv6, or does not offer sufficiently good IPv6 performance.
Even hardware with good IPv6 performance seems to forward at half the rate of IPv4/MPLS packets; may be accelerated forwarding by tag switching, the idea that originated MPLS, is a good thing ? Rubens
Based on the results it seems to be easy to conclude that about the only reason to put IPv6 over [v4 over] MPLS on the networks (rather than directly on top of the physical infrastructure) is due to the other reason, because some vendors have sold crappy hardware which does not support IPv6, or does not offer sufficiently good IPv6 performance. Even hardware with good IPv6 performance seems to forward at half the rate of IPv4/MPLS packets;
we call that crappy hardware randy
Based on the results it seems to be easy to conclude that about the only reason to put IPv6 over [v4 over] MPLS on the networks (rather than directly on top of the physical infrastructure) is due to the other reason, because some vendors have sold crappy hardware which does not support IPv6, or does not offer sufficiently good IPv6 performance. Even hardware with good IPv6 performance seems to forward at half the rate of IPv4/MPLS packets;
we call that crappy hardware
Based on such point of view, non-crappy hardware would be: (blank) and crappy hardware would be (blank), could you fill the blanks ? Rubens
On Fri, Feb 06, 2004 at 04:05:52PM -0200, Rubens Kuhl Jr. wrote:
Based on the results it seems to be easy to conclude that about the only reason to put IPv6 over [v4 over] MPLS on the networks (rather than directly on top of the physical infrastructure) is due to the other reason, because some vendors have sold crappy hardware which does not support IPv6, or does not offer sufficiently good IPv6 performance. Even hardware with good IPv6 performance seems to forward at half the rate of IPv4/MPLS packets;
we call that crappy hardware
Based on such point of view, non-crappy hardware would be: (blank) and crappy hardware would be (blank), could you fill the blanks ?
As with so many other situations, the blanks can be filled in with "Juniper" and "Cisco", in that order. http://www.juniper.net/company/presscenter/pr/2001/pr-011128.html -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Even hardware with good IPv6 performance seems to forward at half
the
rate
of IPv4/MPLS packets;
we call that crappy hardware
Based on such point of view, non-crappy hardware would be: (blank) and crappy hardware would be (blank), could you fill the blanks ?
As with so many other situations, the blanks can be filled in with "Juniper" and "Cisco", in that order.
I don't get why Juniper and Cisco trie-lookup forwarding would differ in comparing IPv4 and IPv6; Juniper does a 8+1+1+1+1+... search until a leaf node is found, while Cisco does 16+8+8 (or something near it but still with 3 phases); for both architetures, IPv6 longer addresses implies walking more deeply into the tree in order to find where to route. Just to be sure, my point here is not where the effective IPv6 performance suits one needs or not, but wether a router that can forward <amount> Mpps of IPv4/MPLS packets can also forward the same amount of IPv6 packets per second. Rubens
I don't get why Juniper and Cisco trie-lookup forwarding would differ in comparing IPv4 and IPv6; Juniper does a 8+1+1+1+1+... search until a leaf node is found, while Cisco does 16+8+8 (or something near it but still with 3 phases); for both architetures, IPv6 longer addresses implies walking more deeply into the tree in order to find where to route.
ahhh. you have been watching marketing architecture presentations. otoh, we have been using real routers. randy
On Fri, 6 Feb 2004, Randy Bush wrote:
I don't get why Juniper and Cisco trie-lookup forwarding would differ in comparing IPv4 and IPv6; Juniper does a 8+1+1+1+1+... search until a leaf node is found, while Cisco does 16+8+8 (or something near it but still with 3 phases); for both architetures, IPv6 longer addresses implies walking more deeply into the tree in order to find where to route.
ahhh. you have been watching marketing architecture presentations.
otoh, we have been using real routers.
Randy, What is the most PPS you've done with IPv6 on what platforms? Tell us about your work with real routers. Some of us live in elbonia where the only routers we have rely on immigrants hand-delivering packets. (I.e. if you're going to swing the snob stick, at least back it up and show us something) Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
Rubens Kuhl Jr. wrote:
I don't get why Juniper and Cisco trie-lookup forwarding would differ in comparing IPv4 and IPv6; Juniper does a 8+1+1+1+1+... search until a leaf node is found, while Cisco does 16+8+8 (or something near it but still with 3 phases); for both architetures, IPv6 longer addresses implies walking more deeply into the tree in order to find where to route.
There is another factor at play here which is memory bandwidth at the lookup engine. If you have to look deeper into the packet than you can accomplish by using single spin trough the thing that fetches x bit wide words from the packet, you´ll effectively half your packet rate. Doing 8+1+1+1+1+... would seem wasteful for IPv6 with the current address allocation scheme, are you sure that´s what´s used for IPv6 too? Pete
There is another factor at play here which is memory bandwidth at the lookup engine. If you have to look deeper into the packet than you can accomplish by using single spin trough the thing that fetches x bit wide words from the packet, you´ll effectively half your packet rate.
Yes, that might explain the performance halving in some architetures (may be it's what happens with Sup 720, may be not), instead of longer lookup cycle.
Doing 8+1+1+1+1+... would seem wasteful for IPv6 with the current address allocation scheme, are you sure that´s what´s used for IPv6 too?
I'm not. Juniper isn't very open about this matter, and I only got confirmation of that for IPv4. Rubens
Rubens Kuhl Jr. wrote:
There is another factor at play here which is memory bandwidth at the lookup engine. If you have to look deeper into the packet than you can accomplish by using single spin trough the thing that fetches x bit wide words from the packet, you´ll effectively half your packet rate.
Yes, that might explain the performance halving in some architetures (may be it's what happens with Sup 720, may be not), instead of longer lookup cycle.
I have the understanding that catalyst line uses 48 bit access. Wonder where they got that from :-) So when forwarding to single end hosts, you might end up with one third of the performance of IPv4. However I have not confirmed this but you might want to bother your sales engineer.
Doing 8+1+1+1+1+... would seem wasteful for IPv6 with the current address allocation scheme, are you sure that´s what´s used for IPv6 too?
I'm not. Juniper isn't very open about this matter, and I only got confirmation of that for IPv4.
I think they also put that in a public document, probably due to the fact that Cisco put theirs in first. I haven´t seen a document discussing structures either one uses for IPv6 but I have been told they are "different for performance reasons". Pete
On Fri, Feb 06, 2004 at 05:32:57PM -0200, Rubens Kuhl Jr. wrote:
Doing 8+1+1+1+1+... would seem wasteful for IPv6 with the current address allocation scheme, are you sure that´s what´s used for IPv6 too?
I'm not. Juniper isn't very open about this matter, and I only got confirmation of that for IPv4.
Hrm, I could have sworn it was actually 16-1-1-1-1-etc for the trie lookup primitive on the IP2. But alas I am not an ASIC designer, nor do I work for Juniper, nor am I in any way qualified to do anything other than talk out my ass about the benefits and drawbacks of any specific bit groupings in a multi-bit trie implementation in hardware. So unlike the rest of the list, I will quit while I am ahead. :) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
On Fri, Feb 06, 2004 at 04:39:09PM -0200, Rubens Kuhl Jr. wrote:
Even hardware with good IPv6 performance seems to forward at half the rate of IPv4/MPLS packets;
we call that crappy hardware
Based on such point of view, non-crappy hardware would be: (blank) and crappy hardware would be (blank), could you fill the blanks ?
As with so many other situations, the blanks can be filled in with "Juniper" and "Cisco", in that order.
I don't get why Juniper and Cisco trie-lookup forwarding would differ in comparing IPv4 and IPv6; Juniper does a 8+1+1+1+1+... search until a leaf node is found, while Cisco does 16+8+8 (or something near it but still with 3 phases); for both architetures, IPv6 longer addresses implies walking more deeply into the tree in order to find where to route.
Uhh...... One trie lookup is fully supported in ASIC, the other is not.
Just to be sure, my point here is not where the effective IPv6 performance suits one needs or not, but wether a router that can forward <amount> Mpps of IPv4/MPLS packets can also forward the same amount of IPv6 packets per second.
Personally I'd say the routing protocol functionality and stability is as important if not more important. I don't see the point in implementing a v6 network consisting of seperate 7206vxrs (to contain the ios crashes) and tunnels, if you're going to bother with it at least do it native and do it right. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
I don't get why Juniper and Cisco trie-lookup forwarding would differ in comparing IPv4 and IPv6; Juniper does a 8+1+1+1+1+... search until a leaf node is found, while Cisco does 16+8+8 (or something near it but still with 3 phases); for both architetures, IPv6 longer addresses implies walking more deeply into the tree in order to find where to route.
Uhh...... One trie lookup is fully supported in ASIC, the other is not.
Just to be sure, my point here is not where the effective IPv6
suits one needs or not, but wether a router that can forward <amount> Mpps of IPv4/MPLS packets can also forward the same amount of IPv6 packets
That probably would not yield half the performance, but a really crappy performance according to my standards (not so tight as Randy's). performance per
second.
Personally I'd say the routing protocol functionality and stability is as important if not more important. I don't see the point in implementing a v6 network consisting of seperate 7206vxrs (to contain the ios crashes) and tunnels, if you're going to bother with it at least do it native and do it right.
In a ground-up design, yes. Upgrading an existing network in low capex times is not that easy to do. Rubens
participants (6)
-
Andy Dills -
Pekka Savola -
Petri Helenius -
Randy Bush -
Richard A Steenbergen -
Rubens Kuhl Jr.