Re: Why are there no GeoDNS solutions anywhere in sight?

On 20 March 2013 20:43, Andrew Sullivan wrote: > On Wed, Mar 20, 2013 at 08:28:23PM -0700, Constantine A. Murenin wrote: >> Any plans to make DNS itself GeoDNS-friendly? > > No. And I say this as someone working for a vendor that provides that > service. > > Any sort of "Geo" DNS is what protocol

Re: Is multihoming hard? [was: DNS amplification]

On Mar 20, 2013, at 8:11 PM, John Curran wrote: > On Mar 20, 2013, at 2:25 PM, Owen DeLong wrote: >> >> 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 at

Re: Why are there no GeoDNS solutions anywhere in sight?

Constantine A. Murenin wrote: > Why even stop there: all modern browsers usually know the exact > location of the user, often with street-level accuracy. If you think mobile, they don't, especially because "often" is not at all "enough times". > Why is there no way to do any of this? Because i

Re: Why are there no GeoDNS solutions anywhere in sight?

You can set up GeoDNS without anycast with PowerDNS and Bind easily enough (I found PowerDNS easier to setup). If you are using Bind you can use the geoip patch or use views which is a quick hacky way. http://doc.powerdns.com/html/geo.html I can't comment on either solution if it supports getting

Re: Why are there no GeoDNS solutions anywhere in sight?

On 3/20/13 8:28 PM, Constantine A. Murenin wrote: > > Why even stop there: all modern browsers usually know the exact > location of the user, often with street-level accuracy. It should be > possible to say that you have a server in Fremont, CA and Toronto, ON > or Beauharnois, QC, and automatic

Re: Why are there no GeoDNS solutions anywhere in sight?

Constantine A. Murenin wrote: > Why so many years after the concept has been introduced and has been > found useful, can one not setup GeoDNS in under 5 minutes on one's own > infrastructure, or use GeoDNS from any of the plentiful free or > complementary DNS solutions that are offered by provider

RE: Why are there no GeoDNS solutions anywhere in sight?

The first hit on Google for "dns geolocation" results in http://backreference.org/2010/02/01/geolocation-aware-dns-with-bind/, or the first hit for "dns geolocation patch" leads you to http://www.caraytech.com/geodns/ -Original Message- From: Constantine A. Murenin [mailto:muren...@gma

Re: Why are there no GeoDNS solutions anywhere in sight?

On Wed, Mar 20, 2013 at 08:28:23PM -0700, Constantine A. Murenin wrote: > Any plans to make DNS itself GeoDNS-friendly? No. And I say this as someone working for a vendor that provides that service. Any sort of "Geo" DNS is what protocol people would call a "stupid DNS trick". It works in par

Why are there no GeoDNS solutions anywhere in sight?

Dear NANOG@, Not every operator has the ability to setup their own anycast. Not every operator is big enough to be paying 25 USD/month for a managed GeoDNS solution, just to get their hands on GeoDNS. (Hey, for 25$/mo, I might as well have an extra POP or two!) Why so many years after the conce

Re: routing table go boom

William Herrin wrote: >>> Some local system is responsible for detecting connectivity between >>> the ETR and destination and updating the destination-to-ETR map >>> accordingly. >> >> Some local system? > > Yeah, you know, like OSPF or EIGRP. Just like exporting a route from > the IGP to the EGP

Re: routing table go boom

Sander Steffann wrote: >> As the ETR is not the final destination, it is subject to blackholing >> after ETR, which means: >> >>The function in question can completely and correctly be >>implemented only with the knowledge and help of the >>application standing at the endpoints of the

Re: Is multihoming hard? [was: DNS amplification]

Joe Abley wrote: > In practice, it seems to me that the way people multi-home > these days for client-filled networks is: > > 1. Number everything internally using private-use addresses > 2. Use one NAT per upstream > 3. Send your outbound flows through whichever NAT seems appropriate Very reaso

Re: Is multihoming hard? [was: DNS amplification]

On Mar 20, 2013, at 2:25 PM, Owen DeLong wrote: > > 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

Re: Is multihoming hard? [was: DNS amplification]

On Mar 20, 2013, at 16:20 , Owen DeLong wrote: > On Mar 20, 2013, at 10:18 AM, "Patrick W. Gilmore" wrote: >> On Mar 20, 2013, at 09:25 , Owen DeLong wrote: >>> Not one of them will run BGP with a residential subscriber. >> >> Who cares? [See below.] >> > Not one of them will run BGP with a

Re: routing table go boom (was: Re: [c-nsp] DNS amplification)

