> > > It also isn't clear how > > collisions would be managed (Section 3, third paragraph) > if it were possible > > for any multiple applications on the same host to specify > Flow Label values. > > We deleted a whole lot of implementation recommendations in > this area, at the > WG's request. It's entirely algorithmic but it takes you > into API and local > state areas that are out of place in a protocol spec. The IP > stack has to > cache all flow labels in current use, and whether collisions > are allowed or > disallowed is again a use case issue - you might want to use the same > coarse flow label for the audio part of video flows and for > VoIP - or you > might not, depending on how you've chosen to use the flow > label. Again, > it isn't for the IPv6 WG to legislate on this.
=> FWIW, the collision is only an issue in two cases: 1. The actual value of the Flow label has a meaning, and/or, 2. Intermediate nodes have specific states for certain flows. Either of the above, or none of the above can occur depending on how the Flow label is getting used. Therefore, it would make sense to not restrict this specification and to put the onus on future specs that specify ways of using the flow label. Hesham > > Brian > > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > > NEW ADDRESS <[EMAIL PROTECTED]> PLEASE UPDATE ADDRESS BOOK > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [EMAIL PROTECTED] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
