Rare project developers

["Moises R. N. Ribeiro" <>]

Csaba,

Thanks for sharing the updates. Bear in mind that much of our comments are 
guess work into the complexity of protocols/architectures/implementations we 
have only superficial knowledge/experience. Please don't take them by their 
"face value" in order to change your mind/project. Feel free to press the 
"ignore" key :-)      

So, let me see if I manage to get it: the "stacking server" would be the 
central/controler for configuration purposes, which is the element in charge 
of distributing individual configurations across/along the segregated 
elements bound together by backplane ports. Packets will flow on those 
backplane ports using mpls for intra-domain and vpns links for inter-domain, 
and thus routed by igp and bpg, respectively. Kind of textbook networking 
approach for backplane networking (but underneath exploiting data plane 
aceleration/advances/controlability P4/OvS). Protocol innovation in this 
initial prototype, only on regular network ports, right?    

Changing a bit the subject, I've been thinking of the "emulation" 
use/functionality of freeRtr and how it is related to the disaggregated 
approach that you now propose. 

1) In that arena, how could we compete with Mininet, for instance, and use 
tools (like linux tc-netem) on localhost (ports)links for more realistic 
interconnections?  
http://docs.freertr.org/guides/getting-started/002-topology-example/
  

2) Is there a particular way of thinking about "all-in-one" architecture 
(centralized configuration etc) for emulation that would later facilitate 
deployment toward a "multi-node" testbed, so that "portability" could be 
improved toward a seamless? At the moment, although simple, it is not that 
seamless the transition shown here: 
http://docs.freertr.org/guides/getting-started/003-unleash/


3) Finally, still in that digression, how could we think of freeRtr as a 
"emulation engine" linked to the physical nodes to mimic the real network (in 
near real time...or even ahead of time...) and be used behind a "digital 
twin" model?  
https://dl.acm.org/doi/pdf/10.1145/3472727.3472802

Regards,
Moises

 
----- Mensagem original -----
De: "cs" <>
Para: "Moises Renato Nunes Ribeiro" <>
Cc: "edgardcunha" <>, "Everson Borges" 
<>, "gabrieltetznermenegueti16" 
<>, "rare-dev" <>
Enviadas: Terça-feira, 10 de maio de 2022 14:53:04
Assunto: Re: brainstorming about stacking in rare/freertr

hi,
i was further thinking about my previous idea about stacking/backplane 
capability, and i already spotted some missing parts...
most importantly, multicast would be completely broken if we followed that 
slim {swid;brid;vrfid;}... moreover the lack of
diversity, as you already mentioned polka as the protocol... and, as per 
original plan, one had to run an igp... so for now,
i stepped back and here is the current idea, a generalized freerouter 
stacking methodology:
- one will configure the backplane ports on the individual switches with mpls 
and an igp...
- one will configure the bgp with the proper afis: vpnv4, vpnv6 and evpn...
- and there will be a new server called stacking...
and this is where the magic will happen:
so under the stacking server, one will export various parts of the freerouter 
configuration, for now, let's talk about ports...
these parts will be locked on the executing switch, but the config changes 
will happen on a remote freerouter running the
counterpart of the stacking server... all the config changes done on the 
controller, will be propagated to the target router...
in this way, we even can add an openvswitch based box to the fabric, not just 
the p4lang based ones...
much like cisco probably do in their aci stuff, which is basically a 
super-nxos seeing all the leafs' configs in one place...
any idea?
br,
cs


On 5/6/22 01:27, Moises R. N. Ribeiro wrote:
[..]