Rare project developers

[Frédéric LOUI <>]

Hi mc36,

Stacking would be awesome ! 

I was also thinking about similar thing but more « generic ».

Let me explain: stacking would mean grouping several hardware/entity that has 
strict similar hardware.

The further we are moving forward especially with TOFINO the further I was 
thinking about a way to extend capability with additional more capable 
hardware
RARE/freeRtr with DPDK for instance

Just few random idea off the top of my head WRT to generic stacking:
1- possibility to « stack »  different hardware. i.e stack TOFINO with P4DPDK 
RARE/freeRtr switches
2- stack link could be a non uniform link bundle
3- if -1- is possible how to make sure that capability list is advertised ?
4- The generic stack can have a daisy chain design so that split brain 
situation can be avoided
5- Would the CPU header would have an additional field ? (chassis_id) if one 
switch is not using multi chassis:  chassis_id=0 ?
    Or have_backplane flag would have a broader meaning ?

The idea behind this generic stacking is to have a framework so that a switch 
can offload processing that is not possible at its (TOFINO) level 
(encryption, cos, hqos)

I also like the « new kind of nexthop », this reminds me the QFX which boast 
of tremendous amount of port. Basically the switch behaved as a entire BGP 
domain.
The Routing engine card being the BGP RR for each line cards.

Feel free to ignore my comments if you were mentioning strict stacking.

Exciting new idea though !

Cheers
Frederic

> Le 3 mai 2022 à 09:09, mc36 <> a écrit :
> 
> hi,
> 
> during the migration to sde990 we started using the port metadata to silent 
> a warning about casting portid to subifid...
> this seems to open up some more possibilities, especially i'm now thinking 
> about introducing a new have_backplane flag... :)
> the idea here is to one would be able to configure a set of switches to 
> form a cluster at their control and data planes
> much like in cisco aci or their stackwise stuff... here are the some 
> details i'm thinking about right now:
> - on the (on the fly configurable!) backplane ports, we'll use a small 
> prepended backplane header much like on the cpu-port,
>  but here with the extra field about the target memberid... this way the 
> solution will handle well the line-card or
>  multi-chassis modes of operation, because the backplane packets become 
> routeable based on the memberid alone...
> - all the member switches will have configured with an uniform server 
> p4lang configuration exclusively dealing with
>  the backplane port(s) properties and nothing else... under the hood, 
> they'll run a discovery and relay the for-us
>  packets toward the elected controller, and relay the rest of the 
> freertr-middleware communication too...
> - there would be (pair of) a dedicated servers, also configured as part of 
> the backplane to be able to be elected,
>  who will take control over the whole topology, and act as a single point 
> of configuration...
> - think about running a p4emu or p4dpdk instance, and a p4lang to control 
> that, but with something more
> - all the member switches will have a server p4 sw1..swX instances where 
> you export your ports vrfs and bridges,
>  but the trick here would be that these vrf and bridge instances can span 
> multiple switches without any extra
>  configuration needed...
> - this could be achieved in the dataplanes by having a new kind of nexthop 
> which will prepend the backplane header,
>  filling in the target member and the remote nexthopid...
> - do in this way, we would be able to express even much tricker things 
> like, at sw1, i express a member/nexthop pointing
>  to a dpdk3 node where the nexthop involves some crypto and transmit to a 
> nexthop who's also a backplane kind, with member
>  to sw5 and nexthop to a local port...
> 
> any idea?
> thanks,
> cs