[arin-ppml] Abandonment of 103/104

[Davis, Terry L]

Michael

Thanks.  I didn't recall the original proposer of the concept, it was what 5 or 6 years ago?

But yes this is what I was referring to.

Take care
Terry

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of michael.dillon at bt.com
> Sent: Wednesday, December 23, 2009 1:47 PM
> To: ppml at arin.net
> Subject: Re: [arin-ppml] Abandonment of 103/104
> 
> > Is there a good reason that ARIN doesn't pick 1 to 5 hubs in
> > a province/state and assign a /32 or larger to them depending
> > on their Internet population and then make sub-allocations
> > from these region prefixes to smaller entities in that region?
> 
> When I suggested something like this, the feeling was that
> the IETF would have to bless it first. My idea was for the
> IETF to give each RIR a block that was big enough to carve
> out one suballocation region for each of the world's major
> cities that are within the RIR's region. If possible, those
> city allocations would be aggregated into clusters of cities
> that were close to each other, for instance New York and
> Montreal and Boston would be in the same cluster, San Francisco,
> Las Vegas, LA, and Tijuana in another. That sort of thing.
> 
> The basic rationale was that the world's physical network
> links tend to converge on a small number of major cities,
> somewhere between 100 to 1000 cities depending on how fine
> you want to slice it. And the small organizations that want
> to multihome typically either want to stay in the same
> building and change local providers, or move to another
> site in the same metro area, possibly with a new provider.
> 
> There's a lot more to it than that, but if the RIRs would
> implement such a scenario, it would add 1000 new city-aggregate
> routes to the DFZ, and would give end users the option of
> PA, PI or CA (City Aggregate) addressing. The existing PA
> and PI allocations would be unchanged, and no doubt, some
> providers would ignore CA altogether and it would be more
> popular in some cities than in others.
> 
> If we did implement this, then there is no longer any
> good reason for the ITU to call for country allocations
> because, for instance, half the CA address users in
> the Strasbourg, France aggregate would be located
> across the river in Germany. Maybe Tijuana would be
> part of a San Diego aggregate.
> 
> > Huge amounts of the potential global routing tables could
> > then be aggregated regionally with still gaining the ability
> > allow small local sub-allocations for small entities without
> > much impact to the global routing.  Then from the regional
> > aggregations could be broken up locally by ISP.
> 
> Exactly my point. Perhaps the time has come to take another
> serious look at it. As I recall last time, there were no
> substantive technical issues with doing this. The biggest
> problem people had was that it was not guaranteed to work
> unless imposed from above, and then people attacked that
> strawman of "imposed from above". I always viewed it as
> an experiment of sorts where we make the address space
> available to those organizations who want to try and
> make City Aggregate work. Even if it only works in half
> the major cities of the planet, that is 500 cities that
> are not spewing new entries into the DFZ.
> 
> In my opinion, there is no grand solution to DFZ growth,
> just a bunch of small improvements that slow DFZ growth
> and when all of these small improvements are combined,
> they keep DFZ growth manageable. Maybe in 10 years from
> now the RRG and IETF work will come to fruition and we
> will have a grand solution, maybe not.
> 
> > And I'm fine with the idea that if the entity moves out of
> > the regional then they do have to re-address or if they open
> > branches in other regions, those branches get regional
> > addressing based on their location.
> 
> Yes. There is not point in asking an improvement to be
> perfect and to deliver 100% of the desired benefits.
> If it works for over 80% of the cases, then it is worth
> doing.
> 
> --Michael Dillon
> 
> P.S. I will work with anyone who wants to hone this idea
> into an Internet draft.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.