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*
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
