Hi, please allow me some comments as seen from a LIR member (de.jippii former de.ipf) and now from an external point of view (consulting company for isps and ripe members)
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 ;-).
My observations show that RIPE NCC is quite able to judge it more or less efficiently. "More or Less" are defined as follows: - they take care about PA Assignments very well - they sometimes put too many questions for PA Space for bigger companies (like Banks, Cable Companies etc.) --> a seperate PA Proposal should be worked out how to handle with big multinational companies like banks or other companies. ARIN has dealt with a similar issue (but there we looking at CABLE Blocks) quite well - they are enforcing that every multihomed customer should be lir member(kind of) --> they shall create a new registry type called "multihomed but not isp" on which guidelines shall be established. this could solve some problems: - more direct contact between that customer <-> ripe - more "adress space clueness" at the customer side as past experience has shown, the isps are not 100% efficient in doing this; sorry. - would channelize the needs/wishes/possibilities from ripe and the customer. - would also cover some of the costs for running that kind of lir for ripe and generating more awareness at the "corporate" level.
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.
Which is REALLY bad, as seen from operator perspective, increasing the bloat of the routing table.
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":
right.
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.
it SHOULD belong only to one as. Other things are bad ("inconsistent routes").
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.
so this problem should be solved and addressed either with help of the IETF / IEPG and the LIR.
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".
By also looking at the "old SWAMP" space we also should look more into this. we are not able (till now) to efficiently clean the swamp space. either RIPE (with the LIR) should find possible scenarios for this address space, either revoking it from the old users, forcing them to renumber to more clear address space. This would also help to eliminate MANY /24 or /23 out of the routing table. It CAN be done, but only policies need to be defined. If a user still would like to use it internally (for some purposes like products registered on ip addresses) then NAT can be used with help of the isp. But the swamp space needs to be cleaned up!
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.
ACKED. i'm happy to help with the creation of such document.
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."
Well, seeing the recent discussion on NANOG, there exists quite a lot of technology which does not need announced /24 for load balancing (like RAD products). Just my .2 euro-cents :-)) -- Jan-Ahrent Czmok http://www.lambda-solutions.de Technical Advisor ISP Hofdcker Str. 14, 65207 Wiesbaden Tel. +49-(0)-174-3074404