Resumen

  • El borrador actual de multicast en LISP explica que la pérdida del ITR que actúa como raíz exige reconstruir estado hacia otro encapsulador y volver a comunicarle los flujos (S-EID,G) deseados.
  • Anycast puede conservar el RLOC y convertir el cambio del underlay en una reconvergencia RPF. El ETR, sin embargo, quizá no sepa que cambió la máquina; el sucesor puede tener que esperar al siguiente Join/Prune periódico.
  • Daniel Kade propone un recibo de sucesión de raíz y una deuda explícita de reenvío de joins. Son controles operativos, no nuevos campos de LISP ni de PIM.

Una dirección sana puede ocultar un árbol mudo

Imaginemos un flujo audiovisual que sale de un sitio y llega a receptores alojados en varias redes. El Ingress Tunnel Router de origen falla. El enrutamiento lleva el RLOC anycast a un segundo ITR. Las sondas vuelven a alcanzar la dirección y el underlay multicast corrige la interfaz de camino inverso. El equipo de routing puede afirmar, con razón limitada, que la dirección se recuperó deprisa.

Eso no demuestra la recuperación del servicio. El ITR antiguo guardaba el detalle de qué ETR remoto se había unido a qué origen y grupo. La nueva instancia puede aceptar tráfico dirigido al mismo RLOC sin conocer ese inventario. El nombre de la raíz sobrevive; su memoria pertenecía a otro proceso. Hasta que los receptores repitan su intención, la raíz sustituta puede ignorar qué debe encapsular y a quién.

Anycast no incumple aquí su contrato. Su función es permitir que varios lugares anuncien una dirección y que el routing seleccione una instancia. No promete replicar el estado interno del servicio. El error de gobierno aparece cuando un operador toma la accesibilidad de la dirección como certificado de continuidad de todo sistema con estado que se presenta detrás de ella.

draft-ietf-lisp-rfc6831bis-07 está activo y en IESG Evaluation. Aspira a Proposed Standard y, si se aprueba, sustituirá al RFC 6831 experimental. La revisión 07 se publicó el 11 de septiembre de 2026. La comparación con la 06 muestra sobre todo lenguaje normativo, referencias actualizadas de IGMP y MLD y mantenimiento editorial. El límite que analiza este artículo pertenece a la arquitectura vigente, no a una supuesta novedad de esa revisión.

La intención usa EID; el underlay usa RLOC

LISP separa Endpoint Identifiers de Routing Locators. Dentro de los sitios, el origen y los receptores hablan de un EID de origen y un grupo multicast. El underlay construye rutas y árboles con RLOC. La separación estabiliza la identidad frente a cambios de ubicación, pero reparte el estado multicast entre dos espacios de nombres.

Un receptor se une a (S-EID,G) mediante IGMPv3 o MLDv2. Su ETR busca el EID del origen y selecciona un RLOC de ITR según prioridad y peso del mapping. En un underlay multicast envía dos señales. Un PIM Join/Prune encapsulado por unicast lleva (S-EID,G) al ITR elegido. Otro Join/Prune crea (S-RLOC,G) en el underlay. El primero explica al encapsulador qué flujo interno se solicita; el segundo construye la distribución apoyada en el locator.

En un underlay unicast, el ITR mantiene una lista explícita de RLOC de ETR receptores y hace replicación en cabecera, con una copia exterior para cada destino. Al otro extremo, el ETR elimina la cabecera LISP y consulta su FIB multicast interno (S-EID,G) antes de reenviar hacia los receptores locales.

Ninguna de estas pruebas reemplaza a las demás. Un Map-Reply identifica locators, pero no confirma que una instancia física haya instalado el flujo. Una comprobación RPF válida muestra la dirección del árbol en el underlay, pero no que la raíz conozca el S-EID. La permanencia del join en el sitio receptor no prueba que el encapsulador remoto lo recuerde. Incluso puede llegar un paquete por un árbol (RLOC,G) compartido y ser descartado porque no existe estado interior coincidente.

