Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[Peter Psenak <[e-mail]>]

Robert,

On 03/03/2021 23:54, Robert Raszuk wrote:
> Hi Tarek,
> 
> Yes as Tony also just indicated it is completely different game here. 
> Headend can do whatever it likes.
> 
> But I think your point and also what Peter said earlier is to actually 
> throw the baby with the bath water by suppressing  advertisements/flooding.

no, we are not throwing the baby. You seem to by trying to find the 
problem where it does not exist.


> 
> It is all subject to proper suppression tuning/timers and I think we 
> have little experience with it (yet).

I would not say so.

> 
> Most importantly we are talking about topology wide changes so IMHO 
> doing it on the receiving node is not an option. It must be done on 
> sender. 


at least we agree on the above.

thanks,
Peter

>Receiver side suppression would be only valid if timers are hard 
> in stone in the RFC.
> 
> Thx,
> R.
> 
> On Wed, Mar 3, 2021 at 11:34 PM Tarek Saad <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Hi Robert,____
> 
>     __ __
> 
>     The RSVP-TE world has had to deal with such churn resulting from
>     frequent link attribute changes (e.g. specific to available BW). In
>     that case, such frequent changes made their way to the network at
>     periodic intervals and in the event they crossed a threshold. In my
>     mind, the link delay attribute is no different and IGPs can react to
>     it just like RSVP-TE did.____
> 
>     __ __
> 
>     Obviously, any path that was computed and placed on a set of links
>     based on a certain view of the network may quickly become stale.
>     However, IMO, any per-path e2e SLA need to be validated (independent
>     of the network topology) e.g., by active measurement using probes or
>     other means.____
> 
>     __ __
> 
>     My 2cents.____
> 
>     __ __
> 
>     Regards,____
> 
>     Tarek____
> 
>     __ __
> 
>     On 3/3/21, 2:57 PM, "Lsr on behalf of Robert Raszuk"
>     <[e-mail] <mailto:[e-mail]> on behalf of
>     [e-mail] <mailto:[e-mail]>> wrote:____
> 
>     __ __
> 
>     Peter,____
> 
>     __ __
> 
>      >  that differ by few microsecond ____
> 
>     __ __
> 
>     Really you normalize only single digit microseconds ???____
> 
>     __ __
> 
>     What if link delay changes in milliseconds scale ? Do you want to
>     compute new topology every few milliseconds ? ____
> 
>     __ __
> 
>     Out of curiosity as this is not a secret -  What are your default
>     min delay normalization timers (if user does not overwrite with
>     their own). Likewise how Junos or Arista normalizes it today ? ____
> 
>     __ __
> 
>     Thx,____
> 
>     R.____
> 
>     __ __
> 
>     On Wed, Mar 3, 2021 at 7:41 PM Peter Psenak <[e-mail]
>     <mailto:[e-mail]>> wrote:____
> 
>         Tony,
> 
>         On 03/03/2021 19:14, Tony Li wrote:
>          >
>          > Peter,
>          >
>          >>> There are several link types in use that exhibit variable
>         delay: satellite links (e.g., Starlink), microwave links, and
>         ancient link layers that deliver reliability through retransmission.
>          >>> Any of these (and probably a lot more) can create a
>         noticeable and measurable difference in TWAMP. That would be
>         reflected in an FA metric change. If you imagine a situation
>         with multiiple parallel paths with nearly identical delays, you
>         can easily imagine an oscillatory scenario.   IMHO, this is an
>         outstanding concern with FA.
>          >> yes, and that is what I referred to as "delay
>         normalization", which can avoid that oscillation.
>          >
>          >
>          > It can also negate the benefits of the feature. One might
>         well imagine that Starlink would want to follow a min-delay path
>         for optimality.  If the delay variations are “normalized” out of
>         existence, then the benefits are lost.  The whole point is to
>         track the dynamics.
> 
>         for all practical purposes that we use it for, the two values of
>         min
>         delay that differ by few microsecond can be treated as same
>         without any
>         loss of functionality. So it's about the required normalization
>         interval
>         - something that can be controlled by the user.
> 
>         thanks,
>         Peter
> 
> 
> 
>          >
>          >
>          >>> Please note that I’m NOT recommending that we back away.
>         Rather, we should seek to solve the long-standing issue of
>         oscillatory routing.
>          >>
>          >> not that I disagree. History tells us that the generic case
>         of oscillation which is caused by the traffic itself is a hard
>         problem to solve.
>          >
>          >
>          > Any oscillation is difficult to solve.  Positive feedback
>         certainly can exacerbate the problem. But solving hard problems
>         is why we are here.
>          >
>          > Yours in control theory,
>          > Tony
>          >
>          >
>          > ____
> 
> 
>     Juniper Business Use Only
>