Resumo

  • Uma adição programada não deve entrar em uso antes de os mecanismos normais de liveness do IS-IS confirmarem todas as adjacências relevantes.
  • Uma remoção programada é diferente: a física orbital torna a perda quase certa, justificando elevar a métrica e instalar desvios antes do desaparecimento do enlace.
  • Autoridade do cronograma, recebimento, enlace observado, convergência, cálculo do PCE, instalação em hardware e resultado para o cliente exigem recibos separados.

A linha verde no mapa orbital

Às 14h, o console desenha uma linha verde entre dois satélites. A geometria entrou numa janela em que uma conexão óptica pode ser possível. O PCE já calculou um caminho de Segment Routing pela aresta, e o equipamento de entrada tem a pilha de rótulos pronta.

O cronograma pode ser autêntico e o cálculo correto para o grafo previsto. Ainda assim, não prova que os terminais ópticos se adquiriram, que a camada de enlace funciona, que o IS-IS formou adjacência ou que um pacote atravessou. A previsão é valiosa por chegar antes da realidade; fica perigosa quando essa antecedência é tratada como autoridade sobre a realidade.

O RFC 9717 registra uma assimetria fundamental. A previsão de conexão não garante que ela ocorrerá; a desconexão imposta pela dinâmica orbital é praticamente certa. A física pode fechar uma janela, mas não promete que terminal, apontamento e controle conseguiram abri-la.

O documento também limita a própria autoridade. Publicado em janeiro de 2025 como RFC Informational do Independent Stream, apresenta a visão do autor, não um produto da IETF nem consenso da comunidade, e não propõe mudanças de protocolo. Publicação não é evidência de validação, implantação ou adoção.

O cronograma precisa de identidade

O plano de gestão fornece as mudanças previstas aos nós L1 ou L2, gateways e PCEs que tomarão decisões com elas. A distribuição exata está fora do escopo. O registro operacional precisa, portanto, de emissor, versão, criação, validade, destinatários, confirmações e histórico de substituição. Sem isso, dois controladores podem afirmar que usam “o cronograma” enquanto operam futuros diferentes.

Receber não é aplicar. Um satélite pode ter a versão correta e um terminal defeituoso; um gateway pode perder uma revisão; um PCE pode atualizar a base antes de a mudança chegar. Previsão e instante de incorporação por cada decisor devem permanecer ligados.

Para adicionar, espere o liveness

Um enlace ou nó novo não deve provocar mudança funcional até que o liveness normal do IS-IS comprove todas as adjacências pertinentes. Tabelas e caminhos podem ser pré-calculados, mas rotas que usam a nova topologia não devem ser instaladas antes da confirmação.

O pré-cálculo comprova grafo de entrada, restrições, algoritmo, tempo e lista de SIDs. Não comprova existência do caminho. Depois da adjacência, LSDB, BGP-LS e base do PCE ainda precisam refletir o mesmo grafo atual.

Quem optar por pré-instalar deve comprovar a reversão caso a topologia não se torne operacional: gatilho, responsável, prazo, rótulos afetados e retirada do estado obsoleto. “Instalado com sucesso” é incompleto quando depende de um evento físico futuro.

Para remover, aja antes da perda

Esperar o liveness declarar a queda desperdiçaria a previsão. O RFC recomenda elevar a métrica cedo o bastante para propagar e convergir, enquanto gateways e PCEs atualizam e instalam caminhos alternativos. A antecedência varia com escala, configuração, distribuição, cálculo e programação.

Devem ser preservados o instante previsto de perda, a mudança da métrica, a dispersão de propagação da LSDB, o novo cálculo, a confirmação do hardware e o último pacote observado. O documento prefere sinalização IGP conhecida a exclusões locais ocultas, reduzindo riscos de informação incompleta e dessincronização.

Um caminho contém oito afirmações

A proposta combina IS-IS, Area Proxy, stripes orbitais, SR-MPLS e engenharia por gateway ou PCE. A auditoria separa: cronograma autorizado; mesma versão recebida; adjacência observada; topologia convergida; caminho calculado; estado instalado; percurso usado; serviço medido.

Confirmação de hardware não comprova o enlace remoto. Adjacência não comprova capacidade. LSDB correta não comprova a pilha de rótulos escolhida. Um teste de cliente não revela sozinho uma entrada PCE antiga. A força probatória vem de um identificador comum e de uma cronologia que mantenha cada camada distinta.

Uma arquitetura ainda por validar

O RFC pressupõe que o grafo está quase sempre conectado, que há enlaces e largura de banda suficientes e que o cronograma costuma ser exato. Se não houver caminho, aceita descartar pacotes e não exige armazenamento. São premissas, não medições de uma constelação nomeada.

O trabalho futuro reconhece que estatísticas exatas de conectividade ISL não são públicas, limites de ângulo, distância e rastreamento são desconhecidos e o tamanho das stripes precisa de simulação e operação. Uma stripe pode ter poucas órbitas ou milhares de satélites, talvez além dos limites de uma implementação IGP.

A leitura responsável não é certificação nem rejeição. O cronograma pode reduzir perdas evitáveis, sobretudo antes de uma desconexão certa. Protocolos existentes oferecem peças plausíveis. Mas a previsão não se autentica sozinha, o caminho não se instala sozinho e um plano de controle verde não entrega serviço.

Fontes

Registros primários: RFC 9717, registro do RFC Editor, histórico do draft e conflict review. Contexto: RFC 9666, RFC 8402, RFC 8660, RFC 4655 e RFC 9552.

Referencial editorial público: realidade, não defesa de posição.