Toerless Eckert <[email protected]> wrote: > draft-ACP section 7. explains how to implement ACP on any low-end > L2-only as well as L2/L3 devices so that the device can operate ACP as > if it was just an L3 device, while in parallel operating unchanged on > some or all ports as an L2 switch with STB: ACP packets are software > routed and software IPsec en/decrypted.
} Predictable scaling requirements for ACP neighbors can most easily be
} achieved if in topologies such as these, ACP capable L2 switches can
} ensure that discovery messages terminate on them so that neighboring
} ACP routers and switches will only find the physically connected ACP
} L2 switches as their candidate ACP neighbors.
So, your solution is to have L2 switches not forward based upon L3 multicast
addresses. While this is deterministically mapped to a unique L2 multicast MAC,
and maybe this can work... but, as you say below, that's not primarily how
the punt has worked in the past.
> The magic to this is also explained, its simply to per-port-punt DULL
> GRASP packets and later encapsulated ACP packets to CPU as it is done
> today for STP, CDP, LLDP, EAPOL packets. The rest is then standard ACP
> implementation as on any L3 ACP device.
okay.
My only request is that we avoid adding a new thing to the list of per-port
things, because they take up ASIC / NPU space.
> In my past implementation experience, the punt option that always works
> is one where you punt a specific ethertype.
Great, so one of the options I proposed is to have a new ethertype for
IPv6-DULL messages, as you also say below.
> This is so because all the
> L2 switch hardware was designed based on supporting 802.1x, and that is
> where LLDP and EAPOL came into play and the minimum HW selector to
> decide between punt/forward/block was simply ethertype.
> Aka: The most simple extension we would need to drastically improve the
> ability for ACP to get into lucrativee markets is to define an ACP
> encap using its own ethertype. That is primarily an issue with finding
> i think 2000 USD and arguing with ethertype registry owner about the
> long term value of that ethertype.
I think that the IEEE/IETF liason can get us an ethertype, given an
appropriate STD track draft.
Tell me if that you think this is within the ANIMA WG's charter.
> Forget using multicast MAC destinations. Maybe i can find the time
> trying to remember all the horrible things that could go wrong with it.
okay.
--
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
