Subject: Rare project developers
List archive
- From: mc36 <>
- To: "" <>
- Subject: [rare-dev] brainstorming about stacking in rare/freertr
- Date: Tue, 3 May 2022 09:09:44 +0200
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
- [rare-dev] brainstorming about stacking in rare/freertr, mc36, 05/03/2022
- Re: [rare-dev] brainstorming about stacking in rare/freertr, Frédéric LOUI, 05/03/2022
- Re: [rare-dev] brainstorming about stacking in rare/freertr, mc36, 05/03/2022
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Re: [rare-dev] brainstorming about stacking in rare/freertr, mc36, 05/04/2022
- Re: [rare-dev] brainstorming about stacking in rare/freertr, Moises R. N. Ribeiro, 05/05/2022
- Re: [rare-dev] brainstorming about stacking in rare/freertr, mc36, 05/05/2022
- Re: [rare-dev] brainstorming about stacking in rare/freertr, Moises R. N. Ribeiro, 05/05/2022
- Re: [rare-dev] brainstorming about stacking in rare/freertr, mc36, 05/10/2022
- Re: [rare-dev] brainstorming about stacking in rare/freertr, Moises R. N. Ribeiro, 05/11/2022
- Re: [rare-dev] brainstorming about stacking in rare/freertr, mc36, 05/11/2022
- Re: [rare-dev] brainstorming about stacking in rare/freertr, mc36, 05/12/2022
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Re: [rare-dev] brainstorming about stacking in rare/freertr, Frédéric LOUI, 05/03/2022
Archive powered by MHonArc 2.6.19.