Fred, I'm confused. We've been talking for months about recommending pseudo-random flow label values as inputs to hash functions, precisely to allow scaleable and stateless load balancing and ECMP.
I completely agree that per-flow state doesn't scale. Regards Brian Carpenter On 2011-01-10 14:26, Fred Baker wrote: > 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 --------------------------------------------------------------------
