Resumen

  • RFC 5195 usa Route Targets para distribuir asociaciones CPI/PPI entre las tablas de puertos de un L1VPN. Una coincidencia confirma la ejecución de una política de importación, no la legitimidad del vínculo comercial o físico que esa política representa.
  • La automatización debe conservar pruebas separadas de origen, autorización, recepción, importación, instalación en la PIT, señalización, reserva, conexión cruzada y tráfico. Sin esa cadena, un inventario coherente puede describir con exactitud el VPN equivocado.

La exactitud mecánica de una clasificación falsa

Los Route Targets resuelven un problema de escala. Cada PE no necesita guardar la información de todos los L1VPN del proveedor. Las comunidades de exportación etiquetan datos locales; las de importación limitan qué rutas pueden poblar cada Port Information Table. BGP hace el trabajo de distribución y retirada.

La operación es precisa, pero su precisión pertenece a la regla configurada. Si el identificador se asigna al cliente equivocado, el protocolo no descubre la intención humana perdida. Propaga, filtra e instala la afirmación según la política disponible.

Por eso Route Target coincidente no equivale a sitio autorizado. La primera frase tiene un testigo: el motor de políticas. La segunda necesita otro: un registro que vincule ese PE, ese Customer Port Identifier y ese Provider Port Identifier con el L1VPN y con una autoridad vigente.

Qué contiene realmente la PIT

RFC 5195 define la PIT como una lista de pares <CPI,PPI> para los puertos del VPN. Una parte es local: procede de los CE conectados o de configuración en el PE. Otra es remota: llegó desde otros PE mediante descubrimiento automático.

La tabla es útil precisamente porque reúne ambas partes para que la señalización pueda resolver direcciones. Pero el uso común no fusiona sus fuentes. Una entrada remota sigue siendo una afirmación recibida. Su presencia indica que superó distribución e importación; no indica que el hardware remoto conserve el puerto, que exista capacidad o que una conexión haya sido creada.

El resumen de RFC 5195 evita esa confusión. La información es necesaria para completar la fase de señalización. El descubrimiento prepara la siguiente operación. El modelo de configuración en un solo extremo reduce las intervenciones manuales; no elimina las acciones del otro extremo ni convierte su resultado en algo conocido por anticipado.

El Join que solo cambió la configuración

Un VPN Join añade una nueva comunidad de importación. Antes de ese cambio, el PE estaba obligado a descartar información que no coincidía con ningún VPN local. Después necesita recuperar las rutas descartadas. RFC 5195 exige Route Refresh en este caso.

El detalle impide tratar el commit de configuración como final del trabajo. Deben existir al menos cuatro recibos: política instalada, refresco solicitado, conjunto de rutas recuperado y PIT reconciliada. Si falta el segundo, la nueva regla puede ser correcta y la tabla seguir incompleta. Si falta el cuarto, BGP puede haber entregado la información sin que el consumidor la haya proyectado.

El VPN Prune presenta el riesgo simétrico. Al desaparecer la última comunidad relevante, las rutas sin coincidencia pueden descartarse. La sesión BGP continúa. Una plataforma que solo vigila el estado de la sesión verá estabilidad mientras una caché conserva un sitio que ya no pertenece al alcance local.

La continuidad de control es positiva, pero no certifica la limpieza de estado. El indicador correcto después de Join o Prune es una reconciliación entre política, RIB, PIT y consumidores.

Autenticar al vecino no autoriza el dato

RFC 5195 exige que ningún PE sea descubierto como miembro si no está realmente conectado y autorizado. Para un vecino directo recomienda autenticación BGP. Eso reduce la posibilidad de que un impostor ocupe la sesión.

Cuando hay locutores intermedios, la confianza cambia de forma. El PE local conoce a su vecino, pero la asociación pudo originarse varias etapas atrás. Debe confiar en que cada participante solo aceptó datos de otro participante confiable. El RFC describe esa confianza como transitiva y reconoce que BGP no demuestra que una pieza concreta nació en un locutor autorizado a publicarla.

El límite es especialmente importante frente a una política errónea. Una cadena de sesiones auténticas puede transportar fielmente una clasificación falsa. La criptografía protege el canal; no corrige la semántica empresarial del Route Target ni crea el mandato del origen.

Máximo no significa libre ni reservado

El mecanismo también puede transportar capacidad de conmutación y ancho de banda LSP máximo para seleccionar salida. Es una ayuda a la decisión, no una reserva. El dato puede ser válido como límite anunciado y, aun así, estar desactualizado respecto de la capacidad libre.

La cadena probatoria debería conservar anuncio, instante y fuente; luego medida operativa, control de admisión y reserva. Si un controlador cambia la etiqueta de máximo remoto a disponible y después a asignado, produce dos conclusiones sin nuevos testigos.

Un inventario parcial puede parecer total

La arquitectura permite particionar reflectores y operar sistemas BGP independientes para información de VPN. La escala mejora porque ningún componente debe conocerlo todo. Sin embargo, el alcance de una vista se vuelve parte esencial de su significado.

Un panel debe declarar qué partición observa, qué productores espera, qué versión de política aplica y cuándo se reconcilió. Dos vistas incompatibles pueden ser correctas dentro de perímetros diferentes. Solo una comparación con un universo declarado permite llamar completa a una PIT.

La secuencia que no puede comprimirse

El recibo mínimo de descubrimiento registra VPN, CPI, PPI, procedencia local o remota, vecino inmediato, origen observado, Route Targets, decisión de importación y autoridad que habilita la asociación. Join, Prune y retirada incorporan eventos de refresco, eliminación y confirmación de los consumidores.

Después comienza otra secuencia: solicitud de señalización, admisión, reserva, estado de la conexión cruzada, continuidad y prueba de tráfico. Este diseño no pretende ser sintaxis obligatoria de RFC 5195. Es una forma operativa de impedir que una capa hable en nombre de las demás.

La tesis de Heng Lu sobre las capas de realidad es aquí una disciplina de producción. El símbolo descubierto sirve para iniciar trabajo. Se vuelve peligroso cuando se usa para declarar que el trabajo terminó. El código en ejecución y el trayecto físico conservan la última palabra; el inventario debe describirlos, nunca reemplazarlos.

Fuentes

  1. RFC 5195 en HTML
  2. RFC 5195 en texto
  3. Página informativa de RFC 5195
  4. Datatracker de IETF: RFC 5195
  5. Historial de RFC 5195
  6. Referencias de RFC 5195
  7. Erratas de RFC 5195
  8. RFC 4847
  9. RFC 5251
  10. RFC 4760
  11. RFC 4360
  12. RFC 4684
  13. RFC 2918
  14. RFC 5291
  15. RFC 2385
  16. RFC 4271
  17. RFC 5925
  18. Heng Lu — capas de realidad y poder simbólico
  19. Heng Lu — especificación inicial mínima
  20. Heng Lu — primacía del código en ejecución