On May 7, 2010, at 15:28, Joel M. Halpern wrote: > The more I think about "encouraging" locally defined use of the flow label, > the less I like it. > > The basic problem is that in the context we are discussing, is for use by > routers. > If you have locally defined flow label usage, then > 1) Any vendor selling to an operator has to somehow manage to support their > locally defined behavior. > 2) Operators MUST configure all their routers to properly understand their > flow label meaning. > 2') Given that it can not be counted on, even the global interpretation such > as the use of non-zero flow-labels for ECMP/LAG balancing would be to be off > by default, since there would be no default expect ability to match that use. > 3) This is quite fragile. Given that there is no indication in the packet of > what meaning of flow-label was intended, there is nothing that will alert an > operator if (as seems periodically inevitable some of the routers are > attempting to apply a different interpretation than the operator intends. > > Basically, from a vendor's perspective, a multiplicity of local > interpretations of flow label is a serious impediment to implementing any > usage of flow label at all. > > One could argue that as long as the routers are all from one vendor, they > will support the same local interpretation. I hope we are not going there! > > Hence, to be clear and specific, I support approach 1, and oppose approach 2.
+1. It appears that the flow label has long been an "attractive protocol", i.e. a solution (more precisely: 20 spare bits) looking for a problem. So far, the only set of problems that it appears to be useful for is *end-to-middle hints*. -- it is not very useful for end-to-end, as it is not protected by destination functions such as the pseudo-header or AH. -- it is not very useful for middle-to-middle, as we don't know how to properly nest this usage. -- it also is not very useful for anything but hints, because it is not protected. The end-to-middle hints that we have found so far appear to be: a) grouping of packets into flows where it is useful to ask for maintaining sequence in ECMP/LAG scenarios b) selection of forwarding behavior (RPL instance ID) in RPL-based domains. I'm not sure I like (b) yet, because it is hard to use by nodes outside these domains, who may not know what forwarding classes are available. It is bad when the packet has to traverse multiple RPL domains. Otherwise, stealing bits from the flow label for traffic-class-style information (as long as it is about hints) sounds almost reasonable. Gruesse, CArsten -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
