Mailing List Archive

ospf auto-cost reference-bandwidth on modern gigabit networks
Hello,

     Is there a recommended 'modern default' for ip ospf auto-cost
reference-bandwidth, to account for the fact that modern networks have
1g and faster interfaces?

    My core equipment all has 10G and 1G interfaces today, and it seems
to me that if I set the reference-bandwidth to 100gbps, Im not losing
anything, but gaining a useful distinction between the modern
1g,10g,40g,and 100g interfaces of today. I understand the necessity of
setting this on all routers in the network, however, I do have some
older equipment (cisco 7201) doing T1 aggregation that also has 1g
interfaces with nothing higher, so I am wondering the practicality of
maybe just skipping this default change on that and like gear? These
devices are at the edge and further only have single uplink connections
to the core so it would seem safe to not worry about this here.


Thank you.


_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
Hey,

> Is there a recommended 'modern default' for ip ospf auto-cost
> reference-bandwidth, to account for the fact that modern networks have
> 1g and faster interfaces?

To me this never made any sense. It's a very atypical case where you
want your topology to be link-bw based. The most common use-case is,
you want distance metric, i.e. everything is equal, and you want least
amount of hops. The 2nd most common case is role-based, that you have
P-P lower metric than P-PE so you don't transit via PE and so forth
(but each P-P are largely equal, due to topology having few options to
target PE) and the 3rd most common is to have idealised latency based
metric, so that you can model best path on nTh failure (to have bw)
with RSVP.

Reference bandwidth sounds like a very niche scenario where it would
be sensible.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
On 29/Apr/20 17:04, Mike wrote:

> Hello,
>
>      Is there a recommended 'modern default' for ip ospf auto-cost
> reference-bandwidth, to account for the fact that modern networks have
> 1g and faster interfaces?
>
>     My core equipment all has 10G and 1G interfaces today, and it seems
> to me that if I set the reference-bandwidth to 100gbps, Im not losing
> anything, but gaining a useful distinction between the modern
> 1g,10g,40g,and 100g interfaces of today. I understand the necessity of
> setting this on all routers in the network, however, I do have some
> older equipment (cisco 7201) doing T1 aggregation that also has 1g
> interfaces with nothing higher, so I am wondering the practicality of
> maybe just skipping this default change on that and like gear? These
> devices are at the edge and further only have single uplink connections
> to the core so it would seem safe to not worry about this here.

When we moved to IS-IS in 2007, we decided to set our reference
bandwidth to 1Tbps (not in the routers, but as a concept).

My recommendation would be not to set the reference in the network.
Rather, have it as an architecture concept and deliberately design
metrics off of your reference. 1Tbps seemed reasonable in 2007. Who
knows, maybe 10Tbps is reasonable in 2020 (with the downside being that
your metrics will be very high for very slow links).

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
On 29/Apr/20 17:16, Saku Ytti wrote:

>
> To me this never made any sense. It's a very atypical case where you
> want your topology to be link-bw based. The most common use-case is,
> you want distance metric, i.e. everything is equal, and you want least
> amount of hops. The 2nd most common case is role-based, that you have
> P-P lower metric than P-PE so you don't transit via PE and so forth
> (but each P-P are largely equal, due to topology having few options to
> target PE) and the 3rd most common is to have idealised latency based
> metric, so that you can model best path on nTh failure (to have bw)
> with RSVP.
>
> Reference bandwidth sounds like a very niche scenario where it would
> be sensible.

So we design metrics based on:

* Device function (P, PE, P/PE or LAN).
* Bandwidth.
* Latency.

We calculate a coefficient that takes all those 3 above into account to
ensure that the right device is always carrying the right traffic over
the fastest and shortest path.

Mark.

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
On Wed, 29 Apr 2020 at 16:10, Mike <mike+lists@yourtownonline.com> wrote:
>
> Hello,
>
> Is there a recommended 'modern default' for ip ospf auto-cost
> reference-bandwidth, to account for the fact that modern networks have
> 1g and faster interfaces?
>
> My core equipment all has 10G and 1G interfaces today, and it seems
> to me that if I set the reference-bandwidth to 100gbps, Im not losing
> anything, but gaining a useful distinction between the modern
> 1g,10g,40g,and 100g interfaces of today. I understand the necessity of
> setting this on all routers in the network, however, I do have some
> older equipment (cisco 7201) doing T1 aggregation that also has 1g
> interfaces with nothing higher, so I am wondering the practicality of
> maybe just skipping this default change on that and like gear? These
> devices are at the edge and further only have single uplink connections
> to the core so it would seem safe to not worry about this here.

