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

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 27 January 2014 19:19 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02DD1A034B; Mon, 27 Jan 2014 11:19:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYqcEwHlF2be; Mon, 27 Jan 2014 11:19:09 -0800 (PST)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 27A8B1A0264; Mon, 27 Jan 2014 11:19:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 096EF102BF0; Mon, 27 Jan 2014 11:19:07 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from Joels-MacBook-Pro.local (pool-70-106-135-128.clppva.east.verizon.net [70.106.135.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 087C3102B42; Mon, 27 Jan 2014 11:19:05 -0800 (PST)
Message-ID: <52E6B128.8060306@joelhalpern.com>
Date: Mon, 27 Jan 2014 14:19:04 -0500
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>, joel jaeggli <joelja@bogus.com>, "stbryant@cisco.com" <stbryant@cisco.com>
References: <201401240320.s0O3KsR9013700@maildrop2.v6ds.occnc.com> <52E2BBC0.2030203@isi.edu> <52E68C12.2050308@cisco.com> <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu> <52E6AA0B.1050600@bogus.com> <52E6AB15.2080907@isi.edu>
In-Reply-To: <52E6AB15.2080907@isi.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "mpls@ietf.org" <mpls@ietf.org>, IETF discussion list <ietf@ietf.org>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jan 2014 19:19:11 -0000

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
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>