Resumen

  • La extensión aprobada por el IESG añade a un camino candidato de BGP SR Policy el NRP ID de la partición de recursos con la que se lo asocia.
  • El número expresa esa asociación dentro de un dominio, pero no asigna recursos, no valida el selector local ni demuestra capacidad, aislamiento o calidad de servicio.

El campo llega; la reserva no

Supongamos que un headend recibe dos caminos candidatos para la misma combinación de color y endpoint. Uno incluye NRP ID 17; el otro, NRP ID 29. Desde el plano de control, esa diferencia orienta cada camino hacia una Network Resource Partition distinta.

Nada en esos cuatro octetos describe la disponibilidad de los enlaces, las colas provisionadas o el aislamiento observado. Tampoco confirma que el headend eligiera ese camino, instalara su lista de segmentos, tradujera el identificador al selector correcto y marcara el tráfico como esperaba el operador.

No se trata de un incidente real, sino de un caso de control. Sirve para separar la afirmación que viaja por BGP de las acciones que deben materializarla.

La separación cobró relevancia el 25 de agosto de 2026. A las 18:03 UTC, la IETF anunció la aprobación por el IESG de la revisión 13 de “BGP SR Policy Extensions for Network Resource Partition” como Proposed Standard.

La fecha de aprobación no cierra la publicación

El documento fue elaborado por el grupo Inter-Domain Routing. Según el anuncio, hubo discusión sobre las dependencias con trabajos de TEAS y SPRING, seguida de consenso aproximado para avanzar y resolver las referencias normativas en la cola del RFC Editor.

En el corte de evidencia del 28 de agosto, Datatracker aún lo mostraba como Internet-Draft activo. El RFC Editor lo mantenía bloqueado por una referencia no recibida. La revisión de IANA indicaba un cambio de versión y una acción todavía en curso. Por eso, la aprobación del IESG no autoriza a inventar un número RFC definitivo ni a dar por terminada la actualización de registros.

El anuncio informa dos implementaciones. El informe público de IDR menciona Huawei VRP y H3C Comware, pero conserva lenguaje de una versión anterior y filas de funciones con la marca TBD. Es evidencia de que existe código y trabajo de integración. No es una prueba completa de conformidad con la revisión 13, interoperabilidad en producción ni adopción amplia.

Una NRP es un conjunto operativo, no una etiqueta

El RFC 9543 define la Network Resource Partition como un subconjunto de recursos del underlay y las políticas asociadas capaces de apoyar uno o más servicios de network slice. El RFC 9732 explica cómo una construcción de conectividad puede mapearse a una NRP en el marco de VPN mejoradas.

Esa definición reúne objetos físicos y decisiones operativas. Alguien debe provisionar capacidad y tratamiento de reenvío. Una política debe determinar su uso. El servicio debe dirigirse hacia el camino. Y las mediciones deben mostrar lo que ocurrió.

El NRP ID de la revisión 13 es un nombre de 32 bits, único dentro de un dominio NRP. La configuración e implementación del dominio enlazan ese nombre del plano de control con un NRP Selector ID del plano de datos. No es un inventario de recursos ni una garantía global.

Además, el documento cubre un diseño concreto: un selector dedicado, común a todo el dominio, que aparece en el plano de datos. Otros mecanismos para escoger una NRP quedan fuera de su alcance y pueden no necesitar esta señal en SR Policy.

Una regla de seis octetos reduce la ambigüedad

La extensión define un sub-TLV NRP ID dentro del BGP Tunnel Encapsulation Attribute cuando el tipo de túnel es SR Policy. La revisión 13 usa el tipo 123 y exige una longitud de seis octetos: uno para flags, uno reservado y cuatro para el identificador.

Los flags y bits reservados se transmiten en cero y se ignoran al recibirlos. El identificador cero está reservado: el emisor no debe usarlo y el receptor ignora un sub-TLV que lo contenga. El elemento es opcional y solo puede aparecer una vez en cada camino candidato.

