[GTER] pc router

Tue Apr 24 15:18:38 -03 2012

Correção: Troquei o Klaus pelo Henrique nas referencias ao RouteFlow:

> Henrique, obrigado pela menção do RouteFlow! Voce foi mais rapido que eu,
> queria fazer a disseminação do projeto (Apache 2.0) para comunidade do
> GTER na proxima semana assim tenhamos atualizado o site, materiais e
> documentação com a nova versão do desenho.
...
> Henrique, seu comentario é muito válido: "O certo seria modelar o plano
> de dados no routing engine consolidado".

Foi mal! Os sobrenomes de origem estrangeiro me confundiram :)

Henrique, obrigado de novo pelas observações. Confio em que podamos
dar continuidade a discussão. Estamos no ponto do projeto que
precisamos de input e feedback da realidade dos operadores de rede, os
requisitos, e os casos de uso que possam realmente trazer poder de
inovação, simplicidade e baixo custo para quem compra e gerencia os
equipamentos de rede, sem depender 100% dos vendors.

Abraços,
Christian

Em 24 de abril de 2012 15:12, Christian Esteve Rothenberg
<esteve at cpqd.com.br> escreveu:
> Klaus e colegas,
>
> compartilho sua visão de que o modelo de roteamento "caixa preta
> única" está mudando com a modularização de componentes e a
> disponibilidade de APIs que permitam uma efetiva separação dos planos
> de controle e de encaminhamento autenticamente multi-vendor (ex:
> OpenFlow).
>
> Se alguem não acredita no modelo, já seja na escalabilidade,
> performance o problemas de convergencia e tolherancia a falhas pela
> separação dos planos, vale a pena olhar no que a Google apresentou na
> semana passada no Open Networking Summit. Ainda não tem os slides
> completos das duas apresentações da Google mas um ótimo resumo é o
> seguinte: Hoje, 100% do tráfego de produção do backbone entre os data
> centers deles é baseado numa arquitetura baseada em Quagga rodando em
> servidores externos e "roteadores" OpenFlow, que na verdade são
> encaminhadores "burros" com um minimo de plano de controle. Vide mais:
>
> http://www.convergedigest.com/Bandwidth/newnetworksarticle.asp?ID=35604
> http://www.networkworld.com/community/blog/google-pwns-networking-part-1
>
> Klaus, obrigado pela menção do RouteFlow! Voce foi mais rapido que eu,
> queria fazer a disseminação do projeto (Apache 2.0) para comunidade do
> GTER na proxima semana assim tenhamos atualizado o site, materiais e
> documentação com a nova versão do desenho.
>
> RouteFlow (https://sites.google.com/site/routeflow/projects)
> basicamente vem juntar pilhas de protocolo open-source baseados em
> Linux (Quagga, XORP, Bird) rodando em servidores commodity com alto
> poder computacional e mantendo o plano de dados line-rate sobre
> hardware "commodity" que implemente o padrão OpenFlow.
> Nos estamos colaborando atualmente com a Google, NTT, e uma serie de
> universidades parceiras (Unicamp, Indiana University, Ufscar, Unirio)
> no aprimoramento da solução para tornar ela uma realidade.
>
> Seguem alguns artigos publicados pelo grupo:
>
> "RouteFlow: Roteamento Commodity Sobre Redes Programáveis"
> http://dl.dropbox.com/u/15183439/Papers/RouteFlow-RB-RESD-v4_n1_a05.pdf
>
> "Uma plataforma de roteamento como serviço baseada em redes definidas
> por software"
> http://dl.dropbox.com/u/15183439/Papers/WGRS12-Uma%20plataforma%20de%20roteamento%20como%20servico%20baseada%20em%20redes%20definidas%20por%20software-120501.pdf
>
> "Revisiting IP Routing Control Platforms with OpenFlow-based
> Software-Defined Networks"
> http://dl.dropbox.com/u/15183439/Papers/WPEIF12%20-%20Revisiting%20IP%20Routing%20Control%20Platforms%20with%20OpenFlow%20based%20SDN%20-%20120501.pdf
>
>  "OpenFlow e redes definidas por software: um novo paradigma de
> controle e inovação em redes de pacotes".
> http://www.cpqd.com.br/cadernosdetecnologia/Vol7_N1_jul2010_jun2011/pdf/artigo6.pdf
>
>
> E a seguir mais informações sobre a demo que fizemos na semana passada no ONS:
> https://sites.google.com/site/routeflow/updates/happyoneyearoftheopen-sourcerouteflowproject
>
>
> Klaus, seu comentario é muito válido: "O certo seria modelar o plano
> de dados no routing engine consolidado".
> Isso é precisamente no que estamos trabalhando na linha de aBGP
> (aggregated BGP). Mais detalhes no artigo acima:
> "Uma plataforma de roteamento como serviço baseada em redes definidas
> por software"
> http://dl.dropbox.com/u/15183439/Papers/WGRS12-Uma%20plataforma%20de%20roteamento%20como%20servico%20baseada%20em%20redes%20definidas%20por%20software-120501.pdf
>
>
> Neste 2012 gostaríamos de ver casos piloto da tecnologia RouteFlow em
> provedores e redes corporativas no Brasil.
> Um ponto positivo é que o software está disponivel e uma adoção da
> tecnologia pode ser tão "simples" quanto a substituição (ou expansão
> da rede) de só um roteador legado por um roteador RouteFlow, não é
> preciso pensar numa migração da rede como um todo.
>
> Desde já ficamos a disposição para mais discussões, requisitos, e um
> desenvolvimento comunitário que possa mudar a realidade atual do setor
> em certos ambientes de rede.
>
> Abraços,
> Christian
>
> --
> Christian Esteve Rothenberg, Ph.D.
> Converged Networks Business Unit (DRC) / CPqD
> Tel.:+55 19-3705-4479 / Cel.: +55 19-8193-7087
> esteve at cpqd.com.br
> www.cpqd.com.br
>
> Em 24 de abril de 2012 13:46, Henrique de Moraes Holschuh
> <henrique.holschuh at ima.sp.gov.br> escreveu:
>> On 24-04-2012 12:51, Klaus Schneider wrote:
>>>
>>> Exatamente, o quagga não encaminha pacotes, serve apenas como route
>>> server, que seria a única semelhança com o PTT. O quagga suporta
>>> muitas sessões full(nunca usei com mais de 3, mas certamente suporta
>>>  mais de 10), coisa que fica um tanto complicado mesmo em um 7206 com
>>>  npe-g2. O problema de softrouters é exatamente capacidade de
>>> encaminhamento, e não estava discordando e sim concordando =)
>>
>>
>> Daqui a uns poucos anos, o roteador "caixa única" vai ficar obsoleto,
>> pelo menos em aplicações com fluxo de pacotes elevado e pouco
>> centralizadas:  você vai comprar o plano de controle de alguém (e também
>> terá a alternativa FLOSS), mas o plano de dados será distribuído, usando
>> switches OpenFlow ou equivalente.  Isso já existe como produto
>> comercial, mas ainda está caro.
>>
>> O ruim disso é o plano de controle ter uma topologia completamente
>> diferente do plano de dados.  Tem uns jeitos meio absurdos de resolver
>> isso.  O certo seria modelar o plano de dados no routing engine
>> consolidado, mas até lá dá para montar uma gambiarra usando uma árvore
>> de VMs que espelha a topologia real, e usar alguns recursos mais
>> avançados do OpenFlow para espelhar na topologia virtual o que realmente
>> está acontecendo no plano de dados.
>>
>> http://www.openflowhub.org/display/routeflow/RouteFlow+Home
>>
>> Aliás, essa do plano de controle não seguir o caminho do plano de dados
>> pode acontecer quando você usa refletores ou servidores de rotas.
>> Cuidado nesses casos, porque o iBGP não vai refletir a realidade dos
>> enlaces, e portanto o *IGP* e a topologia tem que garantir que nunca vai
>> haver particionamento no plano de dados que não seja detectável no plano
>> de controle (e vice-versa!).  Daí a recomendação de colocar os
>> refletores em caixas de meio de caminho, seguindo a topologia.
>>
>> Sinceramente, eu preferia que parassem de colocar CPU furreca nos
>> roteadores com portas Gigabit e encaminhamento por hardware.  Ninguém
>> vai reclamar que uma caixa ficou 1% a 5% mais cara porque no lugar de um
>> ARM ou MIPS com quase nada de memória, foi colocado um Mobile Processor
>> x86-64 com 8GiB de DDR3 ECC.
>>
>> --
>> Henrique de Moraes Holschuh <hmh at ima.sp.gov.br>
>> IM@ - Informática de Municípios Associados
>> Engenharia de Telecomunicações
>> TEL +55-19-3755-6555/CEL +55-19-9293-9464
>>
>> Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
>> e do custo que você pode evitar.
>>
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter

-- 
Christian Esteve Rothenberg, Ph.D.
Converged Networks Business Unit (DRC) / CPqD
Tel.:+55 19-3705-4479 / Cel.: +55 19-8193-7087
esteve at cpqd.com.br
www.cpqd.com.br