On 16-Jun-21 14:38, Michael Richardson wrote:
> 
> Brian E Carpenter <[email protected]> wrote:
>     > I think this works. Is there an established API for accessing LLDP?
> 
> Not that I know of.
>     There is https://github.com/intel/openlldp which seems more current than
>     the 2013-era Sourceforge project.
> 
> When using it, there is IPC from a CLI tool to the daemon to get/set info.
> For all I know, it interfaces to snmpd on *nix machines as well.
> 
> HOWEVER, I suspect that in control plane CPUs, that it's all vendor
> proprietary anyway.  I hope that openlldp will "just work" on the 8-port
> Zyxel switch that I have that boot openwrt.
> 
>     > One comment:
> 
>     >> Unicast traffic between two control plane CPUs
>     >> should not be a problem, so actual ACP traffic could be sent just fine,
>     >> as
>     >> long as it is only unicast.
> 
>     > Some ACP traffic will be multicast, of course, but *over* the unicast
>     > pt2pt links that carry the ACP VRF. So yes, it's unicast from the
>     > link's PoV.
> 
> Yes.
> Do you think that the document should beat people over the head about this?

Well, I think it needs to be spelled out. It certainly wasn't instantly
obvious to me (I mean a year or two ago).

> Do you think that telling people to turn off DAD and NS is enough?
> I guess they should turn off MLD as well.

Well, they might want to do regular data plane operations, no?

> Is there some IPv6 LL operational aspect that I've forgotten that would
> require multicast?  

I'm only aware of RA/NS/DAD stuff. Might be worth asking on v6ops.

> Until I revised the document this afternoon, I was
> convinced that I was going to have to add some attributes to the M_FLOOD
> announcement to make up for stuff that would normally arrive by NS/NA.
> 
> In looking at things, the only thing I knew I needed was the peer's L2
> address, and that's already there in the LLDP source address.  It could be
> that it's hard to get at though, so we might want to keep that in mind.

Ack
   Brian

_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to