Rare project developers

[mc36 <>]

hi,

i was thinking a lot about how to proceed when i'll get the math code from 
you, and i came up with the following two:

introduce ttl in polka:
as discussed during the vc, a fail-proof protocol should have a last resport 
safeguard against routing loops...
at the polka patch i have, you allocated a 16 bit version field, so my idea 
is to split that one into two
8bit parts, one for verison and the other for ttl, which must be decremented 
on every forwarding node,
and the packet must be discarded when it reaches zero...

abuse output port:
at the paper, you describe the polka forwarding calculation results directly 
in the output port...
in the polka patch you conclude to polka_portid, which is good for proof of 
concept testing,
but it will not work in the wild... first of all, just concluding to a portid 
cannot result in
layer2 header rewrites: that is, on a given link, the ethernet.srcaddr must 
be the sender, and
the ethernet.dstaddr must be the remote, who you will to forward to... on 
point to point
connections, basically yuo can abuse ethernet and send with arbitrary 
ethernet addresses,
but on switched lans, it won't work at all... so the portid alone is not 
enough, moreover,
the current routing protocols does notfloods this information nor in the igp 
or bgp databases...
so to have the ethernet rewrite info at hand, and to support broadcast lans, 
where you could
have two neighbors on a given link, at least a nexthopid should be encoded, 
but it's the same
story, no any current protocol encodes this info into the databases...
okk, we could ask ietf for new code points to store this info in the long 
run, but it's time...
so for now, my idea here is to abuse polka's portid and encode the target 
nodeid instead...
it'll result in an additional table lookup in the ig_ctl_polka.p4 but it'll 
solve all the above...
for preparation to this, i introduced a new outcome from some routing 
protocols in freerouter,
the index to prefix mapping table... here is the commit, and below the output 
from my homenet...
https://github.com/mc36/freeRouter/commit/b27377c6da5c6f7c7eab7766dbc509a8e6310853
so from now, lsrp, ospf, isis and bgp all populate this table correctly, so 
these will
have polka support... this table will be sent to the dataplane, and the 
polka.portid
will be looked up in this table to have a nexthopid to forward the packet 
to...
you will not have to do anything about this in your part of the code, i'll 
silently
use your routeid encoder this way....

i'm seeking your insight on the above...

regards,
cs


noti#show ipv6 srindex inet
index  prefix
10     2001:db8:1101::1/128
20     2001:db8:1101::2/128
24     2001:db8:1101::10/128
25     2001:db8:1101::1101/128
26     2001:db8:1101::11:11/128
27     2001:db8:1101::26/128
29     2001:db8:1101::29/128
31     2001:db8:1101::31/128
32     2001:db8:1101::24/128
33     2001:db8:1101::25/128
40     2001:db8:1101::4/128
50     2001:db8:1101::5/128
54     2001:db8:36::1/128
80     2001:db8:1101::8/128
97     2001:db8:1101::222:222/128
110    ::/0
180    2001:db8:1101::18/128
181    2001:db8:1101::180/128
190    2001:db8:1101::19/128
191    2001:db8:1101::190/128
193    2001:db8:1101::252:198/128
197    2001:db8:1101::252:197/128
199    2001:db8:1101::199/128
200    2001:db8:1101::20/128
210    2001:db8:1101::21/128
240    2001:db8:1101::240/128
260    2001:db8:1101::27/128
270    2001:db8:1026:1001::2/128

noti#



