Hi Thomas: I've seen different requirements depending on where the utilization would be.
a) Close to the source of the source or destination, the flow label could be used in an application-aware fashion, for instance to influence the routing of the packet in VRFs. We'll note that we do not have a .1Q equivalent in IPv6 and that though too small, the flow label is the only place before the IPv6 header to indicate a context in which the destination address is to be used. b) Farther in the network, it could be used for blind NECM. >From the discussions I've seen, people are mostly focused in b), with an additional assumptions that a flow is something that has a given source/destination pair. Sadly (for me) the case I'm most interested in is a), and the flows I look at can often be useful only if you can group multiple source / destinations in a single flow. What I'd really like to see is that whatever is decided to help b) does not prevent a). I think it can be done easily if the border routers are allowed to overwrite a FL, which is not the case today. Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Thomas Narten > Sent: Tuesday, January 11, 2011 2:41 PM > To: [email protected] > Subject: Flow Labels: what problem are we solving? > > Sorry to get back to basics, but I have not followed all the Flow Label > discussions or read all the drafts. I have read > > draft-ietf-6man-flow-ecmp-00.txt > draft-ietf-6man-flow-update-01.txt > > pretty carefully and I still don't quite understand what real problem we are > trying to solve - and thus, whether the proposed changes actually help or are > a no op. > > Is there a document that speaks to this? > > Question: > > I understand the value of ECMP type load balancing. But how much of a > problem is it today (with IPv6) if the Flow Label is not used? > > If you hash on just the 5 tuple (excluding the flow label), you get (I assume) > the equivalent of what you have in IPv4 today. Why is that not good enough? > > Also, splitting flows across different links would seem to have value primarily > if you hvae a single source (or rather single src/dest pair) generating a *lot* > of traffic/flows, i.e., so that if you split traffic from that source/dest pair, you > see measurable load-splitting. > > Is this happening in practice today? Can operators please speak to this? And > if it is a problem, is it primarily with tunneled traffic (where the tunnel > aggregates many flows), or is it really between individual pairs of nodes that > are sending a *lot* of traffic to each other? Are there examples of this? > > (I'm not necessarily opposed to this work going forward, but I'm not entirely > convinced we are solving a real problem. Help me please.) > > Thomas > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
