Resumen

  • RFC 7067 y RFC 8171 definen cómo los modelos Push y Pull pueden sustituir parte del tráfico unknown-unicast, ARP y ND por correspondencias de un directorio, pero la ausencia significa cosas distintas en un conjunto completo y en uno incompleto.
  • RFC 8302 y RFC 8380 trasladan esas correspondencias a la optimización y al reenvío. Cuanto antes actúa el dato, mayor es el daño potencial de una entrada obsoleta o falsa, por lo que confianza, caducidad, actualización y protección del canal son controles independientes.

Análisis

Cuando una respuesta evita la pregunta correcta

La inundación es costosa porque pregunta a muchos nodos por una sola dirección. Un directorio promete sustituir esa repetición por una correspondencia: dirección IP, dirección MAC, Data Label y RBridge de salida. El borde puede recibirla por anticipado mediante Push o solicitarla cuando la necesita mediante Pull. En ambos casos, una consulta centralizada evita tráfico multidestino.

La contrapartida es que la red deja de volver a preguntar mientras confía en la respuesta. Si una máquina virtual se traslada de RB1 a RB2, el dato que llevaba a RB1 puede conservar una forma válida y una ruta equivocada. La eficiencia de ayer se convierte en la persistencia del error de hoy.

RFC 7067, publicado como Informational en noviembre de 2013, formula el problema y el diseño general. Linda Dunbar lo escribió con Donald Eastlake, Radia Perlman e Igor Gashinsky. No es una especificación del Internet Standards Track. RFC 8171, coescrito por Donald Eastlake 3rd, Linda Dunbar, Radia Perlman y Yizhou Li, lleva mecanismos concretos al Standards Track en junio de 2017.

La secuencia continúa con RFC 8302, de Yizhou Li, Donald Eastlake 3rd, Linda Dunbar, Radia Perlman y Muhammad Umair, y con RFC 8380, de Linda Dunbar, Donald Eastlake 3rd y Radia Perlman. Ambos son Standards Track de 2018. El registro público de IETF de Linda Dunbar confirma su participación. No convierte un trabajo colectivo en invención individual ni prueba que una red concreta lo haya desplegado.

Completo no es sinónimo de central

RFC 8171 permite que un servidor Push anuncie si posee información completa para un Data Label. La palabra cambia el efecto del protocolo. Con un conjunto completo ya distribuido, un RBridge puede descartar una trama hacia una dirección unicast ausente en vez de inundarla. Con un conjunto incompleto, esa ausencia solo demuestra que el directorio no sabe.

La diferencia puede expresarse como dos negaciones. “No tengo el dato” conserva la posibilidad de que el destino exista. “Sé que no existe en este ámbito” permite suprimir la búsqueda. Mezclarlas en un único código de no encontrado concede a una base parcial autoridad para cerrar el camino.

Tampoco basta con que la base esté en un lugar central. RFC 8171 llama primario al servidor que obtiene información mediante un mecanismo fiable destinado a asegurar frescura, pero deja fuera de alcance cómo se puebla ese servidor. El protocolo puede distribuir un dato correctamente sin haber observado la migración que lo volvió falso. Un secundario puede copiar con fidelidad el error del primario.

Por eso la procedencia tiene varias capas. Hay que saber qué sistema originó la correspondencia, qué servidor la entregó, qué cobertura declaró, qué cliente la guardó y qué observación la confirma. La firma de un canal demuestra la relación entre hablantes; no demuestra que la dirección continúe en el mismo puerto.

El servidor debe recordar quién podría recordar

Las respuestas Pull pueden llevar una duración de vida. Mientras no caducan, el cliente evita nuevas consultas. Pero una caché positiva puede sobrevivir a un traslado, y una caché negativa puede sobrevivir a la creación de un nuevo terminal. La corrección exige ocuparse de ambas.

RFC 8171 obliga a un servidor que emplea duraciones distintas de cero a enviar actualizaciones para reducir el tiempo durante el cual los clientes usan datos obsoletos. Ofrece tres métodos de consistencia. El más ligero conserva fechas agregadas por Data Label y puede vaciar grandes conjuntos. El más detallado registra qué RBridge recibió qué respuesta positiva o negativa y hasta cuándo podría conservarla. El primero ahorra estado en el servidor; el último ahorra invalidaciones innecesarias.

