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

[Joe Touch <[e-mail]>]

I think we agree that if the router needs faster, then the router gets 
faster.

Where we disagree is whether the "bull in the china shop" gets to ignore 
the rules of the road to get what it wants.

I.e., I won't disagree on what router vendors want or what they're 
willing to support (though I will disagree on what hardware can do, 
based on experience).

I will disagree that routers get to run roughshod over the rest of us to 
do it.

Simple solution -- don't use UDP.

Joe

On 1/30/2014 10:27 AM, Ross Callon wrote:
> +1 to what Joel said. It is clear that Joe's view of "fast enough" for a host interface is not the same as my customer's view of "fast enough" for a core router (nor should it be the same -- routers have to be faster than host interfaces).
>
> More important is the issue of what can we get vendors to implement, which is probably better worded as what can we get network operators to push vendors to implement. If you are talking about fundamentally changing the internal data path for packets within a router or changing the data path into and out of specific chips to carry significantly more information, then we are talking about at least hundreds of millions and probably billions of dollars of equipment that needs to be replaced. This needs a very compelling justification before it is actually going to happen.
>
> Ross
>
> -----Original Message-----
> From: mpls [mailto:[e-mail]] On Behalf Of Joel M. Halpern
> Sent: Monday, January 27, 2014 2:19 PM
> To: Joe Touch; EXT - [e-mail]; [e-mail]
> Cc: [e-mail]; IETF discussion list
> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
>
> 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?  Probably.  Is there
> any reason in the world to expect operators to pay the significant extra
> cost for such?  Not that I can see.
> And even if we could and they would, that is not the world into which we
> are deploying these tunnels.
>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
>>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>
>
>