FWIW.... I agree with Joel. I'd like Flow Labels to remain immutable *except* in the case where it is zero. I know we can't enforce that, but that is the principle we should continue to support, and devices that violate this principle should be flogged by the Protocol Police. :-)
I think we really do want the Flow Label to retain end-to-end meaning. That is, it's contents are created as close to the originating source as possible, since the source probably has the most information available to set it sensibly. That means a first hop router or a router at the originating site's boundary should be able to change it from 0 to something sensible. I view this is a sort of optimization that allows the Flow Label to get set to a useful value even in cases where the host can't be upgraded to do that. I do not want to encourage routers elsewhere in the network to be modifying the Flow Label. We should not just say that because we can't enforce that Flow Labels in received packets satisfy certain properties, we should give up and let it be modified in any way anyone sees fit. My view is that we are just relaxing the Flow Label semantics a little bit. We aren't completely changing them. I think we can do this, while still preserving the original intent (at least in most aspects). No need to change the semantics of the Flow Label any more than the minimal necessary to make it useful for load balancing. IMO, the old text in the document should just be tossed. It makes no sense to me and I don't understand what it is trying to say. :-( If someone can explain to me what the intention of that text is, or what thinking motivated it, that might be useful. :-) E.g. > >> 2. To enable stateless load distribution at any point in the > >> Internet, a network domain MUST NOT forward packets outside the > >> domain whose flow label values are other than zero or pseudo- > >> random. So, If I'm an AS out in the middle of the network, and I'm forwarding packets I don't originate, I'm *required* to reset the Flow Label value because I have no idea if they satisfy the above properties? Say it ain't so! > >> Neither domain border egress routers nor intermediate > >> routers/devices (using a flow-label, for example, as a part of an > >> input-key for a load-distribution hash) can determine by > >> inspection that a value is not pseudo-random. Correct. But this isn't necessarily fatal either. > >> Therefore, if > >> nodes within a domain ignore the above recommendations to set > >> zero or pseudo-random flow label values, and such packets are > >> forwarded outside the domain, this would likely result in > >> undesirable operational implications (e.g., congestion, > >> reordering) Reordering? I don't understand why this is so. Congestion? Maybe, but it is going to far to say "likely". > >> for not only the inappropriately flow-labelled > >> packets, but also well-behaved flow-labelled packets, during > >> forwarding at various intermediate devices. Thus, a domain must > >> protect its peers by never exporting inappropriately labelled > >> packets. Right. And Bad Guys are really respectful of doing the right thing that the spec says in order NOT to be Bad Guys... > >> This document does not specify the method for enforcing > >> this rule. The suggested way to enforce it is that nodes within > >> a domain MUST NOT set the flow label to a non-zero and non- > >> pseudo-random number if the packet will leave the domain. If > >> this is not known to be the case, the border router will need to > >> change outgoing flow labels. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
