On Wed, Jul 10, 2002 at 11:59:54AM -0400, Brian Haberman wrote: > Hi John, > > [EMAIL PROTECTED] wrote: > > > > I don't disagree with you - however my point was I thought that the > > application should be involved in what value of the flow label is used. > > Is it really the case that the application needs to be involved in > choosing the flow label value? Or is it more reasonable to say that > the app needs to be able to indicate that it wants to use *a* flow > label?
I see it more of a case of being able to apply more than one use to a labeled flow. i.e. say you want intserve and some other processing to happen on a particular flow. This basically requires that the signalling protocols simply communicate the value, not be involved in choosing the value. Well strictly _one_ signalling app/protocol could choose the value, but then two such apps/processes would have trouble being applied at the same time. Hence referring to the following text in section 4: (2) to assign a specific Flow Label for a new flow, and assuming this means 'assign a specific Flow Label value', and not simply a specific Flow Label, I think the text should be deleted. Similarly the text: With [RSVP] or [SDP] either the source or the destination of the flow could have a preference for the Flow Label value to be used. For example, a destination with multiple sources sending packets to it could require all the sources to use the same Flow Label value in order to collapse the classifier state to a single flow state entry, instead of having separate classifier state for each source (ref. the Wildcard-Filter reservation style in [RSVP]). Therefore the source SHOULD honor the destination's request to mark the packets with the Flow Label value specified. should also be changed. First it refers to the destination requiring a specific flow label value, I don't buy that. Why would the destination care about the flow label, it's the end node, and as such has access to all infomation in the packet. Secondly, it is again requiring that a specific value be able to be chosen / forced by the destination, this again could interfere with some other processing/handling also being applied at the same time to the specified flow (as mentioned above). I would also remove 'or requested' from the next paragraph. DF -------------------------------------------------------------------- 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] --------------------------------------------------------------------
