On 4 aug 2009, at 16:24, Shane Amante wrote:
The above assumes that a host actually imposes a flow-label on outgoing IPv6 packets.
It does not, it only requires the encapsulation boxes to do this. Since these don't exist yet, it's trivial to specify that they do this.
I am unfortunately IPv6-less as of late, with first the university and then my ISP stopping their IPv6 service. As such I can't do a quick tcpdump to see how many sessions have a non-zero flow label. But I remember it's the vast majority. What I don't know is the behavior of the different operating systems, I'm mainly familiar with MacOS and FreeBSD, not sure what Linux and Windows do.
Second, I'll check around some more, but with respect to most routers I'm familiar with (particularly, MPLS LSR's that will be carrying IPv6 over MPLS inside a SP's ASN), they *also* don't use the IPv6 flow-label as an input key to calculate a hash to determine the outgoing component-link.
Why not?
I would suspect that if the flow-label isn't well-defined nor is it widely implemented in hosts, then it makes no sense for router vendors to try to include it in their hash-algorithms for ECMP/LAG load-balancing.
The obvious solution in this case would be to use the flow label if available, and (either if the flow label isn't available or always) use the ports if those are available. That only leaves the situation where there is neither a flow label nor ports.
So, in summary, I support UDP/IPvX encapsulation for LISP
It's still the wrong decision. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
