Rare project developers

[mc36 <>]

hi,

On 5/11/22 23:48, Moises R. N. Ribeiro wrote:
> 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?
exactly, the dataplanes wont be touched at all for being stacking capable...
it's all freerouter magic...

> 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/
so freerouter does not need mininet to run multiple instances on a single 
machine...
one can express a cross connect by pointing the udp socket of two freerouter 
to each other,
much like as done in the link above... if one wants to add anything in 
between the two,
the easiest way is creating a veth pair, one side to a freerouter, and the 
other side
to the stuff to be added... anyway, freerouter also have such tools built in 
to be able
to shake out stuff during self-testing...

> 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/
well so these documents describe the internals on how to set up freerouter by 
hand...
i consider them useful because reading them will give you some insight of how 
the it works...
if one wants a seamless experience, one just have to follow the one-line 
installer from freertr.org...

> 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
so this is already there by simply combining the fact that freerouter alone 
is not too resource hungry,
and you can arbitrarily cross connect two freerouters by simply pointing them 
to each other in their -hw config...
so for example the whole geant p4 testbed could be started and run on a 
single pc with the configs from the lab
config archive... one just have to write a test case describing the 
interconnections between the nodes and then
everyone can start their own testbed locally... i've already sent the test 
case for the testbed on the list,
and some of the cc-ed participants in an other thread... anyway, geant 
testbed is not an exception, if one
runs an all-freerouter network, then it's easy-peasy to have some digital 
twins of the infra...

br,
cs



> 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:
> [..]