It has become clear with the passage of time that the description of the
flow label in the original IPv6 specs served only to convince everyone
not to use that field for anything. Even now, no one is sure what to do
with it.
To propose that encapsulators should use this field to mark the flows
would seem reasonable. The problem is that since that was not done in
the first place, as I understand it, router vendors concluded that the
only sensible thing to do was to ignore the field, and do load balancing
on ports just like we did on IPv4.
Saying that we should have done it differently requires that the vendors
be accurate fortune tellers, able to realize that the fields was going
to turn out to be useful, and able to guess what usage they could safely
make that would correctly match an eventual usage :-)
And given the deployment assumptions, if we hope for LISP to be usable
over IPv6, it can not depend for correct operation ona router feature
that is not yet being delivered.
(I will happily eat crow and apologize if it turns out routers already
do what Iljitsch is asking for.)
Yours,
Joel
Iljitsch van Beijnum wrote:
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.
_______________________________________________
lisp mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
