Resumo

  • O draft multicast-over-srv6 reutiliza multicast IPv6 nativo: PIM ou um controlador cria (S,G)/(*,G) com interface RPF e lista de saídas, não uma sequência de SIDs para as ramificações.
  • Um Flex-Algo pode orientar a rota unicast usada por PIM, mas RFC 9502 exige que a participação do plano IP seja anunciada separadamente da participação SR.
  • Intenção aceita, estado aplicado, encapsulamento correto, replicação por ramo e resultado do receptor são recibos distintos e precisam do mesmo identificador de fluxo e intervalo.

Coexistência começa pela pergunta: quem pode apagar?

O draft admite duas formas de criar a árvore: PIM pode construir o estado dinamicamente, ou um controlador pode calcular e instalar entradas multicast IPv6 nativas. É tentador tratar a segunda opção como uma substituição moderna da primeira. A diferença operacional mais importante, porém, não é central contra distribuído. É quem tem autoridade para criar, atualizar, envelhecer e retirar cada (S,G).

Os dois mecanismos podem coexistir quando usam fontes e grupos diferentes. Essa condição precisa aparecer no inventário, não apenas no projeto. Se PIM e o controlador alcançam o mesmo fluxo, um timer pode retirar uma entrada que o sistema central considera permanente; uma reconciliação pode sobrescrever a escolha distribuída. Um HTTP 200 ou commit no datastore prova que uma intenção entrou no controlador. Não prova que todos os nós aceitaram a mudança, que o hardware aplicou a lista de saídas ou que um pacote chegou.

O texto diz que a instanciação northbound será tratada em documento complementar. Portanto, autorização, atomicidade entre equipamentos, confirmação do dataplane e rollback não podem ser atribuídos a este draft. O mecanismo continua sendo multicast nativo, qualquer que seja a origem da configuração.

O nome SRv6 descreve o ambiente, não a bifurcação

RFC 8402 define Segment Routing como source routing para unicast e deixa a aplicação do conceito ao multicast fora de escopo. RFC 8986 define os comportamentos de programação SRv6. Já o texto 01 do draft PIM, assim como suas formas HTML e XML, afirma que a distribuição multicast é ortogonal a SR.

A escolha é reaproveitar multicast IPv6 nativo em uma rede SRv6 somente IPv6. A entrada contém fonte, grupo, interface de entrada validada por RPF e interfaces de saída. Não contém uma lista ordenada de SIDs descrevendo cada ramo. “Multicast transportado por uma rede SRv6” é uma descrição possível; “árvore segment-routed” exige um mecanismo que o draft não especifica.

Flex-Algo influencia a pergunta unicast

PIM-SM escolhe o lado upstream perguntando qual interface o roteador usaria para chegar à fonte por unicast. Quando o prefixo da fonte é anunciado no algoritmo 128, o draft permite que o caminho IP restrito daquele algoritmo oriente o RPF. A engenharia de tráfego chega à árvore por essa dependência, não por uma instrução SR no pacote multicast.

RFC 9350 mostra que uma Flexible Algorithm Definition inclui cálculo, métrica e restrições; o número sozinho não basta. Uma definição incompatível pode fazer um nó abandonar o algoritmo e remover estado. RFC 9502 separa ainda mais: IP Flex-Algo é um dataplane independente e sua participação deve ser sinalizada à parte de SR-MPLS ou SRv6.

Assim, “FA128 suportado” precisa de dois complementos: qual definição e em qual dataplane. Para o RPF descrito no draft, interessa a participação IP. Um nó pode participar em SR e não em IP, ou o contrário. Durante uma mudança, a rota unicast também pode convergir antes do estado PIM; a nova interface RPF passa a rejeitar pacotes que ainda chegam pela antiga árvore.

O overlay multiplica os vínculos que devem ser lidos de volta

RFC 6513 define a arquitetura MVPN e RFC 6514 os procedimentos BGP correspondentes. RFC 6515 permite endereços de infraestrutura IPv4 ou IPv6, RFC 7716 trata Global Table Multicast e RFC 8950 permite next hop IPv6 para NLRI IPv4.

No exemplo do draft, PIM-SSM cria a árvore provedora IPv6 nativa, MP-BGP sinaliza PMSI e rotas multicast do cliente, e o pacote do cliente segue em IP-in-IPv6. O Next Header externo 4 indica conteúdo IPv4; 41, IPv6. Nenhum dos dois valores prova a VPN, o conjunto de receptores ou a replicação correta. O draft diz expressamente que essas soluções não requerem procedimento específico de SRv6.

Uma leitura de volta completa precisa ligar fluxo do cliente, PMSI, árvore provedora, interface em cada ramo, decapsulação no PE e receptor autorizado. Também deve mostrar exclusão: outra VPN e um não membro não podem receber. Entrega positiva sem prova de isolamento é apenas metade do teste.

A revisão 01 não acrescentou uma implantação

A API do Datatracker, a página e o histórico congelados registram um Internet-Draft ativo do grupo PIM. O cabeçalho pretende status Informational; não há AD responsável, shepherd ou telechat exibidos. Não é RFC, censo de implementação, teste de interoperabilidade ou benchmark.

A comparação com a revisão 00 encontrou apenas mudanças de data, expiração, número e cabeçalhos de página. A frase de segurança sobre não criar novos problemas além dos RFCs citados limita o escopo; não autentica uma escrita central, não garante FAD uniforme nem detecta um PMSI errado.

Fontes e limites

O conjunto congelado inclui 01 TXT, HTML, XML, 00 TXT, API, status e histórico. O contexto vem de RFC 7761, RFC 6513, RFC 6514, RFC 6515, RFC 7716, RFC 8402, RFC 8950, RFC 9350, RFC 9502 e RFC 8986. Nenhuma fonte fornece implantação nomeada, matriz de fabricante, tempo de convergência, perda ou SLA.