Julia, Many thanks for the review.
On 13/11/2012 21:00, Julia Renouard wrote: > Way overdue promised feedback for > draft-carpenter-flow-label-balancing-01 - from IETF '84. > > > > Here are some broader thoughts: > > The biggest limitation in implementing this, as a vendor, is > understanding a) how widely adopted the flow label is > currently Very little. That's why the idea is that the flow label should be included as part of the entropy but can only become the main component over time. It's a chicken and egg problem. > and b) the actual entropy we're seeing in the wild. As it happens I've done some work related to this as part of suggesting a hash algorithm better than the appendix of RFC 6437: https://researchspace.auckland.ac.nz/handle/2292/13240 > If you have any data on adoption or samplings of v6 packet > headers that might demonstrate it is in use, this would be > useful information to include. Do we know if off the shelf > stacks are implementing this now? Basically, no. These things take time to propagate. If load balancers are known to support it, this will help propagation. > Or implementing it > correctly? "Correct" usage would also be a concern. Since > this is not a part of the compliance and certification tests > and 6437 is a newer RFC, I would have concerns about the > correct usage of this field. You also have to consider what would be the consequences of incorrect use. (1) flow label set to zero: no impact on header entropy. (2) flow label set to a not-well-distributed value: partial improvement in header entropy. (3) flow label set inconsistently within a given flow: breakage. But this would pretty much have to be malicious. > > Another implementation assumption that may or may not affect > its usefulness is the guarantee that the flow label is not > changed. There is concern that intermediate nodes - perhaps > full proxies or FW's might indeed be rewriting or using the > flow label for other purposes. Despite the admonition, some > might read it as only applying to stateless forwarding nodes. > Any of these cases would break the LB's flow assumptions and > break that flow essentially. Something that might be > interesting to address is any possible heuristics to detect > this condition and "fall back" to standard flow association > algorithms. I agree, and that is also true for (3) above, so I think some such heuristics are needed anyway. However, that's so bound up in the design of a specific load balancer that I'm not sure what can be said in general. > > > > Specific notes and feedback: > > > > Should you might want to reference RFC 6294. I guess it > doesn't say much about LB but seems a gap in any case. As general background, sure. I find that in some ways to be the most depressing RFC I've written ;-). > > > Section 4: > > "Note that balancers usually do not need to consider the > destination address as it is always the same, i.e., the > server address." > > Well, this is not entirely true. LB's can be servicing > different types of servers or pools of servers or services > behind the LB. If this is a core assumption behind the rest > of the document or section, you may need to address this. If > this is not a core assumption - in other words if the rest of > the section does not rely on this assumption, then you may > not need to make this assertion. I'd be interested in a > discussion of what cases an LB may benefit from the 3-tuple > instead of just the 2-tuple. Perhaps none, but the assertion > above leads me ask. Yes, maybe it's just a distraction to mention this. > > > > I would pull out and address the NAT question in a separate > paragraph. I'm wondering if it is worth providing guidance > to NAT designers here. I also wouldn't be so dismissive of > NAT66. While I don't disagree that currently the use-cases > are not compelling, the IPv6 use-cases are still growing and > people come up with new and interesting applications that > continue to surprise. OK > > > > Summary: > > Is it worth pursuing? Perhaps - it is an interesting summary > of ideas and a good reminder of this field but I'm not sure > if this draft brings anything particularly new to the table. > It simply condenses it into a given use-case. Perhaps it has > interop value if it also reinforces or documents current > practices and the behavior required by 6437 such that we get > more consistency in stack implementations and flow-label > usage. > Fair enough. I think the main purpose of the document is to make people like you consider the issue - the IETF can't tell vendors what to do, after all. > > Which area? I'm not sure. Perhaps Transport but I can't > quite judge that. Yes, it's a topic whose place in the IETF is unclear. > > I hope this was helpful. My apologies for taking so long. *Very* helpful, and no apology needed. Regards Brian Carpenter > Julia Renouard > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
