Hi Jeff, excellent question, thank you! If one wants to empower headends with all the telemetry, then there's no need to collect it. A method that triggers node-local measurement is sufficient to calculate node-local performance metrics that may be periodically exported to a Collector or ... flooded using IGP (no, I didn't say that!).
Regards, Greg On Thu, Apr 2, 2020 at 5:19 PM Jeff Tantsura <jefftant.i...@gmail.com> wrote: > Robert, > > We are deviating ;-) > > There’s no feedback loop from telemetry producers back to the TE headend. > The telemetry, either end2end or postcards is sent to a collector that > has the context of the data and normalizes it so it can be consumed by an > external system, being centralized or distributed PCE or anything else that > could make use of it. Do you see IGP anywhere in between? > > > Regards, > Jeff > > On Apr 2, 2020, at 16:03, Robert Raszuk <rob...@raszuk.net> wrote: > > > 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 <j...@joelhalpern.com> > 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 >> > Lsr@ietf.org >> > https://www.ietf.org/mailman/listinfo/lsr >> > >> > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr