Resumen

  • La revisión 03 del borrador del grupo PCE propone negociar S-BFD en OPEN y enviar la solicitud para cada LSP mediante LSPA. El PCE inicia o actualiza; el PCC informa.
  • B=1 exige un discriminador remoto. Para B=0, dos apartados difieren sobre los parámetros que acompañan la orden, y una nota editorial propone que la ausencia de todo el campo también pueda significar retirada.

El plan llega antes que el detector

Un elemento de cálculo de caminos, PCE, puede decidir que un camino necesita una sesión de detección de fallos. El cliente de ese cálculo, PCC, administra el camino en el equipo que ejecutaría S-BFD. El borrador de PCEP sobre parámetros BFD conecta ambos actores mediante mensajes de control. Se gana una forma de pedir una configuración desde el centro. Se abre también una confusión contable: ¿se está registrando la orden enviada, la respuesta del router o un detector que ya funciona?

Antes de la orden hay un trato de admisión. Durante el establecimiento de la sesión PCEP, cada interlocutor puede anunciar en OPEN el LSP-S-BFD-Capability TLV. El bit B a uno anuncia capacidad para intercambiar los nuevos campos. Si falta el anuncio o su B vale cero, el interlocutor no debe enviar campos S-BFD en LSPA hacia ese par. Los tipos de establecimiento de camino anunciados para S-BFD deben pertenecer a la lista que soporta la sesión. Si una lista incluye un tipo ajeno, el borrador pide un error PCErr de tipo 21 y valor 2 y el cierre de la sesión. Sin ningún tipo de camino común, PCEP no puede definir S-BFD para los nuevos LSP entre esos pares.

La frontera merece una lectura exacta. El PCC puede tomar una decisión local sobre S-BFD incluso cuando no puede intercambiar esa configuración por PCEP. Y un OPEN que negocia la capacidad tampoco enciende por sí solo ningún detector. Su función es permitir un vocabulario compartido. En un registro de operaciones conviene distinguir «este par entiende el campo» de «este LSP lo usa». Mezclarlos permite vender compatibilidad como si fuera vigilancia efectiva de cada camino.

La solicitud para un LSP viaja en otro lugar: el LSP-S-BFD TLV dentro de LSPA. El proyecto sitúa su informe desde el PCC en PCRpt y su envío desde el PCE en PCInit o PCUpd. El mismo nombre B reaparece allí con un cometido distinto. En OPEN, B habla de capacidad entre pares; en el LSP, B pide activar o desactivar la función en ese camino. Una pantalla que muestre únicamente «B=1» sin indicar en qué objeto apareció pierde precisamente el alcance de la orden.

Encender exige un número; apagar exige una decisión

El bit B del LSP a uno solicita aplicar S-BFD. En ese caso el borrador exige un subcampo con el discriminador remoto y propone un error si no está presente. También admite un subcampo opcional para el intervalo mínimo de transmisión y un multiplicador entre 1 y 255. Estas piezas hacen más que adornar el mensaje: el receptor necesita saber a qué sesión remota se refiere la solicitud y si el parámetro está dentro de la regla. Un PCE que anote «orden de encendido enviada» sin el discriminador ha conservado una intención, no una configuración válida.

La desactivación tiene más bifurcaciones. El apartado 4.3.2.1 dice que B=0 retira S-BFD en una actualización del PCE o impide aplicarlo en un camino iniciado por ese controlador. El apartado 4.2 dice que el PCC debe ignorar un PCUpd con B=0 si ese LSP no tenía S-BFD aplicado. Para un LSP iniciado por el PCC, el PCE puede ignorar un informe equivalente cuando tampoco había S-BFD. Es razonable no desmontar lo que nunca se instaló. La prueba de una retirada sigue requiriendo un estado anterior y otro posterior; la mera presencia de B=0 no acredita que se haya retirado un detector.

El nudo del texto aparece con los parámetros que acompañan B=0. En 4.2, el hablante puede ignorar el subcampo, y la decisión de ignorar o guardar la configuración queda a la implementación. En 4.3.2.2, el mismo subcampo debe ignorarse. Después llega una nota del editor con una alternativa distinta: si falta por completo el LSP-S-BFD TLV y ya había S-BFD para ese LSP, la ausencia podría indicar retirada. Una orden explícita de apagar y la omisión de un campo son hechos de cable diferentes. El primero habla. El segundo puede ser silencio. Si el estándar pretende que ambos desmonten una configuración, debe decirlo con una sola voz.

La red no espera a que una interfaz de gestión elija el verbo más cómodo. Un controlador que envía B=0 podría marcar la tarea como terminada; un PCC podría haber ignorado el mensaje redundante, retirado una configuración activa o guardado parámetros según su interpretación de la versión. El PCRpt aporta el punto de vista comunicado por el PCC. Su configuración efectiva y la sesión S-BFD aportan lo que el equipo hizo. Pedir estos tres datos no es burocracia; es saber dónde terminó la orden.

El borrador prevé algunas negativas explícitas. Recibir el campo S-BFD de un par que no negoció la capacidad obliga a ignorarlo y enviar un PCErr de tipo 19. Un multiplicador fuera de 1 a 255 pide un error de tipo 23. La sección IANA todavía representa los nuevos valores y tipos TLV como TBD. El tipo de error existente permite clasificar el rechazo, pero nadie puede anunciar como asignado un número que el propio documento deja pendiente.

Hay además una restricción local que no debería convertirse en eslogan universal. La nota de implementación afirma que algunas implementaciones exigen parámetros S-BFD iguales para los LSP de un mismo grupo de asociación. Si difieren el intervalo, el multiplicador o el discriminador remoto, el hablante debería devolver un error de asociación de tipo 26. La palabra «algunas» separa una limitación presente en ciertos equipos de una regla común para todos. Un PCE puede proponer parámetros distintos; un PCC puede rechazarlos por su implementación. El informe permite ver el choque sin declarar defectuoso al sistema entero.

RFC 7880 describe el mecanismo S-BFD. RFC 8231 y RFC 8281 sitúan la conversación en PCEP con estado y los LSP iniciados por el PCE. El borrador también cita la arquitectura de controlador central de RFC 9050. Esos documentos explican por qué alguien querría controlar el detector desde otra máquina. No certifican que esta extensión nueva funcione en un PCC concreto. La revisión 02 y la 03 mantienen las mismas reglas de control en lo sustancial; la actualización cambió fecha, caducidad y numeración, mientras los dos verbos de la desactivación siguen ahí.

La prueba útil para un despliegue cabe en una secuencia legible: capacidad en OPEN, tipos de camino compartidos, mensaje PCInit o PCUpd para el LSP, informe PCRpt, configuración efectiva y estado de la sesión S-BFD. Cada eslabón tiene dueño. El PCE puede probar su orden; el PCC puede declarar su lectura; la máquina muestra qué aplicó; el detector revela si está activo. Una observación posterior de fallo de camino necesita todavía su propia evidencia. El control central consigue coordinación cuando conserva estas diferencias, no cuando las esconde detrás de un interruptor dibujado.

En las fuentes oficiales de este artículo falta una traza de interoperabilidad que empareje B=0 o B=1 con el informe del PCC y el detector efectivo en una implementación identificada. Esa traza decidiría el caso concreto. Para el texto común queda otra tarea, más modesta y más urgente: acordar si los parámetros se pueden ignorar o se deben ignorar, y si no enviar el campo equivale a pedir una retirada.

Fuentes