[GTER] Contratacao Canal

[Rubens Kuhl Jr.]

Tratamento de DoS nao e' uma questao de boa-vontade; disponibilidade e'
parte do servico, e um backbone que queira dizer que vende
disponibilidade tem que tar boa atuacao para resposta a DoS. Isso inclui
tanto procedimentos automaticos baseados em communities, quanto
procedimentos de acionamento e reacao manual.

Quanto a spam, vale ter isso como um metrica qualitativa, mas nao
influencia diretamente o servico contratado por um AS, pois a nao
resposta a spam de um backbone vai jogar esse AS e seu CIDR no limbo,
nao o de que compra transito desse AS.
Nao responsividade a spam afeta diretamente clientes que usam Ips de um
backbone, como clientes de hosting, LP e broadband.


Rubens




-----Original Message-----
From: gter-admin at eng.registro.br [mailto:gter-admin at eng.registro.br] On
Behalf Of Jeronimo de A Barros
Sent: Tuesday, June 11, 2002 10:45 AM
To: gter at eng.registro.br
Subject: Re: [GTER] Contratacao Canal


Oi...

	Carlos, faltou falar tambem da necessidade de uma equipe de
seguranca seria, atuante e com autonomia suficiente para resolver
incidentes de seguranca e daquele outro problema tabu na GTER mas que e'
uma praga na Internet.

	Quando aparece um DoS por exemplo, a ajuda e boa-vontade do
backbone e' vital para a resolucao do problema.

Abracos, Jero

On Mon, 10 Jun 2002, Carlos Ribeiro wrote:

> Date: Mon, 10 Jun 2002 21:32:22 -0300
> From: Carlos Ribeiro <cribeiro at mail.inet.com.br>
> Reply-To: gter at eng.registro.br
> To: gter at eng.registro.br
> Subject: Re: [GTER] Contratacao Canal
>
> On Mon 10 Jun 2002 19:30, you wrote:
> > Iremos contratar mais alguns enlaces para nosso AS e gostaria de 
> > algumas sugestoes sobre a especificacao (conexoes bacbone, n. hops,
SLA, etc...)
> >   para ver se nao estamos esquecendo de nada e garantir, ou melhor, 
> > diminuir o risco de problemas.
>
> Daniel,
>
> Até onde eu saiba, ainda não temos um documento que possa servir como 
> base para uma especificação desse tipo. Por enquanto, cada um avalia 
> estas informações de uma forma diferente. O que posso fazer é comentar

> sobre algumas dicas, em caráter geral.
>
> (a propósito, este assunto vai diretamente de encontro a um documento 
> que comecei a compor, que busca definir uma 'taxonomia de acesso 
> Internet. circulei recentemente um sumário no grupo. espero que 
> possamos chegar a um consenso a respeito do tema).
>
> As principais medidas de qualidade (indicadas pelo SLA) são a latência

> e perda de pacotes. O problema é que a definição destes parâmetros é 
> muito vaga, tornando qualquer comparação um exercício de futilidade. 
> Sem entrar em detalhes, verifique se o SLA oferecido estabelece 
> definições precisas e critérios claros de medição para os parâmetros 
> contratados.
>
> Alguns itens que eu pessoalmente considero mais importantes do que o 
> SLA são:
>
> - Acesso direto ao pessoal de roteamento IP para ajustes rápidos e 
> eficazes. Em geral, o telefone de acionamento cai em um operador que 
> não tem condições de ajudar no caso de problemas. O processo de 
> escalation deve ser rápido e eficaz. Uma exigência que costumamos 
> fazer é de ter acesso direto ao pessoal de melhor nível técnico. Isso 
> não é usual - afinal, são poucas as pessoas qualificadas, que não 
> podem perder tempo atendendo qualquer tipo de pedido. Nosso argumento 
> é de que quem está abrindo o pedido também tem no mínimo a mesma 
> qualificação; ou seja, se nós queremos falar com alguém de alto nível,

> pode ter certeza de que nós sabemos do que estamos falando.
>
> - competência da equipe de roteamento IP. Certifique-se de que o 
> pessoal que vai atendê-lo realmente entende do assunto. BGP4 não se 
> aprende em qualquer cursinho, exige prática. Certificações ajudam, mas

> em geral uma visita ao centro de gerência, com a oportunidade de 
> conversar com as pessoas diretamente, vai resolver muito mais.
>
> - elasticidade, ou seja, a capacidade de oferecer 'banda sob demanda'.

> Imagine que você perde um link, e precisa redirecionar o tráfego. 
> Pontos para o provedor que conseguir reconfigurar o link em tempo 
> hábil, aliviando o congestionamento.
>
> - política de roteamento BGP4 clara, preferencialmente com suporte a 
> mecanismos avançados, como autenticação, filtragem de rotas, RPF, 
> communities, etc.
>
> Bom, deve ter muitas coisas mais, mas isso é um começo.
>
>
> Carlos Ribeiro
> CTBC Telecom
> --
> GTER list    http://eng.registro.br/mailman/listinfo/gter
>

--
GTER list    http://eng.registro.br/mailman/listinfo/gter