Beginners may also want to keep up with the current specs for IPv6 used in infiniBAND. Only the essential elements are used. http://www.infinibandta.org
----- Original Message ----- From: "Brian E Carpenter" <[EMAIL PROTECTED]> To: "Tony Hain" <[EMAIL PROTECTED]> Cc: "Margaret Wasserman" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, December 21, 2001 5:20 AM Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
