[161615] in North American Network Operators' Group
Re: Is multihoming hard? [was: DNS amplification]
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Mar 21 00:47:14 2013
From: Owen DeLong <owen@delong.com>
In-Reply-To: <3612B8CA-A571-4B79-8A1C-C150CA8416B6@istaff.org>
Date: Wed, 20 Mar 2013 23:44:32 -0500
To: John Curran <jcurran@istaff.org>
Cc: North American Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Mar 20, 2013, at 8:11 PM, John Curran <jcurran@istaff.org> wrote:
> On Mar 20, 2013, at 2:25 PM, Owen DeLong <owen@delong.com> wrote:
>>=20
>> I don't want the residential customers themselves running BGP at all. =
However, if there were motivation on the provider side, automated BGP =
configuration could enable consumers to attach to multiple providers and =
actually reduce support calls significantly.
>=20
> Okay, I'll agree, but "if there were motivation" is a very large =
"if"...
>=20
> The only motivation would be money, as represented by customers =
leaving=20
> to competitors as a result of a service provider not offering your =
proposed=20
> service bundle. =20
>=20
> If you can figure out a way to persuade service providers of this =
belief,
> I would ask that you also persuade them that they have to offer =
dual-stack=20
> for all of their customers (which may have already resulted in them =
losing=20
> a small number of customers who expected IPv6 by now... :-)
You, of all people, John, are very aware of my efforts on this basis.
I agree it's a very large if. In fact, the very real probability that =
dissatisfied customers will
use their ability to multi home and run BGP as a reduction of the pain =
point of changing
subscribers is probably the largest reason that it is not available. The =
providers have
exact opposite motivation. This is a fine example of how the efficiency =
of the invisible
hand fails when it comes to technical products where the masses fail to =
actually
realize that they are being shafted and artificially constrained by the =
limitations placed
on them by their vendors.
However, that's getting a bit far afield for NANOG, so I tried to stick =
to the technical
aspects of the argument.
Owen
