I've reviewed this draft, and have one substantive comment:
I think within the operational considerations (and possibly the info model),
you need some discussion of diagnostics and troubleshooting, both for on-box
and off-box implementations. How do I see that it's working properly, and how
do I diagnose problems when it's not?
One of the problems with the existing hashing algorithms is that they are often
opaque, such that it's not clear what the device is doing, whether the hashing
is working properly and the flows are of the sort that create imbalanced
distribution, or whether hashing has broken somehow -- occasionally you can get
info, but it's usually hidden commands, with difficult-to-interpret responses,
and it's not like most vendors publish their "secret sauce" optimizations of
hashing so that it's easy to predict what will happen given a certain set of
flows.
In order for this to be operationally manageable, especially in the case of
on-router processing of this rebalancing, there has to be an easy way for the
operator to access the information about what's happening - what the result
would be if the flows were balanced according to the hash vs what is happening
as a result of rebalancing, so that they can chase down things like rebalancing
misses or situations where this local optimization is creating a problem
elsewhere in the path because that device did something different in its
attempts to balance better, etc. It may also be that this info is necessary to
properly tune the frequency of sampling, the thresholds for things like
long-lived vs short-lived flows, etc. to the specific network where it is being
used.
I realize that in the model you've proposed, we're somewhat limited because
this is using sampled flow data instead of the realtime packet hash. It may be
that this drives a requirement for the granularity of data being brought into
the system in the external mode, and some requirements about the level of
information available via the UI (or SNMP or XML or whatever) in the automatic
hardware-based mode.
Thanks
Wes George
-----Original Message-----
From: int-area-bounces(_at_)ietf(_dot_)org
[mailto:int-area-bounces(_at_)ietf(_dot_)org] On
Behalf Of The IESG
Sent: Monday, September 16, 2013 9:43 AM
To: IETF-Announce
Cc: int-area(_at_)ietf(_dot_)org
Subject: [Int-area] Last Call: <draft-ietf-intarea-flow-label-balancing-
01.txt> (Using the IPv6 Flow Label for Server Load Balancing) to
Informational RFC
The IESG has received a request from the Internet Area Working Group WG
(intarea) to consider the following document:
- 'Using the IPv6 Flow Label for Server Load Balancing'
<draft-ietf-intarea-flow-label-balancing-01.txt> as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2013-09-30. Exceptionally, comments
may
be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
This document describes how the IPv6 flow label as currently
specified can be used to enhance layer 3/4 load distribution and
balancing for large server farms.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label-balancing/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label-
balancing/ballot/
No IPR declarations have been submitted directly on this I-D.
Anything below this line has been added by my company's mail server, I have no
control over it.
-----------------
This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely for
the use of the individual or entity to which it is addressed. If you are not
the intended recipient of this E-mail, you are hereby notified that any
dissemination, distribution, copying, or action taken in relation to the
contents of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify the sender
immediately and permanently delete the original and any copy of this E-mail and
any printout.