Resumo

  • RFC 9835 guarda no AC de rede a referência do AC exposto na camada de serviço. A correlação mostra qual objeto pretende executar qual pedido; não comprova bearer, encaminhamento nem resultado do cliente.
  • O nome do AC é local ao nó. Perfis herdados, substituições locais, dependências pai-filho e estados administrativo e operacional formam registros separados da configuração efetiva.
  • O recibo final vem depois: alvo correto, configuração aplicada, estado observado, OAM com escopo, serviço ponta a ponta e tráfego consumido pelo cliente.

A ordem fechou no portal, mas a filial continuou isolada

Uma empresa pede conectividade para uma nova unidade. O portal cria uma referência, o orquestrador escolhe um PE e registra um attachment circuit. Inventário e pedido agora compartilham uma chave. Isso reduz um risco importante: implementar o circuito para o cliente ou local errado.

Ainda assim, o bearer pode estar indisponível, a VLAN pode divergir, o perfil de roteamento pode estar desatualizado ou outro acesso da VPN pode não existir. A referência responde “qual objeto?”. Não responde “qual efeito?”.

RFC 9835, identificado também pelo registro do RFC Editor, especifica o modelo ietf-ac-ntw. Ele permite provisionar o AC antes ou durante o serviço e manter no objeto de rede a referência usada para expor aquele AC ao cliente. A norma produz uma costura auditável entre intenção e execução, não uma promessa de que ambas chegaram juntas ao fim.

Bearer, AC e SAP não são nomes para a mesma coisa

RFC 9833 define bearer como o enlace físico ou lógico entre o ponto do cliente e a rede do provedor. O AC é a configuração necessária sobre esse enlace para permitir a troca de dados. Um bearer pode hospedar vários ACs; um AC pode se ligar a vários peer SAPs; um SAP pode terminar vários ACs.

Essa cardinalidade muda a investigação. Falha de bearer pode atingir uma família de ACs. Falha de configuração de um AC pode coexistir com bearer saudável. A referência do bearer identifica onde vincular o serviço, não que o vínculo esteja funcionando.

RFC 9834 oferece bearers e ACs como serviços voltados ao cliente. RFC 9835 descreve o lado da rede. RFC 9836 conecta esses objetos aos modelos de serviço e rede de L2VPN e L3VPN. As fronteiras permanecem porque cada camada tem decisão, estado e prova próprios.

O registro precisa manter referência de serviço, rede, nó, nome local do AC, SAP, bearer e época do mapeamento. Um “circuit-id” global inventado pela interface pode esconder uma migração ou unir objetos homônimos.

svc-ref é chave de associação, não selo de sucesso

RFC 9835 usa a referência de AC do modelo de serviço para correlacionar a solicitação com o AC efetivamente provisionado na rede. Entretanto, o nome do AC de rede é único no escopo de um nó, não da rede inteira. A adoção do mesmo padrão de nomes entre camada de serviço e camada de rede é específica do ambiente.

Logo, dois nós podem possuir ac-17. Uma referência estável do cliente pode apontar para um novo nó após migração. Comparar somente texto produz falso encontro. O recibo deve registrar o conjunto completo: referência, network, node, AC, SAP, ator que decidiu o mapeamento e sua vigência.

RFC 8969 distingue modelos de serviço do cliente, modelos de rede e modelos de dispositivo. Traduzir entre eles é trabalho operacional. Estruturas comuns reduzem ambiguidade, sem transformar tradução em observação física.

A configuração efetiva precisa de proveniência

RFC 9835 permite perfis de rede compartilhados. O AC herda o perfil, salvo quando refina localmente o mesmo dado; nesse caso, o valor local prevalece. Assim, a configuração aplicada é resultado de resolução.

Guardar só o nome do perfil apaga exceções. Guardar só a exceção apaga a base herdada. Uma auditoria deve fixar a revisão do perfil, os valores recebidos, as sobreposições, a fonte de cada valor vencedor e a impressão digital do resultado enviado ao dispositivo.

RFC 9836 também dá precedência aos dados do AC referenciado quando eles se sobrepõem a informações inline de um acesso VPN. Essa regra decide qual intenção vale. Não comprova aplicação atômica, interpretação igual em equipamentos nem reversão correta.

RFC 8342 separa intenção/configuração de estado operacional na NMDA. RFC 8345 fornece o modelo de rede que RFC 9835 amplia. A presença do objeto inicia a pergunta: o que foi pedido, o que se tornou efetivo e o que a rede observa?

Excluir o pai amplia o alcance de uma decisão

Um Parent AC pode guardar propriedades comuns e os Child ACs, detalhes de peer SAPs específicos. Os filhos herdam. RFC 9835 determina que a exclusão do pai exclua todos os filhos.

A regra impede órfãos no modelo, mas cria uma superfície de cascata. O esquema não comprova que o controlador enumerou os filhos certos, removeu estado de rede na ordem correta, preservou serviços não relacionados, atualizou cobrança ou manteve rollback.

Antes da exclusão, o operador deveria congelar pai, filhos, SAPs, serviços, bearers, perfis efetivos e estados observados. Depois, deveria comparar a intenção com dispositivos e tráfego. A linha ausente no datastore comprova uma mutação no modelo, não a retirada segura do serviço.

O estado administrativo deve poder ser desmentido

RFC 9835 mantém estados administrativo e operacional separados e trata sua divergência como possível gatilho de anomalia. RFC 9833 inclui aguardando validação, aguardando processamento, administrativamente proibido e rejeitado. São fatos de fluxo de trabalho, não fatos do plano de dados.

Um pedido aprovado pode aguardar ativação. Um AC configurado pode estar down. Uma interface up pode carregar a VLAN errada. Um AC saudável em um ponto não comprova uma VPN saudável.

RFC 9408 define o SAP como ponto de referência do lado do provedor e separa o estado observado ali do estado global do serviço. RFC 9181, RFC 9182 e RFC 9291 dão tipos e modelos de VPN; RFC 9543 amplia o contexto para network slices. Um indicador local não fala por todos esses escopos.

A sequência de evidência distingue solicitação; aceitação e referência; mapeamento para rede/nó/SAP/AC; resolução de herança; envio ao alvo; estado operacional; OAM limitado; estado ponta a ponta; e tráfego ou canário da aplicação. Não são obrigatoriamente nove bancos, mas nenhum recibo pode assumir a autoridade do seguinte.

As fontes não estabelecem implantação nomeada, produto conforme, incidente, adoção, economia nem SLA. A cadeia proposta é análise operacional e não novo requisito IETF.

Quem lê e escreve o vínculo controla informações sensíveis

RFC 9835 alerta que leitura indevida pode expor identidades peer-sap-id. Escritas podem alterar roteamento, filtros, criptografia, chaves e vínculo de serviço. Uma conta capaz de mudar serviço→AC pode deslocar realidade de rede, não apenas catálogo.

Convém separar criação da intenção comercial, tradução para rede, escrita em dispositivos e observação. O log deve conservar ator autenticado, escopo, valor anterior, valor novo e resultado. “API 200” não é prova de mandato nem de entrega.

O ganho durável de RFC 9835 é tornar rastreável a costura entre promessa e execução. Quando a referência conduz até observação independente e resultado do cliente, a automação pode ser responsabilizada. Quando ela encerra o chamado sozinha, automatiza apenas a aparência de conclusão.

Fontes