Hi Tony, Yes, I’m aware FA is hop-by-hop.. My point is per-link delay changes can be suppressed and advertised at periodic intervals (usually order of mins) or immediately based on crossing a threshold. The per-path delay cannot be accurately extracted from a “snapshot” of the view of the topology (e.g. adding per link delays for traversed links - as those values may quickly become stale). Such validation IMO (if any are needed) will have to come based on active/passive measuring mechanisms..
Regards, Tarek On 3/3/21, 5:41 PM, "Lsr on behalf of Tony Li" <[email protected]<mailto:[email protected]> on behalf of [email protected]<mailto:[email protected]>> wrote: Hi Tarek, Please recall that in FA there is no path setup. If the delay changes and it propagates to other nodes, then the network will SPF and paths may change immediately. Tony On Mar 3, 2021, at 2:34 PM, Tarek Saad <[email protected]<mailto:[email protected]>> 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" <[email protected]<mailto:[email protected]> on behalf of [email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 Juniper Business Use Only
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
