Hi Joel, > Robert, you seem to be asking that we pass full information about the > dynamic network state to all routers
No not at all. Only TE headends need this information. To restate ... I am not asking to have a synchronized input to all routes in the domain such that their computation would be consistent. I am only asking for TE headends to be able to select end to end paths based on the end to end inband telemetry data. I find this a useful requirement missing from any of today's operational deployments. Many thx, R. On Fri, Apr 3, 2020 at 12:59 AM Joel M. Halpern <[email protected]> wrote: > 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
