I concur. The flow label should be set by the source host and remain immutable as it travels over the network.
Rich At 12:20 PM 12/21/01 +0100, Brian E Carpenter wrote: >Tony is 100% correct in all his comments. I'd add that >hop-by-hop options are not even on the radar screen for >hardware implementation, but for QOS flows we absolutely >need things that hardware can process at line speed. > > Brian > >Tony Hain wrote: > > > > Margaret Wasserman wrote: > > > What is wrong with a hop-by-hop option? Isn't that the "right" > > > mechanism for an IPv6 host to send a "message" that is processed > > > by all routers in the path? > > > > Hop-by-hop options will be slower to process, and the point is that the > > origin knows which packets belong together in any specific flow, and > > there is no way the routers can deduce that. If the origin specifies > > which packets belong together, there is no valid reason for anything > > along the path to decide otherwise. > > > > > >You are assuming that every router along the path is part of the same > > > >administrative system and would react consistently to the marking. > > > > > > No I'm not assuming that all routers in the path will understand > > > the flow label. I am assuming, though, that the flow label will > > > only be _useful_ within an administrative system that has > > > a consistent (or at least compatible) understanding of its meaning. > > > > I didn't state my argument clearly. I agree that not all routers along > > the path may care to pay attention, but as you said your assumption is > > that the ones that do are all are part of a single administrative > > system. This is not reasonable to assume in the general case, so what I > > am arguing is that routers in any independent administrative system in > > the path have consistent information to base decisions on. How they > > acquire the interpretation is independent of the fact that the bits are > > consistent throughout. > > > > > I don't understand how these three systems can usefully interpret > > > the same bits in two different ways. If I am choosing a random > > > flow label value at the source (with an "interactive system" that > > > indicates its meaning out-of-band), why won't I just get random > > > behaviour from the intermediate domain in your example? > > > > You might, but if we allow the intermediate domain to independently > > modify the bits there is no hope that the remote domain can get it > > right. As I said earlier, it is possible for the intermediate system to > > provide a predictable behavior based on the additional knowledge of FL > > without explicit knowledge of the semantics, but that might be more > > along the lines of drop-probability than EF or the like. > > > > > Then, why not leave the specification of flow label semantics and > > > rules to this same WG? > > > > Because the participants in those WGs have consistently proven they > > don't understand the concept of an architecturally consistent immutable > > field which the origin can trust. > > > > 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] >-------------------------------------------------------------------- ------------------------------------ Richard A. Carlson e-mail: [EMAIL PROTECTED] Network Research Section phone: (630) 252-7289 Argonne National Laboratory fax: (630) 252-4021 9700 Cass Ave. S. Argonne, IL 60439 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
