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 <ts...@juniper.net
<mailto:ts...@juniper.net>> 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"
<lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org> on behalf of
rob...@raszuk.net <mailto:rob...@raszuk.net>> 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 <ppse...@cisco.com
<mailto:ppse...@cisco.com>> 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
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
