[ppml] 2005-1 or its logical successor

[Tony Hain]

Cathy,

 

When you look too closely you can't see the forest for the trees. Yes on a
fine grained scale topology is not currently limited by geography. On a
global scale there are very few paths between major regions. The totally
random interconnect model is not a technical requirement; it is a business
choice that directly impacts the global routing system. People are
complaining about the size of the routing table, but that table could be
contracted by restricting topology. 

 

All of that misses the point though. Today we don't want to think about
restricting topology. I was not suggesting that by using a geo method for PI
would actually change anything in the short term. As long as everyone that
gets PI has a real global routing slot it really doesn't matter how those
are handed out. The point of the note was to look at the option that PI be
allocated such that down the road if the decision about random interconnects
changed we would have the option to aggregate out many of those PI prefixes
that are not necessary in the 'local' context where local is truly defined
by operators/policy makers in any given space. Structured interconnects have
a different business model than we are currently operating under, but they
do have substantial impact on the size of the routing system. 

 

There is no reason for ARIN to even bother with evaluating 'need' or
'appropriate use' of PI space as long as there is a way for providers to
aggregate out the ones that have not paid enough to support a global slot.
Most small/home multi-homers would be perfectly happy with failover between
local providers in a city. Trying to set a threshold of number of
hosts/subnets to get PI space is strictly about trying to limit the routing
table size. That is not ARIN's problem, it is the provider's problem. ARIN
has a role in that the assignments need to be done in a way that allows the
providers to do the aggregation. 

 

Tony

 

 

  _____  

From: cja at daydream.com [mailto:packetgrrl at gmail.com] 
Sent: Sunday, October 30, 2005 11:13 AM
To: Tony Hain
Cc: ppml at arin.net
Subject: Re: [ppml] 2005-1 or its logical successor

 

Tony,

As much as I think that geographical addressing could be a good idea,
networks aren't routed geographically.  The interconnections aren't there to
make aggregation per your RFC feasible.  I believe that currently there is
as much geography taken into account as can be.  The RIRs get blocks for
their regions.  Some aggregation could be done at that level depending on
how things are connected together.  I do not believe that assigning PI space
per your rfc will gain us anything that assigning PI blocks per region out
of a known PI block won't do.  You refer in your note to aggregating the
further from the source.  Unfortunately "distance" is assessed on how far
topologically in a provider network the traffic travels, not necessariliy on
how far it goes geographically. 

---Cathy

On 10/29/05, Tony Hain <alh-ietf at tndh.net> wrote:

For the purposes of discussion, one approach would be to define the PI space
in a way that could be aggregated the further it went from the source. A
sequential assignment scheme creates a swamp that is hard to manage over 
time. An approach like:
http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-08.txt
would allow for aggregation at distance, while still allowing those that 
want to have a route carried globally to enter into a direct business
relationship with each carrier for that routing slot. This would seem to
align the burden with the financial model.

Even if you started with the assumption that there was no aggregation in the

geo based PI approach, as it became popular in each region a business case
for exchange based aggregation would emerge. I know that 'topology does not
match geography', but this approach would act to constrain topology in a way

that would force alignment of the finances with the exceptions.

Tony

_______________________________________________
PPML mailing list
PPML at arin.net
http://lists.arin.net/mailman/listinfo/ppml

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051031/f8ff6b4e/attachment.htm>