[nsp] Methods for Non-BGP multihoming

[Ryan O'Connell]

On Fri, 26 Jul 2002 14:12:36 -0400 Joe Provo <joe.provo@rcn.com> wrote:
> On Fri, Jul 26, 2002 at 06:33:23PM +0100, Ryan O'Connell wrote:
> > 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.
> 
> "No" is WRT "perfectly acceptable".

That depends on who decides what's "perfectly acceptable". I guess the
people on this list are a fair cross-section of those "in charge" on the
internet, so it would certainly be true to say it's not "perfectly
acceptable" as some people don't think it is.

> 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.

I'm not aware of any that do, but ISPs do all sorts of things so I'm sure
there are some that do. Those that do should probably only throw away
the one not listed in the RADB - otherwise you're partially defeating the
purpose of doing it in the first place. It would be trivial to prepend the
victims AS onto an announcement to hijack anyway, so I'm not sure what
benefit you'd really get. I have no idea how many ISPs filter enough to
only accept $customer_as^ on announcements.

> 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". 

One would hope that if use of inconsistent-origin-as becomes widespread
that vendors wouldn't do this or at least that ISPs would not use it. I
can't see why anyone would want such a feature.

> 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.

BGP relies on AS-path length if all other things are equal - there's
no mention in the specification that origin ASes should be consistent nor
that routers should throw away such advertisments. Arguably, any
implementation that does is "broken".

> 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.
> 
> * 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.

I agree - for most situations, NAT is your friend. Particularly, if you
need less than a /20 of IP address space many ISPs won't listen to you
advertisments anyway. Unfortunatly, it's only effective if you only have
clients using the 'net, not servers, but it should be the first choice for
such situations.

--
         Ryan O'Connell - CCIE #8174
<ryan@complicity.co.uk> - http://www.complicity.co.uk

I'm not losing my mind, no I'm not changing my lines,
I'm just learning new things with the passage of time