|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: a radical proposal (Re: protocols that don't meet the need...)
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
|