Summary

  • El borrador draft-ietf-idr-rt-derived-community-13, actualizado el 28 de octubre, describe una comunidad extendida que copia los valores Global Administrator y Local Administrator de un Route Target y cambia su subtipo. Según el propio documento, el marcador resultante identifica el RT original sin controlar la propagación de rutas ni provocar su importación en una VRF. Sigue en evaluación del IESG y está previsto como documento Informational.
  • Los registros de IANA ya incluyen seis asignaciones de RT-derived-EC referidas a un borrador anterior de 2021. El texto nuevo solicita actualizar esas referencias y asignar otros valores. La inscripción de un código y la definición de su uso por un receptor son decisiones distintas.

Una VPN no es una lista única de destinatarios

El ejemplo oficial presenta diez routers de borde en una VPN. Todos importan rutas con un Route Target común. Ahora aparece otra ruta que debe asociarse a la misma VPN, pero solo algunos routers necesitan recibirla. Si se le pega el RT común, la maquinaria de distribución tiene motivo para enviarla al conjunto entero. Si se fabrica un RT diferente para cada subconjunto, la misma relación con la VPN queda repartida entre muchos nombres. La propuesta separa el dato «pertenece a esta historia» de la orden «entra en estas tablas».

La comunidad derivada mantiene los números administrativos del RT padre. El subtipo nuevo permite reconocerla como otra cosa. La sección 2 dice expresamente que su presencia, en virtud de este borrador, no altera la propagación de la ruta ni la introduce en una VRF. No cabe en la información de membresía de RT descrita por el RFC 4684, y una política que coincida con Route Targets no coincidirá con la comunidad derivada. Es una referencia a la llave, no una llave duplicada.

El RFC 4360 da sentido al contraste: el Route Target identifica routers que pueden recibir las rutas que lo llevan. La comunidad derivada copia parte de su identidad para que varios subconjuntos puedan hablar de una VPN común. La autorización de distribuir e importar queda en el RT real o en otra regla escrita para un uso concreto. Tratar las dos etiquetas como equivalentes por sus números sería saltarse la distinción que el subtipo publica.

IANA registra el nombre; la política decide el efecto

El registro de comunidades extendidas BGP de IANA muestra entradas RT-derived-EC existentes con 0x15 y una entrada IPv6 específica con 0x0015. El borrador habla de seis asignaciones previas, todavía referidas a su antecesor de 2021. Pide actualizar las referencias, renombrar la entrada EVPN y añadir valores para un RT IPv6 basado en UUID y dos clases de transporte. Esas adiciones figuran como solicitudes del borrador; la página actual no permite presentarlas como tareas terminadas.

Tampoco basta memorizar la pareja habitual 0x02/0x15. El documento remite a su tabla de correspondencia y dice que la pareja es una convención. Un RT IPv6 del propio cuadro usa 0x0011 y espera una asignación derivada. Quien quiera interpretar correctamente el mensaje debe leer tipo, subtipo y registro aplicable, no adivinar derechos por parecido visual.

La propuesta reserva para documentos posteriores la acción que adoptará el receptor. Cada uso debe decir sobre qué AFI/SAFI y tipos de ruta viaja el marcador y qué hará el router al verlo. Ahí está el siguiente reparto de autoridad: IANA puede dar un valor estable, pero no decide por cada red si una ruta se instala, se importa o se anuncia. Los autores de usos futuros y las políticas locales asumirán esas decisiones.

El 28 de octubre el Datatracker situaba el texto en IESG Evaluation, con revisión IANA pendiente tras cambio de versión. Las fuentes muestran semántica propuesta y asignaciones existentes; no documentan un fallo de producción causado por confundir ambas etiquetas. La publicación final y las pruebas de implementación serán hechos posteriores.