> "collected only on active paths" is not something I propose but is the property of on-path > telemetry collection method.
That is all fine. The point is that the notion of active paths in the network may represent those in default topology over any path. That can be computed by PCE. So default topology may have N active paths while application specific topologies M where M is a subset of N meeting required end to end constraints. Sure it is possible to discover if my tailends are capable of handling in band telemetry by off line means. But what I am struggling to see why we allowed so much TE stuff into IGPs and we do not want to make it easier for headends to operate without PCE at all for the purpose of delivering such type of services. Kind regards, R. On Fri, Apr 3, 2020 at 1:22 AM Greg Mirsky <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 <[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 >>>>> >>>>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
