Hi Joel,
On Aug 5, 2009, at 1:42 PM, Joel M. Halpern wrote:
Reading this discussion, there seem to be a small number of
practical choices.
If the vendor hardware that is / will be handling IPv6 can handle
the flow label as part of the ECMP / LAG calcualtion, than an I-D /
direction to use the flow label seems sensible. (This is about what
will be used, not what off-the-shelf parts might support in some
other box.) While hardware upgrades take a long time, software
upgrades are easier, particularly if it makes the operators traffic
handling work better.
Conversely, if the hardware we have to count on will not be able to
handle flow labels for ECMP / LAG hash calculations, then it
probably also won't be able to handle alternate protocols (like UDP-
lite). As such, everything that needs ECMP / LAG handling will need
to have TCP or UDP encapsulations, and given that many of those are
protected, we will want to allow UDP with 0 checksum.
Could you explain what you mean by "given that many of those are
protected"?
I have this uncomfortable feeling that many of us (including me) are
missing important details of what is being discussed here, and that
the answer (or at least the problem) might become clearer if we could
pool our knowledge...
For example, I really don't understand how LISP, as currently defined,
gains any significant LAG/ECMP benefits by including a UDP header in
the outer packet... I understand that you want to be able to load-
balance flows, even though they've been encapsulated by LISP. And I
understand that current load balancers can only do this based on a few
fields:
src/dest IP addresses (two RLOCs), the IP traffic class, the IP
protocol field (UDP=17) and the src/dest UDP ports (xxxx and LISP=4341).
I just don't see how this works very well with LISP, though... The
two RLOCs are likely to be constant for all traffic between the same
LISP routers, and ITR/ETR pair (right?). The protocol will always be
UDP (as currently defined), and LISP doesn't do anything unusual with
the traffic class. So, are we expecting all of the load balancing for
LISP flows between a specific ITR/ETR pair to be based on the single
UDP port that _isn't_ 4341? Wouldn't this end-up with a bi-
directional flow being broken into two different flows for load
balancing, resulting in asymmetric routing, because the load balancer
wouldn't see the same two UDP ports in both directions?
I guess I really need to read that ECMP draft again...
Margaret
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
