Tim Chown wrote:
> If that's static /48's, the /29 boundary will need revision...(and
> certainly a /35 would be useless to any medium ISP).

Did the term 'slow-start' get lost somewhere? As I understand rir
policy, the /35 was never intended to be the only allocation a serious
ISP would get. Static vs dynamic is a non-issue, because either there
are enough prefixes to route the currently connected customers or there
aren't. If a service provider wants to allocate prefixes to customers
that aren't connected, they will need a larger block than the one that
allocates dynamically based on connected status.

>
> Would you apply the RFC3194 0.8 HD ratio to subnets within a
> single ISP?
> I don't see that provider networks would be flat or near 100%
> utilisation
> as you suggest in your previous email.

Within the context of a pop, why not? The only reason this would not be
the case is when a provider considers the allocation to be disjoint from
current connected status (ie: static assignment) and the measurement is
done on the connected set rather than the allocated set. The HD ratio
should be calculated on the allocated set no matter if  that is static
or dynamic.


I can already hear the 'what about renumbering nodes?' question. There
is no reason for this to be an issue. Address use is defined to match
the smallest scope appropriate for the connection, so intra-site/on-link
communications will be immune to changes in the global prefix. If a site
is currently disconnected from the service provider, there is no reason
for it to have a global prefix floating around. The only reasons for an
ISP to make static prefix assignments would be if the site wanted stable
DNS entries, but with a decent DDNS infrastructure that is not even
required.

Tony



--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to