Hi, Rémi, >> As for keeping track of flows, as I've just noted to Steven, this >> is a refinement. But you could probably live assuming that all >> flows terminate in a period equal to the duration of the flow label >> space (i.e., when the flowlabel space wraps and you'd reuse a >> flowlabel value, the flow that was previously using that FL value >> has already terminated) >> >> While I've assumed that RFC3697 holds when wrote draft-gont, FL >> immutability is not a requirement for the algorithm to work. > > Note that my proposal doesn't exclude stateful algorithms (no > objection to yours in particular). It just authorizes stateless > algorithms provided they are adequate for the load-balancing purpose. > I just wanted to clarify that the algorithm doesn't need additional state (as sometimes "state" at layer-3 is deemed as a show-stopper :-) )
>>> R1. Packet sources SHOULD set FLs to non-zero values that >>> generally differ from a flow to another (e.g. with currently >>> specified stateful algorithms, or with n-tuple hashes). >>> >>> R2. Packet sources MUST set FLs to zero otherwise. >>> >>> 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. >>> >>> 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. >>> >>> 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 make R3 through R5 a "SHOULD NOT.... but if you do, do it this >> way". -- but could certainly with your "MAY", as stated. > > About R3: If part of a network has the ability to identify 5-tuples > and to compute FLs, replacing null FLs by non-zero FLs seems to me a > completely acceptable choice. As I said, IMHO your "MAY" is acceptable. -- BTW, in R3 omit the "generally" ;-) > About R4: If part of a network has the ability to identify 5-tuples > and to compute good FLs, and has no confidence in upstream provided > FLs, I see no objection to its replacing old FLs by supposedly better > ones for its own load balancing (and, by the same token, for that of > downstream networks that use upstream FLs). Same as above. > About R5: I agree that SHOULD NOT would be better, with no objection > to adding "unless found strictly necessary..." I guess that if we make the above "MAY"s, this one could be a MAY, too. >>> R6. Nodes that tunnel flow aggregates SHOULD replicate non-zero >>> FLs encapsulated packets in encapsulating packets. >>> >>> R7. Nodes that tunnel flow aggregates SHOULD set FLs of >>> encapsulating packets that contain null FLs to a value that >>> characterize the tunnel itself, and MUST set it to 0 otherwise. >> Will give these last two another thought. > > Look forward to it. I'd probably specify these last two in a different document, aimed at tunnels. However, I'd not that R6 and R7 seem to lead to inconsistency: according to R6, the tunnel's FL reflects what's being transferred over the tunnel. According to R7, the tunnel's FL characterizes the tunnel itself. Thanks! Kind regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
