On Jan 21, 2011, at 4:29 PM, Brian E Carpenter wrote:
> On 2011-01-22 12:07, Fred Baker wrote:
>> On Jan 21, 2011, at 11:25 AM, Brian E Carpenter wrote:
>>
>>> We seem to have agreed that the primary purpose of the flow label is
>>> to facilitate load balancing, which is a statistical process.
On 2011-01-22 12:07, Fred Baker wrote:
> On Jan 21, 2011, at 11:25 AM, Brian E Carpenter wrote:
>
>> We seem to have agreed that the primary purpose of the flow label is
>> to facilitate load balancing, which is a statistical process.
>
> except when it is not a statistical process.
Yes, I sho
On Jan 21, 2011, at 11:25 AM, Brian E Carpenter wrote:
> We seem to have agreed that the primary purpose of the flow label is
> to facilitate load balancing, which is a statistical process.
except when it is not a statistical process.
---
Fernando Gont writes:
> On 21/01/2011 04:49 p.m., Thomas Narten wrote:
> > But other uses of the Flow Label outside of that do not have that
> > requirement.
> >
> > So, if you do traditional flows, you have to be sure to generate Flow
> > Labels carefully. The default usage outside of signali
On 21/01/2011 04:49 p.m., Thomas Narten wrote:
> But other uses of the Flow Label outside of that do not have that
> requirement.
>
> So, if you do traditional flows, you have to be sure to generate Flow
> Labels carefully. The default usage outside of signaling does not
> have the same requirem
> However, it is NOT required that flow labels are strictly unique - a
> birthday-paradox rate of duplicate flow labels really won't
> matter. I suggest (and this is a new suggestion that's been in my
> mind for a few days) that the uniqueness requirement can and should
> be relaxed to 'unique with
On 2011-01-22 06:24, Fernando Gont wrote:
> Hi, Bob,
>
> On 21/01/2011 02:20 p.m., Bob Hinden wrote:
>
> 1. It is RECOMMENDED that source hosts support the flow label
> by setting the flow label field for all packets of a flow to
> the same pseudo-random value.
I do not see a rea
Hi, Bob,
On 21/01/2011 02:20 p.m., Bob Hinden wrote:
1. It is RECOMMENDED that source hosts support the flow label
by setting the flow label field for all packets of a flow to
the same pseudo-random value.
>>>
>>> I do not see a reason to require this.
>> Probably that could/shoul
Fernando,
On Jan 21, 2011, at 8:55 AM, Fernando Gont wrote:
> Hi, Thomas,
>
> On 10/01/2011 11:10 a.m., Thomas Narten wrote:
>> The crux of the issue is the following:
>>
>>> 1. It is RECOMMENDED that source hosts support the flow label by
>>> setting the flow label field for all packe
Hi, Thomas,
On 10/01/2011 11:10 a.m., Thomas Narten wrote:
> The crux of the issue is the following:
>
>>1. It is RECOMMENDED that source hosts support the flow label by
>>setting the flow label field for all packets of a flow to the
>>same pseudo-random value.
>
> I do not
On 2011-01-18 08:27, Christian Huitema wrote:
> Thomas Narten wrote:
>
>> I'm a bit stuck on this point, because both of the current flow label
>> document
>> continue to say flow labels should be generated SHOULD be pseudo-random,
>> and I'm not convinced this is necessary, required, or buys u
On Mon, 17 Jan 2011 12:55:53 -0700, Shane Amante
wrote:
Thomas,
On Jan 17, 2011, at 10:08 MST, Thomas Narten wrote:
The point being, an attacker doesn't have to guess the actual Flow
Labels that are being in use, but just come up with way to generate
traffic that ECMP maps onto the target
Thomas,
On Jan 17, 2011, at 10:08 MST, Thomas Narten wrote:
[--snip--]
> The second case concerns a number of paths across which traffic is to
> be split. An attacker might want to overload a particular path. One
> way to do this is to guess the Flow Labels being used for ECMP. But it
> seems like
Thomas Narten wrote:
> I'm a bit stuck on this point, because both of the current flow label
> document
> continue to say flow labels should be generated SHOULD be pseudo-random,
> and I'm not convinced this is necessary, required, or buys us anything.
> What compelling argument am I missing?
Christian Huitema writes:
> 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
> examp
On Jan 11, 2011, at 10:14 AM, Shane Amante wrote:
> What causes pain and/or worry to us operators is when someone launches a
> large *individual* "macro-flow"[1] at the network that start to represent a
> decent fraction of the overall capacity of a physical component-link
> underlying a LAG an
On 2011-01-12 04:41, Yong Lucy wrote:
>>>
>>> [LY] Statistical approach works well under the consumption that there
>> are
>>> thousands of flows and they have the similar rates. Today's Internet may
>>> have the flows that only have few packets and the flows that have
>> thousands
>>> packets per
Shane and all,
>
> What causes pain and/or worry to us operators is when someone launches a
> large *individual* "macro-flow"[1] at the network that start to represent
> a decent fraction of the overall capacity of a physical component-link
> underlying a LAG and/or ECMP path, (e.g.: and the f
Fred,
On Jan 11, 2011, at 10:29 MST, Fred Baker wrote:
> On Jan 11, 2011, at 9:10 AM, Shane Amante wrote:
>
>> It's probably better to say that a hash algorithm works well where
>> individual, long-lived flows (regardless of traffic type) are a small-ish
>> fraction of the physical BW of any in
On Jan 11, 2011, at 9:10 AM, Shane Amante wrote:
> It's probably better to say that a hash algorithm works well where
> individual, long-lived flows (regardless of traffic type) are a small-ish
> fraction of the physical BW of any individual component-link in a LAG or ECMP
> group. It's when
Lucy, Brian,
On Jan 11, 2011, at 08:41 MST, Yong Lucy wrote:
>> In fact no solution works well for short flows and the problem isn't
>> important
>> for long flows with few packets. So I think it's OK to discuss a solution
>> that works for long flows with many packets, since that covers most
>> o
> >
> >
> > [LY] Statistical approach works well under the consumption that there
> are
> > thousands of flows and they have the similar rates. Today's Internet may
> > have the flows that only have few packets and the flows that have
> thousands
> > packets per second and last long. Hash does not
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
> 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
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
On Jan 9, 2011, at 7:05 PM, Steven Blake wrote:
> The network doesn't control port numbers, so his argument obviously doesn't
> apply to ECMP or LAG.
There are more than two common uses of load balancing. ECMP is a side effect of
routing; we decide to multipath route when we know of two next h
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 ECMP.
>
> I completely agree that per-flow state do
On Mon, 10 Jan 2011 14:45:05 +1300, Brian E Carpenter
wrote:
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
arpenter 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 + Sh
gt;>>>>>> whose flow label values are other than zero or pseudo-random.
>>>>>>>
>>>>> Does anyone else have comments, or are we getting somewhere near
>>>>> agreement?
>>>>>
>>>>> Regards
t;>>> 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,
>>>>> not
ents 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 +
Fernando,
Thanks for the comments. About the non-editorial points:
On 2010-12-16 09:39, Fernando Gont wrote:
...
> Section 2 states:
>
>>Also, it could be used as a covert data channel, since apparently
>>pseudo-random flow label values could in fact consist of encrypted
>>data.
>
Hi, Brian et al.,
(I was meaning to send this one more than a week ago... but apparently
this one got stuck in my "Drafts" folder)
In general, the document looks good. However, there are IMO a few issues
that should probably be fixed.
In the Abstract, one gets the impression that this document a
On 2010-12-15 15:58, Steven Blake wrote:
> On Wed, 15 Dec 2010 14:14:02 +1300, 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
On Wed, 15 Dec 2010 14:14:02 +1300, 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
;>> 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
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
>>
>> Ori
he 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-fl
ginal 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 direct
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:
51 matches
Mail list logo
