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). > > 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. > > 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. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer ([email protected]) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
signature.asc
Description: This is a digitally signed message part
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
