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...)
On 16-feb-2006, at 0:15, Fred Baker wrote:
On Feb 15, 2006, at 9:13 AM, Edward B. DREGER wrote:Of course not. Let SBC and Cox obtain a _joint_ ASN and _joint_ address
Interesting. This is what has been called metropolitan addressing. I'm certainly not the one who first proposed it, although I have thought about it for a while, dating at least as far back as 2001.
The crux of the concept as several *have* proposed it is that a regional authority - a city, perhaps, or a consortium of ISPs, or in the latest version of the proposal I have seen the country of Korea - gets a prefix, and sets up an arrangement. SOHOs that want to multihome within its territory are able to get small (/48? /56?) prefixes from it, and providers that deliver service in the area may opt in to supporting such SOHO prefixes.
Whenever I have talked about the model with an ISP, I have gotten blasted.Well, the way you outline above isn't the only way to do aggregation on something other than provider. A while back I worked on this, see http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt
The idea is that a border router within an ISP/carrier network no longer holds a full copy of the global routing table, but only carries a subset. The AS as a whole still has a full view of the entire table, but aggregates make packets flow to a router that holds the appropriate part of the global routing table, and then that router hands the packets off to the right neighboring AS.
The aggregates are only used within the AS so there is no free transit. Obviously it works best if there is interconnection in the metro area in question, but it can also be made to work without dense interconnection.
Based on NANOG shim6 feedback and the push for IPv6 PI in the RIRs, I think it's time to really look at this and/or other non-traditional ways to aggregate. Apart from traffic engineering (which should be solvable) the main problem with shim6 is that it doesn't give users provider independent address space, and it's becoming pretty clear that many users REALLY want this, not withstanding all the IETF efforts to make renumbering easier.
Some sort of non-provider aggregation would allow portable address space for end-users without starting a time delayed meltdown of the global routing table. Another advantage is that such a mechanism makes it possible to start using aggregatable PI space as normale PI space immediately, and only implement aggregation in individual ASes (no coordination necessary) as the size of the routing table increases.
I dropped this approach 2.5 years ago when it turned out that there was no support for it in the multi6 working group, but the heavy criticism of shim6, the push for PI in IPv6 and the fact that geographic aggregation keeps coming up from time to time suggests that it's probably not a bad investment of time for the IETF to look at this and see if there's something there. Maybe in the form of a BOF?