Resumen

  • El historial del IETF registra draft-ietf-pim-gaap-23 el 3 de septiembre de 2026 y sitúa el documento en AD Followup; sigue siendo un Internet-Draft Experimental, no un RFC aprobado.
  • La revisión fija 239.0.0.0/10 para IPv4 y el rango de uso experimental del RFC 10028 para IPv6, evitando que implementaciones independientes partan de espacios configurados de forma distinta.
  • El mismo texto admite que, durante una partición, un lado puede pasar al candidato +1 y el otro al +2 para el mismo nombre. Como las direcciones son diferentes, no hay colisión y el grupo puede seguir dividido al restablecerse el enlace.
  • Un contador sin colisiones no demuestra que todos los participantes compartan la misma correspondencia entre nombre y dirección.
  • Un recibo local de convergencia permitiría conservar esa evidencia. Es una propuesta analítica de Daniel Kade, no una obligación del borrador o del IETF.

Un rango fijo elimina una discrepancia previa

El historial de GAAP fecha la revisión 23 el 3 de septiembre. Ese día el subestado pasó de Revised I-D Needed a AD Followup y la revisión de IANA volvió a Version Changed - Review Needed. La ficha del Datatracker sigue describiendo un trabajo en curso. Ninguno de esos movimientos convierte la propuesta en estándar ni prueba que el IESG la haya aprobado.

El registro de cambios de la revisión 23 dice que atendió el DISCUSS y los comentarios de Éric Vyncke. Su importancia se entiende al mirar dos modificaciones distintas: una obliga a compartir el terreno de cálculo; la otra nombra un estado en el que compartir ese terreno todavía no produce una única respuesta.

GAAP propone asignar direcciones de grupo multicast sin un servicio central. La aplicación entrega un nombre. El protocolo aplica SHA-256 a cuatro cadenas permitidas: el nombre sin cambios y el mismo nombre con +1, +2 o +3. Un nodo anuncia el primer candidato mediante un Claim y espera aproximadamente un intervalo periódico, cercano a un minuto. Si no recibe una reivindicación en la que otro nombre use la misma dirección de red, la aplicación puede empezar a utilizarla. Si aparece esa colisión, prueba el candidato siguiente.

La arquitectura evita mantener un directorio global. Un nodo no tiene que almacenar los Claims de todos los demás. Conserva sus asignaciones y temporizadores locales, y vuelve a construir ese estado blando al reiniciarse. Esa economía de estado solo funciona entre productos distintos si todos comparten las entradas fundamentales del cálculo.

La comparación oficial entre las revisiones 22 y 23 muestra cómo se cierra una brecha. Antes, los rangos de uso para las aplicaciones dependían de la configuración del operador. Ahora el borrador sostiene que un rango configurable solo sería fiable con otra instancia configurada igual; el operador no controla qué biblioteca GAAP incorpora cada aplicación independiente.

Por eso IPv4 debe usar 239.0.0.0/10. El texto remite al RFC 2365 para los bloques de expansión del ámbito Organization-Local y al RFC 5771 para las reglas de asignación. En IPv6 debe usar 0xFE000000–0xFEFFFFFF, el rango Experimental Use que el RFC 10028 reserva para probar nuevos protocolos de asignación dinámica. GAAP no obtiene exclusividad sobre ese espacio; otros experimentos también pueden emplearlo.

Fijar ambos rangos es una decisión de interoperabilidad. Evita que dos programas conformes calculen respuestas dentro de universos incompatibles. No garantiza que terminen eligiendo la misma respuesta dentro del universo común.

La ausencia de choque puede ocultar una división

La reparación de particiones contempla el caso visible. Si los dos lados terminan usando la misma dirección para un nombre de grupo, sus Claims se encuentran al sanar la conectividad y el procedimiento puede resolver la condición.

La revisión 23 incorpora otro recorrido. Imaginemos que, en un lado, una colisión local ajena obliga al nombre compartido a abandonar su candidato base y escoger +1. En el otro lado, otra colisión obliga al mismo nombre a escoger +2. Ambas decisiones pertenecen a la lista permitida y cada una puede ser válida dentro de su segmento.

