[address-policy-wg] Source of routing table growth

Hi,


> Hi Sascha,
> 
>>> The real solution is to have end systems handle session handover between multiple addresses it has, but there seems to be pitifully little traction for that.
>> 
>> I think we've been there (sounds a bit like SHIM to me), we'll see if that takes on. But i don't think such workarounds can replace 
>> BGP multihoming in all cases. But it can help to spare some people the hassle to deal with full BGP multihoming if don't really need to be in the DFZ, but just want some level of redundancy indeed.
> 
> Getting a good solution for this is _very_ important to limit routing table growth. Many people/organizations probably don't want the hassle of BGP if they can get more redundancy and less dependencies on a single ISP (easier renumbering will help too) in a simpler way. But this is IETF territory, not RIPE :-)
> 

indeed!
I am not scientist, i have no clue about how this problem can be solved, and since no one came up with anything better than SHIM 
the last decade, i guess BGP multihoming just cannot be replaced.

Though, i've always explained to my clients that there are more easy and possibly cheaper options in most cases, and everyone else should inform their
clients about alternatives, too.
I have a poor opinion of those PI-shop-ISPs out there, they are doing something seriously wrong. But probably that's only a money issue which might be hopefully fixed with a new charging scheme (but forgive me if i am not convinced yet, dear NCC :-) ).

But in the end, if the End-user WANTS and NEEDS independent resources, and can not live with anything else, i strongly disagree with deliberately
preventing them from getting a slot in the routing table, or charging insane amounts of money for that. That's not the "internet spirit" i grew up with.

==> Work with your customers, most are easily convinced that bad BGP management can break more and cost more than more simple alternatives. 
    Best we all can do.

-- 
Mit freundlichen Grüßen / Kind Regards

Sascha Lenz [SLZ-RIPE]
Senior System- & Network Architect