In message <290E20B455C66743BE178C5C84F1240847E63346F7@xxxxxxxxxxxxxxxxxxxxxx> l.wood@xxxxxxxxxxxx writes: > > "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 At what point does this discussion no longer have any relevance at all to draft-ietf-mpls-in-udp? The draft is going to say SHOULD wrt UDP checksums. If you have an issue with the wording of the draft, please comment on the draft. Curtis > ________________________________________ > From: mpls [mpls-bounces@xxxxxxxx] On Behalf Of Joe Touch [touch@xxxxxxx] > Sent: 27 January 2014 19:24 > To: Joel M. Halpern; joel jaeggli; stbryant@xxxxxxxxx > Cc: mpls@xxxxxxxx; 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