No existe una opción sin coste. Guardar menos detalle desplaza trabajo hacia la red y los clientes. Guardar más detalle hace que el directorio mantenga estado acerca del estado de otros. Incluso el mecanismo más preciso admite pequeños periodos en que la información ya cambió en el servidor y aún no fue corregida en la caché.

La duración debe leerse como un presupuesto de error temporal. Un valor largo mejora la tasa de aciertos y reduce consultas, pero permite que un movimiento tarde más en hacerse visible. Un valor corto acelera la revisión y aumenta carga. En un entorno donde las VM cambian con frecuencia, esa decisión debe seguir la movilidad real y no una preferencia abstracta por menos tráfico.

La confianza ordena pruebas, no crea hechos

RFC 8302 utiliza una caché de relaciones IP/MAC/Data Label para optimizar ARP y Neighbor Discovery. La información puede venir de gestión, de un directorio o del plano de control, y del aprendizaje del plano de datos. Dado que las fuentes pueden discrepar, la función de nivel de confianza permite establecer fiabilidad relativa.

Con datos completos y fiables, el directorio puede limitar el daño de ARP o ND falsificados. Sin SEND, el aprendizaje del plano de datos es manipulable. Pero una fuente protegida tampoco es infalible: puede recibir una configuración incorrecta o retrasarse tras un cambio. El nivel de confianza hace explícita una preferencia; la implementación decide cómo asignarla.

La prueba operativa aparece cuando se mueve el terminal. RFC 8302 dispone que una entrada dinámica local desaparezca si falla el enlace y que una correspondencia sin refresco envejezca. Si el terminal pasa a otro borde, la nueva localización debe reemplazar a la antigua y propagarse. Una política de confianza es sana si permite que evidencia más reciente y apropiada corrija el registro; se vuelve autoridad ciega si protege el dato frente al mundo que debía describir.

Preencapsular significa confiar antes

RFC 8380 permite que nodos no-RBridge de confianza preencapsulen tráfico TRILL con ayuda del directorio. Conocen de antemano el RBridge de salida y pueden evitar una etapa ordinaria de descubrimiento. El diseño reduce tablas y difusión en algunos escenarios, pero traslada capacidad de decisión hacia esos nodos.

El RFC advierte que un nodo asistido no fiable puede falsificar nicknames de entrada o salida y direcciones MAC interiores o exteriores. También puede obtener información de topología. Si se ataca el camino entre directorio y nodo, una correspondencia falsa puede desviar paquetes y violar la política sobre quién debe recibirlos. Por eso recomienda autenticación y cifrado, además de parches, configuración segura y acceso mínimo.

El cifrado protege el trayecto, no la actualidad del contenido. Una entrada obsoleta recibida de la sesión correcta sigue siendo obsoleta. La seguridad necesita varias preguntas consecutivas: ¿quién habló?, ¿qué ámbito cubre?, ¿qué confianza merece?, ¿hasta cuándo?, ¿qué actualización siguió al cambio?, ¿el reenvío observado coincide?

Un registro útil puede ser refutado

La propuesta posterior de Lu Heng sobre especificación inicial mínima, decisión futura localizada y adopción voluntaria ofrece a Sofia Ren una lente editorial. El formato común puede describir la relación necesaria para interoperar. El cliente conserva la decisión sobre confianza, caché, repliegue y aceptación de riesgo. Esta comparación no se atribuye a los autores de los RFC.

La primacía del código en funcionamiento endurece el criterio: el registro sirve mientras coincide con el sistema vivo. Si enlace, movimiento o tráfico lo contradicen, debe poder caducar, corregirse o dejar paso a otra fuente. El directorio coordina una representación; no adquiere soberanía sobre el hecho representado.

Ninguno de los RFC citados aporta cifras de adopción, ahorro real de difusión, pérdida, convergencia o incidentes evitados. Sí permiten construir una disciplina de evidencia. Antes de convertir una ausencia en descarte, una correspondencia en ruta o una base central en autoridad, hay que demostrar cobertura, origen, actualidad y capacidad de corrección.

Un buen directorio responde rápido. Un directorio confiable también sabe cuándo su respuesta ya no debe mandar.

Fuentes