Hi Mike,

To answer your first question, I’d just push it up to 1Tbps rather
than 100Gbps. You don’t know what’s around the corner, you say you
have 10Gbps in the network now, 2 years from now you may put your
first 100Gbps link in and 2 years after that upgrade to 2x100Gbps
LAGs. So, I’d just bump it up to 1Tbps and then you don’t have to
worry about it for a long time / ever again (based on your current
size). If you’re going to the effect of rolling this out now, you
don’t want to do it again in a few years.

There was also a thread on this last year on the J-NSP List, see here:
https://puck.nether.net/pipermail/juniper-nsp/2019-January/036942.html

I’ve worked on some networks with ref bandwidth set to 100Gbps and
1Tbps, it worked fine in all cases, and they were mixed vendor
networks too.

To answer your second question about leaving out some older routers,
that’s really down to your operational niche. If these 7201’s really
only have a single 1G link, on paper it’s fine, but if they have a
recent enough IOS version that supports a 1Tbps ref bandwidth, then
I’d say you should be aligning them to the rest of your network. It
will hurt you a year from now on that 3AM on-call call-out when you’ve
forgotten why and this 7201 has different costs to all your other
routers and you have to waste time bottoming out why, before looking
into whatever the real issue is.

Cheers,
James.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
On Wed, 29 Apr 2020 at 16:21, Saku Ytti <saku@ytti.fi> wrote:
>
> Hey,
>
> > Is there a recommended 'modern default' for ip ospf auto-cost
> > reference-bandwidth, to account for the fact that modern networks have
> > 1g and faster interfaces?
>
> To me this never made any sense. It's a very atypical case where you
> want your topology to be link-bw based. The most common use-case is,
> you want distance metric, i.e. everything is equal, and you want least
> amount of hops. The 2nd most common case is role-based, that you have
> P-P lower metric than P-PE so you don't transit via PE and so forth
> (but each P-P are largely equal, due to topology having few options to
> target PE) and the 3rd most common is to have idealised latency based
> metric, so that you can model best path on nTh failure (to have bw)
> with RSVP.
>
> Reference bandwidth sounds like a very niche scenario where it would
> be sensible.

Hi Saku,

I strongly disagree with this advice to OP.

It isn’t atypical that link-bw is used in my experience, I’d say that
in smaller shops it’s actually the norm. Where one has no dedicate P
nodes for example, all links are PE-to-PE with PEs implicitly acting
as P nodes between a pair of ingress and egress PEs; they’re all the
same function, and network services in smaller shops are also rarely
distributed evenly across the network, and thus bandwidth isn’t equal
in all parts of the network.

One problem with say role-based metrics (e.g. PE-PE, PE-P and P-P) is
that upgrades and failures don’t happen symmetrically. Role based
metrics are a good theory but in practical terms are quite limited, in
particular for smaller shops in my opinion.

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

Provider A delivers within 2 weeks, provider B has no more capacity in
my area, and it takes 2 months. I can’t add provider A’s new
link/wavelength into my P-1 facing LAG bundle until the provider B
wavelength is ready. This is because a role-based PE-to-P cost doesn’t
reflect available bandwidth, I can’t make use of the extra capacity
provider A has provided because traffic is ECMP’ed over both P facing
LAGs. My lower capacity LAG to P-2 is still getting half the traffic.
I could temporarily raise the cost on the PE to P-2 facing LAG, but
then why not just have bw-based cost in the first place?

