Resumen

  • RFC 3970 consideraba activo un túnel de ingeniería de tráfico cuando al menos uno de sus caminos estaba activo; por eso medía por separado el tiempo total y el tiempo sobre el camino primario.
  • Configuración, cálculo, ruta registrada, transporte, contadores y notificaciones eran fuentes diferentes. Los avisos opcionales y limitados y los relojes o contadores discontinuos no constituían una cronología completa.

Un indicador agregado es útil porque evita inspeccionar cada componente. También es peligroso cuando se olvida la compresión que realizó. En RFC 3970, publicado en enero de 2005, un túnel de tráfico era una entidad lógica con uno o varios caminos. Bastaba que uno estuviera activo para que el túnel apareciera activo. El primario podía haber caído y un secundario sostener el resultado.

La MIB no ocultó esa diferencia. Mantuvo un contador para el tiempo total de actividad y otro para el tiempo en que el camino primario estuvo operativo. Si ambos fueran equivalentes, el segundo no haría falta. La disponibilidad del agregado y la fidelidad a la ruta preferida eran hechos distintos.

La norma usó el lenguaje de RFC 2119, las piezas SMIv2 de RFC 2578, RFC 2579 y RFC 2580, y la arquitectura de RFC 3411, contextualizada por RFC 3410. El resultado era una vista gestionada del sistema, no una reproducción de todos sus acontecimientos.

La ruta solicitada no era la calculada ni la recorrida

RFC 3970 dividió la información en túneles, caminos y saltos. Para cada camino mantuvo una ruta configurada, una ruta calculada y una ruta registrada. La primera expresaba restricciones o saltos elegidos por la gestión. La segunda procedía de un algoritmo dependiente de la implementación. La tercera era la secuencia que la señalización dijo haber utilizado. Cero indicaba ausencia de ruta calculada o registrada.

Entre una y otra podían ocurrir decisiones. Los requisitos de ingeniería de tráfico de RFC 2702, las extensiones RSVP-TE de RFC 3209 y el mecanismo histórico de RFC 3212 daban contexto a esas decisiones, pero no volvían intercambiables intención, cálculo y señalización.

Los estados operativos del camino distinguían aún más. down significaba que la señalización falló. dormant era un respaldo sin señalizar. ready había sido señalizado, pero todavía no transportaba tráfico. operational estaba señalizado y transportaba. Haber creado estado en el plano de control no probaba todavía movimiento de paquetes.

Además, el módulo solo configuraba y observaba el ingreso. Ese nodo debía señalizar a los demás; el uso en otros puntos quedó para estudio futuro. Una tabla completa en el ingreso no certificaba cada salto intermedio.

Los contadores necesitaban una biografía

Los octetos y paquetes podían sufrir discontinuidades cuando se reinicializaba el subsistema de gestión y en otros momentos. La MIB exponía el instante de la última discontinuidad. Sin comprobarlo, restar dos lecturas podía producir una cifra sin significado.

La edad, el tiempo activo y el tiempo sobre el primario usaban TimeTicks, que volvían al comienzo aproximadamente cada dieciséis meses. La propia RFC enseñaba a calcular porcentajes con dos muestras y exigía tratar el retorno. Un valor aislado no revelaba toda la vida del túnel.

Las notificaciones tampoco eran un diario. Los avisos de subida, bajada, cambio de camino y cambio de ruta debían limitarse a uno por minuto durante oscilaciones rápidas. El grupo de notificaciones era opcional y la generación estaba desactivada por defecto. Silencio podía significar estabilidad, función ausente, configuración desactivada, pérdida o limitación.

La norma separó cambio y reruta: el primero significaba que cambió el camino activo; la segunda, que el mismo camino adoptó otra ruta. La identidad del camino sobrevivía a una variación de sus saltos.

El siguiente índice libre aún podía perderse

Para crear un túnel, la aplicación leía un índice candidato. Dos gestores podían leer el mismo. Solo el SET posterior resolvía la carrera; quien perdía tenía que consultar otra vez. Leer una oportunidad no equivalía a reservarla.

Algunos cambios exigían pasar la fila a notInService, modificarla y devolverla a active, con nueva señalización. Ese estado describía el ciclo administrativo de la fila, no el éxito del túnel en el plano de datos.

La conformidad mínima podía ser totalmente de lectura. La plena permitía las escrituras declaradas; los avisos seguían siendo opcionales. Por tanto, cumplir RFC 3970 no garantizaba que el dispositivo aceptara configuración remota ni emitiera eventos.

La asociación con la MIB de interfaces, la MIB de túneles IP y las convenciones MPLS de RFC 3811 enlazaba identidades y tipos. No convertía una fila de interfaz, una encapsulación, una señalización y una entrega de servicio en el mismo hecho.

La lectura revelaba la red; la escritura podía alterarla

Cambiar grupos administrativos modificaba el significado de las restricciones. Cambiar ancho de banda, estado o saltos podía desviar tráfico, provocar oscilación o interrumpirlo. Incluso leer exponía extremos, volúmenes y rutas sensibles. Por eso RFC 3970 recomendó autenticación y privacidad de SNMPv3 y desaconsejó versiones anteriores.

Autenticar al principal no bastaba: la política debía autorizar cada GET o SET. Saber quién es alguien, permitirle una acción y observar el resultado de red seguían siendo decisiones independientes.

La ficha del RFC Editor, la búsqueda de erratas y el IETF Datatracker fijan el estado documental. RFC 9141 corrigió después una referencia de archivo obsoleta en los datos de contacto. Ninguna fuente demuestra adopción, disponibilidad, comportamiento de un fabricante o un incidente.

La fuerza histórica de la MIB fue dejar varias verdades juntas sin fundirlas: resumen de túnel, estado de camino, decisión de ruta, contador condicionado y evento deliberadamente incompleto. La observabilidad dependía de respetar esas fronteras.

Fuentes