Subject: Re: [lisp] Suggested UDP checksum text

From: [email-masked] (Noel Chiappa)
Date: Mon, 14 Sep 2009 15:01:12 -0400 (EDT)

> From: Margaret Wasserman <[email-masked]>

    > If we want to write an interoperable specification that includes
    > multiple options that are not interoperable, we have two choices:
    > (1) State that it is mandatory to support one of the choices on both
    > ends, and signal/negotiate the use of any of the other options.
    > (2) Require all implementations of one end of the connection .. to
    > support all of the options.

Yup; good summary.

Do note that this is the list _if we want any pair of boxes to be able to
communicate_; we might not have that luxury, though.

    > There are many currently deployed systems that are _not capable_ of
    > accepting a packet with an IPv6/UDP checksum of zero ... LISP simply
    > _will not work_ over IPv6 on those systems. The list includes all
    > deployed copies of every major operating system, all currently deployed
    > IPv6-capable CPE equipment, and the checksum offload hardware in all
    > recently-shipped Macs and many (perhaps most) recently-shipped PCs.

I guess to start with, the thing I need to understand is why this is a
problem. In general these are not the boxes LISP is targeted toward. Do
you forsee much need for some of these things to be running LISP? Do you
have some particular deployment targets in mind which I don't understand?

I ask this in part because, when thinking about all the host
implementations, it's worth remembering that Multi6 was basically rejected
by the users because it required management of addresses on individual
hosts, so for that reason in general I wouldn't expect individual hosts to
be wanting to run LISP anyway.

So that's why I'm trying to understand the circumstances in which you
forsee a need to run LISP on such boxes. With that in hand, I can think
about the rest...

Sigh, this is such a difficult situation. :-(

   Noel

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Sep 2009 16:58:18 +0300

Noel,

>     > support all of the options.

Yes.

> forsee a need to run LISP on such boxes. With that in hand, I can think

There are many people who need to build networking equipment on top of 
general purpose operating systems. I suspect most of us on this list 
have done it. I've seen many bsd/linux based systems morph into major 
product lines over the years. I don't think we want to discourage this. 
Of course, it is always possible to hack the kernel and replace your own 
code, at least if we are talking about open source. The question is how 
hard that is, what you do with commercial OSes, and whether all this 
will in practice prevent some deployments.

Jari

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 15 Sep 2009 10:30:29 -0400

Hi Noel,

> forsee a need to run LISP on such boxes. With that in hand, I can  

I do not claim to know everywhere that LISP will be deployed...

But, I do think (or at least hope) that it will be deployed on CPE  
equipment, so that end-users can enjoy the benefits of LISP, such as  
stable addresses.

There is a significant amount of CPE equipment based on Linux, FreeBSD  
or various proprietary embedded operating systems.  The stacks in  
those operating systems do not support sending or receiving zero UDP  
checksums in IPv6.

There seems to be some belief that, since Linux and FreeBSD are open  
source, the folks who make CPE equipment can just hack their kernels  
to support zero UDP checksums in IPv6.  However, that doesn't reflect  
reality in a number of ways...  The hack to the kernel to support zero  
IPv6/UDP checksums for some connections and not others is fairly  
complex, and most of the CPE vendors I've known don't want to hack  
their kernel at all.  In general they get a stable, supported Linux  
distribution from an embedded Linux distributor and use that.  They  
value the open source for debugging purposes, but they don't want to  
branch their own kernel off from their supported package.

Customers who use proprietary OSes would have to wait for their vendor  
to support zero UDP/IPv6 checksums, which isn't going to happen  
immediately.  They would then need to upgrade the OS in their product  
to get the new checksum handling code.  OS upgrades are typically  
considered to be a major project and are not taken lightly for stable,  
shipping products.

  Also, there is a significant amount of CPE equipment that does  
checksum offload in hardware, and not all systems offer a way to turn  
this off.  Chips to do IPv6 checksum offload (for UDP/TCP) have been  
widely available for a while now and are widely deployed.  They are  
all based on the current IPv6/UDP checksum standard (RFC 2460), which  
doesn't allow zero UDP/IPv6 checksums.

So, we're talking about a situation where CPE equipment vendors would  
have to modify/upgrade their operating system, turn off IPv6 hardware  
acceleration for their current equipment (causing a significant  
performance drop) and (probably) upgrade their hardware for ongoing  
shipments, just to support LISP.  I don't think we want to put these  
sorts of hurdle in the way of LISP being implemented and deployment on  
CPE equipment.  So, I think we want to design LISP so that it will  
work with TCP/IP stacks and network interface hardware that is widely  
deployed today.

In the future, I also hope that LISP will be capable of running on the  
end systems themselves.   We'll need that capability to support  
mechanisms like the mobility draft or other mechanisms that push LISP  
all the way out to the edges.  I realize that these applications are  
outside the scope of the current IETF WG, though.

> Sigh, this is such a difficult situation. :-(

Yes, it is...  I understand that the requirements in this area for CPE  
equipment based on commodity hardware/software is directly at odds  
with the requirements for (at least some) high end routers.  So, we  
seem to be at an impasse...

When you find yourself at an impasse, sometimes it is best to go back,  
question your assumptions and explore the roads not taken...

I understand that we want to use UDP to support LAG/ECMP.  Is there  
any other way that we could support that?  For example, Francis Dupont  
proposed that we could create unique per-flow three-tuples (two IP  
addresses and a protocol) by assigning a set of IP addresses (same  
prefix, different IIDs) to a LISP ITR, so that the ITR could send from  
different IP addresses to differentiate between different flows.

Or, possibly, we could move to direct LISP-in-IP encapsulation (for  
IPv6 only) and try to move the world in the direction of using the  
IPv6 Flow Label as part of the LAG/ECMP hash in IPv6?

I'd personally prefer the latter, because I agree with Joel that  
debugging tunnels that use multiple addresses on one end would be  
challenging.  However, I may be underestimating how long it would be  
before LAG/ECMP hardware could be deployed that considers the IPv6  
flow label...    I'd strongly prefer either of these choices to where  
we find ourselves now, though.

Margaret