Robert, you seem to be asking that we pass full information about the
dynamic network state to all routers so that they can, if needed, serve
as fully intelligent path computation engines. If you want to do that,
you will need more than just the telemetry. You will need the demands
that are coming in to all of those routers, so that you can make global
decisions sensibly.
Which is why we use quasi-centralized path computation engines.
Yours,
Joel
On 4/2/2020 6:16 PM, Robert Raszuk wrote:
> If you consider such constrains to provide reachability for
applications you will likely see value that in-situ telemetry is
your friend here. Really best friend as without him you can not do
the proper end to end path exclusion for SPT computations..
[as wg member] Are you thinking that shifting traffic to a router is
not going to affect it's jitter/drop rate?
Well this is actually the other way around.
First you have your default topology. They you are asked to
construct new one based on applied constrains.
So you create complete TE coverage and start running end to end data
plane probing over all TE paths (say SR-TE for specific example). Once
you start collecting the probe results you can start excluding paths
which do not meet your applied constraints. And that process continues.
To your specific question - It is not that unusual where routers degrade
their performance with time and in many cases the traffic is not the
cause for it but internal bugs and malfunctions.
Best,
R.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
