Skip to Content.
Sympa Menu

rare-dev - Re: [rare-dev] mpolka in rare

Subject: Rare project developers

List archive

Re: [rare-dev] mpolka in rare


Chronological Thread 
  • From: Cristina Klippel Dominicini <>
  • To: Rafael Silva Guimarães <>, "" <>
  • Cc: "" <>
  • Subject: Re: [rare-dev] mpolka in rare
  • Date: Wed, 16 Feb 2022 14:22:33 +0000
  • Accept-language: pt-BR, en-US


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.

>> 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 :-)

>> 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?

>> 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.

>> 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.

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.




Archive powered by MHonArc 2.6.19.

Top of Page