Using the IPv6 Flow Label for Load Balancing in Server Farms
draft-ietf-intarea-flow-label-balancing-03
Yes
(Brian Haberman)
(Ted Lemon)
No Objection
(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Pete Resnick)
(Richard Barnes)
(Sean Turner)
(Spencer Dawkins)
(Stephen Farrell)
(Stewart Bryant)
Note: This ballot was opened for revision 01 and is now closed.
Brian Haberman Former IESG member
Yes
Yes
(for -02)
Unknown
Ted Lemon Former IESG member
Yes
Yes
(for -01)
Unknown
Adrian Farrel Former IESG member
(was Discuss)
No Objection
No Objection
(2013-11-15)
Unknown
Thanks for addressing my Discuss
Barry Leiba Former IESG member
No Objection
No Objection
(2013-10-08 for -02)
Unknown
One thought I had on reading this document is that it would seem to make sense as an Applicability Statement, rather than as Informational. However, the answers to questions 5 and 6 in the shepherd writeup convinced me that Informational is all that's appropriate at this time.
Benoît Claise Former IESG member
No Objection
No Objection
(2013-10-08 for -02)
Unknown
I see
If the flow label of an incoming packet is non-zero, layer 3/4
load balancers can use the 2-tuple {source address, flow label} as
the session key for whatever load distribution algorithm they
support.
And later on
The association between the flow label value and
the server is stored in a table (often called stick table) so that
future connections using the same flow label can be sent to the same
server.
Isn't it?
The association between the source address/flow label value and
the server is stored in a table (often called stick table) so that
future connections using the same flow label can be sent to the same
server.
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -02)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -02)
Unknown
Joel Jaeggli Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(2013-10-04 for -01)
Unknown
Only one piece of text to comment on: Section 2., paragraph 4: > A careful reading of RFC 6437 shows that for a given source accessing > a well-known TCP port at a given destination, the flow label is, in > effect, a substitute for the source port number, found at a fixed > position in the layer 3 header. Where do you read this in RFC 6437? The text above sounds a bit mysterious in that respect. Anyhow, even if RFC 6437 can be read in this way, your text is not correct as it stands. The flow label is in general not a substitute for TCP port number, as the port numbers are used at the end hosts to demultiplex the incoming traffic. Here is a text proposal from my side to make your point much clearer: A careful reading of RFC 6437 (according to Section X) shows that for load balancers relying on the flow label, the flow label is a substitute for the source port number, found at a fixed position in the layer 3 header, for a given source accessing a well-known TCP port at a given destination.
Pete Resnick Former IESG member
No Objection
No Objection
(for -02)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(for -02)
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(for -02)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -01)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(for -02)
Unknown
Stewart Bryant Former IESG member
No Objection
No Objection
(for -02)
Unknown