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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
[e-mail] 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 [[e-mail]] On Behalf Of Joe Touch [[e-mail]]
> Sent: 27 January 2014 16:48
> To: [e-mail]
> Cc: [e-mail]; IETF discussion list; [e-mail]
> 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 <[e-mail]> 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