Subject: [lisp] Status on UDP checksum issue

From: Sam Hartman <[email-masked]>
Date: Fri, 14 Aug 2009 14:11:53 -0400

I wanted to let the WG know where I think we are.

I'm told by Darrel that Margaret's issues will be opened early next
week.  That's certainly a long delay between issues being sent to the
list and entered into the tracker, and under normal circumstances if I
thought things were going to drag out like that I might well just
enter the issues myself.  However, I think getting more people used to
dealing with the tracker is good and deferring the continuation of the
discussion until over the weekend also sounds reasonable.

Darrel and I had a nice conversation about how we can work to educate
each other.  I expect he'll be telling us more about that in the near
future.

I've had several conversations about how to make the WG work more
smoothly and am open to talking to anyone who has ideas about that.

I believe that Margaret is still investigating the impact of
permitting 0 UDP checksums for IPV6.
This analysis includes:
* LISP packets sent to the wrong destination
* LISP packets sent to some non-LISP endpoint
* LISP packets corrupted in transit

I have not talked to Marshall but I assume he's been following this
discussion and will reflect a number of issues in his draft.

Anyone who wants to flesh out an alternative for meeting some or all
of the requirements stated in this discussion such as something based
on using multiple IPV6 source addresses should do so.  If you want
such an alternative to be seriously considered you may be asked to
prepare a draft under reasonably tight time pressure, so you should
not be surprised by that.

Requirements participants have stated include:

* Works with LAGs/ECMP
* Implementable in router hardware
* Implementable on stock TCP/IP stacks
* Implementable using server/desktop NICs with checksum offload
* Can be easily deployed
* Works through firewalls  and NATs

We have not yet judged formally whether some or all of these
requirements are important to the WG as a whole.  We may b e able to
move forward without that although refocusing on the requirements is
certainly a tool that is available to us.

A while ago, I published a sort of proto consensus call.  It seems
unlikely at this point that any eventual consensus call will be of the
form I published previously, although input we've received so far will
certainly be considered.