Resumo

  • Transport Class ID é uma Color de 32 bits atribuída pelo operador; identifica uma classe local, mas não descreve por si só as condições do SLA.
  • Quando a cor aparece no TEA, no Transport Class RT de BGP CT e na rota de serviço, o RFC prioriza sub-TLV do TEA, RT de transporte e Color do serviço, nessa ordem.
  • Importação, resolução, fallback, programação da FIB, encaminhamento observado e resultado do serviço são estados separados.

Uma classe depende de quem a define

O RFC 9832 agrupa em uma Transport Class túneis que o operador considera suficientemente semelhantes em características de engenharia de tráfego. RSVP-TE, SR-TE e Flex-Algo podem servir à mesma intenção, apesar de mecanismos diferentes. Baixa latência, proteção e desvio de certos nós são exemplos; a classificação exata permanece específica da implementação.

O identificador é um inteiro de 32 bits chamado Color. Zero representa Best Effort; os demais valores são de uso privado. Não existe uma tabela global em que 100 sempre signifique a mesma latência, perda ou proteção. Dois domínios podem compartilhar o número e divergir na promessa. Um terceiro pode usar outro número para uma intenção semelhante.

O registro de origem precisa juntar Color, domínio administrativo, definição mensurável, proprietário, escopo e versão. Sem isso, a igualdade de bits vira uma equivalência comercial que o protocolo nunca declarou.

A precedência não apaga os campos

O Color sub-TLV em Tunnel Encapsulation Attribute pertence ao contexto de uma encapsulação. O Transport Class Route Target em BGP CT orienta a importação em uma TRDB e pode atuar como Mapping Community. A Color Extended Community na rota de serviço expressa o pedido do overlay.

A seção 7.10 resolve conflitos pela indicação mais específica: TEA primeiro, Transport Class RT depois, Color do serviço por último. Essa regra torna a decisão determinística. Para torná-la auditável, é preciso preservar todas as entradas, o atributo portador, o peer, a versão da policy e o resultado efetivo.

Um painel que mostra só “Color 100” não explica se uma opção de encapsulação venceu a classe solicitada pelo serviço. A evidência está na decisão completa, não no valor final isolado.

TRDB é um limite do plano de controle

Cada Transport Class tem uma Transport Route Database lógica. Uma rota BGP CT transporta RD:endpoint, Transport Class RT e label MPLS ou identificador equivalente. Se a classe está provisionada, o papel de Route Target determina a TRDB de importação.

O próprio RFC admite que a TRDB seja implementada como tabela usada apenas para resolução de reachability do next hop. Suas rotas não exigem presença no plano de encaminhamento até resolverem um next hop. Portanto, rota importada não significa rota instalada, selecionada ou utilizada por pacotes.

Como Mapping Community, o RT encontra um Resolution Scheme local. O esquema contém uma TRDB ou uma sequência ordenada. A busca de prefixo mais longo usa a primeira base com correspondência para o endpoint; bases seguintes são fallback. Se não houver esquema para a classe, usa-se Best Effort. Se não houver Mapping Community, o comportamento também é Best Effort, e a rota BGP CT não entra em TRDB de classe.

Essa continuidade compatível pode esconder a perda do tratamento contratado.

O fallback precisa explicar a ausência

Uma correspondência na segunda TRDB não esclarece o motivo da falta na primeira. Pode ser falha de túnel, import policy, filtro RTC, endpoint incorreto, provisionamento defasado ou tecnologia incompatível. O algoritmo diz onde procurar; não identifica a causa.

O recibo de resolução deve guardar rota e peer recebidos, todos os campos Color, Mapping Community efetiva, versão do Scheme, ordem das TRDBs, base que respondeu, túnel escolhido e indicador de fallback. Sem correspondência em nenhuma base, a rota é não resolvível. Uma BGP CT route Best Effort inutilizável não deve ser propagada.

Route Target Constraint também decide distribuição. Ao construir o filtro de saída, múltiplos caminhos EBGP RTC devem ser considerados, e não apenas o best path. A ausência da rota pode começar na distribuição, antes do túnel.

A fronteira traduz o número local

No cenário de namespaces discordantes, o serviço mantém color:0:100500, mas cada domínio o mapeia para TRDB 500, 300 ou 100. Os roteadores de borda reescrevem Transport Class RT de 500 para 300 e depois de 300 para 100.

O desenho limita a coordenação a domínios vizinhos, uma vantagem operacional. Ele não prova que “Gold” tem a mesma especificação em todos eles. O recibo precisa preservar RT recebido e enviado, definições locais, acordo entre operadores, commit da policy, equipamento executor, horário e rollback. Guardar apenas 300 apaga a autorização da tradução.

Depois da resolução vem o pacote

Ao readvertise uma BGP CT route com next hop self em MPLS, o border node aloca label e instala uma rota que troca ou retira o label recebido antes de enviar o tráfego ao túnel resolvido. Implementações também podem instalar seletivamente BGP CT na FIB para peering de controle.

Ainda é necessário confirmar a entrada no hardware, a encapsulação comum e o caminho real. Nos exemplos de interoperabilidade, um nó somente MPLS e outro somente SRv6 continuam com rotas BGP CT inutilizáveis por não compartilharem tecnologia de encaminhamento.

O SLA só fecha com medições na fronteira do serviço: perda, latência, disponibilidade, proteção e janela temporal. O RFC 9832 é Experimental; publicação não comprova adoção nem desempenho. A errata verificada 8583 apenas corrige três menções de SN1 para SN11.

A tese de Heng Lu de que a Internet é “sem cor” recoloca a eficiência observável acima dos rótulos. Aqui, Color deve continuar sendo um índice testado por execução. Running-Code Primacy exige atributos, policy e FIB reproduzíveis; Reality Layers separa identificador, significado administrativo, controle, forwarding e resultado do cliente. São lentes editoriais do BTW, não novos requisitos do IETF.

Fontes