Resumo

  • O RFC 9736 separa os TLVs de Peer Up e Initiation e exige a preservação da ordem de String TLVs repetidos. O que ele corrige é a propriedade dos códigos, não a implementação em campo.
  • Uma conclusão operacional precisa ligar registro e versão do emissor aos bytes, ao parser, ao armazenamento, à sessão, às rotas, ao encaminhamento e ao efeito após uma ação.

A correção pequena que protege extensões futuras

Initiation informa características do sistema monitorado; Peer Up descreve uma sessão BGP. Mesmo assim, o RFC 7854 fez ambos compartilharem o namespace de Information TLV. Quando o BMP ganhou extensões, ficou difícil atribuir novos números sem carregar ambiguidade entre dois contextos diferentes.

O RFC 9736 divide o registro. O antigo passa a se chamar BMP Initiation Information TLVs; o novo é BMP Peer Up Message TLVs. Initiation mantém String no Type 0, sysDescr no Type 1 e sysName no Type 2. Peer Up contém String no Type 0, VRF/Table Name no Type 3 e Admin Label no Type 4. Os demais números correspondentes ficam reservados no lado oposto.

A String TLV é uma sequência UTF-8 cujo fim vem do campo Length, não de null. Information é opcional em Peer Up e sua presença aparece no Message Length comum. String pode se repetir, e a ordem precisa ser mantida no relatório. Se o pipeline guarda apenas o último valor ou transforma uma lista ordenada em conjunto, o dado mudou mesmo que o painel não mostre erro.

Compatibilidade não é evidência de release

O RFC afirma que implementações conformes aos RFCs 7854, 8671 e 9069 também atendem ao RFC 9736. Isso formaliza a continuidade dos códigos existentes. Não prova que uma versão instalada usa a tabela certa, preserva múltiplos valores ou registra tipos desconhecidos.

Um coletor pode reconhecer Type 3 e ainda associar o nome de tabela ao peer Loc-RIB emulado errado. Pode descartar silenciosamente um futuro TLV experimental. Pode confundir ausência opcional com falha de parsing. O registro da IANA permanece correto; quem perde a evidência é a operação.

O recibo confiável começa nos bytes. Preserve a mensagem Peer Up, a sessão BMP, o build e a configuração do emissor, Message Length e a sequência dos TLVs. Vincule isso ao build do coletor, ao schema do parser e à política para valores desconhecidos. Compare a entrada bruta, o evento de decodificação e o registro persistido. Sem a captura original, não há como provar se um valor nunca veio ou se foi descartado depois.

A fronteira depois do Peer Up

No RFC 7854, Peer Up relata que uma sessão BGP passou a Established e carrega as duas mensagens OPEN e dados TCP. Quando a própria sessão BMP sobe, porém, ele também é enviado para peers que já estavam Established. O horário recebido pelo coletor não é necessariamente o início real da sessão BGP.

O RFC 8671 diz que Peer Up/Down é independente de haver Route Monitoring ou Route Mirroring para Adj-RIB-In ou Adj-RIB-Out. Initiation, Peer Up, dump inicial, End-of-RIB e updates incrementais são etapas diferentes. Uma mensagem válida não certifica a completude do feed.

No Loc-RIB do RFC 9069, peers emulados podem se multiplicar por família de endereços. VRF/Table Name ajuda, mas global não é identidade única. Peer distinguisher, BGP ID e capabilities do OPEN precisam concordar.

Onze recibos, não uma luz verde

A revisão defensável identifica o snapshot do registro, a versão do emissor, a sessão e o epoch do peer, os bytes exatos, o parser, a política de desconhecidos, o recibo bruto e o decodificado, a confirmação da sessão, a cobertura do feed, a evidência de RIB/FIB ou teste ativo, a ação autorizada e o resultado independente.

A cadeia pode terminar em incerteza. Peer Up pode confirmar um relato de sessão sem confirmar rotas aceitas. Um feed completo pode não mostrar hardware. O encaminhamento pode não revelar impacto comercial. O RFC 9736 fortalece o começo da cadeia; integridade operacional é não fingir que ele responde ao fim.