Resumen

  • RFC 9107 permite calcular el coste interior desde una ubicación IGP configurada para un cliente, grupo o reflector completo, en vez de usar la posición física del reflector.
  • “Óptimo” significa el camino que esa perspectiva escogería entre los mismos candidatos elegibles y bajo la política pertinente; no demuestra mínima latencia, coste o congestión.
  • La seguridad exige probar asignación de raíz, época topológica, conjunto candidato, presupuesto de cálculo, backup, Adj-RIB-In del cliente y resultado en la FIB.

Pensemos en un reflector virtual instalado en un centro de datos y clientes en tres ciudades. Dos border routers publican el mismo prefix. Los atributos prioritarios de BGP empatan y la decisión alcanza el coste IGP. Para el cliente oriental una salida está cerca; para el reflector occidental, la otra.

El reflector responde correctamente a “qué next hop está más cerca de mí”. Envía la salida occidental a todos. El cliente oriental no ve el candidato que habría preferido. Sus paquetes atraviesan la red hacia una salida óptima solo para una máquina de control que nunca los reenvía.

No hay un componente aislado averiado. Las métricas son correctas, el Decision Process funciona y la session está estable. El error es de perspectiva. Un cálculo exacto desde el lugar equivocado produce una respuesta sistemáticamente equivocada para quien debe usarla.

RFC 4456 ya reconoce el intercambio. Route reflection escala al resumir información y anunciar normalmente solo el best path del reflector. Como el coste IGP cambia según el router, ciertas topologías no reproducen un full mesh. El enfoque clásico intenta que la topología de reflexión sea congruente con la de forwarding.

Los reflectors centrales o virtuales rompieron esa proximidad. Pueden vivir fuera del data path donde resulte cómodo alojar compute. Su ubicación IGP se convierte en input accidental de traffic engineering. Mover el servicio de control puede mover egresses sin alterar una route externa.

RFC 9107 permite elegir una raíz lógica: un nodo de la topología link-state identificado por una dirección, por ejemplo una loopback. El reflector construye un shortest-path tree desde ese punto y usa sus costes a los BGP next hops en el tie-break interior.

La raíz es un punto de vista, no un waypoint. El tráfico no tiene que atravesarla. La route seleccionada, la resolución recursiva del cliente y su FIB determinan el recorrido. Dibujar la raíz como salto físico atribuye al modelo un efecto que no posee.

El operador elige granularidad: una raíz para el reflector, una por grupo o una por cliente. Una implementación compatible necesita admitir al menos una categoría. El sello de RFC 9107 no garantiza cálculo individual.

Cada opción acepta una aproximación. Una raíz global consume poco, pero repite el sesgo tradicional. Una región representa mal a algunos bordes. Una raíz por cliente es más precisa y multiplica SPF y porciones del Decision Process. Precisión y capacidad son la misma decisión vista desde lados distintos.

“Optimal” tiene alcance técnico. En la forma básica, ORR sustituye el coste desde la raíz en el paso e de Phase 2 de RFC 4271. Las políticas anteriores siguen dominando. Una local preference superior puede vencer al next hop cercano.

IGP cost tampoco equivale a latencia, congestión, precio, pérdida o experiencia. ORR facilita hot-potato cuando los atributos anteriores permiten comparar por cercanía. La afirmación correcta es “salida más cercana según esta métrica tras esta policy”.

Cuando los grupos necesitan políticas distintas, RFC 9107 permite repetir una parte mayor o todo el Decision Process. La raíz deja de ser solo perspectiva topológica y la asignación de grupo puede incorporar una perspectiva comercial.

El mapping cliente-grupo es policy de producción. Cambiarlo puede modificar miles de Adj-RIB-Out sin IGP event ni UPDATE externo. Debe tener versión, review, first cohort, exact diff y rollback.

El reflector necesita todos los candidatos elegibles. No puede reproducir la elección del cliente si nunca aprendió una salida. RFC 9107 indica que ADD-PATH debe operar entre reflectors para mantener ese conjunto en diseños entre clusters.

La capability por sí sola no prueba completitud. Deben coincidir dirección y AFI/SAFI, el sender debe incluir el candidato en su set y la import policy debe conservarlo. La prueba es el Adj-RIB-In real del punto ORR. Un SPF perfecto sobre candidatos incompletos sigue dando una respuesta incorrecta.

