Skip to Content.
Sympa Menu

rare-dev - Re: [rare-dev] [gn4-3-wp6-t1-wb-RARE] RARE/freeRtr Polka integration progress

Subject: Rare project developers

List archive

Re: [rare-dev] [gn4-3-wp6-t1-wb-RARE] RARE/freeRtr Polka integration progress


Chronological Thread 
    < Chronological >      < Thread >
  • From: mc36 <>
  • To: Rafael S. Guimarães <>
  • Cc: "Rafael S. Guimaraes" <>, , Cristina Klippel Dominicini <>
  • Subject: Re: [rare-dev] [gn4-3-wp6-t1-wb-RARE] RARE/freeRtr Polka integration progress
  • Date: Wed, 7 Apr 2021 18:44:43 +0200
hi,

On 4/7/21 4:30 PM, Rafael S. Guimarães wrote:
[..]


Sure, a meeting would be amazing. We appreciate a lot your help in this way, and, of course, to ease us in understanding the whole Freertr code. Further, we can know how we effectively contribute (git and tests) to the Freertr. I will do my best to move our effort forward in developing the Java part :).

you're welcomed on the board! :)

So, what do you think to have a meeting next week?

so, as usual, surely, hell yeahh.... :)


What time/day would be better for you?


imho anytime, as usual, please pick a date, but please allow me to cancel
some hours before....
(i have a lot to sleep these days...:()

I don't know your timezone, but from my side is UTC -3  (Brazil/Sao Paulo
time).


i'm in +0100 or, i donno if we left summer/winter time yet, it's CET/CEST

mc36@noti:~$ cat /etc/timezone
Europe/Budapest
mc36@noti:~$





>  that your stuff will be configurable like an srte tunnel, but with a
different layer2.5.... am i wrong on that?

Yes, indeed, the original PolKA header is between ethernet and IPv[46] headers. But, we can think together if you want/suggest other ways to integrate it, aiming the protocol evolution in a fancy and production way.

hmmm, at the moment, i just briefly read dominicini2020.pdf , from that, my
idea was that it's a layer2 source routing....
but i'm far from suggesting other use cases than that... but..... if we move
forward, and, your forwarder will integrate
to freertr java stuff then, for example, you'll have autoroute through the
tunnel interface of yours... we'll have nothing
to do for that, it's automatic graft being part of the java stuff... and it
inherits to the p4 part too, if we proceed to
servP4lang after we got the qc-passed vignette from the board :)



BTW, Frederic and Jordi are already organizing my access to the repository. I
am in touch with them via Slack.


i'm much more interested in signal these days... you can find my reachability
at mc36.nop.hu
but some things to note...
1) if signal does not connect immediately, try again later, that's just the best-effort
delivery "effect" (khm) of the net :)
2) i just not yet started moving to lineage 18.1 on my cell where i mostly
run signal, so that's why
i would go for a quick chat about 2 weeks later...

until that, please think about how would you handle the following situation.
you'll have to come up with a function

public boolean gotPolka(packHolder pck) {
///parse your header here, log every error using logger.error("wtf"); , we'll
assign proper levels later... :)
//as i saw you can have different bit sizes in the header, imho it's the same
as bier's 256 and 4k mode?
//when you need to know a bit's route, you can stick yourself to ipFwd's
actualU. each one resolves to
//a tabRouteEntry, where, you'll find your bit in, then you'll have to pick
the best and use that attrib's
//segrouIdx.. to have the header bit size, you can use segrouSiz field from
the same attrib class...
//you may need some additional fields, feel free to look around in the above
mentioned tabRouteAttr class..
//if you think about this way, polka will be a drop-in replacement for
mpls-sr, seamless mpls-sr and so on...
}


thanks,
cs




Best regards,
Rafael



On 4/2/21 9:32 PM, Rafael S. Guimaraes wrote:
> Hi @Csaba,
>
> Sorry for my late reply. I was struggling this week with some tasks
running in parallel.
np, i also took an offline weekend :)

>
>  > if you would 'handle over' (abandon) the current work as is, then
go with a single pull-req... we'll move forward as sde95 appears soon, in that
case, we'll who will
ensure that
> it compiles and passes the tests in the future...
>
> I have created a new branch (polka) after cloning the RARE
bitbucket repo, and I am working on this branch locally.
>
>  > alternatively if you plan to support polka in long run
@RARE/FreeRTR, then we can
> arrange you rw access to the main repos after the initial pull-req &
merge then
> both of us will patch the stuff: as freertr internal apis evolve then
i'll easily
> move forward and update your forwarder parts also, then update the api
messages
> and the dpdk & p4 code if needed... and if you change your mind then
you'll also
> be able to change these parts....
>
> For me, it is a good alternative! From my perspective, once we have some way to
fork and submit a pull request, we can be more "relaxed" to work because you
will be
> verifying/analyzing the code before merging and making sure that my
pull requests are not breaking/messing the code.

