ietf
[Top] [All Lists]

RE: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

2014-01-27 17:21:21
"ASICs can't do IPv6 in hardware! IPv6 can only be done with slow
software forwarding! We're stuck with v4!"

I think we've been here before.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: mpls [mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of Joe Touch 
[touch(_at_)isi(_dot_)edu]
Sent: 27 January 2014 19:24
To: Joel M. Halpern; joel jaeggli; stbryant(_at_)cisco(_dot_)com
Cc: mpls(_at_)ietf(_dot_)org; IETF discussion list
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating 
MPLS in UDP) to Proposed Standard

On 1/27/2014 11:19 AM, Joel M. Halpern wrote:
Yes Joe, routers could ahve been built to do those calcualtions at that
performance scale.
There are however two major problems:

1) That is not how routers are built.
2) The target performance scale is rather higher.

So could someone build an ASIC to do what you want?

Has. It's already part of nearly every DMA ASIC in a network interface
already.

Probably.  Is there
any reason in the world to expect operators to pay the significant extra
cost for such?Not that I can see.

We're talking about a ring of full adders, the specs for which are given
in an RFC that's 18 years old, and that is already implemented in nearly
every host interface, including 10Gps NICs.

And we're talking about "routers", many variants of which operate at
very high speeds and transparently proxy TCP already. So this is a
solved problem.

And even if we could and they would, that is not the world into which we
are deploying these tunnels.

We're back to "that's not what they do now", at least in some devices.

Well, they don't use MPLS in UDP (since no spec exists), so clearly if
they're limited to doing what they already do, this is an exercise in
futility.

Joe


Yours,
Joel

On 1/27/14 1:53 PM, Joe Touch wrote:


On 1/27/2014 10:48 AM, joel jaeggli wrote:
On 1/27/14, 8:48 AM, Joe Touch wrote:
Those same mechanisms have provided hardware checksum support for a
very long time.

The new header and the payload are actually in different parts of the
forwarding complex until they hit the output queue, you can't checksum
data you don't have.

You can (and some do) the checksum component parts when things go into
memory; the partial sums can be added as the parts are combined in the
output queue.

I appreciate that we're all taking about what might be done, but the
reality is that there are many 'transparent TCP proxies' that have to do
this, so there's clearly a solution, and it clearly runs fast enough.

Joe
_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls

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