[c-nsp] ospf auto-cost reference-bandwidth on modern gigabit networks

[Robert Raszuk]

> 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 <saku at ytti.fi> wrote:

> On Thu, 30 Apr 2020 at 11:33, James Bensley
> <jwbensley+cisco-nsp at gmail.com> 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>