[nsp] Methods for Non-BGP multihoming

Joe Provo joe.provo@rcn.com
Fri, 26 Jul 2002 14:12:36 -0400


On Fri, Jul 26, 2002 at 06:33:23PM +0100, Ryan O'Connell wrote:
> On Fri, 26 Jul 2002 10:43:16 -0400 Joe Provo <joe.provo@rcn.com> wrote:
> > On Fri, Jul 26, 2002 at 08:48:42AM +0300, Pekka Savola wrote:
> > > AFAIK it's perfectly acceptable to have a prefix with multiple origins.
> >  
> > No.
> 
> Opinions seem divided on this topic - some ISPs will let you do it, others
> don't. I've never heard of anyone that'd had any real operational
> difficuties once they've convinced the ISPs concerned to do this however.
> 
> The limitations, as far as I'm aware, are with BGP support tools and
> technologies like RIPE-181/RADB rather than BGP itself.

"No" is WRT "perfectly acceptable".

Some ISPs wouldn't notice if it were going on either, but that doesn't
make it right. "limitation" is NOT the correct word here.  There's a 
lot of things one can do that will "work" in IP in general, let alone 
with BGP, but they are still not "perfectly acceptable". 

Inconsistant origin AS => anycast beyond a routing domain scope - it
undermines any hope of deterministic behavior.  It is perfectly 
reasonable to presume that today's providers will throw away such 
routing trash as potential hijacks.  Or that tomorrow's implementations 
could address the ambiguity in the spec and vendors give a knob (as 
was done with the ambiguity nature of a null MED) such as "bgp 
discard-inconsistent-as". 

What is a remote AS supposed to decide for the proper path? It is
indeterminate and potentially flappy. As such, you have just given up 
control and degraded your reachability.  In my design playbook, one 
strives to maximize one's reachability; if one is relying on protocol 
ambiguities that can & should be filled or provider mistakes, then 
one is setting up for a rude awakening.

To get back to the subject, non-BGP multihoming through provider-
specific space and NAT has been successfully deployed for years,*
without relying on spec ambiguities or any vendors' implementations 
(or bugs). As such you can expect it to continure to work without 
requiring a fire drill down the road.

Cheers,

Joe

* yes, yes NAT is not a universal solution. But it works well for many
  leaf-node applications and if you're trying to avoid p;roper
  multihoming, leaf-node is probably a good description.

--
Joe Provo                                            Voice  508.486.7471
Director, Internet Planning & Design                 Fax    508.229.2375
Network Deployment & Management, RCN                 <joe.provo@rcn.com>