Subject: RE: Multihoming and what we discussed in Atlanta

From: "Aldrin Isaac" <[email-masked]>
Date: Mon, 2 Dec 2002 10:33:15 -0500

% draft-kurtis-multihoming-longprefix-00
% 6.1 Aggregation effects with the current allocation policies
%   ....
%   improved.  With the proposal for multihoming IPv6 as described in
%   this document, the potential for the same routing table growth
%   explosion as we have today exists.  However, given that the
current
%   allocation blocks to ISPs are blocks with 32 bit long prefixes,
one
%   of these blocks will fit the current address assignments of most
%   ISPs.  This means that the routing table will be inherently small
to
%   start with.  Even if all ASes that are active today where to
announce
%   IPv6 address space, it would only be around 14 000 routes.  Almost
%   90% less of the current routing table.  This means that we have
quite
%   a lot of breathing space before we starting running into the same
%   scalability problems as today.  This is due to the current
%   allocations.  Doing multihoming by announcing longer prefixes out
of
%   allocated blocks will make the routing larger but looking at the
%   current amount of multihomed networks, this should not pose a
%   problem.

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.

-- aldrin

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 4 Dec 2002 05:58:21 +0100

> 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?

Why would the the ISP peering policy become more complex? On a side 
note, I have handled peering issues on one of the Tier-1 transit free 
providers, this would not have been an issue for us.

- kurtis -

---

From: "Aldrin Isaac" <[email-masked]>
Date: Wed, 4 Dec 2002 18:56:51 -0500

% From: Kurt Erik Lindqvist [mailto:[email-masked]]
% 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

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 13 Dec 2002 10:25:53 +0100

> 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...

> 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.

> multihoming can be controlled and registries won't have too much

But if I am filtering these blocks, they are not really multihomed?

- kurtis -

---

From: "Aldrin Isaac" <[email-masked]>
Date: Fri, 13 Dec 2002 17:25:16 -0500

Kurt,

% From: Kurt Erik Lindqvist
%
% > 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.

Why do we have well-known blocks for RFC1918, RFC3056, RFC2471, etc.
Why couldn't they have come from arbitrary RIR blocks?  How will an
ISP who does not have an arrangement with you know not to aggregate
multihoming customers allocated from your block?

% > 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?

What I said was "identified with a prefix filter".  I didn't specify
what action should be taken after the identification.  The action I
imply is that ISPs MUST NOT AGGREGATE /48s from this well-known block.
By keeping the block small DFZ growth by multi-homing can be
controlled.

regards -- aldrin