[161661] in North American Network Operators' Group
Re: Is multihoming hard? [was: DNS amplification]
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sat Mar 23 14:31:22 2013
From: Owen DeLong <owen@delong.com>
In-Reply-To: <20618.1363992268@turing-police.cc.vt.edu>
Date: Sat, 23 Mar 2013 11:28:07 -0700
To: <Valdis.Kletnieks@vt.edu>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Mar 22, 2013, at 15:44 , <Valdis.Kletnieks@vt.edu> wrote:
> On Wed, 20 Mar 2013 15:16:57 -0500, Owen DeLong said:
>> On Mar 20, 2013, at 9:55 AM, Seth Mattinen <sethm@rollernet.us> =
wrote:
>>> Based on the average clue of your average residential subscriber =
(anyone
>>> here need not apply) I'd say that's a good thing.
>=20
>> If BGP were plug-and-play automated with settings specified by the =
provider,
>> what would the user's clue level have to do with it?
>=20
> The hypothetical existence of such a box doesn't change the fact that
> providers have to make business decisions based on actual boxes and =
users.
>=20
> Yes, if a plug-n-play idiot-proof BGP box existed, then the profit =
calculus
> would be different. On the other hand, if there existed a reliable
> cost-effective means for faster-than-light signaling, if would =
drastically
> change intercontinental peering patterns. All the same, anybody who's =
planning
> their interconnects in 2013 reality and not looking at who has 40K km =
of
> underwater cable and who doesn't is in for a surprise....
>=20
There is a difference and you know it.
A reliable cost-effective means for FTL signaling is a hard problem =
without
a known solution.
An idiot-proof simple BGP configuration is a well known solution. =
Automating
it would be relatively simple if there were the will to do so.
However, the reality is that ISPs don't want the solution for a number =
of reasons:
1. ISPs are actually motivated to prevent customer mobility, not =
enable it.
2. ISPs are motivated to reduce, not increase the number of =
multi-homed
sites occupying slots in routing tables.
In addition, most of the consumers that could benefit from such a =
solution
do not have enough knowledge to know what they should be demanding
from their vendors, so they don't demand it.
This is a classic case of the "invisible hand" only works when all =
participants
have equal access to information and relatively equal knowledge. The =
problem
with technical products and especially with technical based services =
products
is that the vendor consistently has much greater knowledge than the
subscriber and is therefore in a position to optimize for the vendors =
best
interests even when they are counter to the best interests of their =
customers.
Owen
