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