Resumen

  • RFC 9793 registra el atributo de ruta BGP 41 como opcional y transitivo. En anuncios de prefijos de host BFR transporta identificadores de subdominio, BFR-ID, datos de encapsulación y, cuando corresponde, un siguiente salto BIER.
  • El uso descrito presupone un dominio BIER alineado con un dominio administrativo, que puede abarcar varios AS. Cada router fronterizo compatible debe disponer de una política por sesión o grupo EBGP, con resultado predeterminado de no permitir.
  • Si no se permite, el atributo no sale y, si entra, se ignora silenciosamente sin propagación posterior. La recepción no certifica autorización, coherencia de espacios BIER, instalación en forwarding ni entrega multicast.

El dato que llega no trae consigo el permiso

Imaginemos un router de borde que abre una UPDATE y encuentra exactamente lo esperado por el decodificador: una NLRI /32, el tipo 41, longitudes consistentes y un TLV BIER con subdominio, BFR-ID y datos de encapsulación. No hay error de sintaxis. Tampoco hay todavía autoridad para usarlo.

Ese es el punto más valioso de RFC 9793. El documento permite que BGP anuncie información BIER sin exigir que cada altavoz intermedio sea un BFR. El atributo es opcional transitivo, y la IANA le asigna el código 41. Se vincula a prefijos de host IPv4 /32 o IPv6 /128 dentro de los AFI/SAFI enumerados. No define el uso con prefijos agregados ni con cualquier familia que el operador imagine.

El contenido sirve a un propósito concreto. Un BFER anuncia un TLV por cada subdominio BIER que soporta. Allí figuran un BFR-ID y la encapsulación MPLS o no MPLS, con rango de etiquetas o de BIFT-id. Un siguiente salto BIER puede indicar qué vecino debe entrar en el cálculo. Un BFR que vuelve a anunciar puede actualizar siguiente salto y encapsulación solamente bajo reglas acopladas; si no soporta un subdominio, no debe reescribir su TLV. Incluso un altavoz que no sabe reenviar BIER puede conservar el atributo.

La transitividad, por tanto, protege la continuidad de la señal dentro de una red administrativa que ha elegido usar BGP para construir estado BIER. No demuestra que la señal deba viajar por todas partes.

La excepción específica vence a la regla genérica

RFC 4271 clasifica los atributos y establece que un atributo opcional transitivo desconocido puede conservarse y propagarse con el bit Partial. Un atributo opcional no transitivo desconocido, en cambio, se ignora y no se reenvía. RFC 9793 toma precisamente este segundo comportamiento para el borde administrativo que no autoriza BIER.

El requisito tiene tres piezas. Un router fronterizo que soporta el atributo debe ofrecer una política basada en sesión o grupo EBGP. Esa política dice si el atributo está permitido y su valor inicial es no. Cuando la respuesta es no, el router no puede enviar el atributo al peer. Si lo recibe, lo trata como si fuera no transitivo y desconocido: silencio, descarte del atributo y fin de la propagación.

No hay contradicción. El atributo sigue siendo transitivo en el protocolo. La especificación limita el lugar donde esa propiedad es útil. El control de frontera no se delega al emisor, al indicador Partial ni a la mera capacidad de interpretar el tipo 41. Pertenece a la política efectiva de cada extremo.

AD, AS y subdominio no son sinónimos

Una implementación simple podría etiquetar todo EBGP como externo. RFC 9793 no lo hace. Su dominio administrativo puede contener varios sistemas autónomos. RFC 8279 incluso contempla EBGP como underlay en ciertos despliegues. El número de AS señala una frontera de BGP, pero no dice por sí solo si dos lados comparten autoridad administrativa.

De ahí la granularidad de sesión o grupo. El operador decide qué enlaces EBGP siguen dentro del mismo AD y cuáles llegan a una organización independiente. Un permiso explícito puede ser correcto para el primer caso. Para el segundo, la negación predeterminada evita que el router interprete accidentalmente una coincidencia de formato como una coincidencia de gobierno.

También evita otros atajos mentales. El valor de subdominio ocupa un octeto, pero no constituye un registro mundial. El BFR-ID debe ser único dentro de su subdominio, no en Internet. Una etiqueta MPLS o un BIFT-id pertenece a una asignación local. Un BIER Nexthop indica un insumo de cálculo, no una identidad autenticada. Dos dominios pueden publicar valores numéricamente iguales y estar describiendo sistemas incompatibles.

Entre el anuncio y el resultado hay al menos cinco estados

Primero está el estado declarado: los bytes que el peer colocó en la UPDATE. Segundo, el estado analizado: aquello que el receptor consideró sintáctica y semánticamente utilizable. Tercero, el estado autorizado: la política local permitió que el atributo atravesara esa frontera. Cuarto, el estado calculado: el BFR derivó una entrada BIFT a partir del anuncio y de su FIB unicast. Quinto, el estado ejecutado y observado: la plataforma instaló algo, un túnel existió, los paquetes siguieron una ruta y el servicio produjo un resultado.

RFC 9793 cubre con detalle partes de los cuatro primeros, pero no emite recibos automáticos para el quinto. El túnel hacia un siguiente salto no conectado directamente está fuera de alcance. Una tabla de control no prueba la programación de hardware. Un contador no identifica por sí solo el flujo, el subdominio ni el receptor. Y un receptor que vio un paquete no convierte retrospectivamente en autorizada la importación que lo produjo.

La validación tampoco debe mezclarse con la política. Si las longitudes de TLV no cuadran, RFC 9793 exige attribute discard bajo RFC 7606. Si se repite un TLV del mismo subdominio, se ignora todo el atributo. Repeticiones de la misma longitud de BitString o rangos solapados anulan la información correspondiente. Si dos prefijos declaran el mismo BFR-ID no nulo en un subdominio, no pueden alimentar el cálculo BIFT. Que una excepción de borde exista no cura ninguna de estas contradicciones.

El peligro es una unión falsa, no una historia de incidente

Los BFR-prefix suelen ser loopbacks distribuidos en el AD y no necesitan salir para el funcionamiento BIER. RFC 9793 advierte que, si salen con el atributo y el AD vecino también despliega BIER, dos dominios que deberían ser independientes pueden unirse de forma incorrecta, probablemente con configuraciones en conflicto. De ahí derivan riesgos de seguridad y problemas operativos.

La norma no afirma que haya observado tal evento. No aporta telemetría, una marca, una red, una pérdida ni un cliente afectado. Su lenguaje describe un modo de fallo de diseño. La lectura responsable mantiene esa condición: la fuga crea la posibilidad de que un receptor calcule con nombres cuya autoridad y unicidad no se extienden al nuevo ámbito.

El propio plano de datos marca otra frontera. RFC 8279 dispone que un paquete encapsulado BIER no cruza directamente entre dominios BIER. Se desencapsula, pasa al overlay multicast y puede volver a imponerse en el siguiente dominio, con un equipo actuando como BFER en uno y BFIR en otro. Esa transferencia explícita conserva dos contextos. No autoriza a mezclar sus identificadores de control.

El erratum 8463, ya verificado, corrige un detalle del ejemplo de la sección 6: BFR2 usa el prefijo de BFER1 cuando falta el siguiente salto en la ruta de BFER1. La frontera de la sección 7 no cambia. Del mismo modo, la ficha del RFC Editor y el Datatracker del IETF prueban el estado documental; no prueban ejecución.