Lloyd,
The part about RFC 6936 section 3.1 most relevant might be: There is extensive experience with deployments using tunnel protocols in well-managed networks (e.g., corporate networks and service provider core networks). This has shown the robustness of methods such as Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS that do not employ a transport protocol checksum and that have not specified mechanisms to protect from corruption of the unprotected headers (such as the VPN Identifier in MPLS). Reasons for the robustness may include: If the rate of undetected modified packets is extremely low in "well-managed networks", as we beleive is the case, then UDP checksums won't change the situration much. So why *not* make them optional if experience has shown they are not needed in the types of deployments we are talking about. Curtis In message <290e20b455c66743be178c5c84f1240847e6334...@exmb01cms.surrey.ac.uk> l.w...@surrey.ac.uk writes: > > Stewart, > > your 'I'm not in tunnel applications' suggests you've misunderstood > the argument here. The point is not to protect the tunnel traffic > (which can quite happily checksum itself), it is to protect everything > else on the network from misdelivery. It's not the tunnel application, > it's every application sharing the internet with the tunnel which > has UDP checksums turned off. See all of RFC 6936 section 3.1. > Tunnel is fine, sideeffects of misdelivery do not affect tunnel. > > And in IPv4 and IPv6, the pseudo-header checksum built into > TCP and UDP is all we have. IPv6 deliberately copied v4 here. > > > What is the error rate in modern h/w and network systems? > > No-one measures end-to-end misdelivery. No-one knows. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Stewart Bryant [stbry...@cisco.com] > Sent: 14 January 2014 22:46 > To: Wesley Eddy; Wood L Dr (Electronic Eng); cur...@ipv6.occnc.com > Cc: go...@erg.abdn.ac.uk; m...@ietf.org; i...@ietf.org; ra...@psg.com; > 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 14/01/2014 22:07, Wesley Eddy wrote: > > On 1/14/2014 4:57 PM, l.w...@surrey.ac.uk wrote: > >> I don't think sayng 'oh, that error source is no longer a problem' > >> disproves > >> Stone's overall point about undetected errors, though the > >> examples he uses from the technology of the day are necessarily > >> dated. Dismissing the overall point because the examples use obsolete > >> technology is throwing the baby out with the bathwater; a host-to-host > >> error check catches things that intermediate checks cannot. > >> > >> Measuring error rates across end-to-end Internet traffic is something > >> that has > >> not received much attention , as error detection is not > >> instrumented well - hence citing Stone's published work, in the absence > >> of awareness of anything newer (and as high profile/immediately > >> recognisable > >> as sigcomm) in the area. > >> > > > > +1 ... the message in the paper is applicable to layered systems > > and internetworks in general. Changes in the link technology > > since then don't invalidate it, especially since we know that > > the technology not only changes rapidly, but also is always > > growing in diverse directions, such that there things almost > > universally true today may be turned on their heads tomorrow. > > > > Designs for stacking layers need to follow solid general > > principles in order to be robust to changes (above and below). > > > Note that it is not only the link layer technology that has moved on, > the signal integrity of the h/w at all stages of the design and > implementation process has moved on. > > Can we agree that the statistics in the paper are discredited? > > If not, why not? > > What is the error rate in modern h/w and network systems? > > Is this significant in the application under consideration? > > Finally if we are really concerned that we do actually need a > c/s (I am not in tunnel applications) why are we still happy to > use what is frankly a pathetic check in modern terms? Why > for example are we not moving to something like > the Fletcher 64 bit c/s? > > Stewart _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