At some point in the future, when the capacity on both P-facing LAGs
has been increased, the 2nd member link within my P-2 facing LAG goes
down. Traffic is still ECMP’ed over both LAGs equally though because
the role-based cost on both LAGs is the same. The P-2 LAG is now
congested. I can add complexity by using knobs like “minimum bundle
links” but my only option there would be to have the LAG to P-2 shut
itself down, even though it still has one working link. I want to keep
the LAG to P-2 up, in case the LAG to P-1 dies completely, but just
shift all my traffic to the P-1 facing LAG until the full bandwidth of
the P-2 facing LAG is restored. That would happen automatically with
bw based IGP cost.

Role based and metric based IGP costs are a good idea in theory. They
are a lot more difficult in practice. Another problem with role based
IGP costs is “who has more capacity between a pair of PEs than those
PEs have to their upstream P nodes”? If you find yourself in that
scenario, it isn’t role based IGP costs you need, it’s a long hard
look in the mirror.

Look at the current post-child of Service Provider networking, Segment
Routing, which everyone seems to love; this is exactly one of the
major reasons many networks need SR-EPE. I ask my external peer for an
additional peering links at the two locations we peer at, they deliver
at location 1 tomorrow, and location 2 in another 6 weeks. But I need
this capacity now because that peer is a major CDN and next week some
massive social/cultural thing is happening at short notice. I need to
“engineer” (as in EPE) a disproportionate amount of traffic towards
the first peering location, which isn’t reflected in the BGP
preference.

The key point is this:
OP needs to choose what is actually practical for his network (which
may be role-based costs), not what is academically superior.

Cheers,
James.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
On 30/Apr/20 10:33, James Bensley wrote:

> Role based and metric based IGP costs are a good idea in theory. They
> are a lot more difficult in practice. Another problem with role based
> IGP costs is “who has more capacity between a pair of PEs than those
> PEs have to their upstream P nodes”? If you find yourself in that
> scenario, it isn’t role based IGP costs you need, it’s a long hard
> look in the mirror.

I disagree here.

I've built - across 3 networks on 2 continents - role-based, bandwidth
and latency-linked metrics in IS-IS since 2007.

Each of these networks was differently sized, with the latest being the
largest one, spanning several countries and 3 continents. So it does
work in practice, but it's a concept that took me about a year to
design, for each network.

And yes, I have found myself in situations where "longer" links were
required for service alongside "shorter" links due to some reason or
another, e.g., backbone failure on the path, urgent need for more
tactical capacity, e.t.c. That is okay. Networks are living things - you
have to be able to react to situations even though you have fundamentals
in place.

Mark.

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
On Thu, 30 Apr 2020 at 11:33, James Bensley
<jwbensley+cisco-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
> 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@ytti.fi> wrote:

> On Thu, 30 Apr 2020 at 11:33, James Bensley
> <jwbensley+cisco-nsp@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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
On Thu, 30 Apr 2020 at 12:31, Robert Raszuk <robert@raszuk.net> wrote:

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

I'm skeptical SPT topology ever was remotely typical where it made
sense. It may work approximately, but that's not because it's good
SPT, that's because acceptable outcome has large overlap with possible
implementations.



Two examples spring to mind

1) 10GE network, where you have 1G tails redundantly connected, you
don't want the 1G tail to transit any of the 10GE traffic. You
actually want overload or similar, the dual-connected 1GE is never
desirable to transit.

2) 10GE core, with 1G islands attached to it, 1G will transit 1G
inside 1G island, but you don't want 1G island to transit 10GE core.
So you actually want a penalty on the island-border, so traffic
doesn't cross it. (i.e. role based).

In both above cases, people want distance-vector, with constraints,
and BW based may approximate correct behaviour, but correct behaviour
is actually very different from BW SPT.

I think an interesting exercise is, why don't we see BW based ISIS
topologies, but we do see OSPF? I think it is status quo bias, because
vendors offer OSPF with this default, is must make sense.



--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
On 30/Apr/20 11:31, Robert Raszuk wrote:

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

I just don't see that, in our implementation.

I agree that bandwidth-only metrics aren't sufficient. But combining
that with device functions and latency, really works. Has for us.


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

We run away from RSVP years ago :-). Our model + simple LDP has worked
very well. Fair point, we are in a position to have the kind of capacity
we need on any segment, which goes a long way to realizing this.


Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
On 30/Apr/20 11:39, Saku Ytti wrote:

