Resumen

  • Highest-Preference y Lowest-Preference ordenan candidatos; no convierten la preferencia en una prueba de disponibilidad operativa.
  • La lista elegible, el valor anunciado, el ganador, la instalación de forwarding, la convergencia y el resultado del cliente necesitan recibos separados.
  • Don't Preempt reduce la agitación tras una recuperación, a cambio de permitir que el DF vigente ya no coincida con el favorito administrativo.

La recuperación revela el verdadero contrato

El RFC 7432 asigna al DF la salida de tráfico BUM hacia un segmento multihomed en All-Active, y BUM más unicast en Single-Active. El RFC 8584 organiza la elección en descubrimiento, lista de candidatos y cálculo después de DF_WAIT. El ganador recibe una responsabilidad de forwarding; no recibe una certificación automática de que ya la ejecuta.

El RFC 9785 incorpora un orden administrativo explícito. Alg 2 elige primero el valor numérico más alto; Alg 3, el más bajo. Preference ocupa dos octetos, admite 0–65535 y usa 32767 por defecto. IANA registra estos algoritmos y el bit 0 D de Don't Preempt en la tabla de comunidades extendidas BGP.

La frase decisiva del estándar dice que el operador controla el orden de los PE candidatos suponiendo que todos están operativamente preparados. Por tanto, readiness precede a Preference. Un número mayor o menor no sondea el circuito, no confirma la tabla de datos y no observa al cliente.

La candidatura no se deduce del deseo

Cuando AC-DF acompaña a Highest-Preference o Lowest-Preference, un PE no se considera candidato hasta que se reciben sus rutas Ethernet A-D per ES y per EVI. Ese requisito reduce la posibilidad de elegir una Attachment Circuit que no está disponible desde el punto de vista de señalización. Sigue siendo una frontera limitada: recibir rutas no equivale a instalar la réplica BUM o la salida unicast.

También debe coincidir el algoritmo. Si los participantes mezclan Highest y Lowest, vuelven al cálculo predeterminado del RFC 7432. El estado que importa no es sólo “PE2 ganó”, sino “PE2 ganó entre este conjunto, con estas rutas, estos valores y este algoritmo compartido”.

Las políticas locales pueden cambiar Preference por ancho de banda disponible, puerto caído u otros eventos, pero RFC 9785 deja su definición fuera de alcance. El protocolo transporta el resultado de una decisión local; no valida la calidad del detector ni la racionalidad de la política.

Don't Preempt convierte la divergencia en estado

Imaginemos que PE3, el favorito, falla. PE2 asume como DF. Al regresar PE3, la elección revertiva lo devolvería al puesto y causaría otra mutación de forwarding. Don't Preempt ofrece un comportamiento no revertivo para mantener a PE2.

PE3 espera el boot-timer o hold-timer, recibe las rutas del segmento y elige un PE de referencia. Si su Preference administrativa desplazaría al vigente, puede anunciar una Preference operativa in-use igual a la del referente, con DP=0. PE2 conserva DP=1, y el desempate mantiene al titular.

Así aparecen dos verdades válidas: la configuración continúa diciendo que PE3 es preferible; la señalización operativa dice que, por ahora, no debe preemptar. Una herramienta que sólo compara BGP con la configuración marcará una falsa deriva. Una herramienta que sólo conserva BGP perderá la intención a la que se desea volver.

La no reversión reduce una transición, pero también conserva una elección histórica. Si las razones para preferir PE3 eran capacidad, ubicación o margen operativo, mantener PE2 puede acumular riesgo. Por eso el estado necesita condición de salida: fallo o retirada del referente, cambio explícito, nueva inconsistencia o decisión de volver al orden administrativo.

Coherencia y privilegio de configuración

Para rangos de Ethernet Tags se permite un override local que distribuye los DF. Debe ser idéntico en todos los PE. El RFC advierte de pérdidas o duplicación cuando no lo es. Del mismo modo, la configuración de Don't Preempt debería ser coherente, pero el estándar no la impone y no garantiza el resultado no revertivo si difiere.

La sección de seguridad expone la consecuencia organizativa. Quien controla Preference puede influir por qué PE pasa el tráfico. Quien introduce un algoritmo conflictivo puede forzar el fallback y debilitar Don't Preempt. Autorización y trazabilidad de cambios forman parte de la evidencia de servicio.

El RFC 9784 permite aplicar estos algoritmos a virtual Ethernet Segments. Sus mecanismos de fallo EVC/ENNI, vESI y withdrawal agrupado pertenecen a otro análisis. Tampoco tratamos redundancia de fuentes multicast: este texto se limita a la preferencia del DF y su cadena probatoria.

La ficha RFC Editor, el Datatracker y la búsqueda de errata, sin coincidencias al comprobarla, documentan el estándar. No demuestran despliegue ni resultados de producción.