On Mon, Dec 1, 2008 at 12:57 AM, Michael Meisel <[EMAIL PROTECTED]> wrote: > First of all, we need to push forward with ISP-only solutions. It's the > ISPs that stand to suffer the most from a rapidly growing global routing > table, and they need some tools available to them *that do not depend on > end host involvement* in case it gets out of hand.
Michael, I disagree. IMO, we should focus not on who has the most to lose but on who has the most to gain. Focusing on the losers is a losing strategy. Losers generally act to mitigate or contain their loss at the minimum expense. This reactive and conservative attitude is maladaptive when the solution consists of fresh, change-oriented ideas. To succeed, we want our plans to speak to folks who for a reasonable investment can expect to improve their strategic position. ISPs are the losers in the routing scalability problem. This is just a cost to them, and most of the solutions ask them to spend more money now so they can -hopefully- spend less later. They can be expected to offer miserly resources towards change. Small multihomed entities and maybe also mobile users are the winners in a routing scalability solution. These are the folks who will show excitement and pony up the cash if we find a solution that does something they want. > Thus, we can't rely on anyone deploying any particular scheme, but we > can provide the tools that will allow for a future where routing is > scalable and robust. Yes and no. There's a tipping point beyond which we can rely on self-interest to induce the remaining deployment. To an extent we can also create the first movers. The hard part is getting the first movers to bring in the second movers with enough momentum to carry us through the tipping point. I will say that we should avoid a model where the first-movers club is focused on a dozen or so transit-free core networks with disincentives for anyone else to jump in early. You might recognize this deployment model by its name: IPv6. Consider how IPv6 deployment might have gone differently if: * all pre-free pool exhaustion IPv6 deployment had been based on 6to4 addresses * 2002::/8 subblocks permitted in the BGP core with a "shortest prefix only" policy where only the one shortest IPv6 prefix announced by a given AS was propagated without special arrangements with each other AS. * a requirement that any IPv6 address introduced into the core have someone (either you or your ISP) running a 6to4 decapsulator to catch IPv4-encoded IPv6 traffic, * no IPv6 address assignments outside 2002::/8 until after the IPv4 free pool ran out * encapsulation the expected norm wherever an IPv6 route was not available but an IPv4 route was. Regards, Bill Herrin -- William D. Herrin ................ [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
