nanog mailing list archives
Re: Is multihoming hard? [was: DNS amplification]
From: Owen DeLong <owen () delong com>
Date: Sat, 23 Mar 2013 11:28:07 -0700
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.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?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. 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....
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
Current thread:
- Re: [c-nsp] DNS amplification, (continued)
- Re: [c-nsp] DNS amplification Owen DeLong (Mar 20)
- Is multihoming hard? [was: DNS amplification] Patrick W. Gilmore (Mar 20)
- Re: Is multihoming hard? [was: DNS amplification] Owen DeLong (Mar 20)
- Re: Is multihoming hard? [was: DNS amplification] ML (Mar 20)
- Re: Is multihoming hard? [was: DNS amplification] Seth Mattinen (Mar 20)
- Re: Is multihoming hard? [was: DNS amplification] Joe Abley (Mar 20)
- Re: Is multihoming hard? [was: DNS amplification] Jared Mauch (Mar 20)
- Re: Is multihoming hard? [was: DNS amplification] Masataka Ohta (Mar 20)
- Re: Is multihoming hard? [was: DNS amplification] Owen DeLong (Mar 20)
- Re: Is multihoming hard? [was: DNS amplification] Valdis . Kletnieks (Mar 22)
- Re: Is multihoming hard? [was: DNS amplification] Owen DeLong (Mar 23)
- Re: Is multihoming hard? [was: DNS amplification] Jimmy Hess (Mar 23)
- Re: Is multihoming hard? [was: DNS amplification] Owen DeLong (Mar 23)
- Re: Is multihoming hard? [was: DNS amplification] Kyle Creyts (Mar 23)
- Re: Is multihoming hard? [was: DNS amplification] Matt Palmer (Mar 23)
- Re: Is multihoming hard? [was: DNS amplification] joel jaeggli (Mar 24)
- Re: Is multihoming hard? [was: DNS amplification] William Herrin (Mar 24)
- Re: Is multihoming hard? [was: DNS amplification] John Curran (Mar 24)
- Re: Is multihoming hard? [was: DNS amplification] Leo Bicknell (Mar 25)
- Re: Is multihoming hard? [was: DNS amplification] Kyle Creyts (Mar 24)
- Re: Is multihoming hard? [was: DNS amplification] George Herbert (Mar 24)