Joel, I did not intend to propose that domain-ingress remarking should be mandatory.
If the receiving domain does not critically depend on the received flow label values to be very smoothly distributed, then it has no need for remarking at all. My point is simply just that IF there is a specific requirement on the distribution of the flow label values, the domain must either provide such distribution itself, or trust someone else to have done that already. Maybe this is self-evident, and need not be mentioned in a protocol spec? It would be way simpler to allow marking only once (from a non-zero value), with a "pseudo-random" recommendation, and then have the rest of the path just live with whatever value was set. I would be happy with such a text. However, I'm also OK with text that allows "reasonable" (== consistent) remarking. But that should not be mandated on anyone. Jarno On Jan 31, 2011, at 16:17 , ext Joel M. Halpern wrote: > Several of these comments have a common theme of requiring domains to remark > flow-labels on ingress. > While we have agreed to allow remarking of packets with 0 values in their > flow label, expecting repeated remarking seems to me a very bad idea. > Basically, if we do that, then I expect that most routers will simply assume > that the flow label is useless, since we can not expect peering scale routers > to remark the flow label of packets based on deep packet inspection. > Also, in many cases, as described in other documents, such re-marking is > effectively impossible. > > Yours, > Joel M. Halpern > > On 1/31/2011 8:07 AM, Jarno Rajahalme wrote: >> >>> ISSUE 9. The changes to section 2 include this paragraph. Please read all >>> of it, since the first sentence out of context causes confusion: >>> >>> 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. 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. 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) 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. 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. >>> >>> We've debated and tuned this over several versions of the predecessor >>> draft. But there are still objections, such as: >>> - MUST is too strong, if the downstream operator doesn't care about >>> the flow label; >>> - We don't fully specify what the border routers must do; >>> - We should more fully specify what that hosts must do. >>> The argument for MUST is that we shoudn't allow an operator >>> to send packets into the open Internet with badly formed flow labels. >>> From the Internet's viewpoint, we don't care whether the border router >>> discards packets, clears the label to zero, or classifies packets and >>> sets a new pseudo-random label. And if a host doesn't do what is already >>> recommended, we don't care what it does; the border router has to >>> hide it. >>> >>> QUESTION: Should we, and can we, further improve this text? >> >> The fact remains that the receiving domain cannot trust the previous domain >> to have done the right thing. Therefore: >> >> "If (and only if) the receiving domain makes such use of flow label values, >> that would benefit from an even pseudo-random distribution, the ingress >> routers of such domain SHOULD map the received flow labels to new, >> pseudo-random values. The new values MUST be the same for all packets of any >> received flow, identified either by a non-zero flow label value (with the >> source and destination addresses), or, if the received flow label value is >> zero, by the 5-tuple of the received packet." >> >> I would remove text about domains protecting their neighbors. >> >> Jarno >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
