[GTER] Desvio de trafego de transito pelo PTT

[Andrez]

2013/2/26 Henrique de Moraes Holschuh <hmh at hmh.eng.br>:
> On Tue, Feb 26, 2013, at 10:01, Andrez wrote:
>> > As communities poderiam se referir ao ASN do route-server do PTT, que
>> > são 16 bits. Realmente seria só definir e fazer.
>
> Bloqueio por communities tem um problema: ele é unidirecional.  Você pode muito bem definir nos route-servers do ATM do PTT que uma community estendida (para não dar problema com AS4) indique para NÃO exportar aquela rota para um determinado cliente.  Só que isso não influi as rotas inversas (ou seja, seu tráfego de saída)...
>
> Você precisa então adicionar as communities na sua saída para bloquear o anúncio das rotas para o AS remoto, e filtrar na entrada para não aprender nenhuma rota do AS remoto nas sessões com o PTT.  Já chegou no nível de complexidade operacional onde é preferível simplesmente pedir para o NOC do PTT para filtrar bidirecionalmente nos route-servers.
>

Pois é... acho que o esforço valeria a pena. Se isso se torna um
mecanismo confiável temos um tempo de resposta muito inferior ao das
trocas de e-mail com o NOC do PTT.

> Agora, tem o cenário mais divertido: AS A tem os AS P1 e P2 como provedores de trânsito, e todos os três estão presentes no PTT.  AS A não só tem que filtrar P1 e P2, como ainda por cima precisaria que eles não anunciassem seu prefixo no PTT se for para manter todo o tráfego de trânsito no enlace de trânsito correspondente (tipicamente por motivos técnicos).
>

Isso é bem mais fácil de contornar com a operadora implementando uma
community NO_EXPORT_TO_PTT_X / NO_EXPORT_TO_ALL_PTTS e o cliente
fazendo um filtro simples por AS_PATH.

> Me parece que a GVT está se excedendo, na tentativa de evitar que tráfego destinado para ela por clientes de trânsito dela não prefira ir pelo PTT através de um terceiro (outro provedor de trânsito).
>
>> Se isso acontecesse em um scopo maior seria muito interessante mesmo. Algo
>> como o resultado de uma GTER para uma política/recomendação geral
>> brasileira para communities. Seguindo os mesmos moldes em que o AS anuncia
>> se implementa ou não.
>
> Communities (mesmo extended communities) não são a ferramenta mais adequada para isso.  O melhor seria um painel de controle unificado, onde você declara com quais ASN não quer trocar rotas, e em quais PTTs (tipicamente, todos).
>
Também acho isso melhor em quase todos os aspectos e ainda melhor se
essa tabela for pública, ou no mínimo visível pelo AS afetado.

> É IMPORTANTE OBSERVAR QUE ESSE SERVIÇO JÁ EXISTE, mas no lugar de uma interface web, você envia um simples email pra o NOC do PTTMetro pedindo que "por favor filtrem em todos os PTTs nos quais participo para que meu AS X não troque rotas com o AS Y".
>
> O NOC do PTT coloca filtros bidirecionais no ATM: se você não quer receber rotas do AS A, o AS A também não vai mais receber as suas rotas.
>

Certo... mas partindo da premissa que a troca de tráfego já é uma
atitude de colaboração, acho que no ambiente do ATM essa colaboração
seria quase uma regra. Independente do que seja fornecido como
alternativa pelo PTT, seria muito bom que esse acordo multilateral de
troca de tráfego também envolvece um cordial acordo de políticas de
colaboração da engenharia de tráfego. Casos mais complicados onde essa
política esteja sendo destratada, ou distratada, ai acho que é hora do
PTT fazer o que já faz hoje.

Acho que devemos esperar um mínimo de interesse e competência dos ASs.
Incluindo operadoras.

> Agora, escrever uma recomendação de mapa de communities para servir como exemplo, são outros quinhentos. Aliás, tenho uma para lá de completa já pronta, que ia ser implantada eventualmente no AS53116.  Se houver interesse, podemos reunir alguns exemplos deste tipo na lista, discuti-los, e apresentar publicamente numa próxima GTER.

Eu tenho interesse. Podemos iniciar outra thread para não terminar de
roubar a thread atual! :) Começar como exemplo já seria bom mas
discutir e tornar isso uma recomendação ou política do GTER seria bem
mais legal.( sei que não existe mas acho que poderia existir )

> --
> gter list    https://eng.registro.br/mailman/listinfo/gter

[]'s

-- 
Atenciosamente.
Eduardo Andrez de Oliveira.