Resumen

  • El modelo de descarte puede distinguir pérdidas por falta de búfer de errores y política. Esa exactitud no demuestra que retirar el equipo sea la respuesta adecuada ni que las rutas vecinas tengan margen.
  • La mitigación es una nueva intervención con alcance, reversibilidad y efectos de segundo orden. Debe estar gobernada por evidencia topológica y de servicio, no por una tabla estática clase -> acción.

El controlador detectó descartes de salida por falta de búfer en un nodo de agregación. La tasa superó el umbral durante un minuto. La clasificación, la duración y el alcance coincidían con la regla de automatización. El nodo salió de servicio.

Veinte segundos después, el tráfico se concentró en dos enlaces vecinos que ya operaban cerca de su límite. La pérdida inicial afectaba una cola best effort; la nueva congestión alcanzó voz, pagos y sesiones empresariales. El contador original había descrito correctamente un problema. La respuesta convirtió un problema localizado en un incidente regional.

Ese escenario no contradice el proyecto Information and Data Models for Packet Discard Reporting. Lo confirma. La introducción advierte que una acción equivocada puede empeorar el problema y usa precisamente el ejemplo de retirar un dispositivo congestionado para enviar tráfico hacia enlaces o equipos que también están congestionados.

La revisión 16 del documento OPSAWG está fechada el 30 de julio de 2026 y vence el 31 de enero de 2027. Al cierre de investigación del 2 de octubre era un Internet-Draft activo, pensado como Proposed Standard, sometido al IESG y en la cola del RFC Editor a la espera de asignación. Todavía no tenía número RFC. El estado muestra avance del texto, no despliegue uniforme.

El valor del modelo es claro. Los contadores clásicos agregan pérdidas distintas y dificultan la automatización. La nueva clasificación diferencia errores, congestión y política, y permite relacionar dispositivo, interfaz, plano de control y flujo. Pero el propio proyecto limita su alcance: las acciones asociadas son específicas del despliegue. La norma mejora la señal; no diseña la capacidad de cada red.

Causa local no es consecuencia global

no-buffer informa de una condición local en un punto de reenvío. La causa inmediata puede ser una cola sin espacio. La causa operativa puede estar en otro lugar: un cambio de ingeniería de tráfico, una ráfaga, una caída previa, una distribución incorrecta de hash, una capacidad contratada insuficiente o un perfil de calidad de servicio.

La consecuencia también depende del contexto. Una pérdida breve de tráfico best effort por debajo del objetivo de rendimiento puede ser aceptable. La misma clase, sostenida por encima de un SLA, puede ser involuntaria. El tráfico Lower Effort está diseñado para ceder antes; el tráfico Expedited Forwarding que excede su perfil puede ser descartado intencionalmente por un policer. La clase no lleva dentro el contrato que decide qué pérdida importa.

Por eso el proyecto combina cuatro características: alcance, tasa, duración y clase. Incluso esas cuatro no contienen la topología futura. Al retirar un elemento, cambian las rutas, las colas y la demanda que verá cada vecino. La acción no es la conclusión del diagnóstico; es otro experimento sobre un sistema vivo.

Una tabla de remedios puede ocultar poder

Es tentador codificar una tabla sencilla: error físico, retirar enlace; falta de búfer, mover tráfico; política, no actuar; sin ruta, revertir. El apéndice del proyecto ofrece ejemplos parecidos, pero declara que son ilustrativos. La condición de descarte no determina por sí sola si la pérdida es intencional.

Una tabla sin estado tampoco sabe si una convergencia ya terminó, si una mitigación anterior sigue activa o si el sistema está dentro de un periodo de enfriamiento. Dos controladores pueden reaccionar al mismo evento y deshacer mutuamente sus cambios. Un descenso del contador puede parecer éxito aunque el tráfico haya desaparecido o migrado fuera del área observada.

La autoridad de actuar necesita, por tanto, información distinta: mapa de capacidad, restricciones de protección, prioridad de servicios, dependencias, cambios concurrentes, límites de impacto y un mecanismo de reversión. También necesita una identidad de operación para que una orden repetida no se convierta en dos cambios.

El sobre mínimo de una decisión

La disciplina de capas de realidad de Heng Lu permite describir el error institucional. El descarte es un hecho de ejecución. El contador es un registro. La clase es una interpretación normalizada. La causa raíz es una hipótesis. La maniobra es una orden. La recuperación del cliente es un resultado. Cuando una plataforma llama a todo eso “incidente de congestión resuelto”, borra quién tenía autoridad para saltar de una capa a la siguiente.

Una especificación inicial mínima no necesita centralizar cada decisión. Debe conservar lo suficiente para que el salto sea auditable: identidad de nodo e interfaz, intervalo y discontinuidad, clase y profundidad del modelo, referencia y SLA, flujo afectado, hipótesis, versión de topología, capacidad disponible, acción propuesta, radio máximo, condición de reversión y prueba posterior.

La primacía del código en ejecución convierte esa lista en pruebas. Saturar una cola y retirar el nodo. Repetir cuando los vecinos están al 50, 80 y 95 por ciento. Introducir una caída simultánea. Simular tráfico Lower Effort y Expedited Forwarding. Hacer que el contador baje porque se pierde la telemetría. El controlador debe distinguir mejora, desplazamiento y ceguera.

El modelo IETF puede hacer que la primera pregunta sea más exacta: ¿qué condición reportó el equipo? La organización debe responder las demás: ¿por qué ocurrió, a quién afecta, qué acción está autorizada y qué nueva realidad creará? Una red no se vuelve autónoma cuando reacciona sola. Se vuelve autónoma cuando puede limitarse a sí misma frente a la incertidumbre.

Fuentes