Resumen

  • El IESG aprobó el 13 de agosto de 2026 draft-ietf-opsawg-discardmodel-16 como Proposed Standard. Su modelo de información y su modelo YANG normalizan el reporte de descartes en interfaces, dispositivos y plano de control.
  • El texto advierte que la clasificación no determina por sí sola si la pérdida fue intencionada. El contador identifica una condición local; política, configuración, línea base, duración, servicio, precedencia de implementación y evidencia adyacente determinan el significado.

Una etiqueta común no ordena una respuesta común

La apertura es hipotética y no describe un incidente real. En ambos casos, el equipo puede contar correctamente un descarte de política: el paquete coincidió con una regla aplicada. Esa afirmación no incluye el propósito vigente de la regla.

En el primer enlace, retirar la ACL debilitaría una frontera legítima. En el segundo, mantenerla prolongaría la caída. Una automatización que convierta “policy” en “no actuar” o en “retirar la regla” fallará en uno de ellos.

La normalización sí resuelve otro problema. Hace comparable el punto donde el equipo decidió no reenviar ni entregar el paquete y la rama bajo la que contabilizó el hecho. Reduce el espacio de investigación. No otorga al contador autoridad sobre el contrato del servicio.

Una gramática para observar, no para adivinar

El IESG aprobó la versión 16 de “Information and Data Models for Packet Discard Reporting” para Standards Track. Seguirá siendo Internet-Draft hasta su publicación por el RFC Editor. El trabajo procede del Operations and Management Area Working Group.

El anuncio presenta un modelo de información independiente de implementaciones y un modelo de datos YANG centrado en interfaces, dispositivo y plano de control. El informe del shepherd registra mapeos o implementaciones en nueve plataformas de cuatro proveedores y una implementación abierta parcial. Es evidencia útil de ejecución, no una garantía de adopción universal ni de contabilidad idéntica en silicio.

El árbol separa componente, dirección, tráfico o descarte, capa, subtipo, motivo más específico y métrica. El componente puede ser plano de control, interfaz, flujo o dispositivo. La dirección distingue entrada y salida; las capas 2 y 3 conservan su significado; error, política y falta de búfer son ramas diferentes.

La precisión facilita análisis entre plataformas y posibles decisiones automáticas. Aun así, el equipo solo expone su estado operacional. El modelo no reconstruye el camino completo, el origen de cada condición ni la expectativa comercial del usuario.

El dispositivo que descarta posee un hecho limitado

Un paquete se cuenta como descartado únicamente en el dispositivo que toma la decisión final de no reenviarlo o entregarlo localmente. Pasarlo a otra ruta de procesamiento interna, incluso al plano de control, todavía no es descarte. Si se pierde después, debe contarse en ese punto final.

Siempre que sea posible se atribuye a una interfaz; si no, al dispositivo. Así se evita que un traslado interno produzca pérdidas duplicadas y se fija un observador responsable.

El observador no tiene por qué ser la causa. Una trama recibida con error puede haber sido dañada en el enlace o por un transmisor anterior. Un encabezado externo inválido puede llegar desde arriba. “No route” puede reflejar tabla local, mala configuración o convergencia. TTL agotado puede ser traceroute normal, límite demasiado bajo, convergencia o bucle.

El contador prueba que este dispositivo finalizó un descarte bajo esta clase. No prueba por sí solo que causó la degradación, que allí comenzó el fallo o que deba retirarse del servicio.

Contar una vez no equivale a causar una vez

Las reglas evitan dobles cuentas. En un contexto y dirección, el paquete es tráfico o descarte; pertenece a capa 2 o capa 3; y solo puede caer en una subclase de error, política o falta de búfer. Los tipos finos de congestión también se incluyen en su agregado.

La unicidad hace reconciliables las métricas. No dice que hubiese una sola condición. Un mismo paquete puede encontrar una ACL, un búfer agotado y un encabezado inválido. La canalización necesita escoger qué motivo registra.

Si concurren motivos, la precedencia debe estar caracterizada sin ambigüedad. La implementación debería publicar discard-order-capability, ordenado de mayor a menor prioridad, o documentar otro mecanismo. Plataformas distintas pueden escoger clases distintas ante el mismo paquete si evalúan razones en otro orden.

Por eso el nombre de la hoja no basta para comparar. Hay que incorporar capacidades, precedencia y versión del pipeline. Una actualización puede cambiar la clase vencedora aunque el tráfico y el contrato no hayan cambiado.

Toda serie tiene una época

Los agregados deberían cubrir sus clases detalladas, pero pueden existir tiempos de discontinuidad diferentes. Reiniciar una tarjeta, un proceso o una función separa series que ya no pertenecen a la misma época.

Restar valores sin conocer intervalo y discontinuidad produce tasas ficticias. Comparar un agregado antiguo con hojas recién iniciadas aparenta datos perdidos. Interpretar un reinicio como recuperación puede cerrar el incidente mientras continúa la pérdida.

La cobertura también varía. El equipo puede admitir solo una parte de las funciones; YANG Library permite descubrirlas. Incluso cuando anuncia una función, puede no poblar todos los contadores si expone esa limitación.

Definición, soporte y población son tres estados. Un dato ausente no es cero. Un cero tampoco prueba ausencia de pérdida fuera del componente, dirección o clase observados.

La intención pertenece al operador

El documento afirma expresamente que la clasificación no decide si la condición fue intencionada. El operador combina clase con política local, intención configurada, referencia, duración, alcance, servicio y otras pruebas.

Un contador ACL, policer, uRPF, protección o ruta nula demuestra coincidencia con una regla. La regla puede ser un control correcto o una configuración antigua que afecta a tráfico legítimo. El contador no transporta la aprobación de negocio.

La falta de búfer también depende de contexto. Una pérdida pequeña de best effort por debajo de un indicador pactado puede aceptarse; una pérdida sostenida por encima requiere capacidad o cambio de tráfico. Lower Effort tiene otro umbral. TTL expirado a baja tasa puede ser diagnóstico; un aumento persistente puede revelar un bucle.

La clase aporta señal. La interpretación y el permiso para modificar la red siguen siendo locales.

Automatizar exige unir evidencias

Retirar o restaurar equipos, desviar tráfico, revertir cambios y escalar son remedios incompatibles entre sí. Accionarlos desde una hoja aislada puede ampliar el daño.

El registro de decisión debe incluir identidad y software del dispositivo, componente, interfaz, dirección, capa, clase y subtipo, funciones anunciadas, población, precedencia, valor, hora, discontinuidad y referencia. Debe añadir configuración, propietario, rutas, adyacencias, colas, hardware, flujos y pruebas de paquetes.

Ante política, valide regla y tráfico. Ante errores recibidos, investigue enlace y origen anterior. Ante no-buffer, localice el recurso y la clase. Ante no-route o TTL, examine estado de rutas y tiempo.

El contador funciona como clave tipada para esa unión. Usarlo solo como disparador es automatizar una inferencia incompleta con vocabulario más elegante.

Fuentes