RARE user and assistance email list

["mc36" <>]

hi,

addint cristina and everson because of the polka questions... :)

On 3/4/22 15:28, Moises R. N. Ribeiro wrote:
> Csaba,
>
> Many thanks for your detailed response to my vague questions. A lot of insights for us 
> better understand things "under the hood". ;-)
>
> So, as far as I could understand, the "deepest dig" Freerouter does would be Layer 2 regular 
> protocol via its proper socket implementations, neither raw sockets nor hook trickeries. By 
> "privileged processes" you simply mean "routing/flow/rule tables" that are exported by 
> Freerouter (which is at user/application layer) either to OvS (kernel-level), ASIC (SDK), DPDK (SDK 
> developing kit bypassing kernel), XDP(kernel-level), or whatever comes in the future.
exactly, with the addition that in the beginning when there were no dataplanes, the 
"sudo socat iface:eth0 udp:127.0.0.1:12345" was used to pass packets... :)
today we have the dataplanes and a faster interface to udp implementation, 
but the concept remained, yeahhhh.....

> I am going insist on specif points, though:
>
> -1) Freerouter PolKa needs to be translated into tables at Tofinos when Freerouter is used, right? Provided that 
> Cristina/Rafael already did the implementation of P4 code to skip tables, could (in the future) PolKA be a 
> "dataplane"...I mean: yet another "routing/forward engine" with a simple "set primitives for 
> dataplanes" which Freerouter use to "translate" protocols? I know..."PolKa engine" would need 
> coordination of polynomial IDs to be used while a table are as free as a bird...but for tunnels and alike, it might be 
> possible, provided that there is benefits to motivate it. From your message, I see one: you mentioned of limited flow table 
> (kernel level) of OvS. Scalability of Freerouter, in terms of number of flows, could be limited by this features when 
> forwarding performance is a issue (i.e., there will be flows going to use-level tables).

yeahh but that requires a controller... right now, in freerouter, both polka 
and mpolka implementation uses a single table,
which is filled up with the neighboring router indexes... the segment routing 
ids are reused here so for now polka operates
over an isis, ospf or bgp core flawlessly... cristina called it once 
distributed polka... :)
for now, all the dataplanes have an implementation of it, including the dpdk 
and the tofino one,
and the features are well covered by dataplane tests:
curl www.freertr.net/tests.html | egrep ".*p4lang.*polka.*"
these swapn up a tofino emulator (a dpdk node) surrounded by freerouters, 
builds a polka tunnel and pass some traffic,
finally verifies the counters on the controlling freerouter if everything 
happened in the dataplane...

> 0) How does Freerouter (current implementation) behave considering 
> virtualizer/hypervisors underneath, any trouble ahead for OvS/XDP/DPDK?
from freerouters point of view, it's completely uninteresting if you're using 
it in a vm or not, but...
it's hard to fine-tune for dpdk in a vm because of the cpu pinning and 
sharing issues,
nor the nics are native, and sriov is not an easy topic imho,
and most linux bridge based hipervisors do dirty trick to packets:
they reassemble consecutive segments, does not update the chesksums and so 
on...
but again, theoretically speaking, it's doable, but not an easy-peasy 
thingy... :)

> 1) How does Freerouter behave working along namespaces? Do you have highlight 
> point here?
if not in a vm, but in a bare metal then basically no difference since 
freerouter really does not depend on linux networking :)


> 2) Is there any "formal proof" that the "protocols that are emulated at user layer" by Freerouter could be entirely translated/maped onto the forwarding/routing schemes for the data plane technology? 
no (formal) proof on anything except the dataplane tests... :)

> Or it goes by the path of Ethernet where    Seems Ethernet does not work in theory, only in 
> practice.    :-) It is clear to me that whatever is not "data plane forwarding/routing" 
> is performed at user-level, and that match-action could be more general technique than LPM, 
> mask-match and other regular lookups, and so could "emulate" them. I'm just 
> wondering...if there is an opportunity for a paper to provide a formal proof for that. There is a 
> colleague who is very good at that: http://nigam.info/index.html
imho yess...
but one thing to note, in case of dataplanes involved, they're not using 
software forwarding at all...
everything is precomputed, including the tunnel encapsulations (which are 
kind of nexthops here), etc...
and a huuure policer, some packets per sec is allowed up from the exception 
packets only....
so having the dataplane tests all include a final flood, expecting a 100% 
result of 11111 packets,
and after that, the tests check the controlling freerouter software counters, 
i'm pretty sure that
what is covered that works in hardware...



> 3) In your opinion, is it fair to put in the same league to compete: 
> Freerouter/RARE vs. Sonic vs. Stratum?

no, because they're datacenter switches wehreas we're a router...
and they use frr under the hood which lacking real isis,
their mpls support is dying, their bgp lacks interops in
several aspects compared to junos and cisco... all these
are also tested regularly:
curl www.freertr.net/tests.html | grep interop"
intop1 is cisco xe,
intop2 is cisco xr,
intop9 is junos,
intop8 is frr,
and when it comes to frr, from release to release, i usually have to comment 
out a test or two...
and i heavily peer at dn42 which is a bgp overlay with about 500 ases, and if 
you want to hear
more horror stories why they discourage frr, just ask them... :)
but don't misunderstand me, frr is a nice try for a host stack... but 
networking is not about
hosts, but about real routers... for example take a look how vrfs are 
implemented in linux,
and how could frr interact a bgp neighbor in a vrf... so it's clearly a 
limitation for them
that they rely on the linux stack when it comes things like this...