On Mar 19, 2013, at 4:48 PM, David Conrad wrote: > Patrick, > > On Mar 19, 2013, at 12:07 PM, Patrick W. Gilmore wrote: >> Which is all just a fancy way of saying you can't fix people being idiots by >> changing a protocol, or hardware, or ... well, anything. > > One of the advantages I see

Re: Is multihoming hard? [was: DNS amplification]

On Wed, Mar 20, 2013 at 9:25 AM, Owen DeLong wrote: > 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

Re: Is multihoming hard? [was: DNS amplification]

In message <59415dcc-2d4e-4dd9-87c9-0b56bf24f...@ianai.net>, "Patrick W. Gilmor e" writes: > On Mar 20, 2013, at 09:25 , Owen DeLong wrote: > > >> 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 w

Re: [c-nsp] DNS amplification

Sent from my iPad On Mar 20, 2013, at 10:26 AM, David Conrad wrote: > Arturo, > > On Mar 20, 2013, at 5:32 AM, Arturo Servin 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'

Re: Is multihoming hard? [was: DNS amplification]

Sent from my iPad On Mar 20, 2013, at 10:25 AM, John Curran wrote: > On Mar 20, 2013, at 7:25 AM, Owen DeLong wrote: > >>> 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 grand

Re: Is multihoming hard? [was: DNS amplification]

Sent from my iPad On Mar 20, 2013, at 10:18 AM, "Patrick W. Gilmore" wrote: > On Mar 20, 2013, at 09:25 , Owen DeLong wrote: > >>> 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 >>> thr

Re: Is multihoming hard? [was: DNS amplification]

Sent from my iPad On Mar 20, 2013, at 9:55 AM, Seth Mattinen wrote: > On 3/20/13 6:25 AM, Owen DeLong wrote: >>> 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

Re: Is multihoming hard? [was: DNS amplification]

On Mar 20, 2013, at 11:39 AM, Joe Abley wrote: > I think it's incorrect to insist that the Network doesn't support pervasive > end-site multi-homing when it's clear that people are doing it anyway. I know some small WISPs that balance multiple business DSL links using some of these things. T

Re: Is multihoming hard? [was: DNS amplification]

On 3/20/2013 12:36 PM, Brielle Bruns wrote: > On 3/20/13 6:40 AM, Patrick W. Gilmore wrote: >> 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 >> lin

NYC sales contacts for AS209 and AS2914

The contacts I have seem to all bounce. If anyone from NTT or CenturyLink is lurking who can quote on wholesale IPT out of 60 Hudson, please ping me. Thanks.

Re: [c-nsp] DNS amplification

On 3/20/13 12:26 PM, David Conrad wrote: > Arturo, > > On Mar 20, 2013, at 5:32 AM, Arturo Servin 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

Re: routing table go boom

On Wed, Mar 20, 2013 at 11:42 AM, Masataka Ohta wrote: > William Herrin wrote: >> I can't speak for LISP per se, but the general solution for map-encap >> systems like LISP is that the ITR tags the first packet to the ETR and >> some percentage of subsequent packets to the ETR with an ack request.

Re: routing table go boom

On 3/20/13 11:30 AM, Mike wrote: > > > I appreciate everyones comments on this issue but I think you > nay-sayers are going to lose. I think the future of the internet is > distributed routing where the end points ultimately decide how their > packets flow. I think joe 6-pack should in fact

Re: routing table go boom

On Mar 20, 2013, at 1:43 PM, Matthew Walster wrote: > On 20 March 2013 17:30, Mike wrote: >> >>I appreciate everyones comments on this issue but I think you >> nay-sayers are going to lose. I think the future of the internet is >> distributed routing where the end points ultimately dec

Re: routing table go boom

On Mar 20, 2013, at 1:30 PM, Mike wrote: > > > I appreciate everyones comments on this issue but I think you > nay-sayers are going to lose. I think the future of the internet is > distributed routing where the end points ultimately decide how their > packets flow. I think joe 6-pack sho

Re: routing table go boom

On 20 March 2013 17:30, Mike wrote: > > I appreciate everyones comments on this issue but I think you > nay-sayers are going to lose. I think the future of the internet is > distributed routing where the end points ultimately decide how their > packets flow. > You have actually *heard* of

Re: routing table go boom

I appreciate everyones comments on this issue but I think you nay-sayers are going to lose. I think the future of the internet is distributed routing where the end points ultimately decide how their packets flow. I think joe 6-pack should in fact be able to be connected to as many provide

Re: Is multihoming hard? [was: DNS amplification]

