Resumo

  • O RFC 9752 permite Vendor Information em PCRpt, PCUpd e PCInitiate e esclarece que Enterprise Number vem do registro IANA de Private Enterprise Numbers.
  • Um PEN correto identifica um namespace; não autentica a publicação semântica, a versão, o suporte, o direito de mudar estado nem o efeito na rede.
  • O rastro útil preserva bytes, decoder, acordo de capacidade, decisão local, correlação SRP/PLSP, reconciliação, dispositivo, forwarding, tráfego, rollback e fallback entre fornecedores.

Há uma diferença enorme entre “o PCC respondeu” e “a rede fez o que uma parte autorizada pretendia”. Um PCUpd pode estar bem formado, viajar por TLS, conter um PEN conhecido e receber um PCRpt correlacionado. Ainda assim, o decoder pode ser antigo, o conteúdo pode vir de um editor não autenticado, a política local pode ter ignorado o campo e o plano de dados pode não refletir o relatório.

Publicado em abril de 2025, o RFC 9752 é Proposed Standard do IETF. O registro do RFC Editor e o Datatracker confirmam que ele atualiza o RFC 7470. A mudança adiciona o objeto de informação proprietária às operações PCE com estado; não cria uma linguagem comum para o conteúdo proprietário.

Quando o contêiner passa a acompanhar estado

O RFC 7470 definiu o objeto VENDOR-INFORMATION, classe 34 tipo 1, e o VENDOR-INFORMATION-TLV, tipo 7. Ambos carregam um Enterprise Number de 32 bits seguido de informação cujo formato e interpretação são responsabilidade da empresa indicada. Essa semântica pode ser publicada em RFC Informational ou documentação comercial, mas sua versão não integra o cabeçalho.

O RFC 9752 encaixa o objeto em PCRpt, pelo qual o PCC informa o estado de LSP; PCUpd, pelo qual o PCE pede mudança de atributos; e PCInitiate, usado para iniciar criação ou remoção, com a lista proprietária aparecendo na gramática de instanciação. O TLV já podia entrar em objetos stateful que aceitam TLVs, como SRP e LSP.

Cada posição representa uma alegação diferente. Dados em um relatório não provam que causaram o estado. Dados em uma atualização não provam que foram aplicados. Vários objetos, inclusive de PENs distintos, podem coexistir num PCRpt, sem que o RFC defina precedência geral ou resolução de conflito com objetos padronizados.

O nome no registro não assina a carga

O RFC 9752 aponta corretamente para o registro Private Enterprise Numbers e para o RFC 9371. O registro é First Come First Served; a IANA verifica autorização para mudanças no cadastro. Essa prova pertence ao cadastro.

O RFC 9371 também afirma que ninguém consegue impedir terceiros de usar o PEN de outra entidade em seus próprios dados. Portanto, o número não é assinatura do payload. Ele não prova que a equipe atual, um adquirente ou um fork publicou aquela gramática.

É preciso um pacote separado: identidade do editor, versão, data, hash do documento, hash do decoder, mensagens e objetos cobertos, revogação e fim de suporte. Fusões, cisões e abandono de produto são exatamente os momentos em que a linha do PEN e a custódia semântica podem divergir.

Capacidade não cabe numa resposta binária

Se a implementação conhece o objeto, mas não suporta o Enterprise Number, o RFC 9752 manda ignorá-lo conforme a regra herdada. O emissor não deveria enviar se acredita que o receptor não suporta. Já o RFC 7470 deixa fora de escopo a descoberta dos PENs suportados e observa que interoperabilidade funcional entre fornecedores depende de cooperação.

Convém distinguir: parser reconhece o objeto; software reconhece o PEN; produto implementa uma versão; política permite essa versão para peer, mensagem e LSP. Ignorar pode manter a sessão de base funcionando e eliminar, silenciosamente, o efeito privado. Decodificar pode funcionar e ainda não estar autorizado.

Um recibo de capacidade nomeia extremos, versão, operações, expiração, downgrade e fallback. O teste deve retirar os dados privados e trocar a implementação. Se o sentido do conteúdo padronizado muda sem aviso, há lock-in semântico.

A decisão continua local no PCC

O RFC 9752 recomenda sessão autenticada e cifrada via RFC 8253. TLS protege o canal, não a autoria do dicionário e nem a autoridade sobre um LSP.

O RFC 8231 diz que o PCC só age sobre LSP Update Request quando a política local do gestor permite. Uma solicitação aceita dispara setup e recebe relatório do estado resultante; delegação pode ser revogada. O RFC 8281 exige capability dos dois lados para criação pelo PCE e diferencia parâmetro inaceitável, erro interno e falha de sinalização.

Identidade de sessão, delegação, autorização, parsing, validação e PCRpt são recibos distintos. SRP-ID e PLSP-ID ligam mensagens, mas o relatório continua sendo a visão do PCC. Não é leitura independente de RIB/FIB, label state ou pacotes.

Reconciliação precisa de tempo e de testemunhas diferentes

O arquivo começa com bytes crus, PEN, tipo e posição, peer e época da sessão. Junta manifesto e decoder assinados, versão, resultado do parser, validação, objetos padrão, regra de conflito, delegação e decisão local. Depois correlaciona PCUpd/PCInitiate com PCRpt/PCErr por SRP-ID, PLSP-ID e relógio.

Fora do PCEP vêm transação do equipamento, configuração aplicada, rota ou rótulo programado, observação de tráfego, resultado de serviço e rollback. Após restart, resync ou timeout, a convergência deve ser novamente provada. Snapshot de FIB não garante entrega permanente; um probe não garante SLA.

O próprio RFC 9752 não acrescenta liveness, nova verificação operacional ou obrigação a outro protocolo. YANG padrão pode indicar objeto, TLV e PEN, mas não o detalhe. O texto alerta para covert channel e pede que o operador conheça o decoder e inspecione o conteúdo. Contar ocorrências é insuficiente.

O registro PCEP da IANA confirma os códigos. As fontes não demonstram implantação, incidente, falha, ganho ou resultado de fornecedor algum. Running-Code Primacy, Minimum Initial Specification e Reality Layers, de Heng Lu, funcionam aqui como camada analítica declarada: coordenação escrita não substitui implementação e observação. Não são requisitos do IETF.