[161599] in North American Network Operators' Group
Re: [c-nsp] DNS amplification
daemon@ATHENA.MIT.EDU (Owen DeLong)
Wed Mar 20 16:31:14 2013
In-Reply-To: <5549A641-4F3B-4E9E-9D90-F127E313A5B4@virtualized.org>
From: Owen DeLong <owen@delong.com>
Date: Wed, 20 Mar 2013 15:28:23 -0500
To: David Conrad <drc@virtualized.org>
Cc: "nanog@nanog.org" <nanog@nanog.org>,
Arturo Servin <arturo.servin@gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Sent from my iPad
On Mar 20, 2013, at 10:26 AM, David Conrad <drc@virtualized.org> wrote:
> Arturo,
>=20
> On Mar 20, 2013, at 5:32 AM, Arturo Servin <arturo.servin@gmail.com> wrote=
:
>>> For example I know there are enterprises that would like to multihome
>>> but they find the current mechanism a barrier to this - for a start they=
>>> can't justify the size of PI space that would guarantee them entry to
>>> the global routing table.
>>=20
>> Which is good. If they cannot justify PI space may be they should not
>> get into the global routing table.
>=20
Any organization can easily justify a /48 if they can show two LOIs or contr=
acts for peering or transit from independent ASNs.
> The implication of this statement is that if you cannot afford the RIR fee=
s, the routers, the technical expertise to run those routers, the additional=
opex associated with "BGP-capable" Internet connectivity, etc., the service=
s/content you provide don't deserve resiliency/redundancy/etc.
>=20
> I have trouble seeing how this can be called "good". A "necessary evil gi=
ven broken technology" perhaps, but not "good".
+1
>>> LISP is about seperating the role of the ISP (as routing provider) from
>>> the end user or content provider/consumer.
>>=20
>> Yes, but as mentioned before the cost is in the edge, the benefit in
>> the core.
>=20
> Being able to effectively multi-home without BGP, removing the need to eve=
r renumber, etc., all sound like benefits to the edge to me.
What part of "without BGP" benefits the edge? Multihoming with BGP is much s=
impler at the edge than implementing LISP.
Owen
