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.
One of the problems with IPv6 is that is so similar to IPv4 but
different enough to cause pain for implementations. So since we can
use 0 UDP checksums for IPv4 in UDP in IPv4, we would want to build
(or use existing hardware) that does IPv6-or-IPv4 in UDP in IPv6.
Reasons being (1) cost in building hardware, (2) chip area, (3) power,
(4) complexity, and (5) inconsistency from IPv4.
This is only for encapsulated packets. This is for the outer header
only.
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
Sorry, but we want to build practical products. If you don't build
practical standards, vendors will violate them.
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?
A hardware forwarding engine is not going to compute a pseudo-header
checksum and compute every byte of a packet. It's just not going to
happen.
There has never been a requirement to do this before. My guess is you
can slow performance by 20%.
Dino
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
