[GTER] Construindo um EBGP com NetFPGA

[Rubens Kuhl]

> As minhas previsões estão de acordo com o que eu vejo no mercado e
> sinceramente,
> queria *muito* estar errado, mas, dos meus trânsitos, só a GBLX tem IPv6.

CTBC ?

> Os outros não tem sequer previsão de implantação.

Ter, eles tem, mas não querem se comprometer com algo que não impacte
vendas diretamente.

> Um deles não tem nem bloco
> v6
> alocado pelo Registro.BR e não estou falando de gente pequena não.

Eu sei. Vários desses chegaram a apresentar bids para uma contratação
de acesso 10G que acompanhei, e foram desqualificados por critérios
tais como não ter bloco v6, não ter anúncio v6 na DFZ, ter trânsito
experimental v6 do NIC.br ...


> Toda nossa rede é preparada pra v6. Não há um só ativo que não esteja
> preparado
> pra migração. Infelizmente nós somos peixes pequenos. Os grandes backbones
> não
> estão preocupados com isso, o que me faz pensar se eles tem a mesma
> dificuldade
> de conseguir um bloco v4 como nós temos.

Eles tem sim. A única hipotése para explicar o comportamento deles é a
fé em soluções de Large Scale NAT... essa é uma das piores apostas que
eles podem fazer, mas parecem mais dispostas a elas. Até os
fabricantes estão contando com as vendas de Large Scale NAT para
alcançar metas, sinal de que esses dois segmentos acreditam que
sobreviverão ao esgotamento do IPv4 dessa forma.

>> De hardware não vai mudar, e o gateware deles está bem lento em
>> lançamentos. Eu havia entendido que a idéia era justamente pegar o que
>> já tem de gateware pronto e começar agora... esperar joga qualquer
>> projeto para 2013.
>>
>
> Você entendeu certo. A idéia é pegar o que já existe e alterar.
> Acredito que processador não mudará (aliás, parece ser o mesmo da versão
> 1G).

O GateArray da 10G é um Virtex-5, o da 1G é um Virtex-II; uma senhora evolução.

> As mudanças devem ficar por conta da memória e outros.

Memória também é bem diferente.

>> Não roteadores com hardware-forwarding. Você mencionou 20 Gbps de
>> capacidade tráfego, isso dá 30 Mpps, ou seja, um pacote a cada 33 ns.
>> Forwarding dessa capacidade requer multi-banking de SRAM para
>> funcionar, qualquer DRAM não vai conseguir responder a tempo.
>>
>
> Segundo as especificações:
> Reduced cycle time (15ns at 533 MHz)

Isso para dados que estão na mesma fileira. Como a busca na tabela não
é linear, você tem que pegar o tempo de busca na fileira em uma
determinada percentagem dos acessos.
(e mesmo o tempo de coluna equivalente é 20 ns pela especificação da Micron)

> É preciso estudar o que seria melhor. Pode-se estudar o contrário, ou seja,
> fazer
> buffer + ACL na SRAM e deixar a RLDRAM apenas para o look-up na FIB.

Eu vou ficar muito espantado de qualquer diagrama de timing que
consiga suportar look-up de FIB ou de ACL na RLDRAM.
Deixar a FIB na SRAM e construir uma pequena TCAM usando gates do FPGA
para ACLs curtas (tipo 32 linhas) é a coisa mais plausível que posso
imaginar.

> Mas bloom filter é só pra look-up na FIB. Será necessário pensar em como ela
> será atualizada. Onde você vê a interseção dessas duas tarefas ?

É justamente o que diferencia um roteador que funciona no mundo real
da DFZ... roteador de alta performance e baixa latência para IPTV ou
para aplicações financeiras é fácil exatamente por não ter que lidar
com uma topologia que tem tantas alterações. Uma solução que seja
apenas otimizada para o look-up fará com que cada BGP UPDATE recebido
seja uma calamidade... por exemplo, pode fazer com que seja necessário
usar um banco de SRAM só com a FIB em produção e outro só com a FIB
próxima versão. Um algoritmo com prune seletivo e alterações graduais
evitará esse tipo de problema.

Rubens