In message
<290E20B455C66743BE178C5C84F1240847E63346F6(_at_)EXMB01CMS(_dot_)surrey(_dot_)ac(_dot_)uk>
l(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk writes:
...and UDP Lite just covering the L3 and L4 headers, but not the full
payload a la UDP, is still possible when the full payload is not
visible.
Lloyd Wood
http://about.me/lloydwood
... but doesn't solve the problem of ECMP using old routers so
UDP-Lite is a non-starter.
Curtis
________________________________________
From: ietf [ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Joe Touch
[touch(_at_)isi(_dot_)edu]
Sent: 27 January 2014 16:48
To: stbryant(_at_)cisco(_dot_)com
Cc: mpls(_at_)ietf(_dot_)org; IETF discussion list;
curtis(_at_)ipv6(_dot_)occnc(_dot_)com
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating
MPLS in UDP) to Proposed Standard
Those same mechanisms have provided hardware checksum support for a very long
time.
Joe
On Jan 27, 2014, at 8:40 AM, Stewart Bryant <stbryant(_at_)cisco(_dot_)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