ietf
[Top] [All Lists]

Re: OT was Re: [mpls] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: [tsvwg] Milestones changed for tsvwg WG)

2014-01-14 10:53:44

In message 
<201401122104(_dot_)44370(_dot_)mark(_dot_)tinka(_at_)seacom(_dot_)mu>
Mark Tinka writes:
 
On Sunday, January 12, 2014 08:37:16 PM Curtis Villamizar=20
wrote:
 
Perhaps if you actully worked for a company that made
line cards you would not make the above statement.
 
I work for an operator that pays real money to deploy and=20
use those line cards, and I make it my business to know what=20
I'm paying for.
 
Many of the big router vendors use the same TCAM hardware
for MPLS lookups as they do for IP lookups.  Doing the
lookup is not the rate limiting factor even in hardware
that has an ILM SRAM table and some form of radix based
lookup.  All of the hardwre I've seen in the last 15
years or so forwards MPLS and IP at the same rate.
 
Which was exactly my point - unless you somehow missed that.

What you said was "Current-generation ASIC's have no problem
forwarding MPLS frames at wire rate".

Since you didn't mention IP packets I assumed you were making the 20
year old argument that MPLS forwarding was faster than IP.

...
Except IPv6 before they decided to waste the lower half
of the address space with 40 quintilion host in a
bridged subnet and you really did have to look at the
whole 128 bits.
 
It is no secret that forwarding of IPv6 packets on some=20
vendor equipment is about half the rate of IPv4 or MPLS. But=20
then again, because MPLS control planes are IPv4-driven=20
today, I'm hoping I didn't have to be explicit about not=20
including IPv6 in that group, on this list.

None of the equipment I have worked on (a while back) or the chips we
evaluated recently had such a problem for IPv6 using only the top 64
bits for forwarding.  An argument was made in the early 2000s (by me
and others) that if we allocated global routes only from the top 64
bits all equipment at that time could forward at essentially the same
rate as for IPv4.  The reaction from the IPv6 community was to
completely throw away the bottom half of the address and make it the
host part.

There are chips for which looking at a 32 bit prefix or a 64 bit
prefix is done within the same pipeline and therefore takes the same
amount of time.  Other chips which parallelize packet handling budget
enough microengines to get the job done (only a part of which is the
MPLS ILM or IP destination lookup).

Back when forwarding was done in
software (circa 1995) your statement would have been
true if MPLS preceeded forwarding ASICs which it did
not.
 
You might not know that line cards from C like the LSP=20
(Label Switch Processor) and much of the PFE from J's PTX=20
are forwarding engines that have been made cheaper by=20
reducing the IP FIB on the assumption that all traffic will=20
be carried in MPLS. This is, obviously, an assumption I do=20
not support because:

Those line cards (and designs I was recently involved in) assume what
has historically been called a BGP-free core.  Only the IGP routes are
carried in the core.  BGP is mapped onto the IGP routes.  MPLS carries
traffic across the core.  The core has no BGP routes and therefore
needs a lot fewer entries and the ILM can be put into SRAM rather than
use a TCAM and only a small set of IP routes needs to be supported.

That is done to eliminate a need for large external DRAM or TCAM which
itself and the SERDES needed to go off chip produces heat and requires
power, board space, and cooling and therefore reduces density.
Putting more simple filters in the core also helps increase density.
It is more a power to operate and floor space per Gb/s issue.

For the most part IP/MPLS transport equipment seems to be going this
way, though some people are stuck on MPLS-TP and trying to build a L2
overlay.

If you go back to before 2000 at least one provider built a BGP-free
core over Frame Relay, but FR itself soon died and the overlay didn't
scale well.  Some providers wanted to do this over MPLS but the
RSVP-TE restoration times were too long and the fallback to IP routing
was still needed to make up for that.

      - I run IPv6 natively, and at the moment, there are
        no production-grade IPv6 control planes for MPLS.
 
      - It assumes providers will run 6PE (in which case,
        IPv6 traffic enjoys MPLS and IPv6 wire rate
        forwarding speeds).
 
I do not buy such line cards because for anyone running=20
native IPv6, you could potentially run out of FIB slots to=20
host IPv6 routes.

Unless you run a BGP-free core, whether IPv4 or IPv6.  Then you have
plenty of FIB space.

That is why I say MPLS has allowed vendors to put out=20
cheaper line cards compared to the costs of those which have=20
large IPv4/IPv6 scale. Because MPLS forwarding is so=20
mainstream, there is no additional cost associated with=20
forwarding rates similar to IPv4. So much of the cost of=20
line cards is in QoS queues and routing FIB slots (and MPLS-
biased line cards are stripped of that, hence making them=20
cheaper).

You put forwarding at full rate and cheaper line cards in the same
paragraph with no mention of smaller FIB size due to eliminating the
BGP routes.

Also the statement "Current-generation ASIC's have no
problem forwarding MPLS frames at wire rate" is not true
for most (or all) hardware with 40 byte payloads (even
with plus 4 with TCP SACK plus 4 if MPLS) and 100 Gb/s
interfaces.  It is true for "average packet size"
traffic and on most hardware only true if bursts of 40
byte packets are very limited in duration.
 
C'mon, Curtis. Everybody knows this already. Moreover, real=20
world IP traffic is not all 40 bytes.
 
If operators have doubts about what forwarding engines can=20
do below 128 bytes, that is what PoC labs are for before you=20
buy. And even then, several operators accept the=20
restrictions up to a certain point, because the lab and real=20
life vary significantly.
 
Mark.

OK ... so this is all interesting but I've lost the connection between
this discussion and draft-ietf-mpls-in-udp.  Hence the OT in the
subject.  Would you please remind me what that connection was.

Curtis

<Prev in Thread] Current Thread [Next in Thread>