On 3/20/13 6:40 AM, Patrick W. Gilmore wrote: 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

Re: routing table go boom

Hi, > As the ETR is not the final destination, it is subject to blackholing > after ETR, which means: > > The function in question can completely and correctly be > implemented only with the knowledge and help of the > application standing at the endpoints of the communication > system. >

Re: routing table go boom

William Herrin wrote: > I can't speak for LISP per se, but the general solution for map-encap > systems like LISP is that the ITR tags the first packet to the ETR and > some percentage of subsequent packets to the ETR with an ack request. > If it doesn't get an ack from the ETR (not the final dest

Re: Is multihoming hard? [was: DNS amplification]

On 2013-03-20, at 10:55, Seth Mattinen wrote: > On 3/20/13 6:25 AM, Owen DeLong wrote: >>> 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 lin

Re: [c-nsp] DNS amplification

Randy, On Mar 19, 2013, at 10:53 PM, Randy Bush wrote: > i am not saying bgp and forwarding can deal with growth forever, As I said when I started tilting at this particular windmill, with enough thrust pigs can fly quite well. However, perhaps instead of attaching bigger/hotter/more expensiv

Re: [c-nsp] DNS amplification

Arturo, On Mar 20, 2013, at 5:32 AM, Arturo Servin 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 ro

Re: Is multihoming hard? [was: DNS amplification]

On Mar 20, 2013, at 7:25 AM, Owen DeLong wrote: >> 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. > > Sur

Re: Is multihoming hard? [was: DNS amplification]

On Mar 20, 2013, at 09:25 , Owen DeLong wrote: >> 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

Re: Is multihoming hard? [was: DNS amplification]

On 3/20/13 6:25 AM, Owen DeLong wrote: >> 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 t

Re: Is multihoming hard? [was: DNS amplification]

On 3/20/2013 9:25 AM, Owen DeLong wrote: 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

Re: Is multihoming hard? [was: DNS amplification]

> 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 releva

Is multihoming hard? [was: DNS amplification]

Composed on a virtual keyboard, please forgive typos. On Mar 20, 2013, at 8:07, Aled Morris wrote: > On 20 March 2013 11:44, Arturo Servin wrote: > >>The last presentations that I saw about it said that we are going >> to be >> fine: >> >> http://www.iepg.org/2011-11-ietf82/2011-11-13

Re: [c-nsp] DNS amplification

On 20/03/2013 09:07, Aled Morris wrote: > On 20 March 2013 11:44, Arturo Servin > wrote: > > > The last presentations that I saw about it said that we are > going to be > fine: > > http://www.iepg.org/2011-11-ietf82/2011-11-13-bgp2011.pd

Re: [c-nsp] DNS amplification

On 20 March 2013 11:44, Arturo Servin wrote: > > The last presentations that I saw about it said that we are going > to be > fine: > > http://www.iepg.org/2011-11-ietf82/2011-11-13-bgp2011.pdf > http://www.iepg.org/2011-11-ietf82/iepg-20.pdf > > > It isn't just about "imminient death

Re: routing table go boom

Hi, On 20 Mar. 2013, at 06:40 , Masataka Ohta wrote: [snip] > > Then, how can an ITR, which initially choose a blackholed > locator, know that the locator is not working and fall > back to another locator? In LISP you can check reachability with the echo-nonce function. [snip] > > PS > >

Re: routing table go boom

On 20 Mar. 2013, at 01:05 , Masataka Ohta wrote: > Dobbins, Roland wrote: > >> It is always amusing to see people allude to the end-to-end >> principle to support their arguments, when in fact the >> end-to-end principle is either inapplicable to the topic >> at hand, or actually lends support

Re: [c-nsp] DNS amplification

The last presentations that I saw about it said that we are going to be fine: http://www.iepg.org/2011-11-ietf82/2011-11-13-bgp2011.pdf http://www.iepg.org/2011-11-ietf82/iepg-20.pdf Regards, as On 20/03/2013 02:53, Randy Bush wrote: > i am not saying bgp and forwarding can deal wi

Re: routing table go boom

Hi Masataka, On 20 Mar. 2013, at 00:23 , Masataka Ohta wrote: > David Conrad wrote: > >> One of the advantages I see in LISP(-like) solutions is that it >> allows multi-homing without having to do BGP... > > By having a lot larger table than BGP. > > http://datatracker.ietf.org/doc/draft-iet

RE: [c-nsp] DNS amplification

>Indeed, in many cases, why aren't these things an external, separately rack mountable box with simply an interconnect to speak to the control plane? You mean like CRS multi-chassis systems? adam