On the topic of
"i have a switched LAN and my switch is ACP capable"
That solution should be easily solvable if the switch can use a solution
where it can simply act as a router for the purpose of ACP - while
continuing to act as an L2 switch for the data plane.
With Michaels ACP implementation approach of allocating for ACP (in linux)
a separate MAC-address interface this is simple. Of course this is
still software forwarding of the ACP traffic then. This would not be
my preferred long-term high-performance model for a DC of course,
but i think the original problem for the DC is simply that there
likely is no Broadcom switch that does IPsec. So for such an ACP
one would hope that DC switches can do MacSEC.
Alas, last time (long time go) i looked into MacSEC NICs, you
could at best only do MacSEC on a per-VLAN basis - or for the
whole interface. Not per-MAC address. But that may not be todays
state of affairs.
Too bad that still none of the low-end L2 switch ASIC / NIC like those found
on eay-to-experiment-on OpenWRT routers do seem to have MacSEC...
Cheers
toerle
There is also the argument, that
On Fri, Jul 19, 2024 at 10:25:12PM -0700, Michael Richardson wrote:
>
> Brian E Carpenter <[email protected]> wrote:
> > unfortunately. A couple of comments below (nothing private if you want
> > to forward them.)
>
> .... first, Brian notes how my diagrams seemed to be Penrose
> (space-time/blackhole) diagrams.. and it's because ACPs are used to wormhole
> around network failures :-)
>
> > Slide 33:
>
> > "GRASP DULL needs to offer priority so ACP daemons can pick 2-3 links,
> > and avoid all piling on top of a single DODAG parent"
>
> > That's almost foreseen in RFC 8994 with method-param:
>
> > objective-value = method-name / [ method, *extension ] method =
> > method-name / [ method-name, *method-param ] method-name = "IKEv2" /
> > "DTLS" / id extension = any method-param = any
>
> Yes... we certainly can use that, but we'll have to decide exactly what to
> put into it. RFC9032 and draft-ietf-roll-enrollment-priority describes a
> similiar problem.
>
> On a dense "LAN", like a cabinet full of servers where the Top-of-Rack switch
> is not ACP-aware, what we don't want is a full mesh. It's excessive and
> wasteful. Especially as some DCs do L2 bridging between cabinets using all
> sorts of TE/BGP. What we want, I think, is a tree structure with a fan-out
> of between 3 and 5 connections.
>
> If the ToR switch can be involved, then it can treat all the cables as p2p
> ones for the purpose of ACP. This turns the fully connected "wheel" into a
> star shape. This is also a reason to prefer the L2 methods of discovery,
> like the LLDP things I've talked about in the past: ones that do not spread
> past the current cabinet.
> I don't know a huge amount about ToR switches from the last ten years. I
> wonder if there is a way to offload the ACP communications to another
> device. Perhaps with a mirror port that receives only GRASP multicast (and
> normal unicast)
>
> --
> Michael Richardson <[email protected]>, Sandelman Software Works
> -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
>
>
>
> _______________________________________________
> Anima mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
--
---
[email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
