Resumen

  • El borrador -13 copia los valores de administrador de una Route Target en otro subtipo de Extended Community, pero esa copia no controla la propagación de rutas ni su importación a una VRF.
  • La copia transitiva puede cruzar una frontera entre AS; un filtro eBGP basado en el subtipo de la Route Target quizá no la reconozca.

En BGP, las etiquetas son pequeñas. Sus funciones no siempre lo son.

Una Route Target (RT) puede indicar a qué VPN pertenece una ruta. En las redes que la usan, puede limitar qué routers reciben esa ruta y hacer que una VRF configurada para aceptarla la importe. Una Extended Community corriente puede transportar una etiqueta relacionada sin atribuirse esas facultades. La diferencia importa cuando una ruta debe asociarse con una VPN en solo parte de sus routers PE.

Ese es el escenario del borrador -13, actualizado el 28 de octubre. Supongamos que diez routers PE importan rutas VPN con RT1. Otra ruta debe asociarse con esa VPN en un subconjunto, pero una RT distinta, RT3, controla su distribución. Reutilizar RT1 como etiqueta de asociación insinuaría que todos los routers que importan RT1 deben recibir la ruta. Asignar otra etiqueta por cada subconjunto multiplicaría los valores para una misma VPN.

La respuesta del borrador es una Extended Community derivada: conserva los valores Global Administrator y Local Administrator de la RT, cambia el subtipo y llama al resultado RT-derived EC. Los valores remiten a la RT; el tipo señala que la copia no es una RT.

La diferencia queda escrita de forma expresa. Según este borrador, una RT-derived EC no limita la propagación de rutas, no importa una ruta en una VRF y no coincide con una política que busca la RT correspondiente. Tampoco puede incluirse en el NLRI Route Target Membership de RFC 4684. El borrador define la correspondencia y los códigos; otro documento debe especificar qué hace el receptor con esa etiqueta.

Ahí aparece el problema de frontera. El borrador conserva el octeto de mayor orden del campo Type, así que una RT-derived EC correspondiente a una RT transitiva sigue siendo transitiva. Salvo que una política diga lo contrario, puede cruzar límites entre AS. Una regla que filtre o reescriba el subtipo de la RT no detecta automáticamente el subtipo derivado. Mismos valores de administrador global y local; otro código; otro resultado de coincidencia.

El borrador registra la asignación del subtipo 0x15 en varios registros de Extended Communities, incluidas formas transitivas específicas de AS. No asigna ese valor a todos los formatos posibles de RT; otras correspondencias siguen solicitadas o pendientes. RFC 4360 explica por qué el campo Type permite estructurar políticas para Extended Communities. Aquí, el subtipo es justo donde un filtro puede dejar pasar un valor de la misma familia.

El 30 de octubre, una revisión del Operations Directorate del IETF analizó la versión 13 y pidió una sección específica de consideraciones operativas. Gen Chen señaló riesgos de filtrado y fuga entre AS, límites de alcance y comportamiento de BGP heredado; indicó que se puede filtrar el subtipo 0x15 en las fronteras eBGP si se quiere evitar su propagación. Es una observación de revisión, no prueba de que haya ocurrido una fuga. Señala la distancia entre codificar una etiqueta y explicar cómo se comportará en redes mixtas.

Al 2 de noviembre, el borrador está en evaluación del IESG y figura para la teleconferencia del 5 de noviembre. Un documento informativo puede fijar qué bits corresponden sin decidir quién debe filtrarlos, qué harán los equipos antiguos o cómo se contendrá cada uso futuro. El subtipo cabe en un byte; el inventario de políticas es el trabajo más grande.

Fuentes: borrador -13 · revisión del Operations Directorate · RFC 4360 · RFC 4684