Resumen

  • RFC 6428 intercala CC y un CV proactivo por segundo dentro de una sola sesión BFD.
  • CC y CV emplean puntos de código G-ACh distintos: 0x0022 para BFD CC y 0x0023 para BFD CV proactivo.
  • CV incluye un TLV Source MEP-ID inmutable. El MEP receptor lo combina con la encapsulación, la etiqueta y el discriminador para detectar conectividad incorrecta.
  • RDI solo aparece en el campo de diagnóstico de CC. El campo de diagnóstico de CV debe ignorarse.

La distinción es decisiva: “UP” describe continuidad, no un veredicto universal sobre el servicio. En operación normal, los paquetes CC se intercalan con un paquete CV cada segundo. La pérdida de continuidad se detecta después de la periodicidad de sesión multiplicada por el Detect Multiplier remoto; la conectividad incorrecta se detecta en un segundo. El MEP receptor debe usar el diagnóstico 1 cuando expira el tiempo de detección, el diagnóstico 5 después de una indicación Link Down y el diagnóstico 9 cuando detecta conectividad incorrecta.

El receptor comprueba una encapsulación equivocada; un Source MEP-ID o tipo de MEP inesperado; un discriminador asociado a otra etiqueta; un discriminador esperado que llega por la etiqueta incorrecta; y autenticación inválida cuando está habilitada. Para salir de un defecto de conectividad incorrecta se requieren 3,5 segundos sin recibir un mensaje CV que exhiba ese defecto. Al entrar en el defecto, el MEP receptor afirma signal fail hacia los procesos cliente, pero el bloqueo del tráfico debe depender de la acción consecuente definida por el marco OAM de MPLS-TP, no de la mera llegada de paquetes.

Todos los cambios de estado BFD y los intercambios Poll/Final deben usar paquetes CC. La información de estado y Poll/Final de los paquetes CV debe ignorarse. En operación coordinada, una sesión BFD bidireccional sigue el estado del defecto. En operación independiente se usan dos sesiones; una puede seguir UP mientras recibe RDI. Por ello, la supervisión debe mostrar por separado dirección, campo diagnóstico, identidad de origen y clasificación del defecto.

La autoridad está distribuida. El operador configura el MEG, el MEP-ID, la periodicidad CC, el estado CV deseado, la autenticación y la clave cuando se usa, además de la política de discriminadores. El MEP de origen emite evidencia de identidad, pero no puede declarar por sí solo que la conectividad sea correcta en el receptor. El MEP receptor clasifica el defecto. El marco OAM de RFC 6371 y sus acciones consecuentes limitan el efecto sobre el tráfico cliente. Ningún único valor UP/DOWN sustituye esa separación.

Un sistema solo con CC puede mostrar continuidad recurrente, pero no establecer la identidad del origen previsto. Usar el diagnóstico de CV como RDI inventaría una semántica que la especificación exige ignorar. Un Source MEP-ID equivocado o una asociación de etiqueta incorrecta sigue siendo un defecto aunque lleguen paquetes. Las fuentes no establecen qué proveedores u operadores lo despliegan, la adopción, tasas de falsos positivos, duración del impacto al cliente, costes comerciales ni resultados de restauración. Tampoco prueban que una sesión UP equivalga a la salud de una aplicación.

La página de erratas congelada es solo una instantánea de recuperación, no una afirmación de corrección.

Ruta de decisión del operador

  1. Confirmar el camino MPLS-TP previsto y, cuando se use GAL, verificar que GAL esté en el fondo de la pila con TTL de al menos uno.
  2. Clasificar el punto de código G-ACh: 0x0022 es CC; 0x0023 es CV proactivo. No interpretar el diagnóstico CV como RDI.
  3. Correlacionar la temporización CC, el Detect Multiplier remoto, el código diagnóstico y Poll/Final; calcular el plazo de continuidad con la periodicidad configurada.
  4. En CV, verificar el Source MEP-ID sin cambios y el tipo de MEP esperado, la correspondencia discriminador-etiqueta, la etiqueta recibida, la encapsulación y el resultado de autenticación.
  5. Decidir si se trata de pérdida de continuidad, conectividad incorrecta, defecto remoto o ausencia de defecto; después aplicar la acción consecuente RFC 6371 configurada.
  6. En modo independiente, presentar por separado el estado de sesión y el RDI recibido; nunca reducirlos a “servicio saludable”.

Fuentes

  • RFC 6428 — mecanismo principal de CC, CV y RDI.
  • RFC 5880 — máquina de estados y diagnósticos BFD base.
  • RFC 5586 — transporte GAL y G-ACh.
  • RFC 5921 — marco e identificadores MPLS-TP.
  • RFC 6371 — marco OAM MPLS-TP y acciones consecuentes.
  • RFC 5860 — requisitos OAM de MPLS-TP.
  • RFC 5884 — BFD para LSP MPLS.
  • RFC 5885 — BFD VCCV y compatibilidad solo CC.
  • Erratas de RFC 6428 — instantánea de recuperación congelada únicamente.