Resumen

  • Una incorporación prevista no debe usarse hasta que los mecanismos normales de vivacidad de IS-IS confirmen todas las adyacencias pertinentes.
  • Una retirada prevista es distinta: la física orbital hace casi segura la pérdida, por lo que las métricas y los caminos deben cambiar con margen para converger antes de que el enlace desaparezca.
  • La auditoría debe conservar por separado la autoridad del calendario, su recepción, la adyacencia observada, la convergencia, el cálculo PCE, la programación de hardware y el resultado del tráfico.

La línea verde del mapa

A las 14:00, el controlador dibuja una línea verde entre dos satélites. La geometría ha entrado en una ventana de conectividad óptica posible. El PCE ya ha calculado un camino de Segment Routing que cruza esa arista y el equipo de entrada tiene preparada la pila de etiquetas.

El calendario puede ser auténtico y el cálculo correcto para el grafo previsto. Eso no demuestra que los terminales se hayan adquirido, que la capa de enlace funcione, que IS-IS haya formado una adyacencia ni que un paquete haya cruzado. El pronóstico aporta valor porque llega antes que la realidad; el peligro aparece cuando esa ventaja temporal se convierte en falsa autoridad sobre la realidad.

RFC 9717 formula una asimetría decisiva. Una conexión anunciada no está garantizada: puede fallar por muchas razones. Una desconexión dictada por la dinámica orbital es prácticamente segura. La física puede cerrar una ventana, pero no puede prometer que terminales, puntería y control hayan logrado abrirla.

El propio documento también limita su autoridad. Fue publicado en enero de 2025 como RFC Informational del Independent Stream, presenta la visión de su autor, no la de la IETF ni un consenso comunitario, y no propone cambios de protocolo. Su publicación no prueba validación, implantación ni adopción.

Un calendario necesita identidad y recepción

El plano de gestión debe distribuir los cambios previstos a todos los nodos L1 o L2 que decidirán con ellos, además de gateways y PCE. El mecanismo de distribución queda fuera de alcance. Por eso el registro operativo necesita emisor, versión, vigencia, destinatarios, acuses y sustituciones. Sin ellos, dos controladores pueden decir que usan “el calendario” mientras actúan sobre futuros distintos.

Recibir tampoco significa aplicar. Un satélite puede tener la versión correcta y un terminal enfermo; un gateway puede perder una revisión; un PCE puede refrescar su base antes de que llegue la actualización. El pronóstico y el instante de incorporación a cada decisor deben conservarse juntos.

Para añadir, primero observar

RFC 9717 exige que una nueva conexión o un nodo incorporado no provoquen cambio funcional hasta que la vivacidad habitual de IS-IS pruebe todas las adyacencias relevantes. Se pueden precalcular tablas y caminos, pero no deben instalarse rutas que dependan de la nueva topología antes de confirmarla.

El precálculo es una hipótesis documentada: grafo de entrada, restricciones, algoritmo, momento y lista de SID. No prueba que el camino exista. Después de la adyacencia, LSDB, BGP-LS y la base del PCE aún deben reconciliarse con el estado actual.

Si se preinstala, hace falta un retroceso demostrable si la topología no llega a operar. El recibo debe incluir disparador, responsable, plazo, etiquetas afectadas y eliminación del estado obsoleto. “Instalado” es incompleto cuando la instalación depende de un acontecimiento físico futuro.

Para retirar, actuar antes de perder

Esperar a que la vivacidad declare la muerte del enlace desperdiciaría la predicción. El RFC recomienda elevar la métrica con tiempo suficiente para propagar y converger; gateways y PCE también deben actualizar e instalar alternativas antes de la pérdida. El margen depende de escala, configuración, difusión, cálculo y programación.

Conviene conservar el instante previsto de desconexión, el cambio de métrica, la dispersión de propagación, el cálculo, el acuse de hardware y el último paquete visto. El RFC considera más seguro expresar el cambio por el IGP que ocultar una exclusión local en cada router, porque así se reducen problemas de información incompleta y sincronización.

La cadena completa

La propuesta combina IS-IS, Area Proxy, stripes orbitales, SR-MPLS y cálculo por gateway o PCE. La prueba completa distingue ocho peldaños: calendario autorizado; misma versión recibida; adyacencia observada; topología convergida; camino calculado; estado instalado; ruta realmente usada; servicio medido.

Un acuse de hardware no prueba un enlace remoto. Una adyacencia no prueba capacidad. Una LSDB limpia no prueba la selección de la pila correcta. Una prueba de cliente no identifica por sí sola una entrada PCE caducada. Hace falta un identificador común y una cronología que una las capas sin borrarlas.

Todavía es una propuesta

El documento supone que la red está conectada casi siempre, que existen suficientes enlaces y ancho de banda y que el calendario suele ser preciso. Si no hay camino, acepta descartar paquetes y no exige almacenamiento. Son premisas, no mediciones de una constelación concreta.

El trabajo futuro reconoce que faltan estadísticas públicas exactas de conectividad ISL, límites de ángulo, distancia y velocidad de seguimiento, y validación por simulación y operación. Una stripe podría abarcar unas pocas órbitas o miles de satélites, quizá fuera de los límites de una implementación IGP.

La lectura responsable no es aprobación ni rechazo. El horario puede evitar pérdidas previsibles y los protocolos existentes ofrecen herramientas plausibles. Pero el pronóstico no se autentica solo, el camino no se instala solo y el servicio no aparece porque el control se vuelva verde.

Fuentes

Registros primarios: RFC 9717, ficha del RFC Editor, historial del borrador y conflict review. Contexto: RFC 9666, RFC 8402, RFC 8660, RFC 4655 y RFC 9552.

Marco editorial público: la realidad y no la defensa de una posición.