Very valid comment - When working on MSD - we had exactly same considerations, since path computation could use different links over different line cards that may have different capabilities, hence we decided to have per link granularity, details in RFC 8491
Cheers, Jeff On Apr 4, 2020, 7:33 PM -0700, Greg Mirsky <gregimir...@gmail.com>, wrote: > Dear All, > I've read these two drafts with interest.. In light of the discussion on the > LSR WG list, I've been thinking about the scenarios where IFIT is being used. > draft-song-opsawg-ifit-framework defines the overall IFIT architecture that, > as I understand it, applicable to different methods of collecting and > transporting telemetry information. > draft-wang-lsr-ifit-node-capability-advertisement is based on the view that > IFIT is a node-wide capability advertised as a binary flag for each listed > method of collecting telemetry information (Option-Type enabled Flag). > On-path telemetry collection is performed in the fast path, i.e., at a link > layer. But a node might include ports with different capabilities. How such a > heterogeneous, IFIT-wise, node will advertise IFIT Capability? To better use > available resources for telemetry information collection, it might be helpful > to advertise IFIT as a capability of a link, not of a node? > What do you think? > > Regards, > Greg > _______________________________________________ > Lsr mailing list > l...@ietf.org > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
