[Int-area] Feedback for draft-carpenter-flow-label-balancing-01

[Julia Renouard <[e-mail]>]

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