Una longitud distinta de seis o la presencia de duplicados vuelve malformada la información NRP asociada al NLRI. Entonces se aplica el tratamiento treat-as-withdraw del RFC 7606. La medida impide que una codificación estructuralmente ambigua entre en el estado de rutas.

Pero su alcance acaba ahí. Un número no nulo puede estar bien formado y, aun así, apuntar al selector equivocado. La validez sintáctica no inspecciona las colas o enlaces detrás del mapeo.

La aceptación BGP abre otra secuencia

El originador debe incluir el identificador cuando el camino candidato se instancia dentro de una NRP que usa el diseño de selector dedicado. El receptor aplica primero las reglas de validez y usabilidad del RFC 9830. El algoritmo ordinario de mejor ruta BGP no cambia.

Solo las mejores rutas seleccionadas para la SAFI de SR Policy pasan después al SR Policy Module. La entrega es un límite de autoridad: una ruta aceptada puede no quedar activa; un camino recibido por SRPM puede no instalarse; una instalación puede utilizar un selector incorrecto si el mapeo local quedó obsoleto.

Para probar el resultado hay que unir la selección de candidato, la lista de segmentos instalada, la versión del mapeo NRP ID-selector, el marcado del paquete, la decisión de steering, los recursos del underlay y las métricas del servicio. El éxito del anuncio solo demuestra una asociación emitida y aceptada bajo un estado concreto de sesión y validación.

El cambio de candidato puede cambiar la partición

La revisión 13 permite que distintos caminos candidatos de una SR Policy se asocien con NRPs diferentes. Lo considera válido, aunque no recomendado, y señala que en los casos normales todos deberían mantener la misma asociación.

La advertencia importa durante un fallo. Un cambio de preferencia puede activar otro candidato sin alterar la clave de política que ve el servicio. Si el nuevo candidato selecciona otra partición, el failover también puede cambiar capacidad, aislamiento, coste y exposición de información sensible.

Ni siquiera la coincidencia numérica resuelve todo. El mismo entero tiene que mapearse igual en todos los headends, producir el selector correcto y encontrar recursos realmente provisionados. La coordinación del número sin coordinación del significado crea una apariencia de continuidad.

El coste de escala aparece en controladores y headends

El borrador reconoce que más NRPs pueden implicar más SR Policies y más caminos candidatos. La información entre el controlador y los headends puede crecer proporcionalmente.

No se modifica el anuncio de SR Policy ni la selección de mejor camino BGP, y el estado añadido se instala en los headends correspondientes, no en todos los nodos de tránsito. Esa delimitación evita atribuir al mecanismo un coste que no tiene, pero no elimina el trabajo de creación, validación, reconciliación e instalación.

Por eso, los contadores deben distinguir rutas anunciadas, válidas, mejores, candidatas en SRPM, activas e instaladas. Agregarlas como una sola cifra permite que una presión de estado en el headend quede oculta detrás de un controlador verde.

Una sesión confiable también puede transportar un error

La seguridad heredada de BGP y SR Policy protege el canal y las fuentes autorizadas. La especificación advierte, sin embargo, que una asociación NRP incorrecta puede perjudicar el aislamiento del tráfico y las garantías de recursos.

Un controlador confiable puede emitir el ID erróneo. Un headend confiable puede asociar el ID correcto al selector equivocado. Incluso un selector correcto puede conducir a recursos cuya configuración ya cambió. La autenticación no prueba la semántica de ninguna de esas transiciones.

El identificador también puede revelar intención sensible: una partición destinada a tráfico crítico o comercialmente relevante. Los operadores deben limitar la distribución a routers y aplicaciones de control de confianza, y comprobar la corrección de la asociación en ambos extremos.

La evidencia mínima por episodio incluye identidad y versión del controlador, peer y sesión BGP, clave NLRI, origen y preferencia del candidato, bytes del sub-TLV, decisiones de validación y mejor ruta, recepción y selección de SRPM, lista de segmentos, mapeo y versión local, configuración de recursos, steering del servicio, selector visto en paquetes, medidas de cola, pérdida, latencia y aislamiento, retiros, alternativas y marcas de tiempo comunes.

Fuentes