Randy Bush wrote:

...

In my (rather extensive) practice, multihoming by itself is usually a major source of connectivity problems.

in my meager and bottom-feeding scum-sucking practice, multi-homing decreased unreliability delivered to our customers by a factor of ten or more.

Right. If you know what you're doing and have resources to manage it. PSG/TLG/RainNet is what? Probably the largest regional in Northwest. Nobody argues about benefits of multihoming for providers like that (and you have enough customers to maintain significant level of aggregation, too). The problem is that basement operators are multi-homing, too.

this very moment i am sitting at a site which is single-homed to an anonymous NSP's major POP in a farming town in mid-Cal. i can not get to www.cisco.com from here. yet i can get to my home net, which is quite multi-homed, and get to cisco from there.

so, as we say in my family, i smell cows.

See advice below.

...

It is _much_ better to multihome to the same provider who then can take care of messy global routing.

just what i always wanted, two connections to a broken provider. you must be kidding.

Pick a provider which is not broken. None of them will help you agaist a clueless idiot injecting /24s covering your nameservers, though (don't feed me the RA -- as long as dominant routers can't do the massive filtering on their own it is close to useless). AUTH_CERTIFICATE attribute anyone? :) It may make sense to restrict multihoming to those who can aggregate their routes to, say, no less than /17s. --vadim PS There is a proof by existance that reliable operation w/o customer multihoming is possible. It is called POTS.