Gorry, On 2009-11-11 02:42, Gorry Fairhurst wrote: > Brian, > > I agree the draft should be updated on this point (and will reference > RFC 3997). > > I have two comments/questions: > > 1) The draft speaks about tunnel encapsulations, and therefore, the > intention (as I recall - others please do chime in) was that a tunnel > ingress performing encapsulating could use a non-zero FL (as you note to > be COMBINED (hashed) with the address information, etc), to assist the > network in directing the encpasulated packet/datagram to the correct > tunnel egress/destination - i.e. load balancing? I'm looking for good > text.
I was talking off-line with Joel Halpern, and I think we concluded that the issue is general enough that it may even need a small draft of its own. No promises, but watch this space. > > 2) IMHO, something like this seems preferable to recommending the IETF > design a new transport protocol variant/mechanism to solve this > particular problem. Does this seem within the spirit of RFC ? Yes, especially the spirit of RFC1958 ;-) Brian > > Best wishes, > > Gorry > > P.S. I now have a marker in the draft to update this in the next rev. > > Brian E Carpenter wrote: >> I may have not quite understood the comments about ECMP >> and the flow label in 6man today. But here goes: >> >> The flow label spec in RFC3697 says, very carefully and >> precisely: >> >> IPv6 nodes MUST NOT assume any mathematical or other properties of >> the Flow Label values assigned by source nodes. Router performance >> SHOULD NOT be dependent on the distribution of the Flow Label values. >> Especially, the Flow Label bits alone make poor material for a hash >> key. >> >> This seems to be frightening people. The point is that, although we'd >> like the flow labels to be widely scattered across the 2^20 possible >> values, we can't be certain that arbitrary sources will generate that >> with adequate randomness. Since we didn't know when we wrote RFC3697, >> and don't know today, which end-to-end use cases for the flow label >> will emerge, we can't make any mathematical assumptions about the >> actual randomness. In fact, today, the average value of the flow label >> is essentially indistinguishable from zero. >> >> The key word in the above extract is "alone". If you want use a hash >> to drive ECMP, don't just hash the flow label, because you'll very >> likely always get the same answer. >> >> If you currently use a 5-tuple for an ECMP hash, expand it to a >> 6-tuple by adding the flow label. >> >> Section 1.2.5 of draft-fairhurst-tsvwg-6man-udpzero-00 says: >> >> An alternate method could utilise the IPv6 Flow Label to perform load >> balancing. This would release IPv6 load-balancing devices from the >> need to assume semantics for the use of the transport port field. >> This use of the flow-label is consistent with the intended use, >> although further clarity may be needed to ensure the field can be >> consistently used for this purpose. Router vendors could be >> encouraged to start using the IPv6 Flow Label as a part of the flow >> hash. >> >> I think the fact is that you can usefully *add* it to the hash, in the >> expectation that non-zero flow labels will appear in future, but >> initially it will do nothing to improve the distribution of the >> hash. So I think that the ports cannot be removed; the second sentence >> above is wrong. >> >> Brian >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
