Michael:
The re-posted draft is a good reminder:
To me, the draft touches on a very important and hopefully lucrative topic, but
i think
the text makes it very hard to figure out what's going on.
Let me try to summarize the situation from where i sit:
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.
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.
The one possible gap for low-end hardware is the function:
punt-to-cpu ACP packets from ports that are in STP blocked state.
In my past implementation experience, the punt option that always works is
one where you punt a specific ethertype. 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. We should simply
make
sure that we build selectors into the encap to make it equal or better
extensible
than EAPOL, so that we effectively have an IETF standards controlled equivalent
to EAPOL. There are IMHO a lot of good reasons not to use EAPOL:
- symmetric (ACP) vs. asymmeric (EAPOL use cases)
- control: IETF vs. IEEE
- risk/overhead: demux of such disjoined use-cases deeper into the packet such
as different
EAPOL sub-typing.
Forget using multicast MAC destinations. Maybe i can find the time trying to
remember
all the horrible things that could go wrong with it.
The other option missing that may benefit discussion is to use a different
unicast MAC
for ACP if the HW can punt-to-CPU a separate unicast-MAC. But it foregoes the
big
benefit of the new ethertype option for us to be able to optimize the encap:
aka:
remove the unnecessary overhead of an outer IPv6 encapsulation but simply run
native IPv6/IPsec packets across a new ethertype with maybe some extensibility
selector (as in EAPOL) before the IPv6/IPsec packet.
Cheers
toerless
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
