more specific routes in today reality

On Tue, Oct 09, 2001 at 12:15:57PM +0200, Gert Doering wrote:
>Hi,
>
>On Tue, Oct 09, 2001 at 01:10:49PM +0300, Vladimir A. Jakovenko wrote:
>>  According to my observations at least since this summer the RIPE NCC staff 
>>  promotes usage of more specific PA routes (originated by more than one AS) 
>>  for multihomed customers opposite to the "classic" scheme with PI addresses
>>  (or new enterpise LIR ;-). 
>> 
>>  In this situation we are going to expect increase of ammount of:
>> 
>>        1. Routes with more than one origin.
>
>No - the more specifics are announced by the customer AS *only* (and the
>upstream AS that this blocks belongs to will permit them "through").

We are talking about different types of multihoming. I mean simple multihoming 
situation when all multihomed customer's needs in routing are covered by they
upstream providers routing policies. In this situation more specific PA route 
can be originated by upstreams without allocation to customer new AS-num.
Moreover, according to ripe-185:

   In order to help decrease global routing complexity, a new AS Number
   should be created only if a new routing policy is required.

>>        2. Less specific routes within existing more specific.
>
>Yes.
>
>>  Actual (ripe-185) document of "IPv4 and ASN Policies in the RIPE NCC Service 
>>  Region" and working draft (on http://www.ripe.net/rs/ipv4policy.html) 
>>  refer to rfc1930 which contains section 7 -  "One prefix, one origin AS":
>
>Yes, but this is a non-issue here.

Why?

>[..]
>>  According to measurements on RIPE DB dump on Oct 4 there were about 17% of
>>  prefixes with more than on origin AS. It isn't just RIPE specific - 
>>  measurements from other IRRs are close.
>
>This is well possible, but not a necessity for this type of multihoming -
>to the contrary, in most cases it's a mistake or a transitional thing.

I do not believe that the most of them are errors. Yes, not all of them was
created for multihoming purposes (don't forget about incoming-channel load
balancing :), but amount of multihoming part (on my opinnion) are increasing.

>>  Announcement of less specific routes within existent more specific route 
>>  (lets assume that there is no bgp routing process misconfiguration - both, 
>>  less and more specific, routes have route objects) clashes with an aggregation 
>>  issues promoted in many RIPE documents. 
>
>Yes, but looking at the overall table, it's beneficial.
>
> - you have the same amount of routes as with "small PI", so it's not worse

Agree.

> - if one is filtering "no /24's", the end site is *still* be reachable,
>   which would not work with PI space.

Disagree. During last time a number of routing curioses at least in our country
have been caused by incorect announcements or filtering more specific routes 
within already announced less specific routes. If you want, I can describe some
of the most common problems. PI addresses have its own set of problems, more 
specific PA addresses also have own set problems. This sets partly overlaps,
but not same. And PA more specific isn't safer than PI. They just unsafe a bit
more different.

>[..]
>>  Unfortunately it is difficult to dispute such policy unactuality without
>>  appropriate documents. Is it possible at least "to legalize" applicability 
>>  of more specific routes with more than one origin for multihoming purposes 
>>  in ripe-185 successor? 
>
>RIPE has no power about *routing*.  But there has been talk on the last
>meeting about writing a BCP concerning routing issues and recommendations
>(I have no idea what the state of this is or whether anybody is working
>on it).

RIPE has the power to make recomendations and publish documents. RIPE NCC has 
the power in ip address space allocation. Good practice for people who make 
decisions in this region is to take into consideration RIPE recomendations. 
If RIPE NCC are going to propose usage of more specific routes for multihoming 
why not to cover that technique with all pros and cons in appropriate documents?

-- 
Regards,
Vladimir.