In message <290E20B455C66743BE178C5C84F1240847E63346F6@xxxxxxxxxxxxxxxxxxxxxx> l.wood@xxxxxxxxxxxx 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@xxxxxxxx] On Behalf Of Joe Touch [touch@xxxxxxx] > Sent: 27 January 2014 16:48 > To: stbryant@xxxxxxxxx > Cc: mpls@xxxxxxxx; IETF discussion list; curtis@xxxxxxxxxxxxxx > 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@xxxxxxxxx> 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