The basic model is that ECMP works by hashing all the fields.
Therefore, you need two related properties:
1) You need those fields to be stable across all the packets in a flow
in one direction. (There is absolutely no need for the answer to be the
same in the reverse direction, as there is no order preservation issue
between the two direcitons.
2) You need to be able to produce (with high probability) different
answers for different flows, so that the hash logic can spread the
different flows across different paths / links.
By varying the source port in the UDP header LISP allows the balancing
logic to spread flows. (The exactly logic it chooses to use to pick the
source port is a local matter. If there are enough different traffic
sources, it can use the inner source address (EID). Or it can use the
EID, and where available source and dest port numbers.
As you implied, there is no RFC on this. That is because it is a local
behavior. (different devices can do different things, and it still
works.) The problem we have surfaced is that other systems actually do
depend upon this behavior, and therefore it probably needs to be documented.
It has been a very long time since I actually worked with this aspect of
router (forwarding) logic.
Joel
Margaret Wasserman wrote:
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
--------------------------------------------------------------------
