Verio Peering Question

Iljitsch van Beijnum iljitsch at muada.com
Tue Oct 2 21:48:13 UTC 2001


On Fri, 28 Sep 2001, Sean M. Doran wrote:

> let me say that not only
> am I a strong supporter of filtering, I have also suggested
> fairly seriously to some registry-types that it is fair to allocate
> individual /32s as necessary to contain address consumption.

So how is this supposed to work? For instance, I get a /27 and an AS
number, and I want to multihome. But nobody will listen to my
announcements. This is not a workable solution.

It is possible to take the position that the responsibility of the ISPs to
filter and the responsibility of the RIRs to assign are completely
unrelated, but that only holds in theory. In practice, people want to get
addresses they can use and use the addresses they can get. So there should
be a reasonable overlap.

Multihomers generally announce just a single route and there are less than
25k AS numbers so the majority of routes is NOT from multihomers so it
seems somewhat harsh to effectively forbid multihoming.

But while we're all discussing drafts on multi6, the routing table is
still growing so some filtering should be expected. Is there really no way
we can all agree on a filtering policy that keeps the routing table in
check but still leaves some room for responsible multihoming?

For instance: each AS gets to announce either a single route (regardless
of prefix size) or only RIR-allocation-sized blocks.

(The problem with this is that you can't make a reasonably sized filter
that enforces this policy, so you would have to trust your peers to some
degree.)

> That is, the registries are correctly focusing on that resource-management,
> and should spend energies on reclaiming wasted space (hello MIT!)
> rather than on managing multiple scarce resources.

IP address space is only a scarce resource because it is allocated in huge
chunks. If we would be able to re-allocate individual un-used IP
addresses, we wouldn't run out for a _very_ long time.

Iljitsch van Beijnum




More information about the NANOG mailing list