Resumen

  • Las rutas de autodetección de MVPN y EVPN pueden añadir o retirar un PE del conjunto de hojas de una política SR P2MP; el controlador realiza después otra tarea: calcular e instanciar el árbol.
  • Para afirmar entrega hay que unir la generación de política con el estado de replicación, el Tree-SID, el contexto de servicio, el split horizon y una observación en el receptor.
  • Hooman Bidgoli aparece como uno de cinco autores de RFC 10018. El registro sustenta una contribución concreta a una obra colectiva, no control individual de la norma ni de una red en producción.

La prueba más tentadora en multicast es también la más barata: contar destinos. Si ayer había ocho hojas y hoy aparecen nueve después de una solicitud de alta, la novena parece confirmar el trabajo. La cifra resulta cómoda para un informe de cambio porque cabe en una celda y parece reunir descubrimiento, topología y servicio.

Sin embargo, solo responde a la pregunta de si el plano de control incorporó una intención. No dice que el controlador encontrara un árbol viable, que todos los nodos instalaran la misma generación, que la hoja eligiera el contexto correcto o que el receptor aceptara la secuencia. El salto entre esas afirmaciones es justo donde una operación puede parecer completa y fallar.

RFC 10018 fue publicado en agosto de 2026 como documento de Standards Track. Rishabh Parekh y Daniel Voyer son sus editores; Clarence Filsfils, Hooman Bidgoli y Zhaohui Zhang completan la lista de autores. El texto extiende MVPN y EVPN para usar árboles Segment Routing P2MP y replicación en ingreso. La arquitectura no borra las fronteras de responsabilidad: las hace observables si el operador conserva sus recibos.

Una hoja es una solicitud de inclusión

Una política SR P2MP se define por una raíz, un conjunto de hojas y uno o varios candidate paths. Cada candidato puede expresar restricciones y un objetivo de optimización, y puede contener ninguna, una o varias instancias de árbol. El conjunto de participantes, la selección de política y el árbol materializado son estados relacionados, pero diferentes.

En MVPN o EVPN, el PE de ingreso importa una ruta de autodetección procedente de un PE de egreso. Ese evento descubre al egreso como hoja del P-tunnel correspondiente y actualiza el conjunto de hojas. Cuando se retira la ruta, el PE sale de ese conjunto. En el otro extremo, el egreso asocia la ruta al servicio y comunica al módulo de política que se incorpora como Leaf o Bud.

El mecanismo aporta algo valioso: una fuente de pertenencia con autor, tiempo y retirada. Permite separar un fallo de descubrimiento de uno posterior. Si la ruta nunca se importó, no tiene sentido buscar primero un defecto de replicación en un nodo que jamás formó parte de la intención.

Pero la ruta no observa el tráfico. Tampoco certifica que las restricciones sean compatibles, que exista una instancia de árbol actual ni que la aplicación remota esté escuchando. Es un input para otra decisión. Convertirlo en resultado confunde el mensaje con la ejecución.

El cálculo necesita su propio recibo

RFC 10018 entrega al controlador el conjunto de hojas y el candidate path, incluidas sus restricciones y objetivo. El controlador calcula una instancia P2MP y enlaza segmentos de replicación en la raíz, los nodos intermedios y las hojas. La forma de instalar esos segmentos —BGP, PCEP, NETCONF u otra— queda fuera del alcance del documento.

Esa frase de alcance evita una falsa garantía. Un sistema puede registrar correctamente la petición mientras el cálculo espera en una cola. El cálculo puede rechazar una restricción imposible. La programación puede alcanzar seis equipos y fallar en el séptimo. Incluso con respuestas satisfactorias, un ASIC puede activar el cambio después que los demás.

La unidad auditable no debe ser “actualización terminada”, sino una generación identificable. Conviene guardar el identificador del candidate path, el hash del conjunto de hojas, las restricciones, el objetivo, la solicitud del controlador, el PTI obtenido y el acuse de cada nodo. Solo así se puede demostrar que una pantalla de control y un contador de datos hablan del mismo árbol.

RFC 9960 define la estructura de la política; RFC 9524 describe Root, Bud, Leaf y nodos intermedios de replicación; RFC 9961 establece ping y traceroute para políticas SR P2MP sobre MPLS. Esta división es deliberada. Configuración, programación y medición son pruebas complementarias.

El Tree-SID no contiene todo el contexto

La instancia de árbol recibe un Tree-SID. En la raíz, el tráfico entra en ese identificador. Los nodos replican según las ramas instaladas. En la hoja, se elimina el Tree-SID y el paquete debe ingresar en el contexto MVPN o EVPN correspondiente.

Si el árbol está dedicado a un solo servicio, su identidad puede bastar para recuperar ese contexto. Cuando el P-tunnel se comparte, hace falta un label de servicio, un SID SRv6 o un argumento que distinga al cliente. Un paquete puede recorrer el árbol previsto y acabar en una tabla equivocada. El tránsito correcto no prueba la entrega correcta.

