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