On Thu, Feb 11, 2021 at 05:40:25PM -0500, Michael Richardson wrote:
>
> 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.
I can not parse this. Can you rephrase ?
> While this is deterministically mapped to a unique L2 multicast MAC,
What is "this" ? Sorry.... can not parse again.
> 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.
Right.
> > 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.
My point was that its not only about the discovery packets. We also want to make
sure that the ACP secure channel packets could also go across blocked ports.
> > 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.
Different encap to make ANI more resilient. Sounds to me like perfectly in
scope of
BRSKI/ACP extensions charter point.
I just think we shouldn't rush this but think it through well:
First of all, relying on a separate MAC address for ACP is the most eay way out.
But its not clear to me if thi works on every hardware. On the other hand, i can
see how i would always have a separate MAC address for ACP if for example i
have classic
PC hardware and implement ACP on the BMC (e.g.: as extension to OpenBMC). But
many switches/routers also have a MAC address pool they can use.
Might make sense to just document that option (can't remember if i mentioned
this
in ACPdraft). But nothing else to do.
When it comes to encapsulating across new ethertype, we need to make it
extensible,
thats IEEE requirement for such a scarce resource. So we might even want to
ask around IETF for similar use-cases to have candidate other values for a
selector field for example.
Need to read through EAP over Ethernet to check what we could share. I forgot
all about it.
But ultimatly, its going to be a small "selector-header" on top of the new
ethertype
that we need to define.
I can see at least two selectors: ACP-secure-channel and Discovery (DULL-GRASP).
I have not thought about use-cases for e.g.: just BRSKI without ACP.
If you read up on the public slides i did eternities ago for my prior employer
about that vendors
(somewhat proprietary) ACP implementation in the context of service provide
ethernet services,
where a customer L2-ethernet service is multiplexed across a service provider
L2VPN service, then those
type of service-edge nodes have all type of pain for discovery protocols such
as CDP/LLDP,
e.g.: for their own instance and for the customer instance. So LLDP has
explicit provisions
for this, and i have to find time to swap in the context of that stuff again.
Much easier
if we had in-person IETFs and someone in the know like Norm Finn could remind
me ;-))
As in: lets make sure that our selector field header could support the same
flexibility
for those use-cases. At least to the extent that we know for a rev0 spec how
many
"reserved/ignore" bits we need and then fill them in later.
Cheers
Toerless
> > 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
>
>
>
>
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
