Resumo

  • A RFC 9857 permite anunciar por BGP-LS o estado operacional de caminhos candidatos de uma SR Policy, pelo headend ou por um PCE que repassa estado aprendido do PCC.
  • O anúncio recebido não comprova sozinho a idade da observação, a geração corrente, a confirmação do FIB, o caminho usado pelos pacotes ou o resultado do serviço.

O retorno operacional finalmente ganhou estrutura

Uma controladora de rede costuma registrar com precisão o que solicitou. O que aconteceu depois pode permanecer fragmentado entre o headend, o gerenciador local de políticas e ferramentas de telemetria. A RFC 9857 melhora essa assimetria ao definir NLRI e atributos BGP-LS para uma SR Policy, seus caminhos candidatos e listas de segmentos. A intenção passa a ter uma resposta operacional transportável.

Esse ganho não deve ser reduzido. Um consumidor pode localizar uma política, distinguir candidatos e ler estados com semântica padronizada. Mas a chegada de uma atualização responde quando o receptor viu a mensagem, não quando o produtor observou o fato. Um PCE pode repassar estado anterior; uma sessão restabelecida pode reanunciar informação preservada; uma política de atualização pode retardar a distribuição.

Por isso, o primeiro rótulo seguro é “recebido”. “Atual” exige uma segunda demonstração. Usar os dois termos como sinônimos elimina justamente a incerteza que uma automação responsável deveria representar.

A identidade do headend não identifica necessariamente a testemunha

Os Local Node Descriptors da RFC 9857 sempre apontam para o headend da SR Policy. Quando um PCE anuncia informação aprendida do PCC via PCEP, ele não substitui essa identidade pela própria. O PCE pode carregar BGP Router-ID, AS e confederação no atributo BGP-LS.

O desenho é correto porque mantém a política ligada ao seu nó. Ainda assim, o armazenamento do consumidor precisa separar “sobre quem é o relatório” de “quem publicou o relatório”. Se apenas o headend for guardado, um relato indireto pode ganhar aparência de observação direta. Se apenas o vizinho BGP for guardado, perde-se o sujeito da política.

Protocol-Origin responde a outra pergunta: qual protocolo ou componente originou a instanciação, como PCEP, BGP SR Policy ou configuração local. Não é identidade criptográfica do observador, timestamp, nem recibo do hardware. O Instance-ID de BGP-LS também não ordena o tempo; ele separa instâncias de roteamento.

Cada bit responde a uma pergunta limitada

O bit A declara que o caminho candidato está ativo e, na semântica da RFC 9256, provisionado no plano de encaminhamento. É uma afirmação operacional relevante do produtor. Não é, contudo, um recibo independente emitido por ASICs ou por todas as placas envolvidas.

S representa desligamento administrativo; B, backup; E, avaliação; V, pelo menos uma lista de segmentos válida; D, delegação; C, provisionamento pelo PCE. Os bits I, T e U tratam de comportamentos definidos de descarte ou trânsito. Nas listas de segmentos, outros estados representam cálculo, verificação, resolução e topologia; M indica remoção após uma falha detectada pelo monitoramento.

Esses sinais permitem diagnosticar a decisão local com muito mais precisão. Nenhum deles mede, por si só, quantos pacotes seguiram o caminho ou se a latência de uma aplicação permaneceu dentro do objetivo.

A RFC não fornece a linha do tempo completa

Não há na RFC 9857 um timestamp obrigatório da observação no produtor, um número monotônico de geração, um recibo separado do SRPM ou uma confirmação de gravação no FIB. A RFC 9552 ainda permite que políticas regulem o momento das atualizações BGP-LS para reduzir o volume. Silêncio pode significar estabilidade, contenção de atualizações ou perda de continuidade.

O controlador precisa construir seu próprio epoch de confiança: identidade do headend, identidade do produtor, sessão e reinicializações, hora de recepção, geração da intenção e prazo máximo aceitável. Mudança de PCE, delegação ou sessão deve suspender a inferência de continuidade até que novas evidências sejam correlacionadas.

Não se trata de culpar o protocolo por não resolver outra camada. Trata-se de impedir que a aplicação acrescente garantias que o protocolo não codificou.

Cinco recibos formam a cadeia de evidência

O relatório BGP-LS é o primeiro recibo: mostra o estado anunciado pelo produtor. O recibo do SRPM mostra qual geração o gerenciador local aceitou. O recibo do FIB ou do hardware confirma o que foi programado. A telemetria de tráfego mostra por onde os pacotes passaram. As métricas de serviço mostram se perda, latência e disponibilidade atingiram o resultado esperado.

Esses eventos não chegam necessariamente na mesma ordem ou frequência. A correlação depende de uma chave estável para política e caminho candidato, de gerações comparáveis e de uma janela temporal explícita. Se uma prova não chegou, a ausência deve continuar visível; reutilizar o último valor verde transforma desconhecimento em certeza.

Uma escala de confiança útil distingue: recebido, corroborado localmente, confirmado no encaminhamento, observado em uso e verificado no serviço. A RFC 9857 fortalece muito o primeiro degrau e ajuda a iniciar os demais. Ela não os substitui.

Registro e errata delimitam o que é interoperável

O registro da IANA contém os tipos e TLVs de BGP-LS usados pela especificação. A página de errata lista a errata verificada 8709, que corrige três ocorrências de “SR Binding SID sub-TLV” para “SR Binding SID TLV”. A correção evita ambiguidade textual, mas não acrescenta marca temporal ou confirmação de instalação. Registro e errata sustentam a leitura normativa; não provam o comportamento de uma implementação específica.

Fontes