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 and b) the actual entropy we're
seeing in the wild. 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? 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.
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.
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.
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.
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.
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.
Which area? I'm not sure. Perhaps Transport but I can't quite judge that.
I hope this was helpful. My apologies for taking so long.
Julia Renouard
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
