RE: Multihoming and what we discussed in Atlanta

["Aldrin Isaac" <aisaac@bloomberg.com>]

% From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se]
% Sent: Tuesday, December 03, 2002 11:58 PM
% Subject: Re: Multihoming and what we discussed in Atlanta
%
%
% > IMHO, for this form of multihoming, multihomers should *not* use
% > prefixes that that are part of the allocation of any of the ISPs
over
% > which it multihomes.  A multihomers address should come from
% > well-known managed PI blocks.  Using part of an ISPs allocation
% > results in inefficient routing, unneccessary fragmentation of ISP
% > address blocks, and more complex policies for ISP peering.
%
% What do we gain with having a dedicated PI block? Except
% administrative overhead. In what way will routing be more
% efficient just because the addresses are from a dedicated block?

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.

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.

If customer had a PI /48 (from well-known limited PI blocks) which he
advertised to both ISP-A and ISP-B, routing will be more efficient
since ISPs know not to aggregate these blocks and therefore there is
end-to-end transparency for customer's /48 route over the Internet.
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
administrative work.

-- aldrin