On Fri, 29 Oct 2010 18:58:20 -0400, Suresh Krishnan <suresh.krish...@ericsson.com> wrote: > Given all that, as Brian said, one class of potential applications that > will not work well with a shorterflow label are the ones where "longer > is better". e.g. The flow label as nonce proposal. This is where we need
> to evaluate how many bits are really required. For nonce usage, obviously more bits are better, though its not clear whether 20 is significantly better than say 16. However, without iron-clad consensus that the FL must be preserved e2e, the nonce proposal won't fly. I don't see such consensus. I would like to see the WG move forward with updated spec language that accommodates the ECMP/LAG usage of the FL. Personally, I think that that a FL = 5 bits is plenty sufficient for ECMP/LAG usage (all that adding the FL to the load-balancing hash achieves is path diversity amongst flows between a particular source/destination pair). We could be generous and allocate 8-10 bits for load balancing. That would leave the other 10-12 bits for the devil's playground. If we went this route, we should then rename the load balancing field to something other than "Flow Label", because it would be too small to uniquely enumerate all of the potential flows between a source/destination pair (an existing property of the RFC 3697 definition of non-zero FLs). Bottom line: if you are *only* using the FL (in combination with the address pair) for ECMP/LAG load balancing, 20 bits is overkill. If you want to carve out bits from the FL to set aside for future use, 4 bits is probably too small to bother with. Regards, // Steve -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