El objeto operativo no es, por tanto, “la ruta multicast” en singular. Es una cadena: intención del receptor, estado fronterizo del ETR, raíz física seleccionada, estado EID del ITR, replicación en underlay o cabecera, aceptación por el ETR y observación final. Cada tramo tiene custodio y reloj propios.

El cambio físico crea una obligación de sucesión

La sección 6 del borrador distingue una avería del ITR de un cambio RPF ordinario. En unicast, la accesibilidad local puede permitir otra selección de locator con poca coordinación. En multicast LISP, el ITR escogido es la raíz encapsuladora del árbol. Si deja de estar disponible, los ETR unidos deben crear estado (S-RLOC,G) hacia la nueva raíz y enviar un Join/Prune encapsulado que le diga qué (S-EID,G) esperan.

La obligación tiene una población precisa: todos los ETR afectados. También tiene un contenido preciso: los estados origen-grupo que cada uno necesita. La detección, la nueva selección y el reenvío no ocurren a la vez en todos los sitios. Una sola marca de tiempo llamada “failover terminado” oculta esa distribución y, en especial, su cola más lenta.

Anycast reduce la señal visible. Si varios ITR usan el mismo RLOC, la ruta mueve la dirección y el underlay puede ver únicamente un cambio de interfaz RPF. Para el ETR remoto, la dirección no ha cambiado. Puede no existir un evento que dispare inmediatamente el reenvío unicast de (S-EID,G). El texto advierte que el nuevo ITR anycast podría aprenderlo solo en el siguiente envío periódico del ETR.

No hay base para atribuir a ese intervalo un número universal. Cambian los temporizadores, las implementaciones, la pérdida, la convergencia y el tipo de underlay. Tampoco se deduce que toda conmutación pierda tráfico. La afirmación firme es más modesta: recuperar una dirección y recuperar el estado son hechos diferentes, y el primero no prueba el segundo.

Deuda de reenvío de joins

Llamo deuda de reenvío de joins al conjunto de intenciones receptoras aún no demostradas en el ITR sustituto. Cuando cambia la raíz física, cada ETR cuyo (S-EID,G) no conste instalado abre una partida. No es un juicio moral ni un simple contador de paquetes: evita que una transición distribuida se pierda detrás de una única dirección verde.

Una partida mínima asocia ETR, S-EID, grupo, ITR anterior, sucesor previsto, generación del último join, hora de actualización, modo de underlay y condición de cierre. Si el equipo emite confirmación de instalación, sirve como parte de la prueba. Cuando no existe, habrá que unir una inspección acotada del estado en la raíz con observación de paquetes en el ETR o en un receptor canario.

No saldan la deuda un ping al RLOC, una entrada en la RIB, un mapping cacheado, una adyacencia PIM ni un proceso vivo. Ninguno demuestra que esa intención concreta alcanzó a esa instancia física. El regreso de un receptor tampoco acredita al resto; cada ETR puede esperar un ciclo distinto.

También puede cerrarse una partida porque la intención dejó de ser válida. El receptor abandonó el grupo, el origen terminó o la política movió el flujo. El cierre debe decir “instalado y observado”, “retirado de forma explícita”, “expirado según regla declarada” o “degradación aceptada por responsable identificado”. La desaparición silenciosa no equivale a recuperación.

El recibo de sucesión de raíz

El recibo de sucesión de raíz reúne esas pruebas. Es una propuesta de Daniel Kade para la gobernanza operativa, no una modificación de paquetes LISP, PIM, IGMP o MLD. Impide que un equipo cierre el incidente solo con la capa que administra.

Primero identifica la instancia física antigua y la nueva, sus RLOC individuales o compartidos, la fuente y hora de detección, la confianza, la versión de mapping usada y el titular de la decisión. Anotar únicamente la dirección compartida sería omitir el hecho que importa: la sucesión física oculta tras ella.

