-----Original Message-----
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Brian E
Carpenter
Sent: Thursday, May 06, 2010 9:11 PM
To: 6man
Subject: [Fwd: I-D Action:draft-carpenter-6man-flow-update-03.txt]
Secondly, it offers the WG a binary choice as the main decision:
"There appear to be two viable approaches:
1. Definitively forbid locally defined use of the flow label.
Strengthen RFC 3697 to say that hosts SHOULD set a pseudo-random
label value, which would clarify and limit its possible uses. In
particular, its use for load balancing and possibly as a nonce
would be encouraged.
2. Encourage locally defined use of the flow label. This approach
would make the flow label mutable and would exclude any use case
depending on end-to-end immutability. It would encourage
applications of a pseudo-random flow label, such as load
balancing, on a local basis, but it would exclude end-to-end
applications such as [I-D.blake-ipv6-flow-label-nonce]."
[[WEG]] I prefer option 2. I echo Shane's concerns that I don't trust end hosts
to be random enough (or random in the right way) to ensure that I can actually
load-balance using flow label as even a partial input on a load-balancing hash
decision. Further, that SHOULD in option 1 means that I can't assume that
anything other than a zero value will be there when considering whether to use
flow label as a part of my hash, making it just one more way that flow label
won't be used.
I tend to think that the lack of a header checksum makes the flow label's
immutability a bad assumption for end hosts (or end networks) to make anyway. I
also haven't seen a compelling use case for an immutable flow label that makes
#2 a bad idea by comparison. As I said at the mic in Anaheim, I'd rather see us
use Flow label to solve a problem that we actually have, like needing to make
loadbalancing work better, rather than reserving it for some compelling future
use that no one can seem to come up with yet. [as an aside, blake-nonce is now
expired and doesn't appear to have much in the way of support that I could find]
Moreover, I think that there are multiple other ways to manage a need to have
persistent data within a header between endpoints across multiple domains,
including extension headers, (especially if standardized under
draft-krishnan-ipv6-exthdr) as well as transport-layer headers, or even payload
data, most of which have mechanisms to ensure that the data hasn't been mucked
with somewhere in the middle. I know there are concerns about scale when
extension headers are involved, but I can say that in our core, we're basically
treating them like IPv4 options - we ignore the options/EH, but pass the packet
through the router if it's not "for us." So from that perspective, core routers
don't care how many extension headers the packet has, nor what people are
trying to do with them. This may still be an issue on PEs and other middleboxes
like firewalls, but if we move towards standardizing the headers, perhaps not
so much.
Thanks,
Wes George
This e-mail may contain Sprint Nextel Company proprietary information intended
for the sole use of the recipient(s). Any use by others is prohibited. If you
are not the intended recipient, please contact the sender and delete all copies
of the message.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
