multi-homing fixed

arman khalili arman at unitedlayer.com
Tue Aug 28 16:22:51 UTC 2001


Well it looks like we have come full circle.

www is born.
ISP numbers increase like rabbits in australia (I even start one)
a lot of $$ is invested in XLEC
Market tanks
XLEC, ISPs, .. file chapter 11
at the end of the day you can even get a dissent Internet connection from a
single provider.

This could be the right theme for the next Nanog T-shirt.

ak


"Howard C. Berkowitz" wrote:

> Having just had my DSL go down yet AGAIN (a more or less daily
> occurrence), I'm inclined to chip in under my telecommuter hat.  Yes,
> I know the best way is to convince my boss to pay for frac T1/frame
> access with dial backup. Working on that.
>
> In the meantime, I have DSL from CAIS, with Covad as the CLEC. Covad
> is in Chapter 11. I've also ordered @home cable to come in for next
> week, and I'm trying to scrounge a multiple-Ethernet router to set up
> alternate connectivity. (Note that I work for a router vendor, so I
> can't go and do something as simple as mail-order a router). @home
> doesn't seem to be in much better financial shape.
>
> At 4:28 PM +0100 8/28/01, Alex Bligh wrote:
> >>The real problem with most basement multi-homers is they go with the
> >>cheapest local service they can get, often from someone clueless with one
> >>POP / one path.  To fix this, they add another cheap, local, clueless
> >>service and pray they don't get clueless at the same time.  Then they
> >>inflict bad judgement on the rest of the Internet by demanding their
> >>routes be distributed.  Bad plan.
> >
> >I do not think anyone (Randy included) is questioning the right of
> >basement-dwellers to multihome (by my previous definition). I think
> >what is being questioned by many and various is
> >(a) their right to do it at other people's expense, without
> >    reimbursement
> >(b) whether the (non-reimbursed) cost to the community is
> >    greater than the (non-paid for) gain to the community.
> >(c) whether there are other technologies which cost less
> >    in total, and/or attribute cost more directly to those
> >    who benefit from it.
> >(d) whether in an effort to achieve multihoming, they are
> >    selecting the technology which costs them the least, or
> >    costs the community the least.
>
> What I'd like to see, as a short-term fix, is to have two local
> providers each agree to have a multihomed block within their
> allocations, and both to propagate this block to the DFZ and each
> other. Microallocations would come out of it; the microallocations
> would not be advertised between the two carriers. Certainly, there
> would be failure modes in which the microallocation might go down for
> one provider, but I'd be in better shape. I'd ideally pick local
> carriers with different kinds of physical connectivity.
>
> While I'm perfectly capable of running BGP with both carriers, I
> recognize that skill would be rare in the basement market, and I
> can't reasonably expect it.  But I am getting truly sick of dial
> backup on a per-host basis.
>
> *thank you -- this may have been more venting steam than anything else **
>
> >
> >Whilst there is no current mechanism to reliably achieve
> >(a) (beyond Roeland kindly offering to pay for Sean's
> >routers), direct market forces fail, so, like with so many
> >other problems, the internet community has come up with
> >hueristic mechanisms to enforce (b) i.e. 'your reachability
> >information is only worth the cost of my carrying it
> >if it contains announcements shorter than a /nn, and I
> >will rely on RIR's to demonstrate that there is a fair
> >correlation between assigment size (and thus prefix
> >length) and usefulness of the prefix to me.
> >
> >If all this sounds a bit "matter of opinion", type stuff,
> >which will never get resolved, well, yes it is, and thus
> >just the right sort of stuff for a flamewar on NANOG.
> >
> >Great, just so long as elsewhere, people are thinking about
> >(c). And then we can have the adoption flamewar (d) on NANOG
> >afterwards.
> >
> >--
> >Alex Bligh
> >Personal Capacity




More information about the NANOG mailing list