Home page logo
/

nanog logo nanog mailing list archives

Re: a radical proposal (Re: protocols that don't meet the need...)
From: Chip Mefford <cpm () well com>
Date: Wed, 15 Feb 2006 14:37:44 -0500



Edward B. DREGER wrote:
MA> Date: Wed, 15 Feb 2006 16:31:56 +0100 (CET)
MA> From: Mikael Abrahamsson

MA> The current routing model doesn't scale. I don't want to sit 5 years from
MA> now needing a router that'll handle 8 million routes to get me through the
MA> next 5 years of route growth.
MA> 
MA> PI space for multihoming and AS number growth is a bad thing for scaling and
MA> economics, however you look at it.

ED> I'm going to suggest something horribly radical (or nostalgic,
ED> depending how long one has been in the industry): inter-provider
ED> cooperation.
ED>
ED> Let's examine _why_ the routing table might become large.  Lots of
ED> smaller players multihoming, yes?  Say two million small businesses
ED> multihome using SBC and Cox.  Must we have two million global ASNs
ED> and routes?
ED>
ED> Of course not.  Let SBC and Cox obtain a _joint_ ASN and _joint_
ED> address space.  Each provider announces the aggregate co-op space
ED> via the joint ASN as a downstream.

This makes a lot of sense.

However, as one of those smaller players, who may be multihomed
using SBC and Cox, as your example says, I can fairly say
that I don't like renumbering very much, and sometimes one
finds there is a good business case to be made to switch providers,
In short, having an ASN is good for me, if not for the community
at large, so how to balance that?

Right now, gettin ONE upstream to issue a private asn can be
like an amatuer dental extraction, imagine 2 that don't like each other,
or more often are totally ambivalent with regards to the others
concerns/cares/policies/proceedures, et al.  One says xxx00, and
the other xxx01, how am I supposed to sort this out?


ED> This is very similar to a downstream using a private ASN to connect
ED> to one upstream in two different locations.  i.e., transit provider
ED> uses the same ASN for all such customers, and certainly needn't
ED> pollute the global table with longer prefixes.

mmmm, okay,

ED> We're dealing with _one_ routing policy: hand it to Cox, or hand it
ED> to SBC.  Why explode it into two million "different" policies?

Are we? Or are we dealing with _one_ routing policy: handing
it to Cox AND handing it to SBC, who mediates? Right now, it
appears as if it would me, the end-user. I'm just not equipped for that.

ED> Look at MPLS.  It essentially hunts down congruent or similar
ED> routing policies, slaps a tag on the packet, and routes based
ED> that. Why not explore options that get it right and coalesce from
ED> the get-go?

ED> Note also that this is totally op-community.  No new protocols
ED> required.
ED> It can be done today without forklifts.


Agreed. Good idea. Nice idea, very appealing, really.

I just don't know how it would play out in practice between
two providers, who as we have seen over recent short history
don't necessarily work and play well together.

ED> I thought I proposed this at 35.  Maybe that was one of the open mic
ED> sessions where time ran out...>
ED>
ED> Eddy
--footer snipped


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]