Sean Doran <smd@chops.icp.net> writes:

Peter and I would naturally love to see no subnets of 195/8 at all, and see everyone using any of 195/8 and talking to networks outside Europe be required to provide transit to all of 195/8.

I fully agree that that is a very desirable goal. However, given the transmission tariff situation and the marketing practises of US ISPs in Europe it is probably not realistic right now.

Failing that, I want to see an absolute maximum of about 1000 prefixes in 195/8, period.

The RIPE NCC allocates address space. We have no control over how ISPs will set their routing policy and design their exterior routing. Would you like to consider for a moment the allocation data for 19[34]/8? prefix #allocs #allocs length 193/8 194/8 PA 12 1 0 PA 13 2 1 PA 14 6 1 PA 15 25 7 PA 16 55 60 PA 17 2 10 PA 18 4 25 PA 19 2 93 PI 16 50 52 ---- ---- Total 147 249 ==== ==== Notes: 1) The table only shows the prefixes currently allocated. 2) The RIPE NCC does allocate in such a way that future allocations can often be aggregated with present allocations. This means that a number of allocations will 'ripple upwards' in the table. It is important to note that we do not make any guarantees about that to our customers but still try to do the right thing. 3) Little can be said at present about the possibility of aggregation in PI space. 4) The allocation information is available in the RIPE database. However due to some procedural problems not all of it is up-to-date at present. We will have this corrected early next year. As you can see the total number of allocations is not that high. The provider aggregateable addresses could be routed in less than 200 routes for each block. Now consider the actual number of routes vs the address space covered for the 'C-Space' /16 block hosts routes hosts addres- / sed route 192.0.0.0 4733440 6471 731 193.0.0.0 8934656 2001 4465 194.0.0.0 6462208 1622 3984 195.0.0.0 1024 4 256 196.0.0.0 708864 356 1991 197.0.0.0 256 1 256 198.0.0.0 7400960 3668 2017 199.0.0.0 7735552 3270 2365 200.0.0.0 4625152 589 7852 201.0.0.0 256 1 256 202.0.0.0 3855680 1362 2830 203.0.0.0 5662720 690 8206 204.0.0.0 10388224 3517 2953 205.0.0.0 5851648 1775 3296 206.0.0.0 10236928 1573 6507 207.0.0.0 32768 3 10922 208.0.0.0 1024 4 256 C Space 76631360 26907 2848 You will note that Europe's performance is far better than that of anyone else if you consider the time of allocation. *Personal Soapbox The RIPE NCC allocation policy has resulted in significant aggregation well before anyone else's! I consider it quite arrogant of Sean Doran (and Peter) to tell us how we should set our policies. *End Personal Soapbox For next year we are planning to continuously compare allocations with observed routes in various ways. The goal of this is advise IRs and ISPs about possible improvements in allocation/assignment and routing. We consider this the appropriate strategy to improve route aggregation.

If you will guarantee that here and on paper, then as Dennis Ferguson and Geert-Jan de Groot have pointed out in various ways, there should be no trouble whatsoever with listening to /19s or even /24s in 195/8.

I can easily guarantee you on paper that we will make every effort not to make more than 1000 allocations from 195/8 and that we will supply you (as everyone else) with the data on valid allocation including whether they are PA or PI. Hint: This makes it easy to verify which /19s ot of 195/8 you need to accept.

If you can't do that and mean it and enforce it, then the only option I see is to impose a bitwise filter which sets a hard ceiling of the number of prefixes we will hear in 195/8.

It should be clear that the RIPE NCC cannot enforce routing policies of any ISP. In order to be totally clear I add that we also do not desire to ever do this because it is a "Bad Thing" (tm). However unless there is consensus that indiscriminate prefix length filters are a "Good Thing" (tm) and the majority of providers use them, we cannot waste of address space by raising our minimum allocation size.

Daniel> SprintLink will be well advised to take Daniel> this into account when defining their routing Daniel> policy.

We did.

Maybe someting went wrong in the definition process then because your policy will likely prevent connectivity to some parts of 195/8. Of course I assume that one of your goals is the largest possible connectivity. Maybe I am wrong, certainly I am curious.

Right now there is nothing allocated under 195/8 right now, and so anything you allocate under 195/8 which isn't aggregated into a 18-bit-or-shorter prefix simply will never work from day one. You should probably consider making this clear to everyone you allocate your /19s to, if you plan to keep allocating nonaggregatable /19s.

It will not work *with/over Sprintlink*. We already advise everyone that - we publish our allocation policy in the appropriate fora so that ISPs can take note of it - we have no control over the routing policies of service providers. I am sure that you can achieve the desired result by setting your filter in 195/8 to /19. Should the number of routes accepted by this filter grow beyond acceptable limits we will certainly work with you as with everyone else to improve the situation. If you intend to keep the filter at /18, I invite you to get out the word yourself. A good start would be to present it at the upcoming RIPE meeting in January. Curiously your's Daniel