> I just don't think the topologies are realistic for BW based. Very true.
It is like GPS putting all cars on the big and congested highway when you have a totally empty asphalt side road next to it :) The BW based IGP metric mapping comes from times of F/R, 64 kbps satellite uplinks and zyxel DTE/DCE V.35 devices. The problem here is that you are all correct in a sense :) The fundamental issue is that routing protocols today just don't know how to create stable routing topologies based on dynamic metrics (of any sort). And this is the same for IGPs or BGP too. Good news however is that overlays come to the rescue and if you really care you can assure your customers packet get best end to end service. Sure a lot of space for improvement there as well, but at least we are at good start. Thx, R. On Thu, Apr 30, 2020 at 11:16 AM Saku Ytti <[email protected]> wrote: > On Thu, 30 Apr 2020 at 11:33, James Bensley > <[email protected]> wrote: > > > APE has a wavelength from provider A to P-1 and a 2nd wavelength from > > provider B to P-2. I’ve asked each provider for a 2nd wavelength from > > me PE to P-1 and P-2, to increase the core facing capacity of the PE. > > I just don't think the topologies are realistic for BW based. It's > just the lower BW links are then useless and never used, and wasted > money. Idea that I'll rather travel exactly 9 10GE links than 1 1GE > link is ridiculously atypical. > > If you have BW problems, then you want some sort of idealised latency > metric and RSVP to put traffic on the best possible path with BW > remaining. > > -- > ++ytti > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
