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.
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.
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
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
> > > 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
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
> 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.
Usually it's a good way to learn about the architecture of the
competitor's(i.e, not the company of the presenter) router; watch both of
them and you get a pretty good image of what they are.
otoh, we have been using real routers.
Those real routers have real architetures with what behaviour regarding
prefix-length ?
Rubens
> > > > 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.
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
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
> 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.
That probably would not yield half the performance, but a really crappy
performance according to my standards (not so tight as Randy's).
> 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.
In a ground-up design, yes. Upgrading an existing network in low capex times
is not that easy to do.
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
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. 