Resumen
draft-ietf-mpls-frr-ext-00permite que el ingreso de un LSP RSVP-TE solicite objetivos de optimización y límites métricos estrictos a los puntos que calculan rutas de respaldo. Cada PLR activaFRR_EXT protectioncuando satisface la petición; si no puede, puede volver a su política local sin activar la marca.- La ausencia de la marca no distingue una delegación prevista, un nodo que desconoce la extensión o un cálculo capaz que no encontró una ruta admisible. Hace falta un registro de procedencia por PLR que una petición, capacidad, política, datos métricos, contexto de cálculo y vigencia posterior.
La pantalla muestra cero; la red tomó una decisión
Supongamos que un LSP protegido tiene cuatro puntos de reparación local. El ingreso pide que sus respaldos minimicen el retardo medio, que el retardo total no rebase un valor y que ningún enlace supere una variación determinada. Tres puntos devuelven la marca nueva. El cuarto deja el bit sin activar.
El cero invita a una explicación demasiado rápida. No significa necesariamente que falte una ruta de respaldo. El equipo puede ser anterior a la extensión y haber ignorado el objeto de forma compatible. Puede comprenderlo, no hallar un camino que cumpla todos los límites y aplicar su política local. O quizá la configuración central no pidió objetivos extendidos y delegó desde el principio.
En los tres escenarios la política local puede producir una protección válida bajo sus propias reglas. Lo que falta es la posibilidad de saber qué escenario ocurrió. Si la consola traduce todo a «fallo de FRR», elimina la autonomía que el protocolo preserva. Si traduce todo a «protegido», elimina el significado de la petición del ingreso.
La respuesta adecuada no es inflar un bit hasta convertirlo en informe. Es conservar alrededor de él el registro operativo que el protocolo no pretende transportar.
Un borrador recién adoptado como trabajo del grupo
La revisión 00 de Signaling Optimization Objective and Bounded Metrics for MPLS Fast Reroute Backup LSP Tunnels está fechada el 23 de agosto de 2026. El Datatracker la presenta como borrador activo del grupo MPLS, con estado IESG I-D Exists. El encabezado indica Standards Track y caducidad el 24 de febrero de 2027. No es un RFC, no ha sido aprobado por el IESG y no demuestra ninguna implantación.
El texto procede de draft-deshmukh-mpls-frr-ext-02. Tras la llamada de adopción, el presidente del grupo registró el 18 de agosto que el borrador había sido adoptado y pidió republicarlo como draft-ietf-mpls-frr-ext. El anuncio del día 23 confirma que la revisión 00 es un elemento de trabajo del grupo. Ese cambio institucional señala responsabilidad editorial del grupo, no una decisión definitiva sobre el estándar.
La base técnica es el RFC 4090. Allí se define la reparación rápida local para túneles LSP RSVP-TE y el objeto FAST_REROUTE, con prioridades, afinidades, límite de saltos y ancho de banda. El borrador nuevo añade un objeto compañero extensible, FAST_REROUTE_EXT, para objetivos de optimización y métricas acotadas.
El ingreso puede ordenar que el respaldo herede los objetivos y límites del LSP protegido o especificar otros. Si no hay configuración explícita, la política del PLR decide. El ingreso expresa una intención común, pero el cálculo sigue ocurriendo en varios lugares con autoridad operativa propia.
Optimizar no es lo mismo que limitar
Los TLV de optimización permiten elegir métrica IGP, métrica TE, ancho de banda no reservado y retardo mínimo, medio o máximo. Para los costes y retardos se busca el valor menor; para el ancho de banda no reservado, el mayor. Pueden enviarse varios objetivos distintos, cada uno con un peso de normalización.
Un límite cumple otra función. El PLR debe tratarlo como restricción dura: los candidatos que no lo cumplan quedan fuera antes de elegir el óptimo. El límite puede referirse al camino completo o a cada enlace. La variación del retardo solo se define a escala de enlace. Una misma métrica puede llevar, por tanto, un límite acumulado y otro por enlace.
El orden también importa. Si aparecen varios límites del mismo tipo y alcance, se procesa el primero y se ignoran los siguientes. La sintaxis evita una negociación ambigua dentro del mensaje, pero obliga al sistema de autoría a conocer exactamente qué bytes se transmitieron.
El borrador no prescribe por qué escoger una métrica, cómo fijar una tolerancia comercial o qué algoritmo debe normalizar unidades distintas. Declara fuera de alcance los criterios para seleccionar objetivos y límites. Esa separación deja espacio a políticas locales legítimas; también hace insuficiente cualquier auditoría que guarde solo el resultado binario.
Cuatro salidas, cuatro responsabilidades
Cuando no existe petición extendida, la política local gobierna por diseño. No hay incumplimiento: el ingreso eligió delegar.
Cuando el PLR no entiende el objeto, debe ignorarlo y reenviarlo sin modificaciones. Esa regla mantiene la compatibilidad en una red con versiones mezcladas. La explicación depende entonces del inventario de capacidades: ¿qué software y qué función estaban activos en ese nodo cuando pasó el Path?
Cuando el PLR entiende la petición pero no puede satisfacer los límites, puede volver a su política local y no debe activar FRR_EXT protection en el subobjeto RRO de la respuesta Resv. Aquí sí existe una petición conocida que cedió ante una alternativa. Hace falta saber qué límite falló, qué camino alternativo eligió la política local y quién autorizó aceptar esa diferencia.
Por último, un PLR capaz que recibe FAST_REROUTE_EXT sin el objeto básico FAST_REROUTE debe rechazar el Path con un error de control de política. Es una entrada mal formada, no una ruta de compatibilidad.
Una cola operativa que no distinga estos resultados envía la reparación al equipo equivocado. La delegación pide revisión de diseño; la incompatibilidad, decisión de actualización; la imposibilidad de cumplir, revisión de topología, métricas o límites; y la estructura inválida, corrección del emisor.
La marca positiva también tiene frontera
Si un PLR satisface el objetivo y las métricas acotadas, debe activar el indicador en su subobjeto RRO. El ingreso puede observar el resultado de cada punto de reparación. Así evita confundir el éxito general de la reserva con el cumplimiento uniforme de la petición.
Sin embargo, la marca solo atestigua lo que el PLR afirma haber calculado en aquel intercambio. No nombra la instantánea de la base TE, la edad de las mediciones, la versión del algoritmo ni los candidatos descartados. Tampoco demuestra que el respaldo continúe dentro de límites después de cambios de carga, reservas o topología.
Y no acredita una conmutación real. El RFC 4090 prepara rutas para reparar localmente una avería con rapidez. Una respuesta satisfactoria no prueba que el detector vaya a reaccionar, que el estado de reenvío siga instalado, que las rutas primaria y secundaria carezcan de riesgos compartidos, ni que el servicio de extremo a extremo cumpla su compromiso.
La autenticación criptográfica de RSVP puede proteger la integridad del mensaje. No protege la actualidad del dato que alimentó el cálculo. Tampoco explica por qué una regla local fue considerada más apropiada. Integridad, calidad de la medida y autoridad de la política son capas diferentes.
Una métrica no llega sola
Los RFC 7471 y 7810 definen extensiones de ingeniería de tráfico para OSPF e IS-IS y dan estructura a atributos de retardo y rendimiento. Un PLR puede utilizar una base TE alimentada por esos mecanismos, por configuración u otra fuente. El borrador FRR no elige una fuente universal.
Dos valores numéricos idénticos pueden provenir de observaciones con edades muy distintas. El ancho de banda no reservado depende de clase, reservas y ritmo de actualización. Un promedio de retardo puede ocultar una cola transitoria que un máximo sí mostraría. Y al combinar métricas heterogéneas, la normalización decide cuánto pesa cada unidad. El campo de peso no conserva el procedimiento completo.
Por eso la pregunta posterior no debe ser solo «¿se activó la marca?». Debe poder formularse así: «¿qué conjunto de datos y qué política hicieron verdadera o falsa esa marca en ese PLR y en ese momento?».
Registro de procedencia de restricciones
La propuesta editorial es un registro por cada pareja LSP protegido–PLR. No amplía el protocolo ni impone contenido nuevo a IETF. Organiza la evidencia que un operador necesita conservar fuera de RSVP.
El primer bloque identifica sesión, ingreso, punto de reparación, recurso protegido y punto de fusión. Guarda huellas exactas de FAST_REROUTE y FAST_REROUTE_EXT, con tipos de métrica, pesos, valores, límites y alcance. Registra si el PLR conocía la extensión, si la analizó, si encontró el objeto compañero y qué RRO devolvió.
Cuando falta la marca, el registro consigna una causa observada sin deducirla del bit: delegación sin petición, extensión no soportada, restricción insatisfecha u otro estado probado. Añade la política local y su versión, el responsable de la excepción y el horizonte durante el que se acepta.
El segundo bloque conserva los insumos: fuente y unidad de cada métrica, hora de observación, época de topología o base TE, método de normalización y versión del cálculo. Identifica el respaldo resultante y, cuando sea relevante, la evidencia de grupos de riesgo compartido. «Camino distinto» no se convierte automáticamente en «destino físico independiente».
El tercero enlaza sin mezclar las pruebas futuras. Una actualización de señalización renueva la afirmación de configuración. Un simulacro muestra si la conmutación ocurrió. Un incidente aporta datos sobre el tráfico. Ninguno debe sustituir retroactivamente la decisión de cálculo.
El registro puede mantenerse dentro del dominio operativo y con acceso restringido. Su finalidad no es publicar topología, sino conservar la explicación ante las personas autorizadas a gobernarla.
Autonomía local con memoria
FRR_EXT protection funciona como especificación mínima compartida: ofrece una manera interoperable de expresar y confirmar restricciones sin obligar a todos los PLR a usar un único algoritmo. Esa modestia es una virtud.
La institución debe completar el mínimo con memoria local. Una marca presente dice que la petición se satisfizo entonces. Una marca ausente abre varias posibilidades. La política puede seguir siendo local siempre que su identidad, insumos, vigencia y vía de revisión no desaparezcan.
El dilema no es control central frente a libertad técnica. Es libertad opaca frente a libertad responsable. La segunda conserva la capacidad de reparar durante una transición y, al mismo tiempo, permite explicar quién decidió el respaldo que finalmente quedó preparado.
Fuentes
- IETF Datatracker: borrador FRR vigente
- IETF Datatracker: historial del documento
- Archivo IETF: draft-ietf-mpls-frr-ext-00
- IETF Datatracker: borrador anterior
- Archivo IETF: revisión anterior 02
- IETF Author Tools: comparación del texto antes y después de la adopción
- Lista MPLS: anuncio del borrador de grupo
- Presidencia MPLS: adopción y republicación
- Grupo de trabajo MPLS
- RFC 4090: Fast Reroute para RSVP-TE
- RFC 3209: RSVP-TE
- RFC 2205: RSVP
- RFC 7471: extensiones métricas TE para OSPF
- RFC 7810: extensiones métricas TE para IS-IS
- RFC 2747: autenticación criptográfica de RSVP
- RFC 5920: marco de seguridad para MPLS y GMPLS
- IANA: parámetros RSVP
- Heng Lu: The Policy Mirror
- Heng Lu: Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
