If an intermediate switch/router is performing the encapsulation to NVGRE, and the switch/router is operating in cut-through mode it can start sending the frame out before receiving the entire frame, this makes it impossible to support GRE checksum in this operating mode. The argument can be made that if you operate in store and forward mode, you could perform this computation, but the downside to that is increased latency. This same issue applies to the UDP checksum. If a checksum can be just on header itself and not the payload it is more friendly to cut through switching, example IPv4 checksum.
Ian -----Original Message----- From: nvo3 [mailto:[email protected]] On Behalf Of Anton Ivanov Sent: Monday, August 04, 2014 11:14 PM To: [email protected] Subject: Re: [nvo3] Taking NVGRE draft to Informational RFC +1 In the presense of a verified (let's say by hardware) GRE checksum the payload checksum can be fed into a generic checksum offload mechanism, thus providing an arbitrary checksum offload for the encapsulated traffic. I do not see the benefits of this restriction. In fact it looks rather counterproductive. So if there are any benefits, they should be discussed in the draft so that we can see what is the rationale for it. A On 04/08/14 21:14, Tom Herbert wrote: > On Sun, Aug 3, 2014 at 10:16 PM, Pankaj Garg <[email protected]> > wrote: >> Hi All, >> >> >> >> As discussed in the NVO3 forum in the past, we intend to take NVGRE to >> informational RFC status. This would ensure that there is a stable way to >> build compliant and interoperable NVGRE implementation. It would also allow >> extensions to NVGRE to be able to refer to a stable document version as >> opposed to rolling revisions, thus removing the risk of introducing >> incompatibilities and interoperability issues later on. We are seeking (and >> would highly appreciate) editorial feedback from NVO3 fellows. Could you >> please review the latest draft of NVGRE (below) and provide us any editorial >> feedback on the latest NVGRE draft by 11th August? >> > Hi Pankaj, > > Per the draft: > > o The C (Checksum Present) and S (Sequence Number Present) bits in > the GRE header MUST be zero. > > This explicitly disallows use of GRE checksum and hence there is no > end to L3 mechanism defined within the protocol to check against > corruption of the nvgre header. As I mentioned before on this list, I > am particularly concerned about the vulnerability of the VSID. I > suspect the intention is that nvgre should only be deployed in > situations where the under lying networks provide error detection > along the whole path (links and in switches). In any case, I would > suggest there should be some discussion of this in the draft. > > Thanks, > Tom > >> >> Thanks >> >> Pankaj (on behalf of NVGRE co-authors) >> >> >> >> >> >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 >> > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
