Jakub Kicinski [off-list ref] writes:

On Mon, 3 Oct 2022 21:59:49 +0000 Daniel.Machon@microchip.com wrote:

quoted

If lldpad was idd able to emit the new pcp app entries, they would be

idd?

quoted

emitted as invalid TLV's (assuming 255 or 24 selector value), because the
selector would be either zero or seven, which is currently not used for
any selector by the std. We then have time to patch lldpad to do whatever
with the new attr. Wouldn't this be acceptable?

I'm not sure I can provide sensible advice given I don't really know
how the information flow looks in case of DCB.

First off - we're talking about netlink TLVs not LLDP / DCB wire message
TLVs?

DCB wire message in this case.

What I was saying is that if lldpad dumps the information from the
kernel and gets confused by certain TLVs - we can add an opt-in
attribute to whatever Netlink request lldpad uses, and only add the new
attrs if that opt-in attribute is present. Normal GET or DUMP requests
can both take input attributes.

Old lldpad will not send this attribute to the kernel - the kernel will
not respond with confusing attrs. The new lldpad can be patched to send
the attribute and will get all the attrs (if it actually cares).

Another aspect is that lldpad will never create these entries on its
own, until it gets support for it, at which point these issues would
presumably get fixed as well. The only scenario in which it breaks is
when an admin messes with the APP entries through iproute2, but then
uses lldpad. Which doesn't make sense to me as a use case.