Resumo

  • Quando 255 octetos deixam de bastar, várias ocorrências do mesmo tipo e da mesma chave podem representar um objeto IS-IS; cada parte precisa ser analisável sozinha e o receptor deve reunir todas, sem depender da ordem ou do fragmento LSP.
  • O sub-TLV de capacidade tipo 30 é apenas informativo, não identifica codepoints individualmente e não pode mudar o que o protocolo envia ou aceita.
  • A autorização de implantação exige uma matriz externa que comprove cada implementação receptora no codepoint relevante, além de canário, critério de parada e reversão testada.

O ensaio de laboratório termina bem. Duas partes entram em ordens diferentes e o equipamento recompõe os mesmos atributos. A equipe registra “suporta MP-TLV” e prepara a mudança. Só depois alguém percebe que o ensaio cobriu um codepoint, enquanto a implantação pretende usar outro.

É justamente nesse intervalo entre uma etiqueta ampla e a capacidade concreta que mora a contribuição da RFC 9885. IS-IS carrega informações em tuplas Type-Length-Value. Como os campos Type e Length têm um octeto cada, um único TLV transporta no máximo 255 octetos de valor. Com redes maiores e mais atributos de engenharia de tráfego, um objeto lógico pode ultrapassar esse limite. A RFC consolida várias ocorrências como mecanismo padrão de expansão quando a especificação anterior não definiu outro.

Um MP-TLV não é um fluxo de bytes cortado onde houver espaço. As ocorrências pertencem ao mesmo objeto quando têm o mesmo tipo e, quando aplicável, a mesma chave já definida para aquele objeto. Cada parte deve ser analisável sem consultar as demais. Nenhum sub-TLV ou outra unidade de dados pode atravessar a fronteira entre partes; esse corte torna a codificação inválida.

O receptor recompõe o significado

Uma implementação compatível aceita as informações de todas as partes. A ordem de chegada e a posição em fragmentos LSP são irrelevantes. As partes podem estar no mesmo LSP ou em LSPs diferentes; em um IIH, a posição também não altera a interpretação. O receptor processa o conteúdo como uma concatenação lógica, descontando a chave repetida que preserva a identidade do objeto.

Isso não elimina conflitos. Um valor fixo, como uma métrica que não integra a chave, pode ser repetido com resultados incompatíveis. Um sub-TLV que deveria aparecer uma vez também pode surgir com valores concorrentes. Ambos os casos são erros. Se a especificação original não disser o que fazer, vale a primeira ocorrência no LSP de menor número; dentro de um IIH, vale a primeira ocorrência.

A RFC separa tolerância de recepção e disciplina de emissão. O receptor não pode rejeitar duas partes de 100 bytes só porque elas caberiam juntas. O emissor, porém, não deveria criar várias ocorrências enquanto os dados ainda couberem em 255 octetos e o codepoint não admitir o procedimento. Se o TLV inteiro ainda cabe, mas o LSP atual não tem espaço, é preferível mover o TLV completo para outro LSP.

Essa assimetria é deliberada. Aceitar uma forma válida, embora desnecessária, protege a interoperabilidade. Evitar a divisão sem necessidade reduz a superfície em que uma implementação antiga pode divergir. Um painel que mostra somente “recebido” confunde essas duas responsabilidades.

Um aviso que não negocia

Quando o suporte é parcial, um roteador pode escolher uma ocorrência e ignorar outra. Se a parte omitida contiver atributos de enlace usados em cálculo restrito, os dispositivos deixam de calcular sobre a mesma topologia. A RFC aponta o risco de encaminhamento inesperado, laços e descarte de tráfego. Não relata um incidente; define o perigo que a implantação precisa impedir.

Para ajudar o diagnóstico, foi criado o sub-TLV tipo 30, com comprimento zero, dentro de Router CAPABILITY. Ele anuncia suporte para codepoints em que textos anteriores deixavam a regra de múltiplas partes implícita. O escopo do TLV portador é por nível IS-IS.

O limite vem escrito no próprio padrão: o anúncio serve apenas para informação. A implementação não deve mudar o que envia nem a forma como processa o que recebe por causa dele. Não é negociação entre pares, consentimento distribuído ou trava automática.

O tipo 30 tampouco informa quais codepoints são suportados. O documento presume uma cobertura ampla, mas reconhece que uma implementação real pode ter construído MP-TLV apenas onde um cenário específico exigiu. O sinal parece um booleano; a realidade é uma matriz.

A coluna MP dos registros IANA responde a outra pergunta. Y significa que o procedimento se aplica à definição daquele codepoint. Não afirma que uma imagem instalada o implementa, que a geração está habilitada ou que todos os receptores de uma área chegaram à mesma interpretação.

A autorização fica fora do anúncio

A RFC recomenda controles de geração no nível de cada codepoint. Quando há desativação, a implementação deve registrar tanto o recebimento de um MP-TLV desabilitado quanto a necessidade local de gerar um enquanto a função está desabilitada. Esses registros mostram exposição e necessidade; não executam a decisão.

Antes de ativar, o operador deve provar que todas as implementações receptoras interpretam corretamente o codepoint em questão. Isso pede nível, papel, plataforma, versão instalada, bytes de teste, resultado de análise, cálculo de caminho, FIB e plano de retorno. A autenticação de IS-IS continua útil, mas uma informação de origem íntegra pode ser mal compreendida por um receptor antigo. Integridade e capacidade semântica são provas diferentes.

A primazia do código em execução impede o atalho. O registro define aplicabilidade. O roteador emite uma declaração ampla. Só o comportamento observado do binário exato que calculará e instalará a rota demonstra a condição decisiva.

Fontes