[rrg] making a difference

[Paul Francis]

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: rrg-bounces at irtf.org [mailto:rrg-bounces at irtf.org] 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 
> <meisel at cs.ucla.edu> 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 ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: 
> <http://bill.herrin.us/> Falls Church, VA 22042-3004 
> _______________________________________________
> rrg mailing list
> rrg at irtf.org
> https://www.irtf.org/mailman/listinfo/rrg
>