[GTER] RFC 2544 ou similares é. Soft-router

[Douglas Fischer]

Um banho conhecimento em HMH!?!?!

Sobre CTRIE E CUDA
------------------
Eu particularmente discordo da ideia de insistir em escalar em X86 usando
CTRIE por mais de um motivo:
1º Porque, se levarmos a ferro e fogo, já está provado que thead-safe não
existe.
   Mas aí já entramos numa seara quase tão religiosa quanto windows vs
linux e não vale a peleja.
2º Porque se esse processamento em algum momento chegar num ponto de ter
que escalar horizontal, em CTRIE "isso non ecziste".

Parece "exagero", mas pense que esse Controller vai ter que recalcular cada
mudança de rota que aconteça na rede para cada uma das perspectivas da rede.
Ou seja: Chegou um anúncio de rota morta e eu tenho 10 Roteadores, vai ter
que reconvergir e recalcular sob 10 perspectivas distintas.
Num ambiente de uma operadora pequena ou de um ISP grande...
Com 2-3 trânsitos, 2-3 conexões a PTT com uns 10-15 Bilateriais, e uns
30-40 DownStreams.
Aí adicione a complexidade de ter que separar essa rede em duas
regiões(Ex.: Sudeste e Nordeste.)
Não vai ser qualquer caixinha Pentium4 que vai tocar essa meleca...

Justamente pensando na possibilidade de escala horizontal é que eu começo a
repensar os meus conceitos entre PROCEDURAL vs FUNCIONAL.


Sobre Patentes
--------------
Que banho de água fria!
Então quer dizer que se um projeto open-source chegar à mesma solução que
um projeto patenteado, sem uso de técnicas escusas, tem-se que jogar tudo
fora?
Te juro que isso está descendo atravessado...
Ver se gasto um tempo pesquisando sobre isso.


Sobre Compressão de tabela de rotas
-----------------------------------
Na verdade eu tinha uma ideia muito menos elaborada sobre isso!
Minha ideia era uma coisa bem tosca(para não dizer gambiarrenta):

  1 - BGP do ASN continua sendo todo multihop baseado em route-reflector.
Mas depois de calculada a RIB resultante, e antes de mandar as atualizações
para cada um dos clients:
  2 - Ignorar todos os atributo de BGP(focando só na rota)
  3 - Sumarizar a tabela resultante usando algorítimos como os que já são
usados para OSPF ou ISIS.
  4 - Mandar para o client, através de BGP, uma tabela "fictícia"
miguelando todos os parâmetros do BGP... Focando exclusivamente a FIB que
vai ter que ficar Router-Client.


Mas essa metodologia que você sugeriu faz muito mais sentido.
Principalmente esse conceito do Lossless vs Lossy.
Porém envolve um esforço de desenvolvimento muito maior.


Em 20 de fevereiro de 2017 11:15, Henrique de Moraes Holschuh <
hmh at hmh.eng.br> escreveu:

> On Wed, Feb 15, 2017, at 17:23, Douglas Fischer wrote:
> > Imagine um ASN baseado em Route-Refletor centralizado.
> >  - E que esse route-reflector rodasse numa engine escrita em algo que
> > suporta-se CUDA/Shared-Nothing, com Hardware PARRUDO de CUDA.
>
> CUDA seria útil só na implementação do plano de dados (para a TCAM),
> acho.
>
> Para o plano de controle, usando implementações decentes de RCU, e
> locking, uma implementação para lá de avançada de estrutura de dados
> baseada em TRIE e/ou C-TRIE, e alguns cores parrudos x86, já dá conta de
> todo o plano de controle BGP.
>
> Dá para montar a C-TRIE da tabela full em alguns segundos, e otimizar
> C-TRIE é *muito* fácil.  Se tiver muita memória, quem sabe pode
> particionar a TRIE/C-TRIE em várias sub-árvores usando RCU para fazer
> múltiplas atualizações simultâneas em pontos diferentes da árvore (que
> estejam em sub-árvores diferentes).  De qualquer forma, o uso mais
> trivial de RCU já permite nunca bloquear os leitores mesmo enquanto
> atualiza a árvore.
>
> Isso criaria a FIB comprimida para a TCAM.
>
> >  - E além de simples Route-Reflecting, ele fize-se a sumarização da
> >  tabela internet para cada um do BorderRouters.
>
> Diversas técnicas para fazer isso são patenteadas, motivo pelo qual eu
> nunca tentei implementar para ver o que aconteceria. Quem sabe ainda
> faça algum dia por motivos acadêmicos, mas não dá nem para colocar em
> software livre sem fazer pesquisa de patentes primeiro (para não por em
> risco o projeto de software livre para onde iria o código, nem o meu
> próprio pescoço), e isso tira a graça de qualquer coisa.
>
> Procure por papers sobre compressão de tabelas de rotas, e sobre
> C-TRIEs.  Tem paper sobre compressão com perda (lossy) e sem perda
> (lossless), estudo da eficiência, etc.
>
> Por sinal: compressão com perdas de FIB/RIB significa que você roteia
> alguns "buracos" onde não havia nenhuma rota no lugar de descartar o
> pacote, por exemplo.  Ou no caso de trânsito (onde supostamente qualquer
> escolha funciona, embora existam escolhas "melhores"), você pode ignorar
> alguns prefixos "mais específicos" entre as feeds marcadas como
> "internet" (e mandar o pacote para um upstream diferente).
>
> O que eu não sei se patentearam é a ideia mais do que óbvia de
> compressão lossless básica: não precisa instalar na FIB nenhuma rota
> mais específica que envie o pacote para o mesmo gateway que uma menos
> específica, pelo menos do ponto de vista de  forwarding/routing.  Note
> que tais rotas mais específicas podem ser necessárias na FIB por outros
> motivos (por exemplo, para implementar contadores de tráfego por prefixo
> atualizadas pelo forwarding engine).
>
> >  - Diminuiria o tamanho da TCAM de cada BorderRouter
> >  - Diminuiria o tempo de lookup na FIB
>
> Sim.  Por isso tem caixa por aí que comprime FIB "sem dizer para
> ninguém", particularmente quando é lossless (que é invisível para o
> usuário): evita chamar a atenção, etc.
>
> --
>   Henrique Holschuh
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
Douglas Fernando Fischer
Engº de Controle e Automação