Let me phrase Brian's comment differently.
Presume we actually get wide use of the flow label in accordance with
the load balancing draft.
What can go wrong? Well, someone could send all their traffic with a
single flow label, reducing the randomness.
So what goes wrong. All of that subscribers traffic ends up on a single
link. Mostly, that means that if he does this, he increases the
likelihood that his traffic will get damaged. Seems unlikely he would
choose to do that.
We coudl fo course view this as a deliberate attack. But, in fact, it
is an attack that could already be done. The subscriber simply sends
all his traffic with a single set of ports (source and dest). That will
have the exact same effect on the current system that a fixed flow-label
would have under the proposed behavior.
So I do not see why the network needs to "control" the flow label, any
more than it needs to "control" the ports the subscriber uses.
Yours,
Joel
On 1/9/2011 8:26 PM, 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: internet-dra...@ietf.org
Reply-To: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
CC: ipv6@ietf.org
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
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