> I think an interesting exercise is, why don't we see BW based ISIS
> topologies, but we do see OSPF? I think it is status quo bias, because
> vendors offer OSPF with this default, is must make sense.

Your basis (bandwidth, latency, function, e.t.c.) is just an arbitrary
concept that you can develop for yourself.

That a "reference-bandwidth" command does not exist in IS-IS doesn't
mean anything. You're welcome not to use it in OSPF too :-).

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
> We run away from RSVP years ago :-).

Good ! Would never suggest RSVP-TE any longer :)

I rather meant end to end performance routing when applied to your WAN.
Maybe just with few anchor nodes to diversify the paths. Could be SR based
could be plain UDP.

Thx


On Thu, Apr 30, 2020 at 11:59 AM Mark Tinka <mark.tinka@seacom.mu> wrote:

>
>
> On 30/Apr/20 11:31, Robert Raszuk wrote:
>
> > 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.
>
> I just don't see that, in our implementation.
>
> I agree that bandwidth-only metrics aren't sufficient. But combining
> that with device functions and latency, really works. Has for us.
>
>
> > 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.
>
> We run away from RSVP years ago :-). Our model + simple LDP has worked
> very well. Fair point, we are in a position to have the kind of capacity
> we need on any segment, which goes a long way to realizing this.
>
>
> Mark.
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
On 30/Apr/20 12:12, Robert Raszuk wrote:

>  
>
> Good ! Would never suggest RSVP-TE any longer :) 
>
> I rather meant end to end performance routing when applied to your
> WAN. Maybe just with few anchor nodes to diversify the paths. Could be
> SR based could be plain UDP.

Guess you remember my feelings on SR :-).

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
On Thu, 30 Apr 2020 at 09:58, Mark Tinka <mark.tinka@seacom.mu> wrote:
>
>
>
> On 30/Apr/20 10:33, James Bensley wrote:
>
> > Role based and metric based IGP costs are a good idea in theory. They
> > are a lot more difficult in practice. Another problem with role based
> > IGP costs is “who has more capacity between a pair of PEs than those
> > PEs have to their upstream P nodes”? If you find yourself in that
> > scenario, it isn’t role based IGP costs you need, it’s a long hard
> > look in the mirror.
>
> I disagree here.
>
> I've built - across 3 networks on 2 continents - role-based, bandwidth
> and latency-linked metrics in IS-IS since 2007.
>
> Each of these networks was differently sized, with the latest being the
> largest one, spanning several countries and 3 continents. So it does
> work in practice, but it's a concept that took me about a year to
> design, for each network.

Hi Mark,

You say you disagree, I didn't say it couldn't or shouldn't be done, I
said that "They are a lot more difficult in practice", and you said it
took you a year to design, so actually I think you agree with me ;)

> And yes, I have found myself in situations where "longer" links were
> required for service alongside "shorter" links due to some reason or
> another, e.g., backbone failure on the path, urgent need for more
> tactical capacity, e.t.c. That is okay. Networks are living things - you
> have to be able to react to situations even though you have fundamentals
> in place.

^ This! This last statement 100% "Networks are living things" <- that
is my point. Saku's advise reads to me that bw-based metrics can AND
should never ever be used unless there is no other choice. I am
disagreeing with *that*. There is a time and a place for each method,
and it depends on your context, not that one method is should be
preferred over another "unless you have to", each method should be
equally evaluated against the requirements.

Cheers,
James.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
On 30/Apr/20 12:39, James Bensley wrote:

> You say you disagree, I didn't say it couldn't or shouldn't be done, I
> said that "They are a lot more difficult in practice", and you said it
> took you a year to design, so actually I think you agree with me ;)

Agreed. 16hrs on a long-haul flight is a long time to spend in a tube :-).

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
On Thu, 30 Apr 2020 at 10:13, Saku Ytti <saku@ytti.fi> wrote:
>
> On Thu, 30 Apr 2020 at 11:33, James Bensley
> <jwbensley+cisco-nsp@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.

None of these methods are perfect. For sure, bw based is flawed as you
said above, hoping 9 hops vs. 1 in a cross-country scenario would be
bad for most typical service providers, hopping 9 hops instead of 1
across an inner city metro however is virtually unnoticeable to the
average user.

