Rare project developers

[mc36 <>]

hi,

On 3/26/21 10:42 AM, Ronald van der Pol wrote:
> 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?

feel free to do so... but be warned, it's jira, and a methodology behind 
it... :)
i created the tasks with story level not accidentally..... :)

> > 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.

not bad... i'm also on the opinion that int headers are better before
the udp/tcp/gre/whatever simply because if they're not, then it fucks up
the parser logic, so int cannot coexist with anything else involving layer4
stuff like nat, l2tp, mpls in gre, etc... but again, we should see what
nexus9k does and align to them.... not we're the internet at the moment,
nor barefoot who seemingly pushes that after-layer4 approach....

one thing, in rare/freertr, there is no global, everything is in a vrf...
that is, an additional exact vrf match would be needed, much like as
we already do with nat/pbr/acl/whatever.....


> > 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.

the answer is within the question. we have a control
plane that programs you the desired evpn rules already,
describes the macs learnt from the lan ports, advertises
them toward the rest of the dc, etc...
we already cover these with interops and dataplane tests...

int is just a small addition to that, but need to be
mastered, and need to be interwork...

programming tofino is not that hard at all when you
know what you would do etc, etc... i basically copy-paste
the bmv2 code and surround with if-defs to fit the asic
with the rest of the features... but that's the last stage
i described yesterday....

and again, before reaching that point, the rest of the
stuff need to be mastered otherwise you wont be able to
easily rule out things... once you have the java sw forwarder
covered with an interop, which is the harder part obviously,
then having the dpdk c code is about 50 lines of code for
int.... then you can write the dataplane test cases...
after that, you can start playing with bmv2 or tofino,
and when you feel you're ready, just start the dataplane
tests and it'll tell you the truth... and if that passes,
then a green mask automatically appears on the project wiki.
sure thing, you can start playing with p4 from the start
but then what will be in the test case that generates the
green mark? and what will that green mark garantee?

and finally, no rush on it at all, it's a thing that
we need to study if we want to come up with something
that can be a drop-in replacement to an existing aci/apic
installation at any point... again, the rest is there already,
why int would be the exception? :))

regards,
cs