I agree with Joel that this problem is broader than just LISP. This is an issue with any device that is encapsulating quite a bit of traffic (that represents many smaller flows that could be split) in a tunnel over IPv6. It would (IMHO) serve us well to do this right.
I also agree with Joel that there is a wide range of existing equipment deployed, and at least some of the existing high speed (core) IPv6 routers could include the flow label in the hash, at the cost of a microcode software update, and probably removing something else from the hash. There isn't all that much IPv6 traffic right now (some please correct me if this is wrong), and the ramp-up speed seems relatively slow. Thus to me it seems that the time frame that it would take to change router hardware is long, but no longer than the time frame that it is likely before we find ourselves with enough IPv6 traffic that we actually need to do a good job of ECMP splitting of traffic going over an IPv6 tunnel. Thus I think that it would be okay to do this by putting a hash of higher layer flow information into the flow field, if we think that is the right way to do it. Ross (speaking as an individual contributor with my own personal opinion only). -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Joel M. Halpern Sent: 10 August 2009 13:11 To: Havard Eidnes Cc: [email protected]; [email protected] Subject: Re: [lisp] Flow label redux Actually, looking at this as a LISP problem is probalby misleading. This issue applies to any intermediate device based, high capacity, tunnel mechanism. 1) High capacity tunnel mechanisms are going to be concerned to implement in hardware, where the UDP checksum may be difficult 2) High capacity tunnels are the very ones whose traffic could and should make use of ECMP / LAG operation. Starting from there, the line of argument then proceeds to look at what works. What works in the real world IPv6 deployments is UDP with 0 checksum. That enables ECMP / LAG without excessive effort / overhead. Note that UDP-lite is not an answer in terms of what works now. The vast majority of deployed provider-edge (PE) and provider-core (P) devices will not look at the port numbers in the UDP-lite header because they do not recognize the protocol. The next question is whether this could change. I am still collecting information on this. Product seems to fall into three categories: 1) Software forwarders. Obviously, these can change 2) Microcoded packet processors - These can probably change which field is looked at, within limits 3) Hardware mechanisms - these really can not change their handling, as they are in the field. Preliminary data indicates that there are a non-trivial number of hardware devices already out there and handling IPv6. There are a noticeable number of core devices that could be changed in small ways (microcoded or software), for example to use the flow-label instead of some other piece of information in the packet. We can look at the hardware and complain, or we can look at it and thank the vendor for acting promptly on RFCs. We can not reasonably expect the hardware to change in any meaningful time frame. I am still colelcting implementation data, so I may be misled by what I have gotten. But it seems to me that we are unfortunately stuck with UDP with 0 checksums if we want high capacity tunnels to be able to make use of ECMP / LAG in the moderate time period (out through at least 5 years, maybe longer.) Yours, Joel Havard Eidnes wrote: >> > the O UDP checksum proposal obsoletes all the today deployed nodes >> > which check them (so all hosts I know and perhaps a lot of routers too) >> >> OK, so what are the other options for encapsulating a packet in a IPv6 >> packet? > > Um, surely, routers are not specified to validate layer-4 > checksums for transit traffic?!? > > Let's look at this another way? As I understood it, UDP 0 would > be used by LISP encapsulating/decapsulating devices. > > If some random (non-LISP encap/decap) host by mistake received a > 0 UDP packet, it would be dropped, which should do no harm. > > In practical terms, only LISP encap/decap devices would need to > be modified to accept 0 UDP packets under some specific rule / > circumstance, as an exception to the general rule. > > The only thing which would prevent this would be one of > conformance to the letter of the original spec, which apparently > bans 0 UDP checksums. > > So what's so bad about that? > > Regards, > > - Håvard > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
