So... how is this supposed to work:
RPL-Root
|
rtr
... ...
rtr1 rtr2 ... rtr10
| | |
---+----+---+---+++++---+----- LAN
|
rtrX
I am on rtrX and wonder, which (subset) of the 10 routers rtr1...rtr10 on the
LAN to build ACP channels to, right ?
Are you telling me i should break confidentiality and export some RPL
parameter from inside the ACP into DULL GRASP so that i would know everybody
but rtr1 suxx and won't give me a direct connection to the root ?
Or else should i randomnly hope that my packets do not have to travel
across the LAN because i connect to rtr10, rtr10 itself decided to connect
to rtr9, ... and all the way to rtr2 connecting to rtr1 ?
Of course this is a pathological setup, e.g.: i think in actual DC
networks withso many paths we just for switches to be ACP enabled as opposed
tohaving big, dumb LANs. AFAIK, all the switches support L3, Any of the
L2 connectivity sounds more like a service to the hosts, not a limit to
the switch hardware.
Cheers
Toerless
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]
