Sorry for the (very) late response, finally remembered to reply.
On Fri, 7 May 2010 16:03:25 -0500 "George, Wes E IV [NTK]" <wesley.e.geo...@sprint.com> wrote: > > -----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. Does there have to be a single use, or more specifically, a single specific use? It seems to me that one of the reason why there have be quite a variety of proposals on it's use are that it has some attractive properties that no other header fields or extension headers have i.e. - it's always in the IPv6 header, rather than optional like extension headers - all IPv6 implementations in at least the past 10 years support it - it is a constant and fixed size, avoiding the complexity and performance impact of dealing with a variable length field - it's mutable by the network - being 20 bits in size, it can be used to encode a million values Once concern I have about changing the above properties to suit the the ECMP traffic load balancing use case is that I think ECMP is a fairly niche use. It seems to me that only the largest of networks need to use ECMP because individual link speeds such as 40Gbps aren't large enough for them. All other networks running IPv6 won't gain any benefit from this use case, yet they're always paying the price of the flow field because it is in each IPv6 packet. I think with standardisation of 100Gbps link speeds, and talk of 1Tbps link speeds in the relatively near future, ECMP traffic load balancing usefulness for the largest of networks will also be reduced. I think making the flow field more widely useful than this specific case would be better. Regards, Mark. >[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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
