Resumo

  • A RFC 9862 representa uma política SR por uma associação PCEP e cada caminho candidato por um LSP. O caminho é a unidade de sinalização, mas certas decisões só existem quando se considera a associação inteira.
  • O TLV INVALIDATION carrega o sinalizador D de configuração em um caminho candidato. Se qualquer caminho o habilitar, Drop-Upon-Invalid vale para toda a política SR; o descarte só começa depois que todos os caminhos candidatos ficam inválidos.
  • Um comprovante de descarte no nível da política deve reunir capacidades negociadas, membros completos, D configurado e operacional, instante do limiar, caminho escolhido e resultado nos pacotes. É uma proposta editorial de Daniel Kade, não um campo da RFC nem uma exigência do IETF.

Um alerta vermelho ao lado de um caminho parece local. Ele chegou em um objeto LSP, está ligado ao identificador daquele caminho candidato e cabe em uma coluna da mesma linha. O modelo de armazenamento pode estar tecnicamente correto e, ainda assim, produzir uma explicação errada se presumir que o efeito termina onde o dado foi codificado.

Drop-Upon-Invalid é configurado pelo TLV INVALIDATION de um caminho candidato, mas não é habilitado apenas para esse caminho. Um único candidato com D de configuração basta para que a política SR inteira tenha a função. Nesse momento ainda não há descarte. Outra condição precisa ocorrer: todos os candidatos da política tornam-se inválidos. Só então a política entra em estado de descarte, escolhe o candidato habilitado de maior Preference e continua atraindo o tráfego para descartá-lo no headend, em vez de permitir um fallback comum.

O objeto que leva a intenção, o conjunto que atravessa o limiar, a política que muda de estado e os pacotes que sofrem o efeito são unidades diferentes. Reduzi-las a “D=true” preserva o formato e apaga a responsabilidade.

Uma associação por política, um LSP por possibilidade

Uma política SR contém um ou mais caminhos candidatos. A RFC 9862 introduz a SR Policy Association, ou SRPA, para representar essa política em PCEP. Cada LSP dentro da associação corresponde a um caminho candidato. O arranjo respeita a gramática existente porque o LSP é a unidade que PCEP sinaliza, atualiza e reporta.

Essa escolha cria uma obrigação de correlação. Informações sobre a política são transportadas no nível do candidato, até quando seu significado depende de todos os membros. A SRPA oferece a chave para reconstruir o conjunto, mas não garante que a plataforma operacional preserve a fotografia usada na decisão. Reinício de sessão, inclusão ou retirada de caminho e telemetria amostrada podem deixar apenas o último LSP que emitiu alarme.

Cor e endpoint identificam a política; originador e discriminador participam da identidade do candidato. Um candidato pertence a no máximo uma SRPA, seu identificador fica estável durante a sessão PCEP e não pode ser repetido na mesma política. Isso permite uma junção confiável. Ainda é preciso materializá-la com tempo e proveniência.

As capacidades também têm escopo estreito. Os dois pares anunciam suporte a SRPA antes do uso; quem anuncia deve incluir a associação em cada LSP de política SR que origina. O TLV SRPOLICY-CAPABILITY separa suporte para prioridade de computação, Explicit NULL, invalidation e operação stateless. Uma SRPA recebida sem capacidade negociada gera erro e fechamento de sessão. A evidência confirma que os pares podiam falar a mesma linguagem, não que todo caminho estava inválido nem que houve perda de pacote.

O mesmo D pode ser intenção ou estado

O TLV INVALIDATION possui campos Config e Oper. No primeiro, D significa que o caminho candidato está configurado para habilitar Drop-Upon-Invalid. No segundo, D significa que o LSP está ativamente descartando tráfego em razão da função. Compartilhar a letra não transforma configuração em resultado.

A direção da mensagem completa o sentido. PCE para PCC leva a instrução de ativar ou desativar. PCC para PCE informa o ajuste atual e se o LSP está no estado de descarte. Uma base que guarda apenas o último D, sem locutor, direção, sessão e horário, pode registrar uma ordem como confirmação e uma expectativa como observação.

O comportamento normal ajuda a enxergar a escolha. Um LSP inválido deixa de atrair tráfego, que pode seguir por outro LSP ou pelo IGP. Drop-Upon-Invalid faz o contrário deliberadamente: mantém a atração e descarta no headend. Isso pode ser sensato quando escapar para uma rota não autorizada seria pior que interromper. Pode também ampliar uma falha quando a configuração está velha ou mal aplicada. A RFC torna o mecanismo interoperável; não escolhe o risco em nome do operador.

