[161575] in North American Network Operators' Group
Re: Is multihoming hard? [was: DNS amplification]
daemon@ATHENA.MIT.EDU (Owen DeLong)
Wed Mar 20 09:27:20 2013
From: Owen DeLong <owen@delong.com>
In-Reply-To: <187DE460-85DA-4462-8946-717C7FEDE87C@ianai.net>
Date: Wed, 20 Mar 2013 08:25:11 -0500
To: "Patrick W. Gilmore" <patrick@ianai.net>
Cc: North American Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> I don't know a single ISP that wants to throttle growth by not =
accepting additional customers, BGP speaking or not. (I do know several =
that want to throttle growth through not upgrading their links because =
they have a captive audience they are trying to ransom. But that is =
neither relevant to this discussion, not controversial - unless you are =
paid by one of those ISPs=85.)
Comcast
Verizon
AT&T
Time Warner Cable
Cox
CenturyLink
to name a few.
Not one of them will run BGP with a residential subscriber.
> And please don't reply with "then why can't I run BGP on my =
[cable|DSL|etc.] link?" Broadband providers are not trying to throttle =
growth by not allowing grandma to do BGP, and swapping to LISP or =
anything else won't change that.
Sure they are. If they weren't, it would be relatively straight forward =
to add the necessary options to DHCP for a minimal (accept default, =
advertise local) BGP configuration and it would be quite simple for CPE =
router manufacturers to incorporate those capabilities.
The problem is BGP doesn't scale to that level and everyone knows it, =
so, we limit growth by not allowing it to be a possibility.
You are right, however, LISP won't change that.
>> LISP is about seperating the role of the ISP (as routing provider) =
from the
>> end user or content provider/consumer.
>=20
> I am unconvinced that is a good idea. At least using the definition of =
"end use" or "consumer" I frequently hear.=20
+1
However, a locator/id separation without map/encap is a desirable thing =
that could allow the routing system to scale better. Unfortunately, we =
failed to address this issue when designing IPv6. It will not get =
correctly solved without a revision to the header design. There is no =
will to change the packet header in the near future. We're having too =
much "fun" rolling out the current one.
Owen
