Resumo

  • Rotas de descoberta automática de MVPN e EVPN alimentam o conjunto de folhas de uma política SR P2MP; um controlador ainda precisa calcular e instanciar uma árvore a partir do candidate path.
  • Entrega exige recibos que possam ser unidos: geração PTI, programação de replicação, Tree-SID, identificador do serviço, split horizon, contadores e observação no destinatário.
  • Hooman Bidgoli é um dos cinco autores nomeados do RFC 10018. A evidência pública delimita sua contribuição sem transformar trabalho coletivo ou implantação em propriedade individual.

Há uma diferença incômoda entre uma mudança aceita e um serviço percebido. No primeiro instante, o PE de entrada reconhece uma nova folha. Depois, uma requisição chega ao controlador. Mais tarde, equipamentos recebem segmentos de replicação. Só no fim um aplicativo distante pode confirmar que a sequência apareceu sem perda ou duplicação.

Quando o painel mostra apenas a primeira etapa, a operação corre o risco de antecipar o desfecho. O conjunto Leaf é preciso, mas sua precisão está limitada à associação pretendida. Ele não observa a fila do controlador, a versão ativa em cada nó, a tabela VPN escolhida na saída ou a saúde do consumidor.

Publicado em agosto de 2026 no Standards Track do IETF, o RFC 10018 tem Rishabh Parekh e Daniel Voyer como editores e Clarence Filsfils, Hooman Bidgoli e Zhaohui Zhang como demais autores. O documento especifica o uso de árvores Segment Routing P2MP e ingress replication por MVPN e EVPN. Sua arquitetura fornece um bom antídoto para o atalho: cada transição conserva um significado próprio.

A descoberta automática mantém a intenção de associação

Uma SR P2MP Policy contém uma raiz, um conjunto de folhas e um ou mais candidate paths. O candidato pode expressar restrições e objetivo de otimização, e pode possuir zero ou mais instâncias de árvore. Associação desejada, escolha de política e árvore instanciada não são o mesmo estado.

Quando o PE de entrada importa a rota de descoberta automática de um PE de saída, ele descobre esse PE como folha do P-tunnel e o adiciona à política correspondente. A retirada da rota o remove. No PE de saída, a rota é vinculada ao serviço MVPN ou EVPN e o módulo da política recebe a indicação de participação como Leaf ou Bud.

O ganho é concreto. A operação passa a ter eventos identificáveis em vez de uma lista inteiramente manual. Pode perguntar quem anunciou, qual entrada importou, que política mudou e quando a retirada ocorreu. A ausência da rota explica por que uma folha nunca entrou na intenção de distribuição.

O que a rota não faz é medir o caminho de dados. Ela não atesta que as restrições admitem solução, que a instância foi instalada em todos os pontos ou que o processo receptor aceitou o fluxo. A descoberta autoriza o próximo passo; não assina o resultado dele.

A árvore calculada precisa pertencer a uma geração

Com o conjunto de folhas, o candidate path, as restrições e o objetivo, o controlador calcula uma instância P2MP. Em seguida, costura replication segments na Root, nos nós intermediários e nas Leaves. O RFC 10018 não prescreve se a instalação usa BGP, PCEP, NETCONF ou outro mecanismo.

Essa exclusão de escopo cria uma obrigação operacional. Uma atualização pode estar disponível no roteador, mas aguardando cálculo. O controlador pode rejeitar uma restrição ou aceitar a solicitação sem concluir a programação. Uma transação southbound pode alcançar quase todos os dispositivos e deixar um deles na versão anterior.

O registro de mudança deve, portanto, nomear a geração. Candidate path ID, hash do conjunto Leaf, restrições, objetivo, solicitação ao controlador, PTI calculado e acknowledgements por nó precisam compartilhar uma chave. Sem ela, o “sucesso” de uma interface não pode ser comparado à contagem de outra.

Os RFCs associados mantêm a mesma divisão. O RFC 9960 trata da estrutura da política. O RFC 9524 descreve Root, Bud, Leaf e nó intermediário de replicação. O RFC 9961 fornece ping e traceroute para SR P2MP Policy em MPLS. Política, instalação e OAM são superfícies coordenadas, e não três nomes para um fato.

A árvore compartilhada exige outra identidade

Uma instância recebe um Tree-SID. A Root injeta o payload nesse identificador, os nós do provedor o replicam nas ramificações e a Leaf remove o Tree-SID para entregar o conteúdo ao contexto MVPN ou EVPN.

Em uma árvore dedicada, o próprio identificador pode permitir a recuperação do serviço. Em uma árvore compartilhada, vários serviços usam o mesmo P-tunnel. Um label, service SID SRv6 ou argument deve selecionar o contexto do cliente. O pacote pode chegar pela árvore certa e terminar na tabela errada.

