Resumo
- Em 13 de agosto de 2026, a IESG aprovou o
draft-ietf-opsawg-discardmodel-16como Proposed Standard. O modelo de informação e o modelo de dados YANG oferecem uma forma mais consistente de relatar descartes em interfaces, no dispositivo e no plano de controle. - O próprio documento afirma que a classificação não determina se um descarte foi intencional. O contador descreve uma observação local ao dispositivo; intenção, configuração, linha de base, duração, contexto do serviço, ordem da implementação e evidências adjacentes determinam seu significado.
A mesma classe pode exigir decisões opostas
A abertura é hipotética, não o relato de uma falha de fornecedor ou de uma rede. As duas observações podem ser verdadeiras porque um descarte por política significa que o tráfego encontrou uma regra aplicada. Ele não informa se essa regra ainda representa a intenção do serviço.
Na primeira interface, uma lista de controle de acesso rejeita tráfego que nunca teve autorização para cruzar a fronteira. A elevação do contador mostra uma proteção funcionando. Remover a regra criaria exposição. Na segunda, uma alteração de topologia colocou tráfego legítimo na mesma condição de correspondência. O equipamento informa a mesma classe, mas manter a regra amplia a indisponibilidade.
É aí que o novo modelo se torna útil. Uma linguagem comum reduz a área de investigação sem transformar o contador em juiz. Ela pode dizer onde o dispositivo tomou a decisão final de descarte e em qual ramo contabilizou o evento. Antes de declarar a perda aceitável, apontar a causa raiz ou alterar a produção, a automação ainda precisa de evidências locais.
A aprovação cria uma gramática comum de observação
Em 13 de agosto de 2026, a IESG aprovou a versão 16 de “Information and Data Models for Packet Discard Reporting” para publicação como Proposed Standard. O texto continua sendo um Internet-Draft até sua publicação pelo RFC Editor e é trabalho do Operations and Management Area Working Group.
O anúncio descreve um modelo de informação independente da implementação e um modelo YANG para descartes em interfaces, dispositivos e plano de controle. Segundo o parecer do shepherd, houve mapeamentos ou implementações em nove plataformas de hardware de quatro fornecedores, além de uma implementação de código aberto para parte do modelo YANG. É evidência importante de código em operação. Não comprova implantação universal, contabilidade idêntica em silício ou suporte por qualquer rede de produção específica.
Os contadores de gerenciamento existentes podem indicar totais de descartes e erros, mas suas semânticas amplas dificultam separar perda desejada de perda indesejada. O trabalho aprovado introduz uma hierarquia: componente, direção, tipo de tráfego ou descarte, camada de protocolo, subtipo, motivo mais específico e métrica.
O componente pode ser o plano de controle, uma interface, um fluxo ou o dispositivo inteiro. A direção separa entrada e saída; a camada separa quadros de camada 2 e pacotes de camada 3; os principais ramos de descarte distinguem erro, política e falta de buffer. A gramática compartilhada facilita investigação e automação entre plataformas.
Ela não cria um observador onisciente. O modelo registra estado operacional exposto por um aparelho. Não reconstrói todos os fatos a montante, o caminho completo do pacote, a expectativa do cliente ou a decisão administrativa que deu sentido ao estado.
O dispositivo que descarta detém um fato estreito
As regras de implementação definem onde a contagem pertence. Um pacote só é contado como descartado pelo dispositivo que toma a decisão final de não encaminhá-lo nem entregá-lo localmente. Enviá-lo a outra etapa interna, inclusive ao plano de controle, ainda não constitui descarte. Se ele for abandonado depois, a contagem pertence ao ponto do evento final.
Essa regra reduz ambiguidades. Uma passagem interna deixa de parecer uma perda e um único dispositivo assume a responsabilidade pela observação. A atribuição à interface é preferível; quando não for possível, o evento deve ser atribuído ao dispositivo.
Mas o ponto de observação não é necessariamente a origem causal. Um erro de recepção na camada 2 pode significar que o dispositivo descartou corretamente um quadro corrompido no enlace ou transmissor a montante. Um erro de camada 3 pode descrever um cabeçalho externo inválido recebido de outro lugar. Um descarte por falta de rota pode decorrer de tabela local, configuração incorreta ou convergência transitória. A expiração do TTL pode resultar de diagnóstico normal, limite baixo do emissor, convergência ou loop de roteamento.
O contador sustenta a frase “este dispositivo concluiu um descarte nesta classe”. Sozinho, ele não sustenta “este dispositivo causou a falha”, “esta foi a primeira anomalia” nem “esta correção é segura”.
Contagem única não significa causa única
O modelo evita contagem dupla. Dentro de uma direção ou contexto, um quadro ou pacote deve pertencer ao tráfego ou ao descarte, não aos dois. Um descarte na camada 2 não deve aparecer também na camada 3. Cada evento pertence a no máximo uma subclasse entre erro, política e falta de buffer; um tipo detalhado de falta de buffer também integra seu agregado.
Essas restrições tornam os totais conciliáveis. Elas não dizem que houve somente uma condição contribuinte. Um pacote pode encontrar uma regra, um buffer raso e um cabeçalho inválido. O dispositivo precisa, mesmo assim, escolher deterministicamente um ramo de relato.
Quando vários motivos se aplicam, a precedência precisa ser descrita sem ambiguidade. A implementação deve expor discard-order-capability, ordenada da maior para a menor prioridade, ou documentar outro mecanismo. Duas plataformas podem observar o mesmo pacote e selecionar classes diferentes se seus pipelines aplicarem os motivos em ordens distintas, embora ambas respeitem sua precedência documentada.
Por isso, a automação deve ingerir capacidade e ordem junto com os contadores. Comparar apenas o nome das folhas cria falsa equivalência entre equipamentos. Uma mudança de firmware ou pipeline pode alterar o motivo vencedor sem mudar o tráfego nem o contrato do serviço.
Cada contador pertence a uma época
Os totais agregados de camada 2 e camada 3 devem cobrir as classes inferiores, mas o documento permite exceções quando contadores granulares têm tempos de descontinuidade diferentes. Reiniciar uma placa, um processo ou uma função pode colocar totais e subtipos em épocas de evidência incompatíveis.
Subtrair valores sem o intervalo de observação e a descontinuidade pode fabricar uma taxa que nunca existiu. Somar um agregado antigo a folhas recém-inicializadas faz dados válidos parecerem incompletos. Interpretar um reset como recuperação pode encerrar um incidente enquanto a perda continua.
A mesma cautela vale para cobertura. Implementações podem oferecer apenas parte das funções de plano de controle, interface, fluxo e dispositivo. O YANG Library torna as funções suportadas detectáveis. Mesmo em uma função declarada, nem todo contador precisa estar preenchido; a implementação deve expor o que efetivamente fornece.
Três estados precisam permanecer separados: o modelo define um contador; o dispositivo anuncia a função; a implementação preenche o contador na época atual. Ausência no terceiro estado não é zero. E zero não prova que nenhum pacote afetado existiu fora do campo observado.
A intenção continua local ao operador
O limite está escrito no documento: a classificação não decide se uma condição é intencional. O operador faz essa avaliação combinando classe, política local, intenção configurada, comportamento de referência, duração, escopo afetado, contexto do serviço e outras evidências.
O descarte por política mostra o problema. Ele comprova que o tráfego correspondeu a uma ACL, um policer, uma verificação de caminho reverso, uma regra de proteção ou uma rota nula explícita. A correspondência pode proteger uma fronteira legítima. Também pode refletir ACL obsoleta, prefixo errado, perfil antigo de cliente ou interação imprevista depois de uma mudança.
A perda por falta de buffer também é contextual. Uma taxa baixa em tráfego best-effort pode ficar dentro do compromisso aceito; perda persistente acima do limite pode exigir capacidade ou movimentação de tráfego. O tráfego Lower Effort pode ter outra linha de base. Uma folha de congestionamento não carrega o contrato do serviço para dentro do equipamento.
TTL expirado em baixa frequência pode ser apenas traceroute. Um salto sustentado pode indicar convergência ou loop. A classe é o sinal; taxa, duração e topologia decidem se ela se torna incidente.
A automação precisa unir evidências
O documento menciona possíveis respostas: retirar ou restaurar um enlace ou dispositivo, mover tráfego, reverter uma mudança ou escalar para um operador. São ações materialmente diferentes. Escolher a errada pode ampliar a interrupção ou remover um controle intencional.
Uma decisão segura une vários registros. Começa pela identidade do dispositivo, software e pipeline. Preserva componente, interface, direção, camada, classe e subtipo; anúncio da função; prova de preenchimento; precedência; valor, hora, descontinuidade e linha de base. Acrescenta a configuração ou política capaz de produzir o resultado, seu responsável e a intenção aprovada. Depois incorpora roteamento, adjacência, filas, hardware, fluxos e pacotes antes e depois do ponto observado.
Para descarte por política, é preciso verificar a regra e o tráfego correspondente. Para erros de recepção, inspecionar enlace e transmissor a montante antes de retirar a interface que descartou corretamente. Para falta de buffer, localizar o recurso limitado e separar capacidade de entrada de pressão na fila de saída. Para falta de rota, comparar estado de roteamento e tempo de convergência.
O contador é poderoso como chave tipada dessa união. Isolado como gatilho, ele apenas automatiza com maior precisão uma inferência sem sustentação.
Fontes
- IETF Datatracker — documento sobre descartes
- IETF Datatracker — histórico do documento
- IETF Datatracker — parecer do shepherd
- Lu Heng — Minimum Initial Specification
- Lu Heng — Running-Code Primacy
- Anúncio da IETF — ação de protocolo
- Internet-Draft aprovado — versão 16
- RFC 2863 — Interfaces Group MIB
- RFC 3444 — modelos de informação e dados
- RFC 7011 — IPFIX
- RFC 7950 — YANG 1.1
- RFC 8341 — controle de acesso NETCONF
- RFC 8343 — modelo YANG de interfaces
- RFC 8349 — modelo YANG de roteamento
- RFC 8525 — YANG Library
- RFC 8530 — elementos lógicos de rede
- RFC 8791 — extensões de estruturas YANG
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
