Thomas, All,
On Jan 10, 2011, at 15:31 MST, Thomas Narten wrote:
> Brian E Carpenter writes:
>> Given that we expect people to put flow labels into a
>> hash function of some kind, a 20-bit pseudo random number
>> seems like a better default than 1,2,3,... (depending on
>> the hash function, obvi
On 2011-01-11 12:40, Yong Lucy wrote:
>> If you want to
>>> tell me "oh, I take the modulus of the flow label with the
>>> number of servers I have to select which server", or any
>>> similar stateless algorithm, I can do it with that hash just
>>> as easily. And yes, that gives me a session predic
>
> If you want to
> > tell me "oh, I take the modulus of the flow label with the
> > number of servers I have to select which server", or any
> > similar stateless algorithm, I can do it with that hash just
> > as easily. And yes, that gives me a session predictably going
> > to the same server.
On 2011-01-11 11:50, Fred Baker wrote:
> On Jan 10, 2011, at 11:26 AM, Christian Huitema wrote:
>
>> Fred wrote:
>>
>>> Note that I am in favor of suggesting that the Flow Label be included in
>>> the hash when doing load balancing. It is a no brainer. At worst, it is a
>>> no op. But it certain
Hi Thomas,
On 2011-01-11 11:31, Thomas Narten wrote:
> Brian E Carpenter writes:
>
>> I'm not sure there's a problem here. The draft has the
>> pseudo-random label as a SHOULD and Fernando's crypto
>> algorithm as OPTIONAL. The problem with the RFC 3697
>> text is that it apparently encouraged l
On Jan 10, 2011, at 11:26 AM, Christian Huitema wrote:
> Fred wrote:
>
>> Note that I am in favor of suggesting that the Flow Label be included in the
>> hash when doing load balancing. It is a no brainer. At worst, it is a no op.
>> But it certainly is never better to exclude it.
>
> Have yo
Brian E Carpenter writes:
> I'm not sure there's a problem here. The draft has the
> pseudo-random label as a SHOULD and Fernando's crypto
> algorithm as OPTIONAL. The problem with the RFC 3697
> text is that it apparently encouraged lots of people
> to design complex schemes for encoding semanti
I'm not sure there's a problem here. The draft has the
pseudo-random label as a SHOULD and Fernando's crypto
algorithm as OPTIONAL. The problem with the RFC 3697
text is that it apparently encouraged lots of people
to design complex schemes for encoding semantics in the
flow label.
Given that we e
On 2011-01-10 18:42, Fred Baker wrote:
> On Jan 9, 2011, at 5:45 PM, Brian E Carpenter wrote:
>
>> 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 E
The changes in this version are basically:
- clarified that this is not a formal update of RFC 3697
- clarified text about domains exporting inappropriate labels
There are no changes of the intended technical meaning, since as
far as we can tell, most of the WG is OK with current technical
con
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:
> Have you looked at the security implications? Suppose that an
> attacker can predict the hash algorithm used by a router. This
> attacker could then pick "interesting" values of the flow ID, to
> get the flow of traffic directed to particular paths, or not. For
> example, they could systemati
Fred wrote:
> Note that I am in favor of suggesting that the Flow Label be included in the
> hash when doing load balancing. It is a no brainer. At worst, it is a no op.
> But it certainly is never better to exclude it.
Have you looked at the security implications? Suppose that an attacker can
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 : Duplicate Address Detection Proxy
Author(s) : F. Costa, et al.
Filename: draft-ietf-
Brian E Carpenter writes:
> 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 have a general issue with the above, but I'm not sure whether its a
re
A data center load balancer can afford, by its nature, to do as much
work as it needs to in order to get the information it needs.
The same can not be said for the ECMP / LAG case which Brian, Shane,
Steve, and I have been talking about.
Specifically, with the structure of extension headers, th
16 matches
Mail list logo
