more specific routes in today reality

Hello.

 My apologies if mentioned below issues have already been discussed. If
 they were - pls just point me to the location where I can find more on
 that subject.

 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.
       2. Less specific routes within existing more specific.

 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":

   Generally, a prefix can should belong to only one AS. This is a
   direct consequence of the fact that at each point in the Internet
   there can be exactly one routing policy for traffic destined to each
   prefix. In the case of an prefix which is used in neighbor peering
   between two ASes, a conscious decision should be made as to which AS
   this prefix actually resides in.

   With the introduction of aggregation it should be noted that a prefix
   may be represented as residing in more than one AS, however, this is
   very much the exception rather than the rule.
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 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.

 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. In 1990th such announces would be 
 treated as typical "bad practice" but now they are more and more close to 
 "regular practice".  Just in fact there is still some network operators, 
 whose routing policy (in the part of BGP peers filtering) had been formed 
 by influence of rfc1930 and other aggregation issues, states something like 
 that: "if peer announces more specific routes within existent less specific 
 route, all more specific routes will be rejected unless peer explicity asks
 to accept it".
 
 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? 

 On my opinnion it would be also good to:

	1. Create new RIPE document which would describe usage of more specific
	   routes with multiple origins for multihoming, including all pros and
	   cons of such technique.
	2. Extend ripe-127 successor with references to new document mentioned 
	   above or (why not?) integrate both of them in one document.
	3. Extend ripe-211 successor with something like that:

"Due to tendency of increasing number of small blocks (smaller than the default
allocation size) of PI or PA (more specific multihoming, load balancing, etc) 
addresses network operators taking routing decisions based on prefix length are
recommended to accept and route longer (up to /24) prefixes with valid route 
objects."

-- 
Regards,
Vladimir.