<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(Christopher Morrow): because I have 2 locations, one in NYC one in SFO. Running a private<br>
network link between them is more expensive than 2 commodity internet<br>
links, I can't (today) expect longer than a /48 to pass through<br>
inter-AS boundaries... so I need (now) a /47. Now, look at a business<br>
like 'the Limited' who has (at last count) +1200 remote/disconnected<br>
sites... they could need a much larger block than a /48, if they<br>
wanted the benefits of easy multihoming/no-renumbering.<br></blockquote></blockquote><div><br></div><div>These remote sites probably don't host publicly reachable services, so a simple "use PA addresses (/48 or even /56) and tunnel to corporate" approach would work just fine, yes? They could even be multi-homed, but use something like GRE to have multiple concurrent tunnels over different providers' addresses to get back to the hub.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Look at Allstate Insurance that had, at last count +10k remote<br>
sites... a /48 is a single SITE, not a single ORGANIZATION.<br></blockquote></blockquote><div><br></div><div>And how many of those remote sites have, say, ~33k network segments?<br>(I only ask because ... well, see below)</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Note that none of the above colors the discussion about NAT nor<br>
internal numbering schemes related to ULA*, I was simply pointing out<br>
that it's entirely inaccurate to believe that 'Few Organizations will<br>
need more than a single /48'.<br>
</blockquote>
</blockquote><div><br></div><div>"Few" is subjective. Comparable to every company out there, yes - I think "few" is an accurate term. In absolute numbers, perhaps resembles a different descriptor?</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">(David Farmer): Could I please direct you to Draft Policy 2010-8 up for discussion in Toronto in less than two weeks, and specifically the following section;<br>
<br>
6.5.8.1. Initial assignment size<br>
<br>
Organizations that meet at least one of the following criteria are<br>
eligible to receive a minimum assignment of /48. Requests for larger<br>
initial assignments, reasonably justified with supporting documentation,<br>
will be evaluated based on the number of sites and the number of subnets<br>
needed to support a site.<br>
<br>
Organizations may request up to a /48 for each site in their network,<br>
with the overall allocation rounded up to the next whole prefix only as<br>
necessary. A subnet plan demonstrating a utilization of 33,689 or more<br>
subnets within a site is necessary to justify an additional /48 for any<br>
individual site, beyond this the 0.94 HD-Ratio metric of the number of<br>
subnets is used.<br></blockquote><div><br></div><div>So an org with multiple "fairly large" sites (or that can draft an address plan making it appear so ... ) can get multiple, discrete, noncontiguous blocks. Don't most networks of that size have their own mechanism(s) for back-hauling traffic between sites? I guess I am trying to say that I don't see this solving a common problem ... happy to be wrong though!</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
All assignments shall be made from distinctly identified prefixes, with<br>
each assignment receiving a reservation for growth of at least a /44.<br>
Such reservations are not guaranteed and ARIN, at its discretion, may<br>
assign them to other organizations at any time.<br>
<br>
Note: Organizations with multiple sites are encouraged to consider the<br>
use of /56s for smaller satellite sites.<br></blockquote></div><br><br><div><br>/TJ<br>
</div>