I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-intarea-flow-label-balancing-01

Reviewer: Ben Campbell
Review Date: 2013-09-30
IETF LC End Date: 2013-09-30

Summary: This draft is essentially ready for publication as an informational RFC. I have some minor and editorial comments that may be worth considering prior to publication.

Major issues:

None.

Minor issues:

-- General: 

Is this draft intended only to apply to HTTP load balancers, or is it generic to any application protocol? I think you intend the 2nd, but there's quite a bit of HTTP specific text throughout. If that's correct, it might be helpful to explicitly mention it, or to make the HTTP specific parts more generic. (e.g. "application-layer proxy" vs "HTTP proxy".)

Nits/editorial comments:

-- general:

I personally find it easier to read and understand drafts that use the TCP/IP architecture layer names rather than OSI numbers. The names have more intrinsic meaning, and since we are talking about TCP/IP architecture stuff, that model seems to fit better.

-- section 1, 1st paragraph:

It might be helpful to actually define "load distribution" and/or "load balancing".

-- section 2, 1st paragraph:

I got a little confused by the reference locations. In particular, I expected the citation at the end of the first sentence to point to the flow label spec, not IPv6 in general. I think it would be more clear to add the 6437 reference immediately after the first occurrence of "IPv6 flow label", and remove  "... and it is defined in [RFC6437]" from the second sentence.

-- section 3, first bullet list item:

Is it worth mentioning SRV here?

-- section 3, 3rd bullet list item:

-- is "raw HTTP" the same as "plaintext HTTP"?

-- section 3, 4th bullet: 2nd sentence: 

Please expand ECMP. 

-- "According to the specific scenario, it will spread new sessions..."

I suggest "Depending on the specific scenario..."

The antecedent for "it" is slightly ambiguous.

The use of the term "spread" makes it sound like a given session might get spread across multiple destinations. Maybe something along the lines of "assign new sessions to specific destinations across..."

-- " 'Persistance' is defined as guaranteeing that..."

s/ guaranteeing/"the guarantee"

-- "... run to completion on a specific server"

Would it be more precise to say that all packets for a particular session are delivered to the same server?

-- section 3, bullet list nested in numbered list shortly before the diagram:

Please put blank lines between the list entries.

-- section 3, preamble to diagram:

What is a "maximum layout"?

-- section 3, last paragraph:

Can you elaborate on why usage by proxies is unlikely to be cost effective? I can guess why, but it would be better to say it explicitly rather than leaving the reader to draw the conclusion.

-- section 4, last item in bullet list:

You say that forwarding the flow label has no performance benefit. That may be true locally for the proxy, but if a load balancer exists between the proxy and the server, there may be an overall benefit.

-- section 4, first paragraph after bullet list:

You assert that logic for handling extension headers can be omitted. I assume you mean from the actual program flow for the specific case, not from the code altogether, right? You would still need that logic for the zero value flow label case, wouldn't you?

-- section 4, last paragraph, last sentence:

s/ "statistical assumption" / "assumption that label collisions will be statistically rare"

-- section 5, 2nd paragraph: "Specifically, the specification [ ] states..."

Is that an intentional Tom Swiftie? :-)