Please disregard, these comments are intended for
draft-ietf-opsawg-large-flow-load-balancing-05. I replied to the wrong thread.
Sorry for the spam.
Thanks,
Wes
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
George, Wes
Sent: Monday, September 16, 2013 11:49 AM
To: ietf(_at_)ietf(_dot_)org
Cc: int-area(_at_)ietf(_dot_)org
Subject: RE: [Int-area] Last Call: <draft-ietf-intarea-flow-label-
balancing-01.txt> (Using the IPv6 Flow Label for Server Load Balancing)
to Informational RFC
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.
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.