stla registry db issue
Bob Fink
fink@es.net
Wed, 22 Dec 1999 11:27:27 -0800
--=====================_185895261==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Brian,
At 11:21 AM 12/22/99 -0600, Brian E Carpenter wrote:
>Well, here is the key text from RFC 2374. (there is no reason it should
>be different in subTLA space):
>
> ...It is recommended that
> organizations assigning NLA address space use "slow start" allocation
> procedures similar to [RFC2050].
>
> The design of an NLA ID allocation plan is a tradeoff between routing
> aggregation efficiency and flexibility. Creating hierarchies allows
> for greater amount of aggregation and results in smaller routing
> tables. Flat NLA ID assignment provides for easier allocation and
> attachment flexibility, but results in larger routing tables.
>
>My concern is that the way Kazu asked his question, with the concern about
>frequent updates, did not seem compatible with the idea of slow start and
>hierarchical aggregation. If we don't start with habits that create aggressive
>aggregation, IPv6 routing will be in deep trouble as it grows.
>
>I also have a concern that if an operator is really an ISP, giving them an
>NLA instead of a subTLA may be a problem until we have proved how to do
>convenient renumbering. What happens when they want to migrate away from
>using
>WIDE as their aggregator? (I realise that this is a heretical thought, since
>the current rules on subTLAs are more restrictive.)
>
>However, I agree that Kazu is not describing a strict violation of the RFCs.
Sorry I misinterpreted your concern, but at least it is clear to me now.
I've never discouraged anyone from trying to hand out intermediate transit
NLAs between the subTLA (or pTLA) holder and the end-user site (/48), and I
think what the WIDE folk are doing is just fine.
Thanks,
Bob
--=====================_185895261==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
Brian,<br>
<br>
At 11:21 AM 12/22/99 -0600, Brian E Carpenter wrote:<br>
<blockquote type=cite cite>Well, here is the key text from RFC 2374.
(there is no reason it should<br>
be different in subTLA space):<br>
<br>
...It is recommended that<br>
organizations assigning NLA address space use "slow
start" allocation<br>
procedures similar to [RFC2050].<br>
<br>
The design of an NLA ID allocation plan is a tradeoff
between routing<br>
aggregation efficiency and flexibility. Creating
hierarchies allows<br>
for greater amount of aggregation and results in smaller
routing<br>
tables. Flat NLA ID assignment provides for easier
allocation and<br>
attachment flexibility, but results in larger routing
tables.<br>
<br>
My concern is that the way Kazu asked his question, with the concern
about<br>
frequent updates, did not seem compatible with the idea of slow start
and<br>
hierarchical aggregation. If we don't start with habits that create
aggressive<br>
aggregation, IPv6 routing will be in deep trouble as it grows.<br>
<br>
I also have a concern that if an operator is really an ISP, giving them
an<br>
NLA instead of a subTLA may be a problem until we have proved how to
do<br>
convenient renumbering. What happens when they want to migrate away from
using <br>
WIDE as their aggregator? (I realise that this is a heretical thought,
since<br>
the current rules on subTLAs are more restrictive.)<br>
<br>
However, I agree that Kazu is not describing a strict violation of the
RFCs.</blockquote><br>
Sorry I misinterpreted your concern, but at least it is clear to me now.
<br>
<br>
I've never discouraged anyone from trying to hand out intermediate
transit NLAs between the subTLA (or pTLA) holder and the end-user site
(/48), and I think what the WIDE folk are doing is just fine.<br>
<br>
<br>
Thanks,<br>
<br>
Bob<br>
</html>
--=====================_185895261==_.ALT--