more specific routes in today reality

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