You may care to reference this to Section 2.2 of RFC 6936, which provides some background to where UDP-Lite may help, and some of the potential pitfalls.
Gorry > > Or perhaps UDP heavy with a FCS at the end and no checksum at all. > > You do make a good point that perhaps UDP lite should be mentioned in > MPLS over UDP as an option. > > Curtis > > > In message > <290e20b455c66743be178c5c84f1240847e6334...@exmb01cms.surrey.ac.uk> > l.w...@surrey.ac.uk writes: > >> you've got the perfect application to encourage UDP lite adoption and >> deployment here. >> >> Lloyd Wood >> http://about.me/lloydwood >> ________________________________________ >> From: Stewart Bryant [stbry...@cisco.com] >> Sent: 15 January 2014 11:31 >> To: Randy Bush >> Cc: Wood L Dr (Electronic Eng); w...@mti-systems.com; >> cur...@ipv6.occnc.com; go...@erg.abdn.ac.uk; m...@ietf.org; >> i...@ietf.org; ts...@ietf.org; j...@mit.edu; lisp@ietf.org >> Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: >> gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)) >> >> On 15/01/2014 11:08, Randy Bush wrote: >> > [ you insist on cc:ing me, so you get to endure my opinions ] >> > >> >> it seems that there are no valid statistics for the current Internet >> >> to sustain your case. >> > as we discussed privately, there seem to be no real measurements to >> > sustain any case. this is all conjecturbation. >> > >> > what i do not understand is why, given the lack of solid evidence that >> > we are in a safe space, you and others are not willing to spend a few >> > euro cents to have a reasonable level of assurance at this layer. >> > >> > randy >> Randy, >> >> It is not a few cents, it is likely the re-engineering of a lot >> of silicon. >> >> The reason that UDP is of interest is that the on path silicon >> knows how to process it, for example it knows how to to ECMP it. >> >> The reason that the UDP c/s is a problem for a tunneler is that >> it needs to have access to the whole pkt to calculate the >> c/s, but as you know the silicon optimised that access away >> a long time ago. >> >> The alternative would be UDP-lite, but the ability of on path >> silicon to process that as competently and as completely as it >> processes UDP is by no means clear. >> >> - Stewart > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
