On 2011-07-23 10:42, Karl Auer wrote: > On Fri, 2011-07-22 at 08:37 -0300, Arturo Servin wrote: >> If there were any reason for not using the flow label, I think you >> should state it very clearly in the document. > > Well, the obvious ones are > > a) your diagnostic may not be tracking a flow, but single packets or > groups of packets that are only part of a flow. It may even be trying to > figure out why a flow is not working. > > b) something else may be using the flow label such that modifying it for > debugging purposes is impossible. > >> On 22 Jul 2011, at 04:59, Roland Bless wrote: >>> a) the Flow Label is part of the standard common IPv6 header, thus >>> always present and easier to process (even in the fast path) as >>> you also pointed out. > > True, but if it is in use, you have a flow you can't diagnose (at least > not by using the flow label). Bear in mind that the flow label may even > change in transit (if I read the burbling, ever-changing discussion on > flow labels correctly, which I may well not have).
Since it's not protected by any checksum, it may be changed maliciously and undetectably. The 3697bis draft being reviewed now by the IESG states that it must not be changed once it has been set to a non-zero value, but also recognises that certain (relatively paranoid) firewalls may change it anyway. More to the point, 3697bis makes very specific recommendations as to how the flow label should be set by default. It is not a set of free bits. >>> b) Useful Flow Label support in end-systems (i.e., setting the Flow >>> Label correctly) is more likely than support for this newly >>> suggested additional option, once it would have been adopted. > > Not sure I see your point here. As soon as the flow label is being used > by end systems - correctly OR incorrectly - it can no longer be used by > diagnostic tools, or at least not if they need to modify the flow label > values. Exactly. Brian > >>> c) it is really unclear how you would enable the use of the proposed >>> option in end-systems on demand. In case of debugging a network >>> problem you need to enable this option later, if not too late. > > Presumably debugging tools would be able to do it. Having a debugging > tool after the fact is still better than having no tool at all. > > My chief worry is that if you start inserting headers in a packet stream > to debug it, you are changing what it is you are debugging - for > example, possibly causing fragmentation where none was occurring before. > The flow label has the nice property that it is in every packets anyway. > However, there are plenty of classes of problem where an additional > header would not affect the situation, and for those problems, this > seems like a useful addition. > > As a generic debugging tool, it seems to me the diagnostic header is the > most general and flexible, for all that it is not appropriate in some > situations. And it doesn't seem to actually *hurt* anything, or at least > no more than any other headers might. > > Regards, K. > > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
