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