Al volver el enlace, las dos direcciones son diferentes. Por tanto, no aparece el patrón que GAAP denomina colisión: una misma dirección adjudicada a nombres distintos. El borrador afirma que el grupo queda dividido y deja su resolución como cuestión abierta para el experimento.

La posición de Éric Vyncke en la papeleta del IESG había planteado precisamente si los lados que usan +1 y +2 llegarían a detectarse y converger. La nueva redacción es valiosa porque ya no permite confundir el borde con un detalle de implementación. Pero reconocer la pregunta no equivale a contestarla.

Así, el valor cero en una métrica puede describir dos realidades incompatibles. Puede significar que el mismo nombre conduce a una dirección y todos los miembros se reúnen. También puede significar que conduce a dos direcciones y nadie disputa la dirección del otro lado. La colisión es un suceso negativo; su ausencia no certifica la propiedad positiva de rendezvous.

El RFC 10019, que formula el problema de la asignación multicast sin configuración central, exige detectar y resolver colisiones de direcciones creadas durante una partición temporal. GAAP intenta responder a esa exigencia. El nuevo caso queda fuera de la palabra «colisión»: es una divergencia de correspondencia. Un experimento serio debe conservar ambas categorías por separado.

El resultado experimental necesita una prueba positiva

El borrador no presenta GAAP como tecnología desplegada. Declara que la asignación descentralizada basada en hash no ha sido desplegada y explica por qué solicita el tratamiento Experimental. El trabajo debe medir si la detección y la resolución bastan en condiciones prácticas, qué tasas de colisión surgen a distintas escalas y cuánto crece el tráfico periódico de Claims. La experiencia apoyará una futura vía hacia Standards Track o descubrirá limitaciones que obliguen a revisar el diseño.

Para incluir la división silenciosa, no basta con sumar los conflictos observados. Hace falta reconstruir el destino de un nombre. ¿Qué candidato seleccionó cada lado? ¿Qué dirección usó? ¿Cuándo sanó el enlace? ¿Los participantes previstos volvieron a intercambiar tráfico en un solo grupo? Sin esos datos, un caso no detectado desaparece de la estadística justamente porque no produjo alarma.

Un recibo de convergencia puede ser local y acotado. Podría vincular un identificador del nombre protegido para no revelar más de lo necesario, las cohortes de cada lado, el índice del candidato, la dirección elegida, los tiempos de partición y reconexión, la ruta de detección, la alcanzabilidad posterior y la decisión de reparación. El revisor marcaría convergió, divergió o sin observación suficiente.

Ese recibo es una propuesta editorial mía. No figura en GAAP ni representa una instrucción del IETF, IANA o el grupo PIM. Su función es separar evidencia de interpretación: demostrar qué ocurrió antes de declarar que el mecanismo funcionó.

La distinción de Lu Heng en Minimum Initial Specification, Localized Future Decision ayuda a conservar la descentralización. El rango fijo es la regla mínima compartida. Los métodos para observar y reparar la excepción pueden evolucionar en cada experimento, siempre que sus resultados sean comparables y no se pierdan.

Running Code Primary evita sustituir ese resultado por el progreso documental. IANA puede asignar números y los revisores pueden cerrar posiciones; nada de eso reproduce una partición con candidatos diferentes. La prueba concluyente debe ejecutarse con implementaciones identificadas y dejar una traza que una el nombre, la dirección y la comunicación final.

La revisión 23 hace dos cosas honestas: reduce una divergencia evitable y publica otra que todavía no sabe resolver. Gobernar bien el experimento significa no permitir que la primera oculte la segunda.

Fuentes

  1. Ficha del Datatracker de GAAP
  2. Historial de GAAP
  3. GAAP, revisión 23
  4. GAAP, revisión 22
  5. Comparación oficial 22–23
  6. Papeleta del IESG para GAAP
  7. RFC 10019: problema de asignación multicast zeroconf
  8. RFC 10028: identificadores dinámicos de grupo multicast IPv6
  9. RFC 2365: multicast IP con ámbito administrativo
  10. RFC 5771: directrices IANA para direcciones multicast IPv4
  11. Lu Heng — Minimum Initial Specification, Localized Future Decision
  12. Lu Heng — Running Code Primary