ORR redistribuye state. ADD-PATH hasta cada edge permite decisión local, con RIB y update load altos. ORR conserva alternativas en el centro, calcula una salida por perspectiva y envía menos estado. El ahorro periférico concentra información, CPU y confianza.

La topología también necesita procedencia. RFC 9107 cita IS-IS, OSPF y BGP-LS. Una database puede existir y estar stale, incompleta, en otro area o level, o ser distinta entre reflectors. La presencia del feed no demuestra una vista vigente.

BGP-LS transporta información hacia el cálculo, pero no certifica al consumidor. Hay que registrar época, cobertura, health de sesiones y comparar con los routers de forwarding. RFC 7752 fue sustituida por RFC 9552; un diseño actual debe identificar la especificación y el software reales.

La resolución recursiva añade una frontera. Si el next hop BGP se alcanza mediante otra route BGP, interesa el coste IGP final. RFC 9107 exige que un producto incapaz de aportarlo trate esos paths como menos preferidos en esta comparación, sin invalidarlos para Phase 2. Una route válida puede perder porque el cálculo no atraviesa su recursión.

Las limitaciones de producto no son protocolo. Junos documenta condiciones cuando la resolución primaria usa MPLS en lugar de IGP. Cisco documenta límites sobre rSPF, BGP-LU y múltiples topologías IGP en su implementación. Cada address family debe probarse en su plataforma.

Tampoco basta una promesa de vendor. El software puede elegir correctamente para la raíz configurada y aun así representar mal al cliente, usar topology vieja o carecer de un candidato. Corrección de producto y corrección del sistema no son sinónimos.

Los backup roots cambian al observador durante una avería. RFC 9107 recomienda admitir ubicaciones de respaldo; Junos ofrece primary y backup. La reachability puede seguir, pero muchos exits cambian porque cambia el punto desde el que se mide.

El backup necesita un route-set diff previsto. En una prueba acotada se elimina la raíz primaria, se observa el nuevo SPF, se comparan anuncios por grupo y se comprueba FIB y tráfico. “Backup configurado” no es prueba de continuidad.

En forwarding hop-by-hop, varias capas de reflection pueden producir loops si la topología no está diseñada con cuidado. RFC 9107 también admite entornos tunneled, pero una selección racional desde una raíz no garantiza interacción segura con toda la red.

El compute forma parte del contrato. Cientos de raíces pueden implicar cientos de árboles y evaluaciones sobre una tabla grande. Una precisión fina puede extender convergence, agotar CPU o memoria y acumular decisiones precisamente durante el fallo.

La prueba de capacidad combina routes, clients, roots, nodos IGP y fan-out del evento. Mide steady state, recomputación completa, cambio incremental y tiempo entre IGP event, selección ORR y advertisement. Un sistema correcto solo en calma no controla la emergencia.

El primer registro vincula cliente, AFI/SAFI, raíz primaria y backup, grupo, policy, owner y aproximación aceptada. El segundo demuestra candidatos y ADD-PATH entre reflectors. El tercero guarda topology epoch, costes y el paso exacto que decidió.

El cuarto pertenece al cliente: anuncio recibido, import, best reason, resolución, FIB y egress observado. Si otra route vence, es un hecho que debe explicarse, no una excepción que ocultar.

Los escenarios mueven clientes entre grupos, pierden raíces, activan backup, retiran un candidato, envejecen la topología, introducen recursión, policy superior y carga. Cada uno tiene delta esperado y límite temporal.

Rollback restaura perspectiva. Quitar ORR puede devolver al reflector su ubicación física, pero las rutas inversas deben llegar y cambiar la FIB. Si topology o candidatos cambiaron, la línea base no garantiza volver al pasado.

La autoridad se divide. IGP owners validan raíces, BGP owners grupos y políticas, operators capacidad y rollout, y traffic owners el resultado. Un reviewer independiente debe poder rechazar la afirmación de que un nodo representa a un cliente.

La especificación inicial mínima de Heng Lu encaja: estandarizar una raíz lógica y el lugar de la decisión, sin imponer centralización o granularidad. Running-code primacy exige observar topology, set, anuncio, FIB y packet. Data sovereignty significa poder inspeccionar y disputar la perspectiva, no solo almacenar un grafo.

ORR corrige una forma de centralización mediante otra más dirigida. Libera al reflector de su ciudad física, pero convierte el mapa de raíces en una autoridad de routing. La pregunta no es si el resultado se llama óptimo, sino con qué ojos se calculó y si los paquetes estuvieron de acuerdo.

Fuentes