Hi Robert, "collected only on active paths" is not something I propose but is the property of on-path telemetry collection method.
Regards, Greg On Thu, Apr 2, 2020 at 4:16 PM Robert Raszuk <rob...@raszuk.net> wrote: > > collected only on active paths > > Here we clearly diverge :) > > The notion of default active paths in my view represents many more > alternative paths constructed based on the default topology while cspf or > flex algo products may consist only of subset of those per applied > constraints. > > Thx, > Robert > > > On Fri, Apr 3, 2020 at 1:13 AM Greg Mirsky <gregimir...@gmail.com> wrote: > >> And another note regarding the use of on-path collected telemetry >> information. I'd point that that information is collected only on active >> paths. Thus it characterizes the conditions experienced by already existing >> flows. Hence it might not be related to a path that the system intends to >> instantiate. One needs active OAM to collect such information. >> >> Regards, >> Greg >> >> On Thu, Apr 2, 2020 at 4:08 PM Greg Mirsky <gregimir...@gmail.com> wrote: >> >>> Hi Robert, >>> I think that there's no apparent requirement to collect performance >>> information form each node in the network in order to select a path with >>> bounded delay and packet loss. Would you agree? >>> >>> Regards, >>> Greg >>> >>> On Thu, Apr 2, 2020 at 4:03 PM 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
