Resumo

  • As RFCs 9833–9836 modelam separadamente o bearer subjacente, o AC solicitado pelo cliente, o AC de rede do provedor e as referências que conectam esses objetos a VPNs L2 ou L3.
  • Uma solicitação validada pode continuar em awaiting-processing; nomes de AC no serviço e na rede também podem ser diferentes. Aceitação e igualdade de nomes não provam realização.
  • A cadeia de evidências segue por mapeamento, PE/SAP, vínculo VPN, configuração pretendida e aplicada, estado operacional, OAM e tráfego. Cada recibo tem autoridade limitada.

O pedido de circuito aparecia como concluído. Dentro da rede, ainda faltava o objeto que transformaria esse pedido em caminho operacional.

Isso não é prova automática de falha ou má-fé. É a fronteira preservada pelas RFC 9833, RFC 9834, RFC 9835 e RFC 9836. Publicadas em setembro de 2025 no Standards Track, elas distribuem a ordem e sua realização entre modelos YANG relacionados. Assim, o estado de uma camada não toma emprestada a autoridade de outra.

As páginas de RFC 9833, RFC 9834, RFC 9835 e RFC 9836 registram consenso da IETF e aprovação do IESG. Não registram adoção, conformidade de fornecedor, uma ativação real ou um pacote encaminhado. Norma publicada e serviço entregue são fatos diferentes.

O bearer não é o AC

Bearer é o enlace físico ou sem fio subjacente. AC é a configuração feita sobre ele para permitir troca de dados entre a terminação do cliente e a rede do provedor. Um bearer pode sustentar vários ACs; um AC pode envolver vários CEs ou SAPs pares; e um CE pode terminar vários ACs.

Logo, bearer disponível não significa AC correto e ativo. A retirada de um serviço também não dá autoridade para remover o bearer compartilhado ou serviços irmãos. Um painel com um único sinal verde apaga exatamente a cardinalidade necessária para limitar ações automáticas.

Na RFC 9834, o provedor pode emitir uma referência de bearer, recuperada pelo cliente e reutilizada no pedido de AC. O provedor pode aceitar ou rejeitar identificadores fornecidos pelo cliente. O identificador de AC só é único no domínio do provedor; precisa permanecer ligado ao emissor, ao escopo e ao alvo atual.

O pedido portátil não conhece a engenharia interna

A RFC 8309 define o modelo de serviço ao cliente como descrição do que é solicitado ou percebido, não de como o provedor realiza internamente. A RFC 9834 oculta PE, SAP, interface, topologia e tecnologia.

Essa abstração permite usar semântica comum em redes distintas. Também impede que o objeto do cliente prove o posicionamento que foi criado para esconder. Seu recibo deve conter solicitante autenticado, autorização, referência de bearer ou peer-SAP, ID do AC de serviço, parâmetros, validação e estado administrativo.

A RFC 9833 inclui awaiting-validation, awaiting-processing, admin-prohibited e rejected. Um pedido aprovado e validado pode continuar aguardando processamento antes da ativação. Converter esse estado em “ativo” não simplifica a informação: inventa a entrega.

A rede atribui outra identidade

A RFC 9835 define ietf-ac-ntw, que correlaciona a referência de serviço ao AC de rede e guarda o posicionamento PE/SAP. É a passagem da intenção portátil para recursos internos concretos.

O texto diz que usar a mesma convenção de nomes nas camadas de serviço e rede depende da implantação. Os nomes podem coincidir, mas a igualdade não é garantida. A evidência é a referência explícita. Uma junção apenas textual pode anexar telemetria ao pedido errado depois de migração, renomeação ou reutilização.

A existência do objeto de rede tampouco prova aplicação. A RFC 8969 separa modelos de serviço, rede e dispositivo e pede que estado operacional e estatísticas retornem às camadas superiores. O modelo expressa a intenção do orquestrador; sistemas inferiores devem comprovar o resultado.

Glue liga objetos, não comprova entrega

A RFC 9836 introduz ietf-ac-glue, conectando os IDs de AC aos modelos de VPN. Ela amplia o modelo de serviço L3VPN da RFC 8299, o modelo de serviço L2VPN da RFC 8466 e o modelo de rede L3VPN da RFC 9181. As RFC 8345 e RFC 9543 fornecem contexto de topologia e garantia.

O glue prova uma associação modelada. Não prova alocação, configuração aplicada, alcançabilidade, encaminhamento ou SLA. Se o AC de serviço aponta para o AC de rede A e a VPN aponta para B, todos os objetos podem existir e todos os IDs podem ser válidos; o grafo é que está errado. Verificar apenas presença produz um falso positivo.

Pretendido, aplicado e observado

A RFC 8342 distingue valores configurados, configuração pretendida e estado operacional. Atrasos, hardware, protocolos e dependências podem separá-los. Comparar <intended> com <operational> revela quanto da intenção entrou em uso.

A evidência completa autentica e autoriza o principal, resolve o bearer, aceita o AC de serviço, mapeia o AC de rede, seleciona PE/SAP/interface, liga a VPN correta, gera configuração pretendida, observa aplicação e estado e, por fim, mede OAM, alcance, tráfego e resultado de serviço separadamente.

A RFC 7950 define YANG sem impor uma arquitetura única. A RFC 9408 oferece um quadro de segurança para módulos YANG. Essas fontes não identificam invasão ou vazamento; mostram por que autorização deve ser limitada à camada e ao objeto certos.

A especificação inicial mínima com decisões futuras localizadas de Heng Lu aparece aqui como prática: padronizar referências determinísticas e deixar topologia e recursos com o operador. A primazia do código em execução leva a auditoria aos sistemas reais. E realidade, não advocacia, limita a conclusão: quatro RFCs fornecem um mapa de controle, não um atestado de circuito ativo.

Fontes