On Tue, 7 Sep 2010 13:58:21 -0600, Shane Amante <[email protected]> wrote:
> Hi Fernando, > > I have a question on: > http://tools.ietf.org/html/draft-gont-6man-flowlabel-security-00 > > Unless I misunderstand something, you're proposing that a flow-label be > constructed using the IPv6 Source & Destination values as input-keys to a > hash function as follows: > Flow Label = counter + F(Source Address, Destination Address, Secret > Key) > If you do the above, then intermediate routers that are performing LAG > and/or ECMP load-balancing will not be able to use the flow-label as an > input-key for calculating a load-balancing hash. Instead, intermediate > routers will have to fetch a 5-tuple of {Source IP, Destination IP, > Protocol, Source Port, Destination Port} from the IPv6 header to calculate > a load-balancing hash (and, at the same time, completely ignore the > flow-label as an input-key for its flow-based load-balancing hash, since > it's redundant). Shane, I don't think your conclusion follows. One thing you want for LAG/ECMP is for each flow from a given <src_addr, dst_addr> to have a unique FL value. Fernando's algorithm achieves this by incrementing counter for each new flow from that address pair. With that said, I don't think this algorithm is necessarily ideal. The FL value for any two flows from a <src_addr, dst_addr> pair may only vary by a few bits, so if a switch/router uses a poor hash algorithm for LAG/ECMP, you may not get a good load spread. > Why couldn't (or, shouldn't) the hash function instead use the following: > Flow Label = counter + F(Source Port, Destination Port, [Protocol], > Secret Key) > > If you did this, then intermediate routers & switches that were performing > LAG and/or ECMP load-balancing could easily use the following > /fixed-offset/ header fields as input-keys to the load-balancing hash: > Load Balancing Hash = F(Source IPv6 Address, Destination IPv6 Address, > "draft-gont" Flow Label) > IMHO, this would allow draft-gont-6man-flowlabel-security to > nicely/peacefully co-exist with widely deployed/used flow-based > load-balancing schemes for LAG and ECMP. If you include protocol/src_port/dst_port in the hash, there is nothing preventing two flows from the same <src_add, dst_addr> from sharing the same FL value, due to a hash collision. Regards, // Steve -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
