[GTER] Anúncios v4 /25 nos IX

[Davi Nunes]

@Rogerio

Em ter, 17 de jul de 2018 às 21:58, Rogerio Mariano <rsouza.rjo at gmail.com>
escreveu:

> Eu penso que nesse caso dos anúncios, o IX.br siga uma prática e senso
> comum em todos os IXPs vigentes no diretório da PCH (
> https://www.pch.net/ixp/dir) e e as incumbents do mundo, além do ponto
> principal: estarem aderentes e em acordo com a RFC 7454 e com a BCP 194
> (item 6.1.3 da BCP em lide). Fazer anúncio de prefixos > /24 IPv4 ou > /48
> IPv6 é deselegante e prejudica a tabela global da Internet. ISP
> desorganizado gosta de fazer isso.

 Eu não discordo de nada acima indo até o momento da fase 2 de esgotamento
do v4.

Mas, chegamos a fase 3 do esgotamento v4 e ainda por cima v6 mau caminhando.
Então, vendo como a coisa está caminhando, devido a politicas tomadas e
pensadas no não esgotamento do v4, chegamos a como estamos agora, então
assim como a implantação do v6, eu prego fortemente para que, sejam tomadas
boas práticas conscientes para o final do v4, uma vez que, quem estiver
chegando agora, está "pagando" o preço de quem chegou antes e ainda por
cima, não tem o "direito" de querer implantar as medidas por que elas foram
planejadas para digamos 60% .. no máximo 80%, mas iai quando chegamos em
81%, fingimos que está tudo bem e seguimos em frente?

Não que seja o caso do colega inicial, mas, entendeu a profundidade de se
manter rígido e não se adequar?

...ISP que conhece boas práticas de
> roteamento, *sabe o que faz e não comete essa heresia¹*. Em resumo, penso
> que
> nesse caso o IX.br esta apenas seguindo um padrão adotado mundialmente e de
> boa prática no qual todo ASN Brasileiro deveria seguir.
>

Vou voltar a destacar o que me referi, estamos usando uma formula de medida
para proporções erradas e tempos errados

¹cadê IPv6 ativo e sendo largamente distribuído? (isso também é uma heresia
concorda?)



>
> Saudações,
>
> RMS
>
> Em 17 de julho de 2018 15:40, Roberto Alcântara <roberto at eletronica.org>
> escreveu:
>
> > Rubens,
> >
> > Não consegui contar só os /24 para fazer a conta, então vai com todos
> > mesmo:
> >
> > Se o router-server do nosso maior IX tem hoje 93k prefixos, mesmo que
> todos
> > os prefixos atuais fossem /24 (não são) e então desagregados em /25 (não
> > serão),  não chegaria a 30% de uma sessão full-routing. Continuo sem
> > entender porque isso é um risco à escalabilidade.  Não me parece razoável
> > supor que todos os /8 do IX seriam desagregados em /25 (assim como não
> são
> > em /24).
> >
> > Eu entendo a decisão de não desagregar mais a tabela v4 global
> > perfeitamente. Mas no caso do *ATM dos IXs*, considerando que a escolha
> do
> > Registro.br de menor alocação possível para clientes finais foi o /24 (e
> > /48), me parecia razoável que o IX suportasse os /25 para conseguir
> atrair
> > o tráfego regional.
> >
> > O fato é que quem possui alocação de cliente final tem dificuldade de
> > influenciar o tráfego pelo IX regional, mesmo que suas operadoras de
> > trânsito estejam no IX... E isso é ruim p/ a região.
> >
> > sds,
> >   - Roberto
> >
> >
> > Em ter, 17 de jul de 2018 às 14:21, Rubens Kuhl <rubensk at gmail.com>
> > escreveu:
> >
> > > > Com a restrição ao /25 *nos router-server do IX* limitam-se as opções
> > por
> > > > atrair o tráfego regionalmente para quem é cliente final e recebeu as
> > > > alocações mínimas. O MED pode ser uma alternativa, mas é outra
> > conversa.
> > > >
> > > > No caso em questão, *dentro do ATM do IX*, não consigo observar como
> o
> > > > crescimento da tabela pode ser um problema real ao aceitar prefixos
> > /25.
> > > O
> > > > número de prefixos no route-server já é limitado pela própria
> natureza
> > > > regional do IX.
> > > >
> > > >
> > > Um dia o PTT-ANSP já teve só 5 membros... hoje o IX.br de SP tem um
> pouco
> > > mais do que isso. Não se pode colocar algo que pode causar limitação de
> > > crescimento só porque um IX ainda seja pequeno.
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>