WG, after some thinking, I have revised this document from problem statement to a proposed solution.
The short of it is that the problem is multicast/broadcast, such as done for ND, DAD and GRASP-DULL. 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. So the problem isn't ACP operation (IKEv2, IPsec, TCP for BRSKI onboarding), but GRASP-DULL discovery! This was my thought a few weeks ago. My answer is to embed the GRASP DULL CBOR inside an LLDP TLV. The only only issue is that each GRASP M_FLOOD message contains a session-id, which I think needs to change upon each M_FLOOD that is sent. It would be better for LLDP, as I understand it, if each message could be identical, unless there is an actual change to the contents. (Annoyingly, "session-id" does not appear in RFC8990 Section 2.7 on Session Identifier) I can't identify an impact of not changing it when the LLDP is retransmitted. [email protected] wrote: > Title: Autonomic Control Plane design for Layer-Two Switched Networks > Document date: 2021-06-15 > Group: Individual Submission > Pages: 6 (it got shorter!) > Html: https://www.ietf.org/archive/id/draft-richardson-anima-l2-friendly-acp-02.html > Abstract: > This document proposes a design for an L2 aware Autonomic Control > Plane that can be deployed easily to layer-two (Ethernet) switched > technologies that are common on Campus/Enterprise network > architectures. > This document leverages the hop-by-hop announcement used in LLDP, but > runs bulk data over normal IPv6 Link-Local unicast ethernet frames. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
