195/8

[Daniel Karrenberg <]

  > Sean Doran smd@localhost 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