Rare project developers

[Ronald van der Pol <>]

On Thu, Mar 25, 2021 at 18:53:50 +0100, mc36 wrote:

> hi,
> 
> excellent news, thanks!
> if you have that code somewhere in public, i would
> appreciate if i can take a look at it, or even better,
> if you can pick up a task here that would be excellent...

Do you mean: create a subtask for RARE-53?

> here is my initial idea on the tasks need to be done:
> 
> we pick up one, (i personally +1 to int, as that
> i have access to in our lab on some n9ks to interwork
> test with...:)

My code is INT and I add the INT info to a IPv6 hop-by-hop
extension header. On ingress (int_role == source) I
encapsulate the original packet with an IPv6 header
plus extension header. An ACL determines for which
packets this (INT info recording) is done. The nodes
in between have int_role == transit. The egress node
has int_role == sink. The ACL and int_role are set
via the control plane.

BTW, I started with the shim header on top of TCP/UDP.
But this needed a magic bitstring to identify the
shim header. I found this ugly. Another option is
to stick the INT info in TCP options. But this
probably does not make it through middle boxes.

> then we'll study how and what they do compared to
> the drafts, then we must come up with a software
> only implementation, to have something that i can
> sometimes interop test against to n9ks, and then
> regularly interop test that sw fotwarder for the
> dataplane vms (bmv2, tofino, dpdk/libpcap), and
> have that fancy matrix on the project page a
> meaningful green mark...:)
> 
> when the sw forwarder is done, we should proceed
> with the p4emu for dpdk/libpcap (c code) simply
> because that is i can easily experiment on my
> homenet (10+ nodes, not a big deal if i down
> some:), to see the possible bottleneck of the
> design and fine-tune the export/import between
> the dataplane/control-plane and don't have to
> deal with the middleware (bffwd)....
> 
> after that stage, we could proceed to bmv2
> to have something in p4 finally, but it's
> still a warmup stage for the tofino p4 code...
> as everything is already in a known good state,
> and have test cases covered and executed regularly,
> at least on the p4emu codebase-controlplane, we can
> rule out everything and we can concentrate only on
> the p4 parts....

Why not start with the most restricted dataplane?
I remember that it took quite some effort to make
the Tofino compiler happy.

    rvdp