Rare project developers

[mc36 <>]

hi,

On 2/16/22 15:22, Cristina Klippel Dominicini wrote:
> Hi Csaba,
>
> Thanks for the feedback! We believe M-PolKA can tackle interesting use cases, 
> and would be great to have it running on FreeRouter.

yeahh, saw some in the paper and i'm also interested.... :)

> > > my first impression was that after the mod operation, it's basically do what 
> > > bier does, that is, we take the result, and interpret it as an outport 
> > > bitmap, don't we?
> Yes, exactly! We just changed the meaning of the portid polynomial and the 
> pipeline for cloning the packets according to the bitmap. It will be really 
> great if we can reuse part of the bier implementation for that end. Do you 
> think we can do that for both freeRouter and Tofino? Then, we could run some 
> experiments comparing BIER with m-PolKA :-)

hopefully you'll able to do that...


> > > and this is where we hit a limitation, depending on the size of crc is in 
> > > use, we can only describe 16 output ports, which is clearly not enough...
> Is it possible to use CRC32 for M-PolKA's implementation in FreeRouter?

surely yess, we can use crc32, that one was also made parameterizable back 
when polka was introduced... :)
but that would reduce the core nodes expressable in the routeid by half...


> > > my idea to overcome the above, what if we interpret mpolka mod result as a 
> > > bitmap to this index table? it then raises the limitation to 16 igp neighbors 
> > > per core node, which is more friendly...
>
> As we are already bound to the SR indexes, I think it is a reasonable 
> reinterpretation.
> Another simple way would be to have two nodeids per switch (or more), for 
> example. Then, with the same routeid we could address half of the ports with 
> nodeid1 and the other half with nodeid2. This would incur in two CRC 
> operations to generate the bitmap.
> We could also explore some other encoding techniques for the bitmap. Today is 
> our weekly meeting at Ufes, so we will discuss with the group about the 
> possibilities, and we give you a feedback on this subject.

imho absolutely this is the way to follow instead of doing crc32,
and one can easily have two loopbacks if one have more than 16 igp peers...


> > > an other implementation idea is to use a different ethertype for mpolka to 
> > > not confuse the unicast or multicast packets on the wire as they'll differ on 
> > > handling...
> Agreed! We also have some other ideas for failure protection and chaining 
> that would change the header, and consequently, would need a different 
> version code.

fine... then i'll wait until you discuss with your colleges and then i'll 
proceed with adding mpolka...
since then i've done some digging into the code and imho mpolka will use 
bier-id instead of srid because
that beast already populates a thing bfrlist, which is the per node peer 
index table we need for mpolka
to interpret the bitmap over... it's just a config thing like the regular 
polka and sr case...
after this, the initial version will be able to address the multihoming use 
case you discuss
in your paper, moreover it'll be able to do the (iptv) headend usecase from 
bier tests...

regards,
cs


> Best regards,
> Cristina
>
> ________________________________________
> De: mc36 <>
> Enviado: quarta-feira, 16 de fevereiro de 2022 03:21
> Para: Cristina Klippel Dominicini; Rafael Silva Guimar  es
> Cc: 
> Assunto: mpolka in rare
>
> hi,
> i went through your mpolka paper, first of all, congrats, nice work!
> my first impression was that after the mod operation, it's basically do what 
> bier
> does, that is, we take the result, and interpret it as an outport bitmap, 
> don't we?
> and this is where we hit a limitation, depending on the size of crc is in use,
> we can only describe 16 output ports, which is clearly not enough...
> in freerouter, polka is bound to segment routing ids, and the result of the 
> mod
> is not a port but an sr index... my idea to overcome the above, what if we 
> interpret
> mpolka mod result as a bitmap to this index table? it then raises the 
> limitation to
> 16 igp neighbors per core node, which is more friendly...
> an other implementation idea is to use a different ethertype for mpolka to not
> confuse the unicast or multicast packets on the wire as they'll differ on 
> handling...
> afterall, i found it feasible both for software and dataplane implementations,
> so it could become a drop-in replacement for the current ip multicast over 
> bier...
> any opinion?
> thanks,
> cs
>
>
> ________________________________
>
> 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.