On 10/22/21 16:58, mc36 wrote:
> hi,
> excellent news, thanks!
> i'm waiting for your code, then i'll start integrating asap!
> have a nice weekend,
> regards,
> cs
>
>
> On 10/22/21 16:41, Cristina Klippel Dominicini wrote:
> > Hi Csaba,
> >
> > Just to let you know. The Java ring lib worked like a charm :-) I just need to double check some Math considerations, because the representation of the libs are a bit different. 
> > I have already translated our code to Java, and on Monday I will execute the final tests and send to you a stable version.
> >
> > Best regards,
> > Cristina
> >
> > ________________________________________
> > De: mc36 <>
> > Enviado: quinta-feira, 21 de outubro de 2021 02:13
> > Para: Cristina Klippel Dominicini; Cristina Klippel Dominicini; Rafael S. 
> > Guimaraes; Rafael S. Guimarães
> > Cc: ; Magnos Martinello; Moises R. N. Ribeiro
> > Assunto: Re: custom crc32 library in freerouter
> >
> > hi,
> >
> > lib: okk, pick any lib you see fit and convenient for you...
> >
> > github: it's me: https://github.com/mc36/
> >
> > finally, i'am also very excited that we're getting closer and closer to 
> > polka....
> > when i first read your paper, i had the feeling that it's an excellent idea! 
> > :)
> >
> > thanks,
> > cs
> >
> >
> >
> >
> > On 10/21/21 03:40, Cristina Klippel Dominicini wrote:
> > > Hi, Csaba,
> > >
> > > These are great news! I am very happy to learn that Tofino now supports the polynomial configuration in runtime by the control plane. Thanks for asking the question to Vladimir 
> > > in the FASTER forum.
> > >
> > > Indeed, we use only basic arithmetic functions from sympy, and calculate the multiplicative inverse. Could you please send your github user to us? Then, we can share our 
> > > repository of our python lib.
> > >
> > > I will double check tomorrow, but the following lib in Java seems to have all 
> > > the required methods: https://rings.readthedocs.io/en/latest/
> > > It is Apache License: https://github.com/PoslavskySV/rings
> > >
> > > Thank you very much for your support. We are looking forward to integrate 
> > > PolKA in FreeRouter :-)
> > >
> > > Best regards,
> > > Cristina
> > >
> > > ________________________________________
> > > De: mc36 <>
> > > Enviado: quarta-feira, 20 de outubro de 2021 00:26
> > > Para: Cristina Klippel Dominicini; Cristina Klippel Dominicini; Rafael S. 
> > > Guimaraes; Rafael S. Guimarães
> > > Cc: 
> > > Assunto: Re: custom crc32 library in freerouter
> > >
> > > hi.
> > > sorry for the spam but i forgot to tell you a great news:
> > > as some of us was already involved in this thread, i asked vlad if they 
> > > progressed with the crc,
> > > and it seems that yess, they did, we can set the coeff from the control 
> > > plane, hurray:
> > > https://community.intel.com/t5/Intel-Connectivity-Research/Changing-CRC-polynomial-from-the-control-plane/m-p/1323312
> > > regards,
> > > cs
> > >
> > >
> > >
> > > On 10/20/21 05:15, mc36 wrote:
> > > > hi,
> > > >
> > > > thanks for the quick response... i reply topic by topic...
> > > >
> > > > crc:
> > > > just a small footnote that i refactored them again to get back the original 
> > > > speeds...
> > > > the trick there was that it was a static final table that is, it was common 
> > > > for all the
> > > > classes, so it was computed only once... now it's true again...:)
> > > > not that much happened, just the class instantination parameter changed...
> > > >
> > > > sympy:
> > > > after a quick look, it seems to me a huuuge (33mb) symbolic math package...
> > > > but in guess you're only using a small subset of that... at least from the 
> > > > paper,
> > > > my bet is that you only need a class that represents a polynomial, and the
> > > > add, sub, div, mul functions over it (as i shown for ellitic curves during 
> > > > the vc)
> > > > so if that's the case, i would suggest you that simply give me some time and
> > > > let me come up with something that can calculate only these over a poly 
> > > > class...
> > > > if you could shar your current python code could help me to see what you need 
> > > > from sympy...
> > > > i really love doing such things because it refreshes a bit the things i learnt
> > > > during the university classes, and i really like explore and understand 
> > > > things...
> > > > finally, calling out to external libs are always costy because of the
> > > > java-ish overhead that is put by the non-specific libs, and when you
> > > > have an unstable network and you have to recompute frequently then it
> > > > pays off to have everything in hand that you can fully optimize...
> > > > snoopy.vhpc#show platform | include uptime
> > > > uptime: since 2021-10-16 10:00:37, for 3d18h
> > > > snoopy.vhpc#show ipv4 bgp 1955 bestpath | include change
> > > > changes allÃ' Ã' Ã' Ã' Ã'  15784774
> > > > changes nowÃ' Ã' Ã' Ã' Ã'  37
> > > > snoopy.vhpc#
> > > > it's the worst example i have for the above, it averages to 45 changes / 
> > > > second...
> > > >
> > > > reusing segment routing id from routing protocols:
> > > > so at the moment it's the quickest way i see to fit the need to populate an 
> > > > id->prefix
> > > > and prefix->id table on each node in a network... also keep in mind that 
> > > > freerouter have
> > > > homebrew routing protocols too (http://lsrp.nop.hu/ and 
> > > > http://pvrp.nop.hu/)... so if we
> > > > need a new value somehow, it can arrive in no time to continue 
> > > > experimenting...
> > > > but in a longer run, you should consider ietf rfcs to have specific values 
> > > > just for polka...
> > > >
> > > > thanks,
> > > > cs
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 10/20/21 03:00, Cristina Klippel Dominicini wrote:
> > > > > Hi, Csaba,
> > > > >
> > > > > Thank you very much for this quick response!
> > > > >
> > > > > Yes! The bmv2 implementation explores predefined tables (code below) for 
> > > > > well-known CRC standards and builds the tables for custom polynomials.
> > > > > https://github.com/p4lang/behavioral-model/blob/main/src/bm_sim/crc_tables.h
> > > > > Their solution was inspired by this code that offers a nice introduction to 
> > > > > the CRC calculation: 
> > > > > https://barrgroup.com/Embedded-Systems/How-To/CRC-Calculation-C-Code
> > > > >
> > > > > Your new code seems to fit our requirements perfectly. We will execute some 
> > > > > tests with default parameters to double check.
> > > > >
> > > > > We used CRC16, because the lower the polynomial degree, the better in terms 
> > > > > of the bitlength of the routeid. In theory, we could use lower polynomials 
> > > > > for small topologies, but
> > > > > we got some errors with CRC8 in our initial tests in Tofino. We will check if 
> > > > > we can use CRC8 in Tofino.
> > > > >
> > > > > Now, we are going to translate our code to provide you with a Java method 
> > > > > that performs the routeID computation given the path information (set of the 
> > > > > nodeIDs and portIDs). Most
> > > > > of our polynomial computation uses the galoisfield module of the sympy lib 
> > > > > (https://docs.sympy.org/latest/modules/polys/index.html). So, I will check if 
> > > > > there is a similar
> > > > > library in Java. For the nodeid computation, it is just a matter of 
> > > > > calculating a list of irreducible polynomials, so it should suffice to have a 
> > > > > fixed list of nodeids for the
> > > > > control plane.
> > > > >
> > > > > Finally, your suggestion to use BGP/IGP for node discovery and reuse the 
> > > > > Segment Routing identifiers seems to be a very elegant solution. We will 
> > > > > study that. Thank you!
> > > > >
> > > > > Best regards,
> > > > > Cristina
> > > > >
> > > > > ________________________________________
> > > > > De: mc36 <>
> > > > > Enviado: terÃf§a-feira, 19 de outubro de 2021 17:21
> > > > > Para: Cristina Klippel Dominicini; Cristina Klippel Dominicini; Rafael S. 
> > > > > Guimaraes; Rafael S. GuimarÃf£es
> > > > > Cc: 
> > > > > Assunto: Re: custom crc32 library in freerouter
> > > > >
> > > > > hi,
> > > > > sorry for the spam again, but i checked again the polka.patch and found that 
> > > > > maybe you're using crc16?
> > > > > so here we go, i also parameterized it in freertr: 
> > > > > http://src.mchome.nop.hu/src/net/freertr/cry/cryHashCrc16.java
> > > > > with this: 
> > > > > https://github.com/mc36/freeRouter/commit/4958add8b8fc48f1a35199f6e57deeb5dfe768ac
> > > > > i'm never against some good refactoring, afterall... :)
> > > > > also, you really should check the last but one vc, we demoed how 
> > > > > segment-routing traffic engineering can work...
> > > > > that is my intent to reach to that same level with polka, with abusing the 
> > > > > already existing igp's and/or bgp's
> > > > > segrout.index flooding mechanisms... here is the video: 
> > > > > https://www.youtube.com/watch?v=jS6RmHKC4aQ
> > > > > regards,
> > > > > cs
> > > > >
> > > > >
> > > > > On 10/19/21 21:31, mc36 wrote:
> > > > > > hi,
> > > > > > sorry for the spam...
> > > > > > so i played a bit with my crc32 library and found out that i can calculate 
> > > > > > the same values with a single class,
> > > > > > just some parameters need to be passed to it become the "ieee ethernet" or the 
> > > > > > "sctp rfc" version of the crc code...
> > > > > > here is what freertr have now at the moment: 
> > > > > > http://sources.nop.hu/src/net/freertr/cry/cryHashCrc32.java
> > > > > > (my bad, the url was bad in the previous mail...:) and this is what happened 
> > > > > > in the code to reach the single class:
> > > > > > https://github.com/mc36/freeRouter/commit/ca58d4fe39f0cd681d6cd21d3a9a2474e07600a8
> > > > > > if you still need a parameter or anything around the crypto lib, just let me 
> > > > > > know...
> > > > > > but hopefully now, it'll be easy for you to come up with the rest, that is:
> > > > > > Ã'  Ãf' - a method to encode the polka.routeid from "List<Integer> 
> > > > > > nodes"...
> > > > > > Ã'  Ãf' - a method to calculate the coefficient (polynominal?) from a 
> > > > > > single node id...
> > > > > > then we can finally have a pure java forwarder and so on, as we discussed in 
> > > > > > the vc...
> > > > > > thanks,
> > > > > > cs
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 10/19/21 17:34, mc36 wrote:
> > > > > > > hi
> > > > > > >
> > > > > > > i've found the crc32_custom magic in bmv2:
> > > > > > >
> > > > > > > behavioral-model-main/src/bm_sim/crc_map.cpp
> > > > > > > behavioral-model-main/src/bm_sim/calculations.cpp
> > > > > > >
> > > > > > > in the crc_map.cpp for crc32c, they uses the same magic as me at 
> > > > > > > http://source.nop.hu/src/net/freertr/cry/cryHashCrc32c.java
> > > > > > > and the table calculation in calculations.cpp seems similar that i do too, 
> > > > > > > but mine works with fixed magic...
> > > > > > >
> > > > > > > but they have no parameter called coefficiet, but the magic called 
> > > > > > > polynomial...
> > > > > > >
> > > > > > > my best guess according to 
> > > > > > > https://en.wikipedia.org/wiki/Cyclic_redundancy_check is that they're the 
> > > > > > > same?
> > > > > > > (but again, it's my bad but i'm a bit noob in these math things, i'm much 
> > > > > > > more a networker and coder guy:)
> > > > > > >
> > > > > > > so if that's the case then i'll create a new crc32 class that needs to be 
> > > > > > > initialized with the poly paramareter...
> > > > > > >
> > > > > > > thanks,
> > > > > > >
> > > > > > > cs
> > > > >
> > > > >
> > > > > ________________________________
> > > > >
> > > > > Esta mensagem (incluindo anexos) contÃf©m informaÃf§Ãf£o confidencial destinada a um usuÃf¡rio especÃf­fico e seu conteÃfºdo Ãf© protegido por lei. Se vocÃfª nÃf£o 
> > > > > Ãf© o destinatÃf¡rio correto deve
> > > > > apagar esta mensagem.
> > > > >
> > > > > O emitente desta mensagem Ãf© responsÃf¡vel por seu conteÃfºdo e 
> > > > > endereÃf§amento.
> > > > > Cabe ao destinatÃf¡rio cuidar quanto ao tratamento adequado. A divulgaÃf§Ãf£o, reproduÃf§Ãf£o e/ou distribuiÃf§Ãf£o sem a devida autorizaÃf§Ãf£o ou qualquer outra 
> > > > > aÃf§Ãf£o sem conformidade com as
> > > > > normas internas do Ifes sÃf£o proibidas e passÃf­veis de 
> > > > > sanÃf§Ãf£o disciplinar, cÃf­vel e criminal.
> > >
> > >
> > > ________________________________
> > >
> > > Esta mensagem (incluindo anexos) contém informação confidencial destinada a um usuário específico e seu conteúdo é protegido por lei. Se você não é o destinatário 
> > > correto deve apagar esta mensagem.
> > >
> > > O emitente desta mensagem é responsável por seu conteúdo e 
> > > endereçamento.
> > > Cabe ao destinatário cuidar quanto ao tratamento adequado. A divulgação, reprodução e/ou distribuição sem a devida autorização ou qualquer outra ação sem conformidade 
> > > com as normas internas do Ifes são proibidas e passíveis de sanção disciplinar, cível e criminal.
> >
> >
> > ________________________________
> >
> > Esta mensagem (incluindo anexos) contém informação confidencial destinada a um usuário específico e seu conteúdo é protegido por lei. Se você não é o destinatário correto deve 
> > apagar esta mensagem.
> >
> > O emitente desta mensagem é responsável por seu conteúdo e endereçamento.
> > Cabe ao destinatário cuidar quanto ao tratamento adequado. A divulgação, reprodução e/ou distribuição sem a devida autorização ou qualquer outra ação sem conformidade com as 
> > normas internas do Ifes são proibidas e passíveis de sanção disciplinar, cível e criminal.