Hi, Dino, On 2009-7-29, at 14:02, Dino Farinacci wrote:
From a practical perspective, we prefer that a LISP encapsulator (ITR and PTR) not incurred additional work when encapsulating packets.
could you share some data on how much of a performance impact we're talking about here? I was under the (maybe naive) impression that checksum offloading was practically ubiquitous these days.
The main LISP spec indicates:(1) The UDP checksum in the outer header MUST be set to 0 by an encapsulator.(2) The decapsulator MUST ignore the UDP checksum. We stand by this text and see no reason to change it.
This is in direct conflict with what RFC2460 says, and I'd personally would find it problematic to approve publication of an Experimental protocol that did this, unless there was an IETF consensus on a standards-track document that would update RFC2460 accordingly. Such a document would IMO need to show extremely strong arguments for why this change is needed. Updating RFC2460 is also in direct conflict with the message that the IETF has been trying to send, namely, that IPv6 is stable and done. Is this really worth it?
There are no practical reasons to use outer header UDP checksums regardless of the 4 combinations of packet types (v4-in-v4, v6-in-v6, v6-in-v4, or v4-or-v6) being forwarded by LISP routers.
I hear you, but is there any quantifiable downside to just compute the checksums, esp. if it can be done in hardware?
Thanks, Lars
smime.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
