Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling

From: [email-masked] (Noel Chiappa)
Date: Tue, 15 Sep 2009 12:52:27 -0400 (EDT)

> From: Marshall Eubanks <[email-masked]>

    > Clearly, the checksum rates on fiber will be higher.

This is header checksum failures we're talking about here, right, not
link-level checksums (at the network layer)?

Whichever one it is, do you happen to have any numbers on the other?

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 15 Sep 2009 13:16:03 -0400 (EDT)

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

    > It is my understanding that the deployed LAG/ECMP equipment that
    > parses on the five-tuple described above will fall back to a three-
    > tuple (2 IP addresses and IP protocol/next header) when the protocol
    > in use is not UDP or TCP.

You've exceeded my area of knowledge, so I can't say.

    > if we did a LISP-in-IP encapsulation and varied the IID of the
    > source IP address based on a hash of the original packets'
    > five-tuple, we would get the same load balancing effect as varying
    > the UDP source port. Is that correct?

By 'varied the IID of the source IP address', you mean plain old 'varied
the source IP address in the outer header', right?

The problem with that is that all the control functions piggybacked on
user-data traffic (liveness/reachability testing, and also mapping
currency) would then stop working, since they packet would no longer
contain the source ITR's RLOC.

We also wouldn't be able to return LISP error messages (which we don't
have yet, but I suspect we might need them) to the source ITR, since we
wouldn't have its RLOC. Ditto for any ICMP errors the packet causes in
transit - again, not sure if we will need them, though.

But in general, at an architectural level, I'm uncomfortable not having
a source address in the packet.

	Noel