prefix lengths [was Re: stla registry db issue]

[Brian E Carpenter]

Paul Wilson wrote:
...
> Finally, on the question of advertising prefix lengths longer than /29, it
> is in fact the proposal of the RIRs that the prefixes announced by any
> organisation will correspond only to their allocation (anywhere from /16 to
> /35), and not to their reservation (which would be either /16 or /29). The
> justification behind this (as discussed with the IAB in Minneapolis last
> year) is that in a future scenario where many TLA and subTLA blocks were
> released and allocated, and where routing table expansion again becomes a
> concern, it is necessary for ISPs to have an objective means available for
> limiting the size of their routing tables, and the best such means available
> is to filter on prefix length.

I have a fundamental conceptual problem with what you are saying,
so we must have miscommunicated in Minneapolis on this. The original
idea was very clear: only TLAs would be visible in the default free routing table,
i.e. the default free table would be strictly filtered at /16 and thus hard
limited to 8192, or maybe 16384 if we had to open up a second set of TLAs.

Then we added one set of subTLAs, which actually gives a hard limit of
8191 TLAs and 8192 sub-TLAs, i.e. 16383, and the default free table contains
prefixes of /16 and /29. It's quite irrelevant if some of the /29s are announced
as longer than /29 as you suggest: there will never be more than 8192 of them
(unless for some reason we get in a situation where 8191 TLAs and 8192 subTLAs
are not enough, but this is unlikely).

(BTW, in actuality there can only ever be 8190 TLA routes, since the TLA allocated
to 6to4 address space will never be in the default free table. But that's a detail).

As far as route filtering is concerned there is no difference between a /29
and a /35; they both aggregate exactly the same, because we have agreed that
there will never be holes in a /29. 

> The alternative is a huge routing table populated with /16 and /29 prefixes
> only, where no objective means for route filtering is available, and where
> bilateral routing agreements would emerge as the only way for an ISP to
> control its tables.

It wouldn't be huge at all; it should never exceed 16382 in fact. There certainly
will be bilats for longer prefixes, all the way out to /48. We can't do anything 
about that, but we can place a strict limit on the default free table.

   Brian