Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

[Greg Mirsky <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> 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 <[e-mail]>
> 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/lsr
>> >
>>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>