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

[Filho Arrais]

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