Strong disagreement below... Derek Fawcus wrote: > > 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.
Absolutely not. This is text is essential to include certain possible ways of using the Flow Label. It allows a host (quite likely an application) to assign a specific, pre-defined, Flow Label value to a new flow that needs that particular value (which might for example be an IANA-defined value, or a value defined in a specific SLA). This sentence absolutely has to stay in. > > 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. No it shouldn't... > > 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. The text says why: it wants to treat multiple flows from multiple sources alike. It don't want to have to peek into every 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). When we understand all the use cases, ten years from now, maybe we can use that argument. But today we need to ensure that we don't accidentally exclude use cases. > > I would also remove 'or requested' from the next paragraph. No, for the same reasons. It isn't appropriate for us to exclude future options. Brian -------------------------------------------------------------------- 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] --------------------------------------------------------------------
