The issue is that randomness doesn't help, if you want a scalable approach. It means that for each flow passing through the load balancing system, I have to store its flow label and assign it a path. What are the arguments against NATs? One of the big ones is the expectation of per-flow state in the network, isn't it? If you're expecting the network to store per-flow state, you by definition have a scaling problem in the network.
To use the flow label in load sharing and have it be remotely scalable, the network needs to be in control of the label. On Jan 9, 2011, at 12:33 PM, Brian E Carpenter wrote: > When reviewing the text for the next update, I rediscovered that > we do in fact say > > "The proposed generic use is to encourage pseudo-random flow labels that can > be used to assist load balancing." > > so (with draft-ietf-6man-flow-ecmp also in progress) I think Fred's > point is covered. > > Regards > Brian > > On 2010-12-15 15:00, Brian E Carpenter wrote: >> We do have draft-ietf-6man-flow-ecmp, which is focussed on ECMP/LAG >> load sharing in tunnels. The reason we're proposing to recommend >> pseudo-random labels by default is so that load sharing becomes a >> natural use case. >> >> When we did RFC 3697, there was strong pressure to keep the spec >> as "pure" as possible. I was sort of assuming the same approach >> this time around. Of course, the WG can decide otherwise, but >> embedding the use case(s) in the protocol spec does lengthen >> the discussion considerably. >> >> Regards >> Brian >> >> On 2010-12-15 14:26, Fred Baker wrote: >>> So you're really really not interested in discussing the one use case that >>> people have actually talked about wanting, which has to do with load >>> sharing? What use case are you addressing? >>> >>> On Dec 14, 2010, at 5:14 PM, Brian E Carpenter wrote: >>> >>>> Hi, >>>> >>>> The authors have received one off-list comment on this version, >>>> requesting additional clarification of the text associated with >>>> this recommendation: >>>> >>>>>> 2. A network domain MUST NOT forward packets outside the domain >>>>>> whose flow label values are other than zero or pseudo-random. >>>>>> >>>> Does anyone else have comments, or are we getting somewhere near agreement? >>>> >>>> Regards >>>> Brian Carpenter >>>> >>>> >>>> On 2010-12-03 12:40, Brian E Carpenter wrote: >>>>> Hi, >>>>> >>>>> This is intended to reflect the various comments made in Beijing, >>>>> notably strengthening the points about the flow label not being >>>>> changed en route. Please review - if the WG is generally OK >>>>> with this version, we'll start to think about RFC3697bis. >>>>> >>>>> Brian + Sheng + Shane >>>>> >>>>> -------- Original Message -------- >>>>> Subject: I-D Action:draft-ietf-6man-flow-update-00.txt >>>>> Date: Thu, 02 Dec 2010 15:00:02 -0800 >>>>> From: [email protected] >>>>> Reply-To: [email protected] >>>>> To: [email protected] >>>>> CC: [email protected] >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the IPv6 Maintenance Working Group of the >>>>> IETF. >>>>> >>>>> >>>>> Title : Update to the IPv6 flow label specification >>>>> Author(s) : S. Amante, et al. >>>>> Filename : draft-ietf-6man-flow-update-00.txt >>>>> Pages : 13 >>>>> Date : 2010-12-02 >>>>> >>>>> Various published proposals for use of the IPv6 flow label are >>>>> incompatible with its existing specification in RFC 3697. >>>>> Furthermore, very little practical use is made of the flow label, >>>>> partly due to some uncertainties about the correct interpretation of >>>>> the specification. This document proposes changes to the >>>>> specification in order to clarify it, making it clear what types of >>>>> usage are possible, and to introduce some additional flexibility. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-update-00.txt >>>>> >>>>> >>>>> >>>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> [email protected] >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >> -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
