Resumen

  • La alcanzabilidad de NEXT_HOP sigue siendo necesaria, pero un túnel o servicio de segment routing puede depender de otro extremo, otro contexto y otro almacén de rutas.
  • La tupla propuesta exige que alcance, preferencia, métrica y seguimiento procedan de la misma resolución; instalación y entrega continúan siendo pruebas independientes.

Una dirección visible no es todo el camino

El modelo de RFC 4271 presupone que un hablante BGP puede determinar si NEXT_HOP es alcanzable y calcular el coste interior hasta esa dirección. GRE, MPLS, SR Policy y SRv6 rompen la correspondencia sencilla. La dirección de control puede responder aunque el punto de salida del túnel, la política o el SID de servicio que realmente mueve los paquetes esté ausente.

La revisión 00 de BGP Best Path Selection Based on Next Hop Resolution apareció el 24 de septiembre de 2026 como borrador Standards Track del grupo IDR. Si se aprobara, actualizaría RFC 4271. Hoy no es una RFC, ni consenso final, ni mandato o medición de despliegue.

Su unidad de control es la tupla de resolución de camino: una clave de resolución y un contexto opcional. La clave puede ser NEXT_HOP, el Tunnel Egress Endpoint de RFC 9012, o un SID de servicio SRv6 de RFC 9252. El contexto identifica el procedimiento y el almacén usados: por ejemplo, Tunnel Encapsulation, una comunidad extendida Color o datos de un sub-TLV SRv6 distintos del SID.

Por eso {N1, C1} y {N1} no son dos formas de escribir la misma consulta. Aunque compartan clave, una resolución mediante SR Policy y una consulta ordinaria de siguiente salto son observaciones diferentes.

La regla decisiva es no coser pruebas

La propuesta impone que resolubilidad, preferencia, métrica y estado de seguimiento pertenezcan a la misma resolución. Tomar el alcance del contexto A y el coste más bajo del contexto B fabrica una ruta que ningún sistema resolvió realmente.

Las restricciones delimitan qué rutas o almacenes pueden satisfacer la tupla. Pueden exigir un tipo de túnel, excluir agregados o ordenar clases de transporte. No constituyen otro componente de la tupla: son política local sobre su resolución.

La comprobación convencional de NEXT_HOP permanece. La comprobación adicional de la tupla, con sus restricciones, puede habilitarse por configuración. Un objeto de túnel disponible no compensa un siguiente salto ordinario roto.

Las métricas tampoco son comparables por ser números. Una puede expresar coste IGP, otra latencia y otra no ofrecer valor. El borrador introduce una preferencia de clave de resolución local, con valores bajos preferidos, para ordenar primero mecanismos heterogéneos. Tras ese filtro, el coste interno procede únicamente de la tupla. Si hay resolución sin métrica, corresponde el máximo coste permitido, no una cifra prestada.

Ocho recibos, ocho preguntas

El recibo de anuncio conserva la ruta, NEXT_HOP y atributos; el de tupla, clave, contexto y derivación; el de restricción, política y almacén elegible; el de resolución, alcance, preferencia, métrica, datos de reenvío y hora en un resultado atómico.

El recibo de selección muestra candidatos y filtros; el de seguimiento, suscripciones al siguiente salto y a cada contexto, incluidos caminos no ganadores; el de instalación, estado RIB, FIB y encapsulación; el de entrega, recorrido del paquete y resultado del servicio.

Una selección no demuestra instalación, y una instalación no demuestra entrega. El borrador cita congestión, pérdidas y desvíos como riesgos posibles; no presenta su incidencia medida ni prueba que la nueva regla los elimine.

El seguimiento debe recordar el contexto

Un hablante debe seguir tanto NEXT_HOP como la tupla. Si cualquiera deja de resolverse, o cambia la métrica de la tupla, todos los prefijos afectados deben reevaluarse. La identidad de seguimiento tiene que distinguir claves iguales con contextos distintos y cubrir caminos mejores y no mejores. Un candidato de reserva puede volverse elegible sin recibir un anuncio nuevo.

Fusionar {N1, C1} con {N1} en una sola suscripción borra precisamente la diferencia que permite auditar la decisión.

Norma mínima, autoridad localizada

La estructura encaja con la propuesta de Heng Lu de una especificación inicial mínima y decisiones futuras localizadas. IETF puede fijar la identidad de la tupla y prohibir la mezcla sin imponer una preferencia global de transporte. Cada dominio conserva restricciones, prioridades y ritmo de adopción.

Su separación entre autoridad y creencia también importa: un anuncio acredita lo anunciado; una resolución, lo que encontró un sistema. Ninguno obliga a creer que el paquete siguió la intención. La primacía del código en ejecución exige versiones, registros atómicos, estado programado y observación del tráfico.

Aunque Color pueda formar parte del contexto, esta cuestión no debe confundirse con las clases de transporte de RFC 9830. Aquí no se evalúan importación de Color o SLA, sino la coherencia de la evidencia usada por una sola decisión BGP.

Estado y límites

La revisión recomienda configuraciones consistentes dentro de un dominio administrativo. La consistencia reduce divergencias pero no prueba el plano de datos. El texto afirma que no añade consideraciones de seguridad sobre el uso existente de NEXT_HOP; restricciones incorrectas, bases obsoletas y preferencias divergentes siguen siendo riesgos.

El borrador cambiará y puede carecer de implementaciones observables. Su aportación inmediata es identificar el atajo prohibido: no construir la apariencia de un camino con hechos obtenidos de varios.

Fuentes