+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
