Re: [Anima] draft-richardson-anima-l2-friendly-acp-02.txt

[Michael Richardson <[e-mail]>]

Brian E Carpenter <[e-mail]> 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?
Do you think that telling people to turn off DAD and NS is enough?
I guess they should turn off MLD as well.

Is there some IPv6 LL operational aspect that I've forgotten that would
require multicast?  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.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide