Resumen

  • BGP origina, propaga y selecciona anuncios SR Policy; SRPM consume sus datos, valida la semántica y compite esas candidatas con las recibidas por otros mecanismos.
  • Distinguisher permite que varias candidatas para un mismo Color–Endpoint permanezcan separadas, pero no expresa significado, autorización ni superioridad.
  • Retirada BGP, cambio de candidata activa y cambio de FIB son hechos distintos; cada uno necesita su propio recibo y su propia causa.

La retirada que no retiró el camino

El episodio inicial es un caso de prueba, no un incidente atribuido a una red concreta. Sirve porque comienza por el final: una retirada BGP puede completarse correctamente sin producir el efecto que el operador imaginaba. BGP elimina una contribución. El módulo de SR Policy vuelve a mirar su conjunto de candidatas. Si todavía existe una alternativa válida, el servicio puede seguir usando el mismo trayecto o uno equivalente.

Esa conducta no contradice RFC 9830. El documento asigna a BGP la distribución de Candidate Paths y crea un SAFI específico. Una vez que BGP conserva la ruta que corresponde a un NLRI, entrega la información a SRPM. RFC 9256 sitúa en SRPM la selección de la candidata activa, la asociación de un Binding SID y la instalación en el plano de reenvío.

Hay, por tanto, dos urnas. La primera contiene rutas BGP que compiten por un NLRI. La segunda contiene candidatas SR Policy que pueden proceder de BGP, PCEP, NETCONF, CLI o configuración local. Ganar la primera permite llegar a la segunda; no garantiza ganar allí.

Esta separación evita que un protocolo de transporte se convierta en autoridad accidental. BGP puede ofrecer alcance, política de importación y robustez de sesión. El headend conserva el derecho y la responsabilidad de decidir qué camino puede usar su propio plano de datos.

Tres números que no deben fundirse

La identidad del NLRI reúne Distinguisher, Color y Endpoint. Color y Endpoint definen la SR Policy. Distinguisher separa anuncios que, de otro modo, entrarían en la misma comparación BGP. Un originador puede usar valores diferentes para candidatas distintas o para headends distintos.

El estándar advierte que Distinguisher carece de valor semántico. No representa coste, prioridad, versión ni calidad. Tampoco es un identificador universal de camino. Si un sistema concluye que 9 debe prevalecer sobre 8, ha inventado una regla que el campo no contiene.

Color tampoco es por sí solo una política completa. Se combina con Endpoint y puede usarse para dirigir rutas de servicio hacia una policy coincidente. Endpoint puede ser una dirección específica, anycast o nula según el modo. Ninguno de esos valores demuestra que una candidata llegó a ser activa ni que un paquete la recorrió.

La procedencia añade otra dimensión. RFC 9830 conserva datos del originador mediante Route Origin Community, ORIGINATOR_ID o Router-ID del peer, en ese orden. Esa reconstrucción permite diferenciar fuentes de protocolo después de la reflexión de rutas. No autentica a una persona, no prueba un poder corporativo y no sustituye el registro de cambio que autorizó el objetivo.

Una evidencia defendible conserva NLRI, identidad de policy, identidad de candidata, fuente de protocolo y autoridad humana como capas separadas. El nombre visible de la policy puede ayudar a navegar, pero es simbólico, puede truncarse y no debe servir como clave de unión.

BGP decide si la carta se puede entregar

La responsabilidad estructural de BGP es real. El anuncio debe usar un AFI admitido y SAFI 73, la longitud correcta y un Tunnel Encapsulation Attribute con tipo SR Policy 15. Ciertas duplicaciones o combinaciones inválidas hacen que la actualización no sea utilizable. El tratamiento treat-as-withdraw contiene el daño en la ruta afectada.

Pero BGP no debe inspeccionar el significado operativo de cada campo SR. Puede comprobar que existe una estructura bien formada sin saber si el segmento es válido para ese headend, si un SID se puede verificar o si el Binding SID solicitado entra en conflicto con el estado local. RFC 9830 entrega esa tarea a SRPM.

Así aparecen estados que una consola pobre suele confundir. Una actualización puede ser rechazada por sintaxis, ignorar un campo no aplicable, no importarse por Route Target, llegar a SRPM y fallar allí, resultar elegible pero perder por Preference, o ganar y no alcanzar el hardware. Cada estado responde a una pregunta diferente.

Las reglas sobre campos desconocidos protegen la evolución del protocolo. Bits reservados se ignoran; ciertos sub-TLV no aplicables pueden quitarse durante la propagación; en varios campos de instancia única se usa la primera aparición y se descartan las posteriores. Esa tolerancia mantiene interoperabilidad, pero exige registrar qué recibió cada salto. “El controlador envió X” no prueba que SRPM evaluara exactamente X.

Las palabras conocidas esconden comparadores distintos

Preference parece una señal BGP, pero no participa en el best path de BGP. SRPM la usa para ordenar candidatas. Priority tampoco selecciona el camino de una route; sirve para ordenar el recálculo de policies tras cambios topológicos. El Weight de una Segment List reparte tráfico entre listas válidas dentro de una candidata seleccionada.

Confundir esas escalas crea diagnósticos imposibles. Un cambio de Preference puede alterar la candidata activa sin tocar la ruta BGP. Un cambio de Priority puede modificar el orden temporal del recálculo sin cambiar la preferencia de ninguna candidata. Un cambio de Weight puede variar el reparto de tráfico sin mover la identidad de la policy.

El Binding SID es otro punto de decisión. El anuncio puede incluir información y flags sobre una BSID, pero el headend debe verificarla o asignarla según su plano de datos y política local. Un comportamiento SRv6 opaco puede dejar explícitamente la elección al receptor. Un SID anunciado no es todavía un SID instalado.

Incluso TC, TTL y Explicit NULL conservan discreción local. El originador puede recomendar; el receptor puede sustituir según configuración. Cuando ENLP falta, la decisión vuelve al headend. El formato común permite comunicar una propuesta sin eliminar la autoridad operacional de quien soportará sus consecuencias.

Route Target define audiencia, no obediencia

Una sesión directa entre controlador y headend mantiene simple la ruta de distribución. Cuando la escala exige reflectores o varios AS dentro de un dominio SR de confianza, los Route Targets indican qué headends son destinatarios previstos.

Importar el Route Target sólo abre la puerta. La candidata todavía debe pasar la validación semántica y el concurso local. Por eso “recibida por el headend”, “importada” y “activa” no son sinónimos. Una automatización que se detiene en el Adj-RIB-In nunca observa las decisiones que importan para el reenvío.

La amplitud del Route Target tiene además un coste de confidencialidad. Una SR Policy puede revelar endpoints, SIDs y decisiones de ingeniería de tráfico sensibles. Una sesión BGP segura no autoriza automáticamente a enviar ese contenido a todos los peers ni a todas las familias. El operador debe definir el dominio, los roles, el SAFI, los Route Targets y la política de exportación autorizados.

La reflexión también puede ocultar el origen inmediato. El vecino que entrega la actualización quizá no sea el controlador que la creó. Registrar sólo la última sesión atribuye al mensajero una intención que no posee. La cadena debe retener originador lógico, peer inmediato y aprobador de negocio.

Del control al paquete hay más de un salto

La afirmación “la policy está en BGP” debe ampliarse antes de respaldar una decisión. Primero está el byte recibido y su firma de captura. Después vienen validación estructural, best path del NLRI e importación por audiencia. Luego SRPM emite un resultado semántico, reúne el conjunto de candidatas, selecciona una activa y resuelve Binding SID, listas y pesos.

Aun entonces falta comprobar el plano de datos. El RIB puede mostrar una intención que todavía no llegó al FIB. Una programación parcial puede dejar miembros antiguos. El hardware puede rechazar recursos. Los paquetes pueden tomar una rama ECMP distinta de la observada en una prueba. El resultado del usuario queda todavía más lejos.

Cada transición necesita un identificador de decisión, hora, dispositivo, versión y motivo. Sin esa cadena, un sistema de gestión sólo puede contar mensajes. No puede explicar por qué el tráfico cambió, por qué no cambió o quién conservó la autoridad en cada punto.

La coordinación mínima conserva opciones

El valor de RFC 9830 está precisamente en no apropiarse de toda la policy. Estandariza SAFI, NLRI, Tunnel Encapsulation Attribute, sub-TLV, propagación y errores. Eso basta para que un controlador y un headend intercambien candidatas de forma interoperable.

El principio de especificación inicial mínima de Heng Lu da sentido a esta arquitectura. Coordinar el idioma común no requiere centralizar la decisión final. La selección local puede incorporar topología, capacidad, seguridad y obligaciones que el originador remoto no conoce. La primacía del código en ejecución exige verificar SRPM, FIB y tráfico. Las capas de realidad impiden que un símbolo administrativo suplante al comportamiento.

Una prueba útil empieza con dos anuncios BGP bajo el mismo Color–Endpoint y Distinguishers diferentes. Después añade una candidata PCEP con mayor Preference. Se observan ambos best paths, el conjunto SRPM, la candidata activa, la BSID y el FIB. Por último se retira cada fuente por separado. El resultado no es una sola luz verde o roja, sino una secuencia de decisiones explicable y reversible.

Fuentes