Hi all,
as noted on mic a few minutes ago, I do not think this draft is a good idea. The two specific points I made on mic are these: - LLDP is intentionally designed to bypass STP; you want to know what is on the other end of the link even if the port is blocked. Can you discard the routes if the port is blocked? Sure. But now you have an interaction not only RIB<>LLDP, but also STP to get the port state and keep up to date. Of course no sane person runs STP in a scenario you would use this LLDP feature in, but I have learned to never underestimate the "creativity" of operators in coming up with weird setups. - MACsec is by default negotiated on the :03 special Ethernet multicast group. LLDP by default runs on :0E. These two groups don't have the same "reach": :03 transits more devices than :0E. That means your "normal" MACsec SA won't be with the device you're talking LLDP with. Both the MACsec and LLDP specs allow configuring the respectively other multicast group, but - that is not default config and not commonly done. Furthermore, no operator I know actually *wants* MACsec on LLDP. They want to know what's connected where while debugging their network, possibly including MACsec. That's a reasonable stance, IMHO. But since you've tied yourself to LLDP, you're now left without any way of authenticating & securing these routes. And this functionality is really the most useful when crossing admin boundaries - worst place to lack security on! I believe the above points are just symptomatic of the layer break that is happening here and you're "reaping the rewards". Routes IMHO just don't belong in LLDP. And with all that said, I don't see what the point of sticking this in LLDP is. The protocol itself doesn't give you anything that any random other multicast discovery protocol does. And you're defining a new feature; there's no compatibility argument. The only functional distinction I can see is the use of the limited scope 01:80:C2:00:00:0E ethernet multicast group. If that is your goal, we should look at achieving that - without going through LLDP. (And I don't think :0E [closest TPMR] is the correct choice; if anything I think the function you're describing might go into :03 [closest non-TPMR bridge, and also 802.1X/MACsec termination]) Regards, equi P.S.: yes, I know TPMRs are quite rare and you'll probably never see one in a datacenter. But the fact that these things just don't quite fit together in their definitions doesn't go away just because the case is rare. OpenBSD has a TPMR implementation. _______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
