[GTER] Construindo um EBGP com NetFPGA

[Provedor Bogus]

Rubens,

Em 19 de outubro de 2011 21:32, Rubens Kuhl <rubensk at gmail.com> escreveu:

> Ao contrário de informação insistentemente repetida por uma certa
> associação, o IPv6 já está no Brasil. E o IPv4 já já vai acabar no
> Brasil... não dá para começar um desenvolvimento em 2011 sem IPv6.
>

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.
Os outros não tem sequer previsão de implantação. Um deles não tem nem bloco
v6
alocado pelo Registro.BR e não estou falando de gente pequena não.

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.


> 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).
As mudanças devem ficar por conta da memória e outros.


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

Seus 33 ns acabaram muito antes disso...
>

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

Estou com dificuldades em encontrar mais informações da SRAM e do
processador.
Elas ajudariam bastante a nortear algumas decisões que ainda não estão
fechadas.


> Mesmo conceitualmente isso já não está decolando...
>

Mas não é essa a graça do negócio ?


> Os problemas de performance de atualização da tabela conforme
> alterações vem do plano de controle são tão determinantes na escolha
> desses algoritmos quanto o look-up. Consolidado e fácil não resolvem
> um pacote a cada 33 ns.
>

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 ?

Abraço !