Le 13 sept. 2010 à 01:38, Brian E Carpenter a écrit : > On 2010-09-10 00:09, Rémi Després wrote: > ... >> R3. Intermediate nodes MAY replace null FL values by non-zero FL values, >> PROVIDED these non-zero values generally differ from a flow to another. > > IMHO that isn't a strong enough condition, if we want load balancing to be > the preferred default usage. In fact it is one of the criticisms of 3697 > that all it demands is a unique value, rather than a pseudo-random value.
I now understand that this wording is insufficiently precise, thanks. Would it be more acceptable to replace "generally differ from a flow to another" by: "have a low probability of collisions with those of other flows, be they from the same source or not." In my understanding, a hash of n-tuples that identify flows, with or without a combination with a stateful counter, satisfies this constraint. Is there something I still miss? > >> R4. Intermediate nodes MAY replace non-zero FL values by non-zero FL values, >> PROVIDED these non-zero values generally differ from a flow to another. > > That makes the FL completely mutable. I don't detect consensus for that; Mutable *within the constraint of the strong condition above* is different from *completely mutable*. The reason for R4 is that, if some intermediate nodes that hve tools and the processing power available to re-compute good n-tuple hashes, their administrators may wish to increase confidence in their own load balancing by re-computating FLs. This behavior wouldn't IMHO be typical but, as it doesn't disrupt anything, it should at least be permitted. > as > people have said, we have diffserv for that, and 6 bits seems to be plenty... Diffserv code points having no relationship with the load balancing objective, they shouldn't IMHO have an impact on how to improve RFC 3697. >> R5. Intermediate nodes MAY replace non-zero FL values by null values ONLY IF >> found necessary for some identified policy-dependent security reason (e.g. >> in some managed firewalls). > > I'd go a bit further - if a domain ends up using non-pseudo-random values, > they should be zeroed out before letting packets escape the domain. I hope the consensus would be that no domain would be permitted to use non-pseudo-random values if not restoring original values at exit. Otherwise, the value of setting FLs in sources would IMHO diminish to much. As a matter of fact, I would personally be better satisfied if intermediated nodes *SHOULD NOT* replace non-zero values by null values. Even better *MUST NOT*, but I got the impression that this was not acceptable to firewall people (=> to be checked?). Regards, RD > Brian > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