Equally and adversely; what do you do in your scenario above when you
have if you have 1.000001Gbps of traffic between that ingress PE and a
remote egress PE? If you actually only have less than 1Gbps of
traffic, why do you have 10G links if you only have sub-1Gbps of
bandwidth, that is wasted money on 10Gbps links? The problem in that
scenario is surely that you have at least 1Gbps of traffic, which is
what justified the spend on 9x 10Gbps, and that the 1Gbps link still
hasn't been upgraded yet to match the other 9x 10Gbps links you have,
so actually bw-based metrics in that scenario, would have prevented
congested.

My point is that it's all about context. We'll have to agree to
disagree perhaps, because I think there is a place for role based
metrics, latency based metrics, a combination of both, and bw based
metrics, and I don't think bw based is that uncommon or unusual.

Cheers,
James.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
On 4/30/20 12:30 AM, Mark Tinka wrote:
> On 29/Apr/20 17:04, Mike wrote:
>
>> Hello,
>>
>>      Is there a recommended 'modern default' for ip ospf auto-cost
>> reference-bandwidth, to account for the fact that modern networks have
>> 1g and faster interfaces?
>>
>>     My core equipment all has 10G and 1G interfaces today, and it seems
>> to me that if I set the reference-bandwidth to 100gbps, Im not losing
>> anything, but gaining a useful distinction between the modern
>> 1g,10g,40g,and 100g interfaces of today. I understand the necessity of
>> setting this on all routers in the network, however, I do have some
>> older equipment (cisco 7201) doing T1 aggregation that also has 1g
>> interfaces with nothing higher, so I am wondering the practicality of
>> maybe just skipping this default change on that and like gear? These
>> devices are at the edge and further only have single uplink connections
>> to the core so it would seem safe to not worry about this here.
> When we moved to IS-IS in 2007, we decided to set our reference
> bandwidth to 1Tbps (not in the routers, but as a concept).
>
> My recommendation would be not to set the reference in the network.
> Rather, have it as an architecture concept and deliberately design
> metrics off of your reference. 1Tbps seemed reasonable in 2007. Who
> knows, maybe 10Tbps is reasonable in 2020 (with the downside being that
> your metrics will be very high for very slow links).
>
> Mark.

My recommendation would be to set the default such that most or all of
the links would default to a metric higher than what your designed
metrics would be. Let the defaults protect you so that if a metric is
missed, the default behavior is not to let the new link become instantly
"best".

pt


_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
On 30/Apr/20 18:30, Pete Templin wrote:

>
> My recommendation would be to set the default such that most or all of
> the links would default to a metric higher than what your designed
> metrics would be. Let the defaults protect you so that if a metric is
> missed, the default behavior is not to let the new link become
> instantly "best".

The default metric for IS-IS is 10.

0 for the Loopback interface in Junos.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: ospf auto-cost reference-bandwidth on modern gigabit networks [ In reply to ]
On Sat, 2 May 2020 at 04:26, Benny Lyne Amorsen via cisco-nsp
<cisco-nsp@puck.nether.net> wrote:

> You can make things more reasonable by simply taking the square root of
> the bandwidth before calculating the metric. Or logarithmic, if you
> prefer.
>
> It is not perfect, of course, but nothing is.

I think anything you do with a BW basis is going to be undesirable
SPT. This is why I think the default is so harmful, it precludes
people from thinking what should their SPT be, because it tends to
work good enough. When it does work, the x9 is actually proxy for goal
of 'never', the topologies where the behaviour is desirable they never
want to go from high-speed => low-speed => high-speed, and as long as
9x is a reasonable proxy for 'never' the SPT works reasonably for many
use-cases. But rarely it is the behaviour they actual desire. The
right behaviour in this example would be to replace the 9x proxy at
speed borders with link-penalty which guarantees high=>low=>high won't
happen, not just hope.

If SPT would do some unequal balancing based on metrics, then
discussion might be very different, and I think somehow
intuitively/subconsciously people think something like this happens 'I
will have 10x less traffic on my 1GE links'.


--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/