Do ATM-based Exchange Points make sense anymore?

Sat Aug 10 12:24:58 UTC 2002

On Sat, 10 Aug 2002, Mikael Abrahamsson wrote:

> It does when you start doing streaming anything, say TV or telephony. I
> agree that this wont be solved using any current L3 or above protocol
> since BGP takes quite a while to recalculate anyway. Any redundancy has to
> be pre-calculated or on a lower level, this is where for instance SRP/DPT
> claims excellence, guess same claims come from the MPLS crowd.

For it to be of any use, this rapid failover would have to be end-to-end
too. It's no good picking on one network element, such as the exchange,
and getting them to spend significant amounts of time and energy on rapid
failover, if it's just going to fall apart on either side.

We've been down this road with multicast. Getting good (non-IGMP)  
multicast containment on a switched ethernet isn't easy, nor is the
current situation ideal - there are several different approaches to
containment out there (and then we come back to getting stuff through the
standards process too).

But, the pressure isn't there either, because the access networks aren't
enabled/capable right now - certainly from talking to UK broadband
providers. There's also a non-technical driver - the bizdev people who are
in favour of per megabit billing will oppose multicast on the grounds that
the meter won't tick over as quickly (in their eyes).

> Personally I agree with you, the KISS principle is golden here. Peering 
> should be cheap, that is the only reason to do it, and therefore one does 
> not want a lot of complexity that brings up the cost. Tweaking eBGP dead 
> timers to 5-10 seconds works well in most cases.

Agreed. However, one thing to consider is the effect that the short timers
has on the routing table, in terms of announcements and withdrawals.

It takes about 20-30 seconds to warm boot a Foundry BI8000/15000 and get
it forwarding. 

So, in the event of a software upgrade (or some other need to reboot,
fairly rare), as long as you dont have fast-external-fallover enabled or
your timers shortened, you will blackhole some traffic, but in the large
majority, BGP sessions will stay up.

With the shorter timers or fast-external-fallover, a very short
maintenance slot at a large exchange can cause ripples in the routing
table. It would be interesting to do some analysis of this - how far the
ripples spread from each exchange!

I'm not saying that one or the other is right, it's just another tax!

> I have some idea about bringing together some of the signalling from
> DPT/SRP into a switching ethernet environment (for instance, have some
> kind of signalling between switches (propagated to hosts) that a certain
> port has gone down and notify that certain mac addresses are no longer
> reachable). 

Keith Mitchell had some ideas about harnessing OSPF at the MAC layer,
which I become involved in. People thought it may have had some potential
(others thought we were on interesting drugs!), but we're back to the tax
thing again. It's yet another protocol, and some people believed that it's
usefulness would be overtaken by MPLS (despite the potential for more
complexity), which we already have.

> Probably won't scale to very large L2 domains, but would perhaps be ok
> for 50-100 nodes connected to an IX.

Which, some argue, reduces the number of potential applications, and
therefore the justification for building it.

Mike