<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:"MS Mincho";
        panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:"\@MS Mincho";
        panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
a:link, span.MsoHyperlink
        {color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:blue;
        text-decoration:underline;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:Arial;
        color:navy;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
        {page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Cathy,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>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. <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>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. <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>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. <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Tony<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> cja@daydream.com
[mailto:packetgrrl@gmail.com] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Sunday, October 30, 2005
11:13 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Tony Hain<br>
<b><span style='font-weight:bold'>Cc:</span></b> ppml@arin.net<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [ppml] 2005-1 or its
logical successor</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>Tony,<br>
<br>
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. <br>
<br>
---Cathy<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal><span class=gmailquote><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>On 10/29/05, <b><span style='font-weight:bold'>Tony
Hain</span></b> <<a href="mailto:alh-ietf@tndh.net">alh-ietf@tndh.net</a>>
wrote:</span></font></span><o:p></o:p></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>For the purposes of discussion, one approach would be to define the PI
space<br>
in a way that could be aggregated the further it went from the source. A<br>
sequential assignment scheme creates a swamp that is hard to manage over <br>
time. An approach like:<br>
<a href="http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-08.txt">http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-08.txt</a><br>
would allow for aggregation at distance, while still allowing those that <br>
want to have a route carried globally to enter into a direct business<br>
relationship with each carrier for that routing slot. This would seem to<br>
align the burden with the financial model.<br>
<br>
Even if you started with the assumption that there was no aggregation in the <br>
geo based PI approach, as it became popular in each region a business case<br>
for exchange based aggregation would emerge. I know that 'topology does not<br>
match geography', but this approach would act to constrain topology in a way <br>
that would force alignment of the finances with the exceptions.<br>
<br>
Tony<br>
<br>
_______________________________________________<br>
PPML mailing list<br>
<a href="mailto:PPML@arin.net">PPML@arin.net</a><br>
<a href="http://lists.arin.net/mailman/listinfo/ppml">http://lists.arin.net/mailman/listinfo/ppml</a><o:p></o:p></span></font></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>

</div>

</div>

</body>

</html>