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@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of > George, Wes > Sent: Monday, September 16, 2013 11:49 AM > To: ietf@xxxxxxxx > Cc: int-area@xxxxxxxx > 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@xxxxxxxx [mailto:int-area-bounces@xxxxxxxx] On > > Behalf Of The IESG > > Sent: Monday, September 16, 2013 9:43 AM > > To: IETF-Announce > > Cc: int-area@xxxxxxxx > > 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@xxxxxxxx mailing lists by 2013-09-30. Exceptionally, comments may > > be > > sent to iesg@xxxxxxxx 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.