As I said, I don't like what I (re-)suggested.
But if we want routers to actually use this, then we need it to be
sufficiently reliable. If too much stuff won't get balanced, operators
will not accept the solution.
Yours,
Joel
On 5/8/2011 9:55 PM, Brian E Carpenter wrote:
Joel,
My loop detector just buzzed. This is more or less where we were
a couple of drafts ago, but people said "don't say that". Now,
I never delete old xml2rfc files, so I can bring back that text.
However, I'd like the WG chairs to decide...
Bert is correct below - if a load balancer doesn't balance the load,
it won't break sessions, but it will degrade performance.
Brian
On 2011-05-09 12:02, Joel M. Halpern wrote:
I rather hate the following idea, and I am not sure that security
gateways would be willing to follow it.
In order for flow label usage to actually help the ECMP hardware, we
have to expect it to work.
What if security gateways were expected to put reasonable, flow
distributing, flow -labels on their packets?
Put differently, what if security gateways were behaving as if the
received flow label were 0, and they were responsible for adding flow
labels as the spec allows?
Yours,
Joel
On 5/8/2011 7:21 PM, Manfredi, Albert E wrote:
Brian E Carpenter wrote:
Nodes MUST NOT change the flow label. But since you can't detect
whether
it's been changed, mechanisms using the flow label for some purpose
must
be robust against unanticipated changes.
If I may try to express what I perceive the problem to be, we have
been told that (for example, and there may be others) certain security
gateways DO change the value of that FL. And presumably, for good
security-minded reasons. So to say FL MUST NOT be changed is, I
gather, factually not possible anymore.
I agree that "since you can't detect whether it's been changed,
mechanisms using the flow label for some purpose must be robust
against unanticipated changes," however I think the hard nut is this
MUST NOT be changed requirement.
So for example, the load balancing use of FL must not cause the
session to break if FL has been changed.
Bert
--------------------------------------------------------------------
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
--------------------------------------------------------------------
