[GTER] Restrições em circuitos layer 2

Henrique de Moraes Holschuh henrique.holschuh at ima.sp.gov.br
Mon Apr 26 11:45:47 -03 2010


Herbert Faleiros wrote:
> 2010/4/23 Rubens Kuhl <rubensk at gmail.com>:
>> O fato de que apenas xSPs tenham demanda para esse nível de
>> transparência WAN não deve ajudar muito a estimular as operadoras a
>> ter um produto com essas especificações, pois isso iria requerer um
>> upgrade significativo de porte de equipamentos.
> 
> assim vai ficar difícil a adesão em massa aos PTT's (os pequenos já
> "emperram" na hora implementar BGP e/ou adquirir ASN + CIDR,
> felizmente não foi o nosso caso, imagina então ser impossível
> contratar um circuito "devidamente especificado" para ligar-se a um
> PIX membro de um PTT?). Imagina se a única maneira de um "pequeno"
> entrar num PTT for contratar espaço num datacenter, alocar um roteador
> ou switch lá dentro, ligar o NOC do AS ao datacenter via equipamento
> próprio lá alocado e de lá entrar no PIX?

É só o provedor pequeno comprar trânsito para PTT com alguém, que fica 
bem simples.  Ele sobe o peering com um AS só, usando ASN privado se 
quiser, e esse AS de trânsito anuncia as rotas do cliente ("provedor 
pequeno") só dentro do PTT, e anuncia para o cliente ("provedor 
pequeno") só as rotas aprendidas do PTT.  A complexidade técnica fica no 
tal provedor de trânsito para o PTT.

Não sei se tem operadora ou PIX prestando esse serviço, mas devem 
existir vários provedores já ligados ao PTT que estão dispostos a 
prestar esse serviço para outros provedores menores.

> A idéia de um PTT não é descomplicar? (dentre diversos outros
> objetivos mais específicos)

Ligar em PTT só é simples se você ignorar completamente os quesitos de 
segurança  :-(

> No meu entender um "clear channel" não deveria ter restrições tolas
> como as que aparentemente vem causando este problema (se é que a causa

Se tem essas restrições, não é clear-channel... é quasi-clear-channel :-)

> MAC-in-MAC foi a solução que eu encontrei p/ não impactar a
> infra-estrutura da operadora, existem outras mais simples (se a causa

MAC-in-MAC resolve o problema de transparência do enlace sim, se usar 
jumbo frame para manter o tamanho do payload, ou se você suportar baixar 
ainda mais a MTU.

Mas por acaso a operadora vai absorver a diminuição na eficiência do 
enlace?   Se eles te venderam como clear-channel, eles deveriam absorver 
a ineficiência do MAC-in-MAC.

Se as caixas deles fizerem MPLS, eles podem trocar sua porta para EoMPLS 
ou coisa parecida no lugar de usar MAC-in-MAC e QinQ...

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



More information about the gter mailing list