EVPN multihoming añade la obligación de split horizon. Su función es impedir que una trama BUM regrese por el mismo segmento Ethernet o llegue duplicada. El conjunto de hojas no demuestra que el ESI y el filtro aplicado coincidan. La lista de receptores puede ser perfecta y el usuario seguir viendo dos copias.

Por eso el registro debe unir Tree-SID, etiqueta o SID de servicio, contexto del segmento Ethernet, valor de split horizon, PE de entrada y búsqueda de egreso. Si se deducen esos datos a partir del número de hojas, la auditoría empieza con una suposición.

La replicación en ingreso cambia el lugar del fallo

El mismo RFC también abarca ingress replication. En lugar de usar un árbol común, el PE de ingreso produce copias separadas y las envía a cada PE de egreso por caminos SR-MPLS o SRv6. El controlador de política P2MP no participa de la misma manera.

La experiencia del cliente puede parecer equivalente, pero la operación no lo es. En un árbol, la consistencia de la generación y de los nodos de replicación es central. En replicación en ingreso, importan el número de copias en origen y la reachability unicast hacia cada salida. Agrupar ambos bajo un campo booleano “multicast” oculta el punto donde buscar.

Durante una migración, la dificultad aumenta: parte de los receptores puede seguir en el árbol y otra parte recibir copias desde el origen. El expediente de cambio debe señalar el modo por receptor, el dueño del corte, el criterio que retira la ruta antigua y el indicador que detecta una duplicación. De otro modo, dos equipos pueden considerar terminado su tramo mientras ambos siguen enviando.

El último tramo decide el significado de entrega

Una cadena de evidencia empieza con los paquetes que la raíz acepta del cliente y los que introduce en el Tree-SID o conjunto exacto de réplicas. Continúa con contadores de entrada, salida replicada y descarte por nodo, siempre ligados a la misma generación. En la hoja recoge decapsulación y consulta de contexto. En el receptor observa secuencia esperada, pérdida, duplicación, orden, latencia y consumo útil.

Ninguna cifra debería absorber a las demás. El contador de la raíz demuestra admisión. El de una rama ayuda a localizar pérdida. La decapsulación demuestra llegada al equipo de egreso. La observación final es la única que demuestra que el endpoint previsto obtuvo el servicio bajo las condiciones declaradas.

Las pruebas deben incluir cambios, no solo estabilidad. Retirar una hoja con tráfico activo permite medir cuánto tarda cada capa en converger y si una copia persiste. Volver a unirla debe crear una generación nueva que pueda rastrearse. Una avería de programación intermedia debe aparecer como incompletitud, no como un árbol “verde”. El failover de un sitio multihomed debe buscar duplicados además de pérdida.

El rastro público de Hooman Bidgoli

El perfil del IETF Datatracker capturado el 1 de septiembre de 2026 atribuye siete RFC a Hooman Bidgoli. Entre ellos están RFC 9524 sobre replicación SR, RFC 9960 sobre la política P2MP, RFC 9961 sobre su OAM y RFC 10018 sobre el enlace con MVPN y EVPN. RFC 10018 consigna afiliación con Nokia en Ottawa. Una página oficial de Nokia SReXperts documenta experiencia en IP/MPLS, multicast y seguridad de routers en la fecha de captura.

La secuencia permite explicar por qué su nombre es relevante: aparece a través de varias capas que la operación debe mantener separadas. No permite atribuirle en exclusiva los mecanismos, el consenso del IETF ni el resultado de una implementación concreta. Los cinco autores de RFC 10018 y las normas que lo preceden hacen visible el carácter colectivo.

El valor de enfocar a una persona no está en crear un héroe técnico. Está en usar una contribución verificable para localizar una decisión de diseño. En este caso, la actualización de pertenencia impulsa una política, pero no sustituye las decisiones ni las pruebas de las capas siguientes.

Diseñar el registro antes de necesitarlo

Cada alta o baja debería conservar el servicio, tenant, modo de entrega, raíz, rutas de autodetección importadas, pertenencia Leaf o Bud, candidate path, restricciones y objetivo. Después debe añadir petición al controlador, generación PTI y confirmaciones de los segmentos de replicación por dispositivo.

La unión continúa con Tree-SID, label o SID de servicio, ESI, split horizon y lookup de salida. Termina con admisión, copias generadas, descartes, decapsulación, OAM, observación del receptor y cronología de alarmas. Para una baja, el registro identifica al solicitante, los tiempos de limpieza y la prueba de que cesó la entrega.

El resultado no es una promesa de simplicidad. Es una forma de hacer localizable el desacuerdo. El conjunto de hojas conserva un significado preciso: intención actual de pertenencia. La frase “servicio entregado” solo aparece al final, cuando la ejecución y el receptor pueden demostrarla.

Fuentes