Hi Aijun, I understand very well what you are trying to achieve and don’t argue the need for it. My point however - routing protocols are not the most suitable transport for it.
Regards, Jeff > On Apr 2, 2020, at 19:39, Aijun Wang <wangai...@tsinghua.org.cn> wrote: > > Hi, Jeff: > The draft only propose to transfer the iFIT capability of the Node via the > IGP protocol, not the telemetry data. > As described in the draft, flooding such capability can assist the > controller(it collects such information via the BGP-LS) to deploy the iFIT > function at the path headend. > > Aijun Wang > China Telecom > >>> On Apr 3, 2020, at 08:20, 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
