Resumo

  • O draft-ietf-mpls-frr-ext-00 permite que o ingresso de um LSP RSVP-TE peça objetivos de otimização e limites métricos rígidos aos pontos que calculam LSPs de proteção. O PLR ativa FRR_EXT protection quando atende ao pedido e pode adotar a política local sem ativá-lo quando não consegue satisfazer as condições.
  • O bit é uma resposta comum e útil, não um histórico da decisão. Cada PLR precisa de um registro que una pedido, capacidade, motivo do recuo, versão da política, origem e idade das métricas, contexto do cálculo e provas posteriores de validade.

A exceção cabe em um bit; a explicação não

Considere um LSP protegido com quatro Points of Local Repair, os PLRs. O ingresso solicita aos quatro que minimizem o atraso médio, mantenham o atraso acumulado abaixo de um teto e evitem qualquer enlace cuja variação ultrapasse outra marca. A resposta volta com três sinalizadores presentes. O quarto está ausente.

O painel pode pintar esse quarto ponto de vermelho. A conclusão ainda seria prematura. O equipamento talvez não reconheça FAST_REROUTE_EXT e tenha ignorado o objeto, como exige o caminho de compatibilidade. Talvez o reconheça, mas não encontre rota que caiba em todas as condições e, por isso, aplique sua regra local. Também é possível que não tenha recebido configuração estendida explícita e que a política do PLR fosse a autoridade prevista desde o início.

Esses cenários podem terminar com uma rota de proteção existente. O que muda é a razão pela qual ela foi escolhida e quem responde por ela. Tratar todo bit ausente como falha mistura inventário de capacidades, projeto de política, qualidade de dados e viabilidade topológica. Tratar qualquer backup como conformidade, por outro lado, esvazia a intenção enviada pelo ingresso.

Não é necessário transformar o protocolo em sistema de auditoria. É necessário manter, fora dele, uma memória capaz de distinguir as decisões que o indicador deliberadamente comprime.

O ponto institucional da revisão 00

Publicado em 23 de agosto de 2026, draft-ietf-mpls-frr-ext-00 é a primeira revisão sob o nome do grupo MPLS de Signaling Optimization Objective and Bounded Metrics for MPLS Fast Reroute Backup LSP Tunnels. O Datatracker o mostra como documento ativo do grupo, no estado IESG I-D Exists. O cabeçalho indica Standards Track e expiração em 24 de fevereiro de 2027. Não é RFC, não recebeu aprovação do IESG e não comprova implementação.

O texto substitui draft-deshmukh-mpls-frr-ext-02. Em 18 de agosto, a presidência do grupo registrou a adoção do antecessor e pediu a republicação como draft-ietf. O anúncio de 23 de agosto confirma que a nova versão é item de trabalho do MPLS. Essa passagem atribui manutenção coletiva ao grupo; não congela a solução nem a transforma em prática operacional.

O alicerce é o RFC 4090. Ele define a reparação local de LSPs RSVP-TE e o objeto FAST_REROUTE, que leva prioridades, afinidades, limite de saltos e largura de banda. A proposta nova acrescenta o objeto companheiro FAST_REROUTE_EXT, baseado em TLVs, para que o ingresso influencie os objetivos e os limites usados no cálculo do backup em cada PLR.

O ingresso pode mandar o backup herdar as condições do LSP protegido ou fornecer valores diferentes. Sem configuração explícita, vale a política local do PLR. A arquitetura não entrega a decisão inteira a uma cabeça central; distribui um pedido por vários calculadores autônomos.

Primeiro filtrar, depois escolher

Os objetivos de otimização abrangem métrica IGP, métrica TE, largura de banda não reservada e atraso mínimo, médio ou máximo. Custos e atrasos são minimizados; a banda não reservada é maximizada. É possível incluir diversos objetivos distintos e atribuir pesos de normalização.

As métricas limitadas fazem outro trabalho. Elas são condições rígidas: uma rota que não satisfaz o limite nem entra na disputa. O escopo pode ser o caminho todo ou cada enlace. O limiar de variação de atraso só existe no escopo do enlace. A mesma métrica pode ter, portanto, um teto de caminho e outro por enlace.

Quando chegam dois limites do mesmo tipo e escopo, apenas o primeiro é processado. Os demais devem ser ignorados. Essa regra simples reforça a necessidade de guardar a sequência exata do pedido: uma tela que apenas lista os valores, sem a ordem efetivamente recebida, pode explicar um cálculo diferente daquele executado.

O rascunho deixa fora de seu escopo os critérios usados para escolher objetivos e limites. Também não converte um peso em descrição completa do método de normalização. É razoável: redes e compromissos variam. Mas a escolha local não pode ser reconstruída apenas com a sintaxe padronizada.

Delegação, versão antiga, impossibilidade e erro estrutural

Na delegação, o ingresso não envia objetivo estendido. A regra local decide por desenho. Nenhuma promessa central foi quebrada.

Na compatibilidade, o PLR não entende o novo objeto. Ele o ignora e o encaminha intacto. O backup continua sujeito à política local. Para explicar o resultado, a operação precisa saber qual capacidade e versão estavam ativas naquele instante.