feel free to work on that, frederic will arrange you an rw access.
from my side, that repo is just a write-only backup of sources.nop.hu/misc/p4bf
<http://sources.nop.hu/misc/p4bf>
that is, once you run the upgrade scripts then your change will be
overwritten....
so, once you did your tests, please notify me, i'll check the diffs,
verify them,
and if i cannot spot a thing, i'll update my /misc/ directory with your
new sources....
is this constrain acceptable for you?


>
>  > so if i understand you correctly, you already have something that
works!  at least, in p4... and if i understand you correctly, you already have
some bfforwarder.py
messages
> that program the dataplanes... on top of these, it's hard to write a
self test imho, we'll need the pure java version implementing the forwarding...
to have something that
can be
> tested against itself, and then to test the dataplane vms against
that...
>
> Yes, you are correct!  Do you think we can do it by steps, for
example, commit the P4 and bf_forwarder.py (data- and control-planes), which we
already have done, and after
> developing and pushing the commit of the Java part (user interface) we
think about end-to-end tests?
>

please move forward with the java part, please, please! :)
i mean just the core forwarding and let me do the rest...
if you have spare time, we could have a meeting and i'll tell you the
dirty details to ease your work....
from that point, once you coded the very core of your idea, then let me
do the rest for you....
that is, the surrounding user interface, tests, everything!
my idea is that your stuff will be configurable like an srte tunnel, but
with a different layer2.5.... am i wrong on that? :)


>  > if you could point me to your repo, then I can have some more idea
on how to proceed...
>
> I have created a gist code for that. I was not sure and a bit
concerned whether I am allowed or not to clone and put your RARE repo in our
Github repository. That's why I
decided
> to keep all the changes locally in my cloned repo.
>
> https://gist.github.com/rafaelsilvag/727507e96849af3de7ad10082c7d7f86
<https://gist.github.com/rafaelsilvag/727507e96849af3de7ad10082c7d7f86>
<https://gist.github.com/rafaelsilvag/727507e96849af3de7ad10082c7d7f86
<https://gist.github.com/rafaelsilvag/727507e96849af3de7ad10082c7d7f86>>

i'll check if a bit later a bit more deeper, but for the first insight, it'll have
the "qc passed" vignette.... :)


>
> So, do you think that we can start working like as you said before
(fork and pull-requests)?
>

imho frederic will arrange you the rw access to the bitbucket somehow....
:)

thanks,
cs




