Tony,
I'm ok with both of the text improvements you proposed.
Thanks,
Jarno
> -----Original Message-----
> From: ext Tony Hain [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 12, 2002 10:04 PM
> To: 'Michael Thomas'; 'Margaret Wasserman'
> Cc: 'Brian E Carpenter'; Rajahalme Jarno (NRC/Helsinki);
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: Flow label draft issues & new text
>
>
> Michael Thomas wrote:
> > ... snip
> > > What doesn't work is if there may be non-zero values in
> > the flow label > that actually don't label flows. How is a
> > load-balancing or load-spreading > router supposed to know
> > that this isn't a flow label?
> >
> > Er, well, it _doesn't_. I guess I just don't
> > attach any special meaning to the word "flow";
> > that is, a flow is whatever the host says is a
> > flow. If it's bizarre, then well, why should
> > the router care? Again, other than maybe gaming
> > fair queuing algorithms[*], why do routers
> > actually care about what constitutes the
> > sematics of the flow? It's really in the host's
> > best interest to be network friendly, right? To
> > give routers information which increases the
> > probability of forwarding its packets in the
> > manner it hopes for, right?
> >
> > ... snip
> > Er, but the flow label *is* an element of a
> > packet classifier, or rather perhaps a
> > replacement for the current method of classifying
> > packets. I thought as far as routers are
> > concerned, flow label were opaque and that no
> > internal semantics were visible.
> >
>
>
> Mike is right, as far as middle-boxes are concerned the FL is opaque
> unless they have been given specific state to believe otherwise. There
> is no reason a load-spreader would have a problem with frequent reuse,
> or even all nodes deciding to use the same value for HTTP as
> long as it
> is basing its decisions on the Src/Dst/FL rather than just the FL.
>
>
> I do have comments on the text. I would like to see the following
> changed from:
> 4. Flow Labeling Requirements
> (4) The source SHOULD assign each new transport connection (e.g.
> TCP, SCTP) to a new flow.
>
> to:
> (4) The source SHOULD assign each unrelated transport
> connection (e.g.
> TCP, SCTP) to a new flow.
>
> This would keep it from conflicting with (3).
>
>
> 5. Flow State Establishment Requirements
> ...
> To enable co-existence of different methods in IPv6 nodes, the
> methods MUST meet the following basic requirements:
> ...
> (3) The IPv6 node facility keeping track of the Flow Label and the
> associated Source and Destination Addresses MUST be utilized
> when assigning Flow Label values to new flows (see section 4
> above).
>
> That wording seems awkward, how about:
> (3) The IPv6 source node MUST provide a facility for keeping track
> of the Flow Label values associated with particular Source and
> Destination Addresses for use when assigning Flow Label to new flows
> (see section 4 above).
>
>
> Tony
>
>
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
