Hi, Shane,
>>> then that would
>>> provide unique flow-label values for the two flows and, consequently, a
>>> unique 3-tuple of {src_ip, dst_ip, flow_label} to be used by
>>> intermediate routers. As a result there is a high probability that
>>> intermediate routers would hash them onto different component-links in a
>>> LAG/ECMP and there is little risk of congestion.
>>
>> This is exactly what this document is proposing. Is there any particular
>> wording that is causing confusion?
>
> The part that is confusing to me is *when* does an implementation run
> your pseudocode to fetch a new flow-label value? If I look at the
> following pseudocode in the draft:
> ---snip---
> do {
> flowlabel = (offset + counter) % 1048576;
> counter++;
>
> if(three-tuple is unique)
> return flowlabel;
>
> count--;
>
> } while (count > 0);
> ---snip---
> ... the way I read the above, when it runs it /will/ return a unique
> 3-tuple of {src_ip, dst_ip, flow_label}. However, it's /not/ clear
> *when* an implementation MUST execute the above pseudocode.
... when you need to select a new FL. That is, when a new flow is
created. e.g., when a new TCP connection is to be established, or when a
new UDP socket is created.
> Based on the following text:
> ---snip---
> Considering that the Flow Label is a 20-bit field, and that Flow
> Label values must be unique for each (Source Address, Destination
> Address) pair at any given time, it might make sense to simply
> randomize the Flow Label value for each new flow.
> ---snip---
> ... in particular, the part that says: "Flow Label values must be unique
> for each (Source Address, Destination Address) pair", implementations
> would most definitely would read that as saying they only need to
> execute your pseudocode when they detect the existence of a new {src_ip,
> dst_ip} tuple. IOW, they would /not/ run your pseudocode when the same
> {src_ip, dst_ip} tuple opens up several different sockets at the same
> time, where each socket connection would have a unique 5-tuple.
Ok, I see your point, and will try to clarify this. -- I'm right now
heading to the social :-), but will post some proposed update sometime
later today (or tomorrow) for you to check and let me know whether it
addresses your concern.
Does this sound reasonable?
Thanks so much!
Kind regards,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
