mailing list archives
Re: a radical proposal (Re: protocols that don't meet the need...)
From: "Edward B. DREGER" <eddy+public+spam () noc everquick net>
Date: Thu, 16 Feb 2006 18:32:59 +0000 (GMT)
JA> Date: Thu, 16 Feb 2006 12:44:27 -0500
JA> From: Joe Abley
JA> Personally, if I was going to multi-home, I would far prefer that my various
JA> transit providers don't cooperate at all, and have sets of peers and/or
JA> upstream transit providers that are as different as possible from each
JA> others'. The last thing I need are operational procedures which are shared
JA> between them.
The biggest sharing would be IP assignment. Let 'A' start at one end of
the pool, 'B' at the other, and they'll meet in the "middle". When one
hits the boundary, it can be moved.
"You're multihoming with 'A' and with us? Okay, fill in the box on your
router that says 'ASN' with '64511'."
JA> If all you want is last-mile redundancy, surely you can just attach twice to
JA> the same ISP and avoid all the routing complications completely?
JA> I get the feeling that there's a lot of solutions-designing going on in this
JA> thread without the benefit of prior problem-stating.
Consumers want to multihome. They may have a dynamic /32, or a /27 if
they're "big". They want to do this right here, right now, today, with
IPv4, using two separate upstreams.
claims ~1B internet users worldwide. Let's pretend that 1% of those
were to SOmultiHOme, and that no routes are coalesced. That's 10M new
I argue that the current combination of technology and administrative
policy cannot support that. Indeed, if it could, _why_ are providers
not accepting /32 announcements? If there's no technical reason not to,
and a financial reason to, why is it not done?
After all, hardware is cheap, upgrading is a fact of life, and allowing
SOHO users to multihome their /29 makes money! Why wait for IPv6 to use
/32 perfect match? Let's do it today, with IPv4!
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
DO NOT send mail to the following addresses:
davidc () brics com -*- jfconmaapaq () intc net -*- sam () everquick net
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: protocols that don't meet the need... Andrew Dul (Feb 14)