> Best regards,
> Rafael
>
> On Fri, 26 Mar 2021 at 11:16, mc36 < <> <
<>>> wrote:
>
>     hi,
>
>     On 3/26/21 2:27 PM, Rafael S. Guimaraes wrote:
>      > Hi @Csaba,
>      >
>      > Thanks for pointing that out. You are right! We have already
done the data- and control plane parts (bf_router.p4 and bf_forwarder.py).
>
>     excellent!
>
>      >
>      > My question is: after successfully compiling 
on those platforms (BMv2, Tofino, and DPDK), what should the next steps be?
Can I drop a pull-request to the
main repository,
>     or must
>      > we use a different branch, the "polka" one, as an
example? We freeze the P4 SDE version 9.4.0 in our deployment phase.
>
>     it depends....
>
>     if you would 'handle over' (abandon) the current work as is,
then go with a single pull-req...
>     we'll move forward as sde95 appears soon, in that case, we'll
who will ensure that it
>     compiles and passes the tests in the future....
>
>     if you already have that repo somewhere, you can still make the
pull-reqs when
>     you change a thing here & there.... but i'll be trickier to
keep them in sync....
>
>     alternatively if you plan to support polka in long run @
rare/freertr then we can
>     arrange you rw access to the main repos after the initial pull-req
& merge then
>     both of us will patch the stuff: as freertr internal apis
evolve then i'll easily
>     move forward and update your forwarder parts also, then update
the api messages
>     and the dpdk & p4 code if needed... and if you change your mind
then you'll also
>     be able to change these parts....
>
>
>      >
>      > Thanks for providing some hints about the Freertr
development step. It is the part of the integration that we did
have no clue on how to proceed.
>
>     so if i understand you correctly, you already have something
that works!
>     at least, in p4... and if i understand you correctly, you
already have some
>     bfforwarder.py messages that program the dataplanes...
>     on top of these, it's hard to write a self test imho, we'll
need the pure
>     java version implementing the forwarding... to have something
that can be
>     tested against itself, and then to test the dataplane vms
against that...
>
>     if you could point me to your repo, then i can have some more
idea on how to proceed...
>
>     thanks,
>     cs
>
>
>
>
>      >
>      > Kind regards,
>      > Rafael
>      >
>      >
>      > On Thu, 25 Mar 2021 at 10:59, mc36 < <> <
<>> < <> <
<>>>> wrote:
>      >
>      >     hi,
>      >
>      >     On 3/25/21 1:51 PM, Rafael S. Guimaraes wrote:
>      >
>      >      >
>      >      > @Csaba, feel free to contact me any time!
>      >      >
>      >
>      >     at the moment all i know is that sent on this
public mailing and my own research (your paper from doi search engines:))
>      >
>      >     knowing these, you should have come up with a
p4 dataplane integration into
>      >     - http://sources.nop.hu/misc/p4lang/
<http://sources.nop.hu/misc/p4lang/> <http://sources.nop.hu/misc/p4lang/
<http://sources.nop.hu/misc/p4lang/>>
<http://sources.nop.hu/misc/p4lang/ <http://sources.nop.hu/misc/p4lang/>
<http://sources.nop.hu/misc/p4lang/ <http://sources.nop.hu/misc/p4lang/>>> for bmv2
>      >     - http://sources.nop.hu/misc/p4bf/
<http://sources.nop.hu/misc/p4bf/> <http://sources.nop.hu/misc/p4bf/
<http://sources.nop.hu/misc/p4bf/>>
<http://sources.nop.hu/misc/p4bf/ <http://sources.nop.hu/misc/p4bf/>
<http://sources.nop.hu/misc/p4bf/ <http://sources.nop.hu/misc/p4bf/>>> for tofino
>      >     - http://sources.nop.hu/misc/native/
<http://sources.nop.hu/misc/native/> <http://sources.nop.hu/misc/native/
<http://sources.nop.hu/misc/native/>>
<http://sources.nop.hu/misc/native/ <http://sources.nop.hu/misc/native/>
<http://sources.nop.hu/misc/native/ <http://sources.nop.hu/misc/native/>>> for
dpdk/libpcap
>      >     if i understand flou's words correctly, you're
done with some of that already:)
>      >     and you should have to proceed with the
configuration parts...
>      >     some hints here are how
>      >     - rsvp-te
http://sources.nop.hu/src/clnt/clntMplsTeP2p.java
<http://sources.nop.hu/src/clnt/clntMplsTeP2p.java>
<http://sources.nop.hu/src/clnt/clntMplsTeP2p.java
<http://sources.nop.hu/src/clnt/clntMplsTeP2p.java>>
<http://sources.nop.hu/src/clnt/clntMplsTeP2p.java
<http://sources.nop.hu/src/clnt/clntMplsTeP2p.java>
>     <http://sources.nop.hu/src/clnt/clntMplsTeP2p.java
<http://sources.nop.hu/src/clnt/clntMplsTeP2p.java>>>,
>      >     - sr-te http://sources.nop.hu/src/clnt/clntMplsSr.java
<http://sources.nop.hu/src/clnt/clntMplsSr.java>
<http://sources.nop.hu/src/clnt/clntMplsSr.java
<http://sources.nop.hu/src/clnt/clntMplsSr.java>>
<http://sources.nop.hu/src/clnt/clntMplsSr.java
<http://sources.nop.hu/src/clnt/clntMplsSr.java>
>     <http://sources.nop.hu/src/clnt/clntMplsSr.java
<http://sources.nop.hu/src/clnt/clntMplsSr.java>>>,
>      >     - srv6 http://sources.nop.hu/src/clnt/clntSrExt.java
<http://sources.nop.hu/src/clnt/clntSrExt.java>
<http://sources.nop.hu/src/clnt/clntSrExt.java
<http://sources.nop.hu/src/clnt/clntSrExt.java>>
<http://sources.nop.hu/src/clnt/clntSrExt.java
<http://sources.nop.hu/src/clnt/clntSrExt.java>
>     <http://sources.nop.hu/src/clnt/clntSrExt.java
<http://sources.nop.hu/src/clnt/clntSrExt.java>>>
>      >     implemented in freertr to have the similar
config interface for polka.
>      >     also to automate the dataplane testing, it
would be nice if you could
>      >     come up with a pure java forwarder, hint here
how nsh/mpls done:
>      > http://sources.nop.hu/src/ip/ipMpls.java
<http://sources.nop.hu/src/ip/ipMpls.java> <http://sources.nop.hu/src/ip/ipMpls.java
<http://sources.nop.hu/src/ip/ipMpls.java>>
<http://sources.nop.hu/src/ip/ipMpls.java <http://sources.nop.hu/src/ip/ipMpls.java>
<http://sources.nop.hu/src/ip/ipMpls.java
<http://sources.nop.hu/src/ip/ipMpls.java>>>
>      >
>      >     if you have any questions or something to
commit to,
>      >     feel free to drop over the fence and we'll see
how to proceed... :)
>      >
>      >     thanks,
>      >     cs
>      >
>


Archive powered by MHonArc 2.6.19.

Top of Page