Rare project developers

[mc36 <>]

hi,

On 3/26/21 12:23 PM, Ronald van der Pol wrote:
> On Fri, Mar 26, 2021 at 11:12:16 +0100, mc36 wrote:
>
> > 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....
>
> To be honest, I lost my interest in INT/iOAM a bit when I
> followed the discussions around MTU/tunnel issues ( INT adds
> bytes to the packet) in the IETF.  The recommendation was to
> use INT only in one domain, e.g. a data centre.
>
> But INT keeps comming back and maybe we should just experiment
> with it and explore the operational issues.

i share your opinion, as we're a router, we already have
rsvp-te, which can work as an underlay for an evpn layer2...
(one can autoroute, static route or pbr to that, it depends...)
but, rsvp-te have that fancy feature that it allocates a
brand new label, which have it's own byte/packet counters,
in every intermediate node.... so if one wants to monitor
a path, it knows the path by at least from the ero object,
at least, and each node have the counters so one can make
the tshooting with these, then tear down the te tunnel...

but heyyyy, int on the other hand is a fancy new shit
that is a calling buzzword for those who don't know mpls.... :)



> > 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? :))
>
> I am a bit confused. There is
> https://bitbucket.software.geant.org/projects/RARE/repos/rare/browse
> and there is your rtr.zip, which also has the Barefoot code
> and seems to be more recent than the bitbucket repository.
> Which code is the RARE project working on?
>
> I see p4bf and p4lang for Barefoot and bmv2, but when you talk
> about the "java sw forwarder", which part of the code are you
> talking about?
>
> Does you code have a repository that I can browse?

so we have https://wiki.geant.org/display/RARE/Home
that is the feature matrix i was talking about, each
line is clickable and gives you the test case that,
if passes, it's a green, if fails, it's a red...

it's a subset of http://www.freertr.net/tests.html
and the links points back to those... in this latter,
they're the p4lang* cases for the rare dataplanes,
each dataplane executed against the same tests,
the only difference is what vm provides the forwarding....
intop1* for cisco xe, intop2* for xe, intop9* for junos.

sources are everywhere, but they're all the same all the time.
rtr.zip is always extracted at http://sources.nop.hu/ and
versioned at https://github.com/mc36/freeRouter
alternatively, i archive and test at http://arc.nop.hu/ ...

bitbucket's p4src and bfrt_python directories are updated
from /misc/p4bf directory, each have the update.sh to do so.

the reason behind it is that one can experiment with the stuff,
then once the release manager starts the update process and
tada, the builder machines work from the updated bitbucket
from that point...
think about it as a staging between the -next and -release.
(i internally do some more tricks and i always use a bit ahead
code when i'm heavily cooking something, more about it at
http://www.freertr.net/releng.html)

regards,
cs