I think in the end this is an argument about nothing. 

>  This implies that IPv6 nodes SHOULD NOT establish any
> flow-specific state unless so instructed by a specific flow state establishment 
>method. 
> 

What Margaret and itojun refer to are flow state establishment methods that
happen to consist of algorithms built into the sending node (rather than
signaling mechanisms or pre-configured flow states).  These algorithms
must avoid duplicate labels, just as signaled or pre-configured
methods must. So the sentence is in fact a no-op and can be deleted.

While I'm writing, I agree with all of Jarno's other changes.

   Brian

[EMAIL PROTECTED] wrote:
> 
> >I don't agree with the "SHOULD NOT" above...
> >
> >There are some potential uses for flow identification that do not rely on
> >any sort of flow establishment mechanism or signalling, such as the use of
> >flow labels for load balancing.
> >
> >To have a useful flow label for these mechanisms, an IPv6 node simply labels
> >all of the packets in a given TCP/SCTP connection or UDP communication with
> >the same flow label,making some basic effort not to re-use flows too often --
> >such as starting with a random number and monotonically increasing it for
> >each new connection or communication.
> >
> >It would be fairly trivial to assign a flow label in this fashion -- not
> >much harder than setting it to zero.  So, you get a reasonable return for
> >very little work.
> 
>         I agree with Margaret.  KAME has been doing this (automatically
>         assign flow labels to TCP/connected UDP traffic) for a long time,
>         so that we can help traffic analysis/diffserv researchers.
>         (they can't correlate traffic due to the use of ESP, or SSH)
>         draft-itojun-ipv6-flowlabel-api-01.txt has more details on it.
> 
> itojun

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to