Actually, I agree with Michael in in-so-far-as that *somebody* should be looking at ISP-only solutions. This of course doesn't mean that others shouldn't be looking at inter-ISP solutions at the same time.
I've been very focused on ISP-only solutions, which is what led to the Virtual Aggregation draft. But this work is quite narrow in scope and not particularly appropriate for RRG. PF > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of William Herrin > Sent: Monday, December 01, 2008 6:55 PM > To: Michael Meisel > Cc: Routing Research Group Mailing List > Subject: Re: [rrg] making a difference > > 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 > _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