No multihoming EVPN, o split horizon impede que tráfego BUM volte pelo mesmo Ethernet Segment e gere duplicação. Um conjunto Leaf correto não prova que ESI e split-horizon state estejam alinhados. Para o receptor, duas cópias continuam sendo falha, mesmo que todos os participantes apareçam no desenho.

O recibo preserva Tree-SID junto com label ou SID do serviço, Ethernet Segment, valor de split horizon, PE de entrada e lookup de saída. Nenhuma dessas informações deve ser inferida apenas pela cardinalidade do conjunto.

Ingress replication muda a mecânica

O RFC 10018 também permite que o PE de entrada faça cópias individuais e as envie aos PEs de saída por caminhos SR-MPLS ou SRv6. Nessa modalidade, o módulo SR P2MP Policy e o controlador não participam como no caso da árvore comum.

O cliente pode ver um resultado semelhante, mas a falha migra. A árvore depende de uma geração coerente e dos pontos de replicação. Ingress replication depende do número de cópias na origem e da alcançabilidade unicast por saída. Um campo genérico “multicast ligado” não informa qual dessas superfícies investigar.

Durante uma migração, o inventário precisa mostrar a modalidade por receptor, o dono do cutover e o sinal que encerra o estado antigo. Sem isso, uma ramificação pode permanecer porque cada equipe supõe que a outra vai removê-la; ou as duas modalidades podem enviar e inflar contadores com duplicatas.

O receptor dá sentido à palavra entrega

Na Root, medir pacotes aceitos do cliente e inseridos no Tree-SID ou conjunto exato de réplicas. Nos nós, medir entrada, saídas replicadas e descartes vinculados à geração. Na Leaf, registrar decapsulation e lookup do serviço. No receptor, observar sequência, perda, duplicação, ordem, latência e consumo útil.

Essas provas não cabem honestamente em um único verde. A Root comprova admissão. Um contador de ramo localiza perda. A decapsulation confirma chegada ao PE de saída. Só a observação final confirma que o endpoint pretendido recebeu o serviço nas condições contratadas.

Os testes de retirada são essenciais. Remover uma Leaf com tráfego ativo e cronometrar descoberta, novo cálculo, desprogramação e fim real das cópias. Uma nova adesão deve formar outra geração rastreável. Uma falha de instalação no meio da árvore não pode coexistir com uma declaração de completude. Um failover multihomed deve testar duplicação, não apenas continuidade.

O alcance da contribuição de Hooman Bidgoli

O perfil do IETF Datatracker capturado em 1º de setembro de 2026 lista sete RFCs associados a Hooman Bidgoli. Entre eles estão o RFC 9524, sobre replicação SR; o RFC 9960, sobre SR P2MP Policy; o RFC 9961, sobre OAM; e o RFC 10018. Este último registra sua afiliação à Nokia em Ottawa. Uma página oficial do Nokia SReXperts descrevia, na data capturada, atuação em IP/MPLS, multicast e segurança de roteadores.

O conjunto documenta relevância em várias camadas do mesmo problema. Não demonstra autoria exclusiva, controle do consenso do IETF ou responsabilidade por uma implantação de produção. Cinco pessoas assinam o RFC 10018, que por sua vez depende de padrões anteriores de MVPN, EVPN e Segment Routing.

Um perfil de pessoa deve servir para tornar uma fronteira coletiva mais inteligível, não para fabricar um protagonista único. A participação registrada de Bidgoli aponta para a diferença que importa: a atualização da associação pode iniciar a construção da árvore, mas não determina sozinha se ela existe nem se o serviço chegou.

Um recibo multicast é uma junção, não um selo

Para cada mudança, preservar serviço, tenant, modalidade, Root, rotas importadas, participação Leaf ou Bud, candidate path, restrições e objetivo. Acrescentar solicitação ao controlador, geração PTI e confirmação de cada replication segment em cada nó.

Juntar Tree-SID a label ou SID do serviço, Ethernet Segment, split horizon e lookup de saída. Encerrar com pacotes admitidos, cópias criadas, descartes, decapsulation, OAM, resultados do receptor e linha do tempo de alarmes. Em uma retirada, guardar solicitante, tempos de remoção e prova de que o tráfego residual cessou.

Essa disciplina não elimina a complexidade. Ela permite localizar onde os registros discordam. O conjunto de folhas pode continuar sendo uma representação confiável da associação pretendida. Entrega é outra alegação, aceita apenas quando as etapas posteriores concordam.

Fontes