Mesmo o D operacional não prova sozinho o resultado de dados. Contadores de encaminhamento e observação de tráfego precisam dizer se os pacotes chegaram, quanto foi descartado e por quanto tempo. Sinalização, estado interpretado e consequência física continuam separados.

A última validade perdida é o gatilho real

Pela RFC 9256, uma política SR fica inválida quando todos os seus caminhos candidatos estão inválidos. Trata-se de um predicado sobre conjunto. A primeira falha reduz resiliência; outra pode trocar o caminho ativo; a política só cruza seu limite quando o último candidato válido falha.

Nesse instante, a política verifica se algum candidato tinha Drop-Upon-Invalid habilitado. Se havia, entra no estado de descarte e ativa o candidato habilitado de maior Preference. A RFC 9862 diz que basta reportar ao PCE um candidato com o D operacional. É suficiente para o protocolo, mas não descreve toda a causalidade.

Considere três candidatos. Um caminho antigo de baixa Preference manteve D por causa de uma decisão anterior. Os dois candidatos principais não têm D. Eles podem falhar sem iniciar descarte enquanto o terceiro segue válido. Quando esse último falha, o ajuste antigo habilita o efeito para a política inteira. O LSP que exibe D operacional mostra o portador atual, mas não quem aprovou o ajuste, por que ele continuou válido ou qual transição completou o estado “todos inválidos”.

Preference não deve ser confundida com computation priority. A Preference do candidato seleciona o melhor caminho: valores maiores vencem e o padrão da RFC 9256 é 100. A prioridade de computação da RFC 9862 ordena recálculos após mudança de topologia: valores menores vêm primeiro e o padrão condicional é 128. Um único campo chamado “prioridade” pode inverter o raciocínio sem parecer absurdo.

Ausência pode significar escolha local

Há ausências deliberadas no protocolo. Se a capacidade correspondente existe e o TLV de prioridade de computação não aparece, usa-se 128. Se o TLV de Explicit NULL não aparece, a configuração local decide. Esse TLV vale para SR-MPLS, deve ser ignorado para SRv6, valores desconhecidos também são ignorados e o operador pode substituir o comportamento sinalizado por uma decisão local.

Portanto, vazio não é sinônimo de política inexistente. Pode acionar padrão, delegar, indicar inaplicabilidade ou ter sido superado. Para explicar um descarte, é preciso preservar o valor efetivo, sua fonte, precedência, versão do software e sessão PCEP.

A RFC 9862 exige que o operador consiga visualizar os identificadores de política e caminho anunciados na SRPA. Recomenda ainda visibilidade sobre capacidades do par e LSPs associados a uma política. É o conjunto mínimo para investigação. Uma explicação durável deve transformar as telas em uma transição atribuível.

Um comprovante para a expansão de escopo

O comprovante de descarte no nível da política começa com cor, endpoint, SRPA, sessão PCEP e capacidades vistas nos dois lados. Em seguida, congela a lista completa de candidatos usada na decisão, incluindo originador, discriminador, Preference, D configurado e validade.

Depois vem a sequência. Para cada caminho, quando e por qual observador ele ficou inválido? Qual foi o último candidato válido? Em que instante “todos inválidos” virou verdadeiro? Quais candidatos tinham D naquele momento? Qual deles, por maior Preference, tornou-se o portador do descarte? Em qual direção apareceu o D operacional? Diferenças entre intenção PCE e relatório PCC devem permanecer visíveis.

Por fim, o plano de dados. O tráfego continuou sendo conduzido à política? Quais contadores registraram descartes no headend? Quando ocorreu o primeiro e o último? A recuperação veio de um caminho novamente válido, alteração da configuração, mudança de membros ou retirada da política? O comprovante inclui responsável, serviço protegido, revisão, exceção e retorno.

Não se trata de exportar topologia a uma autoridade central. SRPA e TLVs podem revelar informação de política. Por isso a RFC 9862 herda a recomendação de sessões PCEP autenticadas e criptografadas com TLS entre PCE e PCC sob a mesma autoridade administrativa. O comprovante deve ser local, controlado e mínimo.

Ele também não é uma extensão do padrão. É uma disciplina editorial para evitar que a posição de um bit seja tomada pelo alcance real da decisão.

Sources