> -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Christian Huitema > Subject: RE: I-D Action:draft-krishnan-6man-header-reserved-bits-00.txt > >But then, waiting for the traffic to increase and the load > balancing needs to materialize also makes a lot of sense.
[WES] No, actually it doesn't, especially not as a justification for this draft. We as operators are telling you that we need something now, because we've seen this load-balancing movie already in IPv4 and we'd like to get ahead of it in IPv6. If you are proposing waiting to implement a better solution for load-balancing because IPv6 traffic isn't there yet, you are simply being short-sighted, which is funny given that this draft is an attempt to future proof the IPv6 header. All it takes is a few key traffic sources/sinks moving to IPv6 on your average network... People see their IPv6 traffic increase dramatically *overnight* simply by enabling whitelisting for the Googtubemail sites. 3 years ago, I might have bought that tired old "wait and see" argument, but not when we're this close to IPv4 exhaust and starting to see real IPv6 deployments happening in many major ISPs. >I am pretty > sure that 5 or 10 years from now someone will be glad that there are > unused bits in the header... [WES] Call me crazy, but I'm pretty sure that's why Extension Headers exist. Someone would be directed to RFC 2460 section 4 and asked to explain why that wouldn't work for their pet idea. This draft's authors have the same burden of proof as far as I am concerned. And no, "...extension headers are not examined or processed by any node along a packet's delivery path..." is not a good enough reason in and of itself, because one would still have to convince people (specifically router vendors and SPs) that this set of bits is so important that routers in the middle of the path would need to slow down their processing or build silicon to look at it (and take some action) at linerate. Yes, I realize that the same issue exists for any existing use of FL that is on the table, but at least there's a reasonable justification for that as being integral to high-scale packet forwarding. See also RFC 3330/5735 for a great example of "future use" gone awry. Wes George ________________________________ This e-mail may contain Sprint Nextel 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 --------------------------------------------------------------------
