Resumen

  • La revisión 13 propone que el next hop se resuelva en la base de reenvío del plano de datos elegido por política y permite una comprobación OAM de ese mismo plano.
  • En una red con VRF, túneles e instancias múltiples, destino y endpoint pueden resolverse en tablas distintas; “una base de reenvío” no identifica cuál manda.
  • La versión de política, la tabla, la cadena recursiva y el motivo de exclusión deben conservarse junto con la decisión, o el operador no podrá explicarla ni revertirla.

El prefijo a.b.c.d pertenecía a la VRF del cliente. Su next hop BGP apuntaba a un PE remoto. El endpoint que permitía llegar a ese PE se resolvía en la tabla de infraestructura, y la etiqueta usada para el transporte vivía en el estado MPLS. Al consultar la VRF, el prefijo parecía válido. Al consultar la tabla equivocada para el túnel, el endpoint parecía ausente. El software excluyó el camino.

El registro decía: “next hop no resoluble”. No decía qué tabla había formulado el veredicto.

Ese vacío está en el centro de draft-ietf-idr-bgp-bestpath-selection-criteria-13. La revisión, fechada el 14 de septiembre de 2026, es un Internet-Draft activo del grupo IDR y busca el estado Proposed Standard. Propone actualizar RFC 4271 si se aprueba, pero todavía no es un RFC. Las cuatro revisiones tempranas disponibles coinciden en que el problema es real y discrepan sobre la madurez del texto: Routing lo considera no preparado; Operations y Security encuentran problemas; BGP lo ve bien encaminado, aunque aún no listo.

RFC 4271 exige que un camino sea resoluble antes de competir en la decisión de mejor ruta. El borrador observa que la ruta IP al next hop puede sobrevivir mientras el plano que transportará los paquetes falla. En MPLS VPN, por ejemplo, PE1 puede seguir alcanzando la dirección de PE2 a nivel IP aunque falte una entrada MPLS, exista un defecto de binding o el LSP no reenvíe. PE1 atrae tráfico porque BGP conserva el camino, pero el núcleo lo descarta.

La corrección propuesta tiene dos partes. La primera dice que la comprobación de reachability debería usar una forwarding database del protocolo de plano de datos particular. La política elige IP, MPLS u otro contexto. La segunda permite comprobar la disponibilidad funcional del camino mediante OAM del mismo plano.

La frase decisiva es “según lo determine la política”. El documento deja esa política fuera de alcance y contempla que actúe por vecino, por SAFI o por ambos. De este modo, la norma apunta al lugar correcto —el plano que efectivamente llevará el tráfico— sin fijar cómo identificarlo cuando hay varias tablas posibles.

La recursión también tiene procedencia

Una ruta VPN no se resuelve en un solo salto conceptual. El prefijo del cliente selecciona un next hop. Ese next hop puede requerir un túnel. El túnel puede obtener atributos por BGP, etiquetas por otro protocolo y un camino subyacente en la tabla global. Cada operación se realiza en un namespace distinto y puede cambiar en momentos diferentes.

La revisión de Operations recupera una pregunta ya planteada a la versión anterior: ¿qué tabla se consulta cuando la dirección de destino y la del endpoint del túnel se resuelven en tablas distintas? La revisión 13 solo dice “una forwarding database de un protocolo particular”. No distingue VRF, instancia, tabla de labels, resolución del túnel ni recursión final.

El problema práctico aparece durante la comparación. Dos routers reciben el mismo NLRI y los mismos atributos. Uno asocia el vecino con una política MPLS y consulta el endpoint en la tabla de transporte. El otro aplica una regla por SAFI y toma un contexto diferente. El primero conserva el candidato; el segundo lo elimina. La divergencia no nace de BGP en la red, sino de una elección local que el mensaje no revela.

Por eso el recibo mínimo de elegibilidad debe incluir: identificador del camino; peer; AFI/SAFI; RD y VRF cuando correspondan; endpoint recursivo; plano elegido; tabla e instancia exactas; versión de política; generación del estado de reenvío; resultado; edad; y razón final. Esos campos no forman una exigencia de la revisión 13. Son la información necesaria para que una organización pueda explicar la decisión que el borrador habilita.

El contexto técnico refuerza la necesidad. El texto cita RFC 5512, ya reemplazado por RFC 9012, que también interviene en la resolubilidad de túneles BGP. Los reviewers mencionan SR Policy y mecanismos de resolución posteriores. Si varios sistemas pueden seleccionar el transporte, la precedencia entre ellos no puede quedar enterrada en un default de fabricante.

