One additional thought I had... if we move towards locally-defined flow label, we probably still need a use case and some direction for traffic that originates in tunnels prior to entering a network that is locally defining flow labels. Specifically, whatever method is employed to generate the flow label as packets come in is still going to be based on some set of data from the packet that may or may not be easily found by a PE or ASBR in the multiple layers of headers a tunneled protocol may generate, and the outer packet may not have enough info to generate an appropriate value for the flow label - multiple flows may look like the same flow because they have the same src/dst and protocol because they're being tunneled between the same endpoints, for example.
So, it may make sense to have a method where the device responsible for doing the encapsulation [should | must] insert a random value into the outer header's flow label that is based on some useful data from the inner headers. To the concern about whether it will be random enough, and whether it will conflict with the locally-significant flow labels, if it is based on the same criteria used for the locally significant flow labels, it's at least mostly safe to assume it'll be useful, and likely it'll be better than not having it. If we go with something like the previous draft, where the first few bits should be set using a defined flag value so that devices that see that value know not to re-mark those flow labels as the packets come into the network, we might have a way to make flow label more useful for traffic that is otherwise not visible enough to the transporting network to take advantage of this work, without having to worry about preserving the value across multiple n etworks. Thanks Wes George -----Original Message----- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of George, Wes E IV [NTK] Sent: Friday, May 07, 2010 5:03 PM To: Brian E Carpenter; 6man Subject: RE: [Fwd: I-D Action:draft-carpenter-6man-flow-update-03.txt] -----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 -------------------------------------------------------------------- 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 --------------------------------------------------------------------
