[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multihoming and what we discussed in Atlanta
I have been running engineering and peering policy for the largest
transit provider in Europe, and this was never an issue to us...
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 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.
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.
Why does it have to be from a well known block? What you describe above
work just as fine with the current allocations.
If customer had a PI /48 (from well-known limited PI blocks) which he
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 -