[Anima] spreading the load out in ACP/RFC8994

[Michael Richardson <[e-mail]>]

Brian E Carpenter <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*