[GTER] Propostas de Large Communities no IX.br: UF e Traffic Engineering por localidade

[Gabriel Wolp]

Olá,
Desculpe a resposta o tanto quanto tardia,
Mas gostaria de pontuar que achei sua contribuição excelente.
Sobre a localização do AS do Anuncio, Gostaria de incluir a seguinte
contribuição:
Possibilidade ao anunciante de cada prefixo, realizar a substituição
do valor atribuído pelo ix ao ASN como um todo, como por exemplo:
ASN de Belo Horizonte 031
10.31.0.0/24 > Bloco Anunciado Sem Community: 26162:031:0 > Belo Horizonte
Override de Localidade pelo anunciante do bloco:
10.0.0.0/24 > 26162:085:0  -> Ceará
10.0.1.0/24 > 26162:061:0  -> Distrito Federal
10.0.2.0/24 > 26162:071:0  -> Bahia
10.0.3.0/24 > 26162:094:0  -> Pará

Obrigado
Gabriel Wolp
Engenharia - UltraFiber

Em ter., 24 de mar. de 2026 às 22:34, Filho Arrais via gter
<gter at eng.registro.br> escreveu:
>
> Prezados membros do GTER e da comunidade IX.br,
>
> Gostaria de compartilhar duas propostas de Large Communities para o
> IX.br que, na minha visão, podem trazer ganhos operacionais relevantes
> aos participantes. Ambas dialogam com temas debatidos no IX Fórum
> Fortaleza 2026, o que reforça a utilidade de uma discussão mais formal
> sobre o assunto.
>
> ----------------------------------------------------------------------
> 1. Sinalização de UF do ASN
> ----------------------------------------------------------------------
>
> Hoje o IX.br já realiza o marcação de prefixos com a região RIR de
> origem (Afrinic, Apnic, Arin, Lacnic, Ripe, Brazil/NIC.br). A proposta
> é estender essa lógica para sinalizar também a UF (Unidade da
> Federação) do ASN para recursos alocados pelo Registro.br.
>
> Modelo sugerido, usando o DDD representativo da UF:
>
>   26162:085:0  -> Ceará
>   26162:061:0  -> Distrito Federal
>   26162:071:0  -> Bahia
>   26162:094:0  -> Pará
>   ...
>
> Motivação:
>
> Em muitos cenários, a latência sozinha pode induzir decisões erradas de
> engenharia de tráfego. Como exemplo, é possível estar fisicamente no
> mesmo datacenter do PIX em São Paulo, Fortaleza ou Brasília, mas com a
> origem ou o destino real do tráfego a milhares de quilômetros dali.
>
> Nesses casos, a latência local não reflete a topologia lógica do fluxo.
> Uma sinalização simples de UF daria ao participante mais contexto
> geográfico para tomada de decisão de roteamento.
>
> ----------------------------------------------------------------------
> 2. Large Communities de TE por localidade
> ----------------------------------------------------------------------
>
> A segunda proposta é adicionar uma dimensão de localidade (DDD) às
> ações de Traffic Engineering, mantendo compatibilidade com o modelo
> atual de Large Communities.
>
> Motivação:
>
> Hoje, quando um participante deseja aplicar política sobre outro
> participante presente em múltiplas localidades, a ação tende a ser
> global. Dependendo do caso, isso pode causar um bloqueio completo entre
> os dois ASNs, mesmo quando a intenção era atuar apenas em uma praça
> específica.
>
> Esse risco é ainda maior quando a sinalização é propagada via upstream
> de trânsito, já que o originador não controla diretamente todas as
> localidades nas quais o peer está presente.
>
> Modelo sugerido:
>
>   Família por localidade:
>     26162:64DDDA:ALVO -> anunciar exclusivamente para ALVO na localidade DDD
>     26162:65DDDA:ALVO -> no-export/prepend para ALVO na localidade DDD
>
>   Campos:
>     DDD -> código de 3 dígitos da localidade
>     A       -> ação
>              0 = no-export
>              1 = prepend 1x
>              2 = prepend 2x
>              3 = prepend 3x
>   ALVO -> ASN do participante alvo
>
>   Exemplos:
>     26162:650110:65001 -> no-export apenas em São Paulo (011) para o AS65001
>     26162:640850:65002 -> anunciar exclusivamente em Fortaleza (085)
> para o AS65002
>     26162:650612:65003 -> prepend 2x em Brasília (061) para o AS65003
>
> Entendo também que o uso do ASN 26162 nessa família é mais coerente do
> que depender de 65000, que já é amplamente utilizado de forma genérica
> por diversas operadoras, inclusive em contextos externos ao IX.
>
> ----------------------------------------------------------------------
> Benefício esperado
> ----------------------------------------------------------------------
>
> As duas propostas são incrementais e compatíveis com a arquitetura de
> Large Communities já em uso.
>
> A sinalização de UF adiciona contexto geográfico útil para decisão de
> roteamento.
>
> Já o TE por localidade permitiria aplicar políticas de forma mais
> cirúrgica, reduzindo impacto colateral entre localidades e trazendo
> mais previsibilidade operacional, inclusive em cenários mediados por
> trânsito.
>
> Os demais membros da comunidade enxergam valor nessa linha de evolução?
>
> Atenciosamente,
> Filho Arrais
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter