On 10/8/07, Keegan.Holley@sungard.com <Keegan.Holley@sungard.com
> wrote:
That brings up an interesing point.
My biggest fear was that one of my other customers could possible
be closer to me that the ISP that provides the primary link and it would
cause them to favor the backup link because of AS path. I think they
are going to fight me on this and telling them to multihome to their original
ISP would probably be frowned upon at this point. I was hoping that
there was an RFC for multihoming that I could use to bail myself out.
What they're asking to do is really Just Fine. It may or may not
accomplish what they want, depending on how they do it, e.g. whether
traffic will go through their other ISP or yours. The main reason it's
a Not Best Practice is that it often doesn't get what the user wants,
e.g. the user only has a /29, so only the aggregate advertisement from
their primary ISP works anyway, or it's PA space so they'll still have
to give it up if they change ISPs. But if they've got a /24,
that's big enough that most carriers will see it these days, and
there's no need to clutter up the BGP ASN space if your user doesn't
need the extra flexibility.
There may even be a market for ISPs to do multihoming on a cabal basis,
e.g. Carrier X and Carrier Y get a /20 that they assign routes from to
customers that use both of them, but only advertise the aggregate to
the rest of the net. They'd still need to handle the more
specific routes internally and exchange them across their peering link,
but wouldn't have to bother the rest of the net with that level of
detail.