OAM agrega una observación, no elimina la ambigüedad

El segundo criterio permite una prueba de path availability mediante un mecanismo OAM asociado al plano escogido. No impone BFD ni LSP Ping; esos son ejemplos útiles en las revisiones y RFC relacionados. Tampoco define cuándo lanzar la prueba. Puede hacerse por efecto de la consulta o existir de antemano.

Esto añade otra dimensión temporal. Un resultado previo puede corresponder a una generación anterior del túnel. Una prueba en demanda puede completarse después de que el estado cambie. Durante el arranque, “sin resultado” puede significar que la sesión aún no existe. Bajo carga, un timeout puede describir al proceso de medición, no al forwarding. Una respuesta positiva puede recorrer una parte que funciona mientras otro miembro ECMP falla.

La consecuencia no debe inferirse del color del indicador. El texto normativo no explica con precisión qué ocurre al fallar el control, aunque la conclusión habla de continuar anunciando o retirar reachability. RFC 4271, en cambio, ordena excluir una ruta no resoluble. Los reviewers piden aclarar esa unión. Hasta entonces, decir que el borrador obliga a retirar sería exagerar su contenido.

Para operar sin borrar incertidumbre hacen falta tres estados: evidencia positiva, evidencia negativa y evidencia indeterminada. La política decide qué hacer con cada uno y durante cuánto tiempo. Esa política debe estar versionada y aparecer en el recibo. Un estado expirado no debe convertirse silenciosamente en negativo; uno no inicializado tampoco.

La decisión puede propagarse más lejos que la prueba

Una medición OAM suele ser local al next hop. Si su resultado cambia la lista de candidatos, BGP puede anunciar otro camino o retirar reachability a vecinos. Una perturbación pequeña se convierte así en evento de routing. Si muchas rutas comparten el next hop, una sola sesión puede afectarlas a todas. Si el resultado oscila, también lo hacen sus anuncios.

Security advierte que quien pueda bloquear, retrasar o falsificar la señal de liveness puede provocar una retirada, conservar un camino roto o dirigir tráfico hacia la alternativa. RFC 5880 trata los falsos estados up y down como riesgos de BFD; RFC 8029 describe spoofing, replay y alteración alrededor de LSP Ping. La autenticación ayuda con origen e integridad, pero no obliga a un atacante on-path a entregar la sonda ni garantiza el mismo trato para los datos.

La prueba positiva conserva un alcance limitado. Demuestra la respuesta prevista por un mecanismo, para un endpoint y un instante. No prueba que todas las FEC funcionen, que la búsqueda de la VRF remota sea correcta, que el prefijo del cliente esté instalado, que el retorno exista ni que una transacción de aplicación termine.

Una evidencia completa separa recepción del camino, selección de política, resolución por tabla, resultado OAM, clasificación de elegibilidad, nueva elección BGP, instalación de forwarding, anuncio al peer y resultado del servicio. Cada transición puede fallar por separado.

El rollback necesita volver a una semántica conocida

La revisión actual afirma que no se espera un impacto negativo en convergencia salvo detalles de implementación. Los reviewers rechazan esa seguridad sin datos. Las sesiones por next hop tienen coste a escala de una malla de PE. Las transiciones pueden producir churn y propagarse a CE. Un despliegue parcial deja a unos speakers aplicando el nuevo criterio y a otros no.

Antes de aplicar la exclusión, la organización debe ejecutar el cálculo en modo sombra. Debe comparar la tabla seleccionada y el resultado OAM con contadores de tráfico, pruebas independientes y resultados de aplicación. También debe medir cuántas rutas comparte cada next hop y qué habría cambiado en BGP.

El rollback correcto restaura la versión de política anterior, invalida decisiones derivadas cuando corresponde y provoca una reevaluación controlada. Desactivar la sonda sin saber si su último negativo permanece cacheado puede prolongar la avería. El inventario de caminos excluidos y la razón exacta son parte del mecanismo de vuelta.

La revisión 13 tiene razón al desconfiar de una ruta IP que pretende hablar por un LSP. La siguiente disciplina es desconfiar de una etiqueta genérica —“MPLS disponible”— que no nombra tabla, instante ni método. El forwarding real no cabe en una sola bandera. La autoridad de excluir un camino debe estar ligada a la prueba concreta que la obtuvo y a la política reversible que decidió creerla.

Fuentes