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

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[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
>>>>
>>>