regards,
cs
> Regards,
> Moises
> PS. The links you've had shared are not accessible to me at the moment.
>
> ----- Mensagem original -----
> De: "cs" <>
> Para: "Moises Renato Nunes Ribeiro" <>
> Cc: "Everson Borges" <>, "edgardcunha" <>, "Magnos 
> Martinello" <>, "rafaelsg" <>, 
> Enviadas: Ter  a-feira, 1 de mar  o de 2022 3:22:28
> Assunto: Re: Freerouter 101
>
> hi,
> good catches, let me explain a bit on these concepts...
> freerouter is a control plane, afterall... it contains it's own tcp/ip stack 
> and all the routing protocols sitting on top of it...
> it is needed to handle and be able to participate at arbitrary level of iso 
> architecture: if one interface is configured to
> layer2 cross-connect, then that, if an other have a tunnel on top of it, and 
> within that tunnel it's a different vrf then that...
> all the encapsulations and routing decisions will happen within freerouter, 
> and if there is no dataplane involved, then it can
> also forward packets in between these interfaces...
> since these are happening over a udp socket, the physical interface and the 
> freerouter deciding what to send to it can sit several hops away...
> (i develop the dataplane vms running remotely, here we had a chat about it: 
> https://lists.geant.org/sympa/arc/rare-users/2022-02/msg00076.html )
> in case of ovs, freerouter just exports the computed routing tables and there 
> is a packet-in/packet-out openflow message to handle
> the exception packets and let freerouter handle them properly... these are 
> the interface's own ips/32, mostly...
> but be warned, ovs in-kernel flow table is very small, everything that falls 
> from that very tight table will be handled in
> ovs user space processes... it means a kernel-user-kernel switching in 
> real-life traffic... very easy to trigger it by starting
> some well-feeded torrents, executing nmap 10.0.0.0/8, and friends...! :)
> then there we have the tofino asic, where we also export the (routing) 
> tables, and the asic routes the packets too, but there is
> no such thing like route-cache nor flow table, it does real lpm, mask-match, 
> or exact-match lookups on the pre-programmed tables...
> in this case we have N frontpanel ports and an N+1 port from the asic's point 
> of view, where freerouter sits... we named it
> cpuport, where the asic can pass the exception packets to freerouter... the 
> frames here are prepended with a 16bit word to
> name the frontpanel port where to/from the packet should go to/came from... 
> this is the point where freerouter's built-in tcp/ip
> stack started paying off: we were able to handle the situation very easily: 
> it was just a some lines of code that multiplexes these
> frames to sdn interfaces in freerouter, then we can do whatever we want on 
> these sdn interfaces in freerouter: do bgp, isis, ospf, whatever!
> then we got the dpdk and xdp dataplanes, which are there to show that this 
> concept, the cpuport and the messages how freerouter instructs
> the dataplanes to add/del/mod in a table works and could do basically 
> anything... these dataplanes mimic the asic behavior so they have
> similar tables and perform almost the same that the p4 code for the asic...
> so from user's point of view, there is no difference if the dataplane is 
> dpdk, asic or ovs, the freerouter configuration,
> look and feel is the same, they're fully interchangeable, and the expected 
> outcome is the same...
> we just had a nice chat how the dataplane test cases utilize this property:
> https://lists.geant.org/sympa/arc/rare-dev/2022-02/msg00129.html
> in the middle of the mail i give a detailed view about the concept...
> regards,
> cs
>
>
>
>
> On 2/28/22 23:42, Moises R. N. Ribeiro wrote:
> > Csaba, (Evenson, Edgard, Rafael Magnos)
> >
> > Freerouter 101: staring with a non-linear reading of the front page...please, 
> > if you have the time, correct my speculations below:
> >
> > Assuming that Freerouter:
> >
> > i)   "receives and sends packets through udp sockets", it should not be a 
> > problem to sit it on top of an OS where OvS does all the SDN trickery we like;
> > ii) by being "independent of underlying* OS capabilities" that might suggest 
> > that virtualization platforms (understood as virtualizers and hypervisors) be used 
> > regardless and
> > wildly; and
> > iii) "internet can be used as backplane for router processes" we could think of 
> > Freerouter as destined from birth to serve and suit our "overlay" approach submitted to 
> > GEANT
> > innovation...and further still from a disaggregation perspective, where virtual network 
> > functions (VNFs) can be "freely" placed out and about and chained to compose 
> > a Freerouter
> > instances with this or that functionality...or microservices fragmented and 
> > replicated at will.
> >
> > all that sounds like "heavens on earth", and I expect you to duly confirm my 
> > "wishful reading" of your statements... but here comes the catch, I mean, the question:
> >
> > "External, privileged processes that place traffic to these udp sockets"... It feels 
> > like... and smells like... "hooks-socks and alikes" here. And the mechanism/architecture
> > designed to "export forwarding tables to xdp, dpdk or hardware switches via 
> > openflow or p4lang" is the key to unlock eventual incompatibilities of OS with 
> > specific hook
> > primitives/functionalities...in other words: "Divide to conquer": each "data plane" has 
> > its own "privileged processes" to skip differences (in kernel, firmware, and even
> > "telepathy" mismatches :-) etc.) and keep Freerouter agnostic on top... 
> > ruling unchallenged just like King Matja   does on his 1000 Forint bill?
> >
> > Regards,
> > Moises


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#242): https://groups.io/g/freertr/message/242
Mute This Topic: https://groups.io/mt/89470723/6413194
Group Owner: 
Unsubscribe: https://groups.io/g/freertr/unsub []
-=-=-=-=-=-=-=-=-=-=-=-