Resumo

  • Quando confirmações de LSPs recebidos e novos pedidos de reconciliação compartilham o mesmo mecanismo de transmissão PSNP, a revisão 05 recomenda servir primeiro as confirmações.
  • O rascunho permite uma tentativa por peer e nível. Num experimento com cerca de 6.700 fragmentos e 40 nós, tentativas sobrepostas produziram pedidos PSNP equivalentes a quase cinco vezes a população de fragmentos.

A recuperação cria uma disputa entre remover e adicionar trabalho

Um CASH aponta que duas visões da LSDB divergem. PASHes recortam o intervalo até que SNPs normais ou flooding façam chegar os LSPs ausentes. Nesse ponto, o receptor precisa pedir a próxima peça e, ao mesmo tempo, confirmar as peças de reparo que já recebeu.

Se as duas tarefas entram no mesmo mecanismo PSNP, a ordem decide a dinâmica. Um pedido acrescenta obrigação. Uma confirmação remove do remetente a obrigação de retransmitir. Se o pedido sempre passa na frente, o temporizador remoto vence, uma cópia retorna e consome mais espaço na fila que atrasou a confirmação original.

O texto da revisão 05, de 26 de setembro de 2026, transforma essa inversão em orientação explícita. O Datatracker também põe um limite necessário: trata-se de Internet-Draft individual, sem stream nem posição formal da IETF. A intenção Experimental não comprova adoção.

O fim da busca não é o fim da tentativa

Na revisão 04, o documento já exigia uma única tentativa de reconciliação por peer e nível. Um CASH periódico novo não pode começar enquanto restarem PASHes ou PSNPs a enviar, nem enquanto transmissões ou retransmissões LSP geradas pela tentativa continuarem pendentes.

Essa definição evita um falso encerramento. No teste descrito, com aproximadamente 6.700 fragmentos e 40 nós, tentativas sobrepostas geraram pedidos PSNP próximos de cinco vezes o número total de fragmentos; a contagem ainda crescia. O rascunho atribui a amplificação ao overlap das tentativas, não à escala por si só nem ao hash.

A revisão 05 completa o controle: se uma fila atende tanto acknowledgments de LSPs recebidos quanto entradas de reconciliação, os acknowledgments devem sair primeiro; o espaço restante pode transportar pedidos. O SHOULD permite exceções justificadas, mas obriga o operador a tratar o scheduler como parte do contrato operacional.

Três comprovantes, três decisões

O artigo anterior da BTW, Os hashes bateram. Isso não provou que a rede estava certa, delimitou a revisão 01: igualdade de resumo encerra uma comparação, mas não certifica topologia ou forwarding. Esta matéria não reabre essa tese. Ela acompanha o ciclo posterior, da diferença descoberta até o fechamento contábil do reparo.

Um acknowledgment PSNP comprova o recebimento de um LSP num escopo; não comprova toda a LSDB. A reconciliação só termina quando PASHes, PSNPs, transmissões e retransmissões associados acabam. Ainda depois disso, SPF, FIB e tráfego exigem provas próprias.

O primeiro comprovante deveria ligar peer, nível, tentativa, gatilho, intervalos, profundidade de pedidos, idade das confirmações, LSPs pendentes, retransmissões, CASHes adiados e transição final. O segundo registra LSDB, cálculo e instalação. O terceiro mede o caminho real. Um estado verde não ganha autoridade para preencher os outros dois.

A capacidade anunciada também é limitada. O Hello Capability separa ASH_RX e ASH_TX por direção e adjacência. A RFC 1195 fornece o contexto; RFC 5304 e RFC 5310 protegem integridade, não verdade física; a RFC 9681 acelera flooding, sem quitar a reconciliação.

Running-Code Primacy pergunta se a confirmação saiu, a repetição cessou e o tráfego voltou. Minimum Initial Specification permite compartilhar só três invariantes — uma tentativa, prioridade do recibo, término explícito — e manter escolhas locais. Reality Layers impede que capacidade declarada vire resultado por linguagem.

Fontes