Después registra el avance del control por alcance: último (S-EID,G) conocido en la raíz anterior, nueva selección, convergencia RPF, generación de join del ETR, reenvío encapsulado y estado instalado en el sucesor cuando sea observable. Cada elemento conserva punto de captura y fuente de reloj. Si los relojes no son comparables, sus marcas no deben presentarse como una secuencia causal segura.

Por último sigue el efecto: primer paquete aceptado por la nueva raíz, primer paquete válido en cada ETR muestreado, continuidad de secuencia o de aplicación cuando exista, ventana de pérdida o duplicación, tráfico no solicitado descartado en la consulta interior y edad de la deuda restante. Una prueba de router no debe llamarse salud de aplicación.

El recibo incorpora la autoridad de reversión. Quizá permita restaurar un locator unicast concreto, drenar el sucesor, provocar una actualización controlada, mover el flujo o aceptar temporalmente la replicación en cabecera. La acción depende de la implementación; el requisito de gobierno es nombrar su alcance, su responsable y su verificación.

Mover la replicación mueve la evidencia

El borrador permite replicar dentro de un sitio, en un router de tránsito, en ETR o en ITR. El underlay multicast conserva estado en la red intermedia. El unicast reduce ese estado y desplaza el coste a copias y ancho de banda del origen. Distintos receptores también pueden elegir ITR diferentes por prioridad y peso de Map-Reply.

La contabilidad debe seguir esa topología. La lista de ETR en el ITR es un plan, no un recibo de entrega. Un árbol (S-RLOC,G) saludable puede transportar más de un origen interior. El documento señala que un sitio puede recibir tráfico que no pidió por compartir árbol y descartarlo al no hallar (S-EID,G). El descarte es correcto, pero la capacidad común ya se consumió.

La seguridad exige distinguir tráfico esperado ausente de tráfico inesperado presente. El borrador describe cómo un sitio malicioso puede hacer llegar datos no solicitados a sitios legítimos del mismo árbol. “El paquete llegó al ETR” puede significar éxito, desperdicio o ataque; el estado interior y el conjunto previsto de receptores deciden cuál.

El hueco de diagnóstico sigue abierto

El detalle de locator reachability, ciertos comportamientos de mPITR y el diseño de mtrace para multicast LISP quedan fuera del alcance del borrador. El texto dice que este último aún debe definirse a partir de Mtrace Version 2. Un diagnóstico genérico de camino no ofrece, por sí solo, una vista completa a través de EID y RLOC.

Cada métrica debería declarar su capa. La prueba del underlay muestra el camino RLOC; el ITR, el estado (S-EID,G); el ETR, la desencapsulación y búsqueda interior; el receptor, la llegada útil. Correlacionarlas puede sostener una afirmación de servicio. Sustituirlas por una sola, no.

El trabajo de un borrador IETF es especificar el mecanismo y sus límites, no entregar una plataforma universal de observabilidad. La precisión corresponde a operadores y proveedores. “La conmutación anycast tuvo éxito” debe limitarse a la dirección. Para declarar recuperado el multicast hay que demostrar también la sucesión de estado y el resultado en los receptores.

Fuentes

  1. Borrador actual de multicast LISP
  2. Historial del borrador
  3. Registro API de Datatracker
  4. Revisión 07 en HTML
  5. Revisión 07 en texto
  6. Diferencias entre las revisiones 06 y 07
  7. Grupo de trabajo LISP
  8. RFC 6831
  9. RFC 9300: plano de datos LISP
  10. RFC 9301: plano de control LISP
  11. RFC 8059: atributos PIM Join para LISP
  12. RFC 7761: PIM
  13. RFC 8487: Mtrace Version 2
  14. RFC 9776: IGMPv3
  15. RFC 9777: MLDv2
  16. RFC 7799: terminología de medición
  17. Fuente XML de la revisión 07