Rare project developers

["Rafael S. Guimaraes" <>]

Hi @Jordi,

Sure, you are welcome :). I've sent it to you as well.

Let me know, maybe we can arrange another day/time that would be possible for you to attend.

Best regards,

Rafael

On Thu, 8 Apr 2021 at 13:04, Jordi Ortiz <> wrote:

Can I join you? Not sure, can not confirm until tuesday but if you send me the link I'll do my best =)

Regards

Jordi

El 08/04/2021 a las 17:44, Rafael S. Guimaraes escribió:

Hi @Csaba, 

I have sent to your email an invitation for a meeting on Tuesday next week at 2 pm(GMT+01). 

Can you confirm if you have received it? 

Feel free to propose another day/time, thanks! :) In the meantime, I will take a look at your repository.

Best regards,

Rafael

On Wed, 7 Apr 2021 at 14:18, mc36 <> wrote:

resending because of the "forwarding errors"....

one thing to note... try to not depend on external libs to achieve a thing,for example i have some poly algos in src/cry/cryHashCrc16 or cryHashHecfor atm cells....
thanks,
cs

On 4/7/21 7:15 PM, mc36 wrote:
> one thing to note... try to not depend on external libs to eachoeve that,for example i have some poly algos in src/cry/cryHashCrc16 or cryHashHecfor atm cells....
> thanks,
> cs
>
> On 4/7/21 6:44 PM, mc36 wrote:
>> 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 thisway, 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 cancelsome 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 onthat?
>>>
>>> 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 wemove 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 justthe 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 longrun @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 evolvethen 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/analyzingthe code before merging and making sure thatmy 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 awrite-only backup of sources.nop.hu/misc/p4bf <http://sources.nop.hu/misc/p4bf>
>>>     that is, once you run the upgradescripts 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 havesomething 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 doit 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 javapart, 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 allowedor 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 2021at 11:16, mc36 < <mailto:> <mailto: <mailto:>>> wrote:
>>>      >
>>>      >     hi,
>>>      >
>>>      >     On 3/26/21 2:27 PM, Rafael S. Guimaraes wrote:
>>>      >      > Hi @Csaba,
>>>      >      >
>>>      >      > Thanks for pointing thatout. 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 inour deployment phase.
>>>      >
>>>      >     it depends....
>>>      >
>>>      >     if you would 'handleover' (abandon) the current work as is, then go with a single pull-req...
>>>      >     we'll move forward as sde95appears 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 youplan 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 iunderstand 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 < <mailto:> <mailto: <mailto:>> <mailto: <mailto:> <mailto:
>>>     <mailto:>>>> 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 knowis that sent on this public mailing and my own research (your paperfromdoi search engines:))
>>>      >      >
>>>      >      >     knowing these, youshould 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 javaforwarder, 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
>>>      >      >
>>>      >
>>>

-- 
Jordi Ortiz


(+34)868884644/(+34)868888532
http://ants.inf.um.es/~jordiortiz
Dpto. Ingeniería de la Información y las Comunicaciones
Universidad de Murcia