Date: Fri, 01 Oct 2010 13:25:24 -0700 From: Doug Barton <dougb@FreeBSD.org> To: freebsd-net@freebsd.org Subject: Re: Call for testers: RFC 5569 (6rd) support in stf(4) Message-ID: <4CA643B4.90109@FreeBSD.org> In-Reply-To: <20100930231715.D95502@maildrop.int.zabbadoz.net> References: <20100923.053236.231630719.hrs@allbsd.org> <4CA26BB7.2090907@FreeBSD.org> <89382820-E423-432E-8346-ADABB9FEED7F@FreeBSD.org> <4CA4E221.4060107@FreeBSD.org> <175A9E47-8457-47A6-9CA1-BDBDC407961C@FreeBSD.org> <4CA51544.9080103@FreeBSD.org> <20100930231715.D95502@maildrop.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm going to combine all of my responses into one message since it will be my last on the topic. It's pretty clear to me at this point that the code is going in, so I will make one last attempt to clarify my points in the hope that they are beneficial to anyone who is actually interested in learning. On 9/30/2010 4:38 PM, Bjoern A. Zeeb wrote: > On Thu, 30 Sep 2010, Doug Barton wrote: > > Hey, > >> In any case I didn't say that 6rd was not useful at all. What I tried >> to make the case for is that its utility is limited, both in the >> absolute sense and in the temporal sense; and that because of these >> limitations the benefits that adding the code bring are outweighed by >> the costs of maintaining it past what will likely be its useful lifetime. > > The maintainance costs are effectively pretty low, especially as it's > coming > with stf; it's a single line in a kernel config and not many more files but > it will have great value to a lot of people the next years. From your statement above it's not clear to me that you have actually reviewed the diff. However your last statement is assuming the point that we're trying to discuss. You're basically saying "it's good because it's good" which isn't particularly helpful. >> My point about FreeBSD 9 is that if we add the 6rd code today, then >> release 9.0 in about a year, then support the RELENG_9 branch for 4-6 >> years that we will still be maintaining code that no one has any use >> for. Sorry if I wasn't clear. > > While I would like to live in that kind of world that by mid 10s all > the tunneling, transition, .. technologies would be gone, ideally > along with legacy IP, I guess you are massively underestimating this > from the early adopters point of view; while for some of us things > have happened and we are waiting for the world to catch up, for other > folks things might not start within the another product lifecycle. > I am sure we'll see a lot of different scenarios for quite some time. > I would expect that we'll still be shipping that code in at least 12.x. I am not saying, nor have I ever said that the complete IPv4 -> IPv6 transition will be complete in the next 5 years. What I am saying is that 6rd, as one particular transition mechanism, will have very limited value, and that the value of it is vastly exceeded by the short term instability and long term support issues that adding it will create. >> In contrast, the bit of my post that you snipped suggested that a >> better course of action would be to focus on the areas of our v6 stack >> that will be used for the lifetime of the protocol, like the >> performance penalty that currently exists for the v6 loopback device. > > I think that noone questions that this will need time as well and so > do another 15 things on the IPv6 side but maybe someone is already > working on it .. Hope is not a plan. :) On 10/1/2010 12:43 AM, Lars Eggert wrote: > > You're seriously underestimating the transition time needed for IPv6. Actually I think based on my extensive experience in this area I'm in a very good position to forecast what's going to happen, but as I've said several times now the overall time that the total v4->v6 transition will take is not relevant to my argument about this code. On 10/1/2010 2:09 AM, Hiroki Sato wrote: > There is no trade-off between improving robustness/performance of the > basic functionality and adding a new protocol in this case. The > negative impact of adding 6rd is quite small if any, and we have > nothing to lose even if 6rd will be useless some day. http://en.wikipedia.org/wiki/Opportunity_cost (seriously, you're part of the project leadership you really should develop an understanding of this topic). Short version, every second you spend doing something that has less overall utility for the project is a second that you cannot spend doing something that has more utility. You and gnn identified the performance penalty on the loopback interface months ago, and told me that it was a massive problem that prevented us from being able to make preferring IPv6 the default. Given that no matter what happens in IPv6 transition land we're always going to need the loopback address, would you not agree that solving that problem is more important than adding new flavors of STF? Doug
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CA643B4.90109>