No recuo consciente, o PLR entende o objeto e aplica os limites como condições rígidas, mas não encontra uma rota aceitável. O texto permite voltar à política local e proíbe ativar FRR_EXT protection no subobjeto RRO correspondente da resposta Resv. Aqui a ausência do bit deve levar ao limite que falhou e à alternativa realmente escolhida.

Há ainda o pedido estruturalmente inválido. Um PLR capaz que receba FAST_REROUTE_EXT sem o FAST_REROUTE companheiro deve rejeitar a mensagem Path com Policy Control Failure. Esse retorno explícito pertence à correção do emissor, não à discussão sobre autonomia do PLR.

Cada situação pede um responsável diferente. Misturá-las em um alerta genérico cria demora e incentiva soluções erradas, como trocar equipamento quando o limite é impossível ou relaxar a política quando o problema é apenas a mensagem formada de modo incorreto.

O sinalizador presente não é um ensaio de falha

Quando atende aos objetivos e limites recebidos, o PLR deve marcar o novo bit no RRO. O ingresso consegue observar o resultado de cada ponto, em vez de supor que uma reserva bem-sucedida significa obediência uniforme. Essa granularidade merece ser preservada.

Seu alcance, contudo, é estreito. A marca registra a afirmação do PLR naquele momento de sinalização. Não identifica a geração da base TE, a idade da amostra, a versão do algoritmo, os candidatos excluídos nem o procedimento usado para comparar objetivos de unidades diferentes. Uma mudança posterior de topologia, carga ou reserva pode invalidar as condições sem mudar a interpretação histórica daquele bit.

Também não prova que o tráfego foi desviado. O RFC 4090 prepara reparos locais para reduzir o tempo de reação a falhas. Uma resposta positiva não garante que o detector funcione, que o estado continue instalado, que principal e backup não compartilhem um risco físico, que exista capacidade quando a falha ocorrer ou que o serviço fim a fim cumpra uma meta.

A autenticação criptográfica de RSVP protege a mensagem contra alteração quando corretamente implantada. Ela não atualiza um dado antigo nem documenta a autoridade da política. Uma declaração autêntica pode ter sido calculada com insumos inadequados.

Todo número carrega um relógio

Os RFCs 7471 e 7810 estruturam atributos de desempenho para engenharia de tráfego em OSPF e IS-IS. Eles ajudam a disseminar informações de atraso e outras métricas. O PLR pode consumir uma base TE formada por esses mecanismos, por configuração estática ou por outra fonte local. O rascunho de FRR não escolhe uma fonte universal.

Uma média observada há segundos e um valor configurado meses antes podem ocupar o mesmo campo. A banda não reservada muda conforme classe, reservas e frequência de atualização. Ao combinar métricas, a normalização transforma unidades diversas em uma comparação; o peso transportado não guarda sozinho a fórmula, a escala ou a versão usada.

Por isso, “limite 20, bit zero” não resolve uma investigação. A resposta útil nomeia fonte, unidade, horário, época da topologia, método e política que produziram o resultado naquele PLR.

Um registro de procedência por ponto de reparo

A proposta editorial de Daniel Kade é manter um registro restrito, indexado por LSP protegido e PLR. Ele não altera RSVP nem cria obrigação para o IETF.

O registro começa pela identidade: sessão, ingresso, PLR, recurso protegido e ponto de junção. Preserva impressões digitais exatas de FAST_REROUTE e FAST_REROUTE_EXT, inclusive tipos, pesos, valores, limites e escopos. Anota suporte da função, resultado da análise, presença do objeto-base e conteúdo relevante do Resv/RRO.

Se o sinalizador não veio, registra uma causa observada — ausência de pedido, extensão não suportada, limite não satisfeito ou outro estado comprovado — sem deduzi-la do zero. Junta a política local e sua versão, a autoridade que aprovou eventual exceção, o prazo e a condição de revisão.

O contexto de cálculo inclui origem, unidade e horário das métricas; época da topologia ou da base TE; tolerância de envelhecimento; método de normalização; versão do calculador; e identidade do backup resultante. Se a organização afirma separação de destino físico, guarda a evidência de riscos compartilhados que sustentou essa afirmação.

Atualizações de sinalização, exercícios e incidentes ficam ligados, porém separados. A atualização renova uma declaração de controle. O exercício testa o desvio. O incidente mostra a consequência sobre tráfego real. Uma evidência posterior não deve apagar os dados que governaram a decisão anterior.

Esse registro não precisa divulgar topologia nem impor o mesmo algoritmo a todos. Ele permite que uma política local continue local sem se tornar indetectável.

Especificação mínima, memória suficiente

O novo indicador é uma boa peça de especificação mínima. Todos podem saber onde o ingresso expressa a condição e onde cada PLR indica que a satisfez. A diversidade permanece do outro lado dessa interface pequena.

O erro seria transformar o mínimo compartilhado no máximo de informação retida. Um bit presente fala de conformidade em um instante. Um bit ausente reúne caminhos distintos para a política local. A organização deve preservar a parte que varia: quem escolheu, quais dados autorizou, por quanto tempo e como a decisão será revertida.

Não se trata de escolher entre comando central e liberdade local. Trata-se de escolher entre liberdade opaca e liberdade justificável. A segunda mantém proteção durante transições e, ainda assim, permite descobrir qual política prevaleceu.

Fontes