Resumen

  • La RFC 10067 empareja dos trayectos de Segment Routing que funcionan en sentidos opuestos. El vínculo permite conocer la ruta de vuelta, pero no convierte los dos trayectos en una sola pieza.
  • La asociación tiene que negociarse y cada extremo conserva su propio identificador. Para declarar que el servicio funciona hay que contrastar los dos sentidos con mediciones reales.

La vuelta no viene incluida en el billete de ida

Un cliente ve una conexión entre dos sedes. El operador ve dos viajes: uno lleva los paquetes y otro trae las respuestas. Es tentador dibujarlos como una sola línea, sobre todo cuando el panel promete «bidireccional». La RFC 10067 da al protocolo PCEP un modo de asociar dos LSP de Segment Routing, cada uno de un solo sentido. Tanto el calculador central como los extremos pueden iniciar la asociación. Ninguno de esos pasos pega los caminos a la fuerza.

Hay un identificador local por cada dirección. El equipo que origina un LSP informa su PLSP-ID; el equipo del otro extremo informa otro. El PCE guarda ambos. La técnica anterior de la RFC 9059 agrupaba LSP de RSVP-TE. Ahora el mismo problema se resuelve para SR y SRv6. El número de asociación es el clip que une dos expedientes. No es una prueba de que los dos trenes hayan circulado.

La utilidad del clip es concreta. El extremo que envía tráfico puede necesitar saber cuál es el camino inverso para usar BFD dirigido, tratado en la RFC 9612, o las mediciones de la RFC 9503. Con la ruta de vuelta en mano, puede preparar esos controles. Aun así, cada sentido se vigila por separado. La RFC 10067 exige que el sistema de gestión correlacione ambos estados para saber si el servicio de ida y vuelta está operativo. Un tablero que solo pregunta por la ida puede felicitarse justo cuando el cliente no recibe respuesta.

El cableado también tiene reglas de admisión

Los pares anuncian primero que admiten el tipo de asociación 8. Si falta el anuncio en cualquiera de los dos, esa asociación no debe usarse en mensajes PCEP. La RFC 8697 describe el armazón general de asociaciones. En un PCE, un LSP SR no puede pertenecer a dos parejas bidireccionales. Si ocurre, el calculador retiene la información de ruta inversa, registra el fallo y dispara una alarma. La libreta de direcciones se niega a dar dos domicilios de vuelta al mismo trayecto.

La ruta inversa llega como objeto explícito en PATH-ATTRIB, marcado para el sentido de retorno. La codificación de varios caminos procede de la RFC 10066. Otro dato puede decir si ambos sentidos comparten recorrido. Si ese dato contradice las propiedades de la ruta inversa, el PCC registra la discrepancia y alarma. Y la vieja marca «Reverse LSP» no se usa aquí: describe otra clase de construcción. La coherencia de las etiquetas evita que un panel mezcle dos modelos de operación.

Al revisar un cambio, pida la negociación, el identificador de la pareja, los dos PLSP-ID, las rutas que cada extremo comunica y las mediciones posteriores. Conserve también la versión anterior. Una incidencia a las tres de la mañana no se resuelve con el dibujo que aprobó la reunión; se resuelve sabiendo qué extremo perdió la vuelta.

La primacía de lo que realmente funciona, defendida por Heng Lu, aporta el criterio editorial. El estándar define cómo nombrar y anunciar la pareja. La red, y quien la opera, tienen que demostrar que la pareja presta el servicio prometido.