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

joel jaeggli <joelja@bogus.com> Mon, 27 January 2014 18:49 UTC

Return-Path: <joelja@bogus.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 E05131A0276; Mon, 27 Jan 2014 10:49:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level:
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 UpBZmwrp5IkO; Mon, 27 Jan 2014 10:49:00 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 775C81A0264; Mon, 27 Jan 2014 10:49:00 -0800 (PST)
Received: from 02351a-maguilar.corp.zynga.com ([199.48.105.4]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s0RImiKS042439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Jan 2014 18:48:44 GMT (envelope-from joelja@bogus.com)
Message-ID: <52E6AA0B.1050600@bogus.com>
Date: Mon, 27 Jan 2014 10:48:43 -0800
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>, "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>
In-Reply-To: <98034F7E-47CF-4ABE-A199-A9DB4DACBC2E@isi.edu>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="OriKbApKhGlWr638DuclAaA0Sme6Slsso"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 27 Jan 2014 18:48:45 +0000 (UTC)
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 18:49:02 -0000

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.

> Joe
> 
>> On Jan 27, 2014, at 8:40 AM, Stewart Bryant <stbryant@cisco.com> wrote:
>>
>>> On 24/01/2014 19:15, Joe Touch wrote:
>>>
>>>> This eliminates the "expands the reach of MPLS argument".
>>>>
>>>> First UDP checksums:
>>>>
>>>>   The UDP checksum is at the beginning of the payload.  Please see
>>>> http://www.ietf.org/mail-archive/web/mpls/current/msg11279.html
>>>>   This makes filling in a new UDP checksum infeasible on most high end
>>>>   hardware.
>>>
>>> That argument would make sense if most hardware wasn't store-and-forward on a per-packet basis.
>> They may be store and forward, but most of the high end designs
>> use multiple grades of memory putting the packet in "slow memory"
>> and providing a snapshot of the header in "fast memory" to the
>> forwarder. Thus although the whole packet is in the system, it
>> it is not accessible to the engine that would need to calculate the
>> c/s.
>>
>> Stewart
>