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.