Mailing List Archive

On Fri, 6 Sep 2019, Jared Mauch wrote:

> What have you found are the most important parts of your settings, be it the underflow/overflow settings or otherwise.

From what I've seen, short timer intervals (statistics every 60s, adjust
every 300-900s) and relatively low adjust thresholds pretty well obviate
the need for overflow/underflow, but I also haven't had any issues with
the amount of resignaling that results. YMMV.

Other important stuff is running adaptive LSPs (to get make-before-break
SE reservations and avoid double counting), and optimize timers (to avoid
relying on auto-bw to clean up after link failures).

This rabbit hole runs pretty deep...

-Rob

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

> Jared Mauch
> Sent: Friday, September 6, 2019 10:42 PM
>
> What have you found are the most important parts of your settings, be it the
> underflow/overflow settings or otherwise. I’ve had a few people come to
> me recently asking for settings information, but I’m curious what the
> collective experience is with auto-bw in your environment and what settings
> were useful.
>
My two cents are use TE for TE and QOS for QOS it's just sooo much simpler that way.

Even with under/overflow you're always gonna be trailing, there's this bin packing problem, it's not deterministic especially during failures and for anything accurate the amount of state goes through the roof so the solution doesn't scale as a result (though the last bit can be solved through SR and SDN controller).
I'd be interested in what problem you're facing that can't be met with diffserv hence intserv needs to be employed -note the TE bit (even with class based tunnel selection) is orthogonal to this question.

adam

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

>
> From what I've seen, short timer intervals (statistics every 60s, adjust
> every 300-900s) and relatively low adjust thresholds pretty well obviate
> the need for overflow/underflow


On Junos it isn't just obviated, it is prevented from working.

https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/mpls-configuring-automatic-bandwidth-allocation-for-lsps.html

Hidden in there (and in the CLI if you dare):

> You cannot configure automatic bandwidth adjustments to occur more often
than every 300 seconds.

> The adjust-threshold-overflow-limit statement (aka overflow) is subject
to the same minimum value with regard to the minimum frequency of
adjustment allowed.
Therefore if your timers are on the floor already at 60s stats and 300s
intervals, overflow can't be used (as it's minimum is also 300s).

So if you have bursty traffic, you will drop within that 5 minute time
frame.

Unrelated, I got this response back from Juniper about `optimize-on-change
{ link-congestion; }`

"This knob is to move LSPs away from a congestion point – typically
congestion caused by link degradation or change in subscription.

Preemption aggressive + soft-preemption is the preferred way to handle this.

We do not recommend this knob at the ingress as this won’t necessarily move
LSPs in the order of setup priority.

It is really something to be handled at the congestion point/transit – to
move away precisely required no of LSPs emanating from various ingresses in
the order of priority.

This knob should be looked at only if customer cant configure preemption
aggressive + soft preemption in the transit for some reason"


?_?



On Mon, Sep 16, 2019 at 8:52 AM Rob Foehl <rwf@loonybin.net> wrote:

> On Fri, 6 Sep 2019, Jared Mauch wrote:
>
> > What have you found are the most important parts of your settings, be it
> the underflow/overflow settings or otherwise.
>
> From what I've seen, short timer intervals (statistics every 60s, adjust
> every 300-900s) and relatively low adjust thresholds pretty well obviate
> the need for overflow/underflow, but I also haven't had any issues with
> the amount of resignaling that results. YMMV.
>
> Other important stuff is running adaptive LSPs (to get make-before-break
> SE reservations and avoid double counting), and optimize timers (to avoid
> relying on auto-bw to clean up after link failures).
>
> This rabbit hole runs pretty deep...
>
> -Rob
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp