Re: Multihoming and what we discussed in Atlanta

[Kurt Erik Lindqvist <kurtis@kurtis.pp.se>]

> It's more administrative overhead for address registries, but that's
> what they're there to do.  Having separate space for multihomers makes
> it possible for an ISP to avoid having to identify it's multihoming
> customers that are not addressed with it's allocation to it's peers.
I have been running engineering and peering policy for the largest 
transit provider in Europe, and this was never an issue to us...

> Assume a customer (1.) addresses with a /48 from ISP-A who's /32 is
> announced as /32 to his peers (2.) customer advertises this /48 to
> ISP-B (3.) ISP-B must advertise this /48 to his peers for multihoming
> to work for customer.  If customers intention was to solicit traffic
> over link from ISP-A, he can't since his /48 is more specifically
> routed over ISP-B.  This problem and other's caused by ISPs
> aggregating routes is what I refer to as inefficient routing.
I think you missed one of my points. Doing what you suggest above is 
what I suggest we do immediately to buy us time for a more permanent 
solution. My solution to your problem above is to give out PI space. 
But this could come from the addresses already allocated to the RIRs 
from IANA. We don't need a dedicated block for that.

> If customer had a PI /48 (from well-known limited PI blocks) which he
Why does it have to be from a well known block? What you describe above 
work just as fine with the current allocations.

> These blocks are easily identified with a prefix filter.  If these PI
> blocks are limited, say to 2^16 well-known /48s, DFZ growth due to
> multihoming can be controlled and registries won't have too much
But if I am filtering these blocks, they are not really multihomed?

- kurtis -