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
--------------------------------------------------------------------
