[GTER] O fim do mundo como nós o conhecemos

Douglas Fischer fischerdouglas at gmail.com
Fri Sep 14 16:15:40 -03 2012


Que "incentivo" melhor que a concessão?

As operadoras recebem a concessão condicionadas a diversos requisitos.
Não conheço a fundo, mas acredito que um deles seja algo como "acompanhar
evoluções tecnológicas".

 É só cumprir o que está previsto nas cláusulas dos contratos de concessão.
Não está cumprindo os requisitos? Perde a concessão...


P.S.: Puxo um gancho sobre o "Porque vocês não pegaram IPv6?".
      São não vou dar conta de cumprir, não assumo o compromisso.


Em 14 de setembro de 2012 15:56, Patrick Tracanelli <
eksffa at freebsdbrasil.com.br> escreveu:

>
> Em 14/09/2012, às 14:04, Rubens Kuhl escreveu:
>
> >> Você sabe se existe alguma estratégia, nem que em estágio de conversa
> de botequim para reciclar e pegar de volta CIDR alocados mas não em uso?
> >
> > Todos os RIRs e NIRs tem alguma política de recuperação de recursos.
> > No caso do NIC.br, vide:
> > http://registro.br/provedor/numeracao/recuperacao.html
> > (um web-archive desta página mostrará outros recursos já recuperados)
>
> Eu vi, me antecipei na dúvida aqui e o colega Gondim já tinha mencionado e
> me inteirei :D
>
> >
> >> Todos sabemos que aqui em terras tupiniquins, era uma prática comum
> simplesmente mentir descaradamente nos projetos para conseguir comprovar
> uso que justificasse alocação mínima de /20. Essa prática era comum também
> quando a tutela era da LACNIC, antes de ir pro NIC.Br, então temos anos
> dessa prática. No velho mundo idem, para alguns países.
> >
> > O que não impede que essas redes tenham crescido a ponto de hoje
> > justificarem um /20.
>
> Esperançosamente uma parte cresceu até além disso, mas na prática da pra
> ver que boa outra parte ainda nem preenche os requisitos de alocação
> inicial...
>
> >
> >> Além disso todos sabemos que as operadoras ao ativar um BGP com CIDR
> próprio para cliente que antes era com rede da operadora, só cobra
> "devolução" da rede alocada quando a própria operadora parece precisar. Mas
> acredito que nunca devolvam ao NIC.BR ou LACNIC ou outro regional, de
> forma expressiva.
> >
> > O NIC.br tem cobrado isso de redes que venham pedir novas alocações,
> > segundo relatos já publicados em listas. Vários operadores inclusive
> > reclamam de problemas em conseguir que os antigos upstreams desmarquem
> > as alocações que tinham.
> >
> >> Além disso temos uma série de CIDR alocados para ASN que nem sequer os
> anunciam. São coisas absurdas como ISPs com /19 alocado que anuncia (e
> consome) /22.
> >
> > Não é obrigatório anunciar os recursos de numeração de que dispõe na
> > DFZ. O uso interno em uma rede é um uso legítimo... obviamente a falta
> > de anúncio é um indicador de possível não uso.
>
> Mesmo colocando uma margem folgada para uso em infra-estrutura que não
> requer anuncio, e simplesmente não uso ainda mas expectativa de
> crescimento, vamos ter muitas e muitas alocações não anunciadas que não tem
> uma explicação rasoável que não seja ociosidade, hoje.
>
> >> Sem falar dos casos menos óbvios, de quem tem seu /20 padrãozão,
> anuncia seu /20 mas usa um /24 no máximo, as vezes /23. Esses dariam mais
> trabalho inventariar o quanto usam de fato.
> >>
> >> Mas enfim, eu tenho pra mim algo óbvio pra todos, que o v4 só está
> acabando em 2012/2013 porque no passado esse recurso escasso foi esbanjado
> e sua alocação racional negligenciada. E não falo de um passado de início
> da Internet civil, falo de poucos anos atrás. Estaria tudo bem se hoje o
> uso de fato tivesse aumentado, mas a alocação indiscriminada e concessão
> idem de CIDR do passado não reflete hoje em uso autêntico em grande parte
> dos casos.
> >
> > Eu acho que há casos globais bem mais graves de /8s dos velhos tempos...
>
> Sim, esses pelo que vi estão sendo "buscados" hehehe antes que alguém
> resolva atualizar a RFC1918 e enxugá-la um pouco pra tornar parte dela
> registrável.
>
> >> Vejo algo parecido hoje com a forma e tamanho com que o v6 vem sendo
> concedido e alocado e mais uma vez sem refletir integralmente sequer nas
> tabelas bgp v6. Mas devido ao tamanho do v6 tenho esperança de não ter
> chinês no mundo o suficiente ou endereçamento v6 mobile em peças de roupas
> o suficiente para concluir que a mesma coisa possa acontecer com v6, ao
> menos enquanto eu não estiver aposentado.
> >
> > A desagregação típica em v6 é menor do que em v4, o que é um indicador
> > positivo.
> >
> >> Ontem mesmo ouvi de um diretor de infra de uma grande empresa de mídia
> nacional dizer:
> >>
> >> "ah não pra que ipv6? quem tem que se preocupar com isso são os
> provedores que precisam endereçar os usuários, agora eu que sou o produto
> final de onde os usuários querem chegar, os provedores vão ter que dar seus
> pulos para trazerem seus clientes ipv6 para minha infra-estrutura ipv4"
> >
> > Até que as operadoras fechem acordos de conteúdo para seus usuários
> > que não incluam essa empresa de mídia justamente por ela não ter v6, o
> > que obriga a operadora a assumir maior custo de translação.
>
> Eu pensei em outra hipótese diferente de esperar o mercado se auto-ajustar
> e ilhar os v4-only, ou as empresas aposentarem antigos diretores em favor
> de outros mais "dispostos" a fazer alguma coisa. Algo diferente de não
> fazer nada e esperar.
>
> Estamos em 2012, acho razoável pensar que até 2014 da pra ter todos os
> servidores de correio e web dual-stack com DNS devidamente configurado.
> Acho razoável pensar que até 2016 provedores estejam entregando dual-stack
> pra usuários finais dentro de uma porcentagem mínima aceitável de novas
> ativações. Mas acho que sem um "incentivo" esses prazos vão pra depois da
> Copa do Mundo da Rússia, quem sabe do Qatar...
>
> --
> Patrick Tracanelli
>
> FreeBSD Brasil LTDA.
> Tel.: (31) 3516-0800
> 316601 at sip.freebsdbrasil.com.br
> http://www.freebsdbrasil.com.br
> "Long live Hanin Elias, Kim Deal!"
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
Douglas Fernando Fischer
Engº de Controle e Automação



More information about the gter mailing list