Resumo

  • A RFC 9960 identifica uma SR P2MP Policy por Raiz e Tree-ID e organiza folhas, caminhos candidatos e instâncias PTI. Esses nomes descrevem transporte, não o direito contratual ou institucional de receber o serviço.
  • A RFC 9961 aponta ping e traceroute para uma PTI específica de um caminho candidato. O texto afirma que não testa o caminho candidato por inteiro e restringe o mecanismo a MPLS, sem cobrir SRv6.
  • Um recibo de audiência multiponto deve ligar a decisão de associação à Policy, ao caminho, à PTI, às folhas, à geração do controlador, ao escopo OAM e ao encerramento da troca. É proposta editorial de Daniel Kade, não requisito do IETF.

A árvore conhece destinos, não integrantes

Distribuição ponto a multiponto evita transportar cópias independentes pelos mesmos enlaces. O fluxo sai de uma Raiz, atravessa trechos comuns e só se divide nos nós em que os caminhos divergem. A RFC 9960 oferece a arquitetura para montar essa estrutura em SR-MPLS e SRv6.

A Policy é identificada por <Root, Tree-ID>. Ela reúne um conjunto de Leaf nodes e caminhos candidatos, com restrições e objetivos de otimização. O controlador calcula P2MP Tree Instances e instala os Replication segments que dão existência ao desenho.

Esses identificadores resolvem um problema real: distinguir políticas, propostas de caminho, realizações e estado por nó. Mas Leaf é uma função de encaminhamento. O termo não declara que o endereço representa um cliente vigente, um tenant autorizado, uma filial ainda aberta ou um integrante atual de uma lista de emergência.

A associação ao serviço nasce em outro sistema. Pode vir de contratos, identidades, papéis, cadastro de participantes ou decisão humana. A automação converte sujeitos em endereços e contextos de serviço. Se essa projeção está atrasada, o controlador não corrige o erro; ele o materializa.

Uma norma reutilizável não deveria escolher os assinantes de todas as organizações. A separação é saudável. O trabalho local é manter a decisão institucional ligada à identidade técnica que a executou.

Uma Policy abriga mais de uma realidade

Uma SR P2MP Policy pode ter vários caminhos candidatos. A Raiz seleciona o ativo pelas regras da RFC 9256. Um caminho pode não ter PTI quando suas restrições não produzem árvore, ou pode conter mais de uma durante make-before-break.

A RFC 9960 exige uma única PTI ativa em cada caminho candidato. Se duas PTIs do caminho ativo funcionarem simultaneamente, folhas podem receber tráfego duplicado. Por isso o Instance-ID é parte da verdade operacional. Uma nova instância pode ser montada, ativada e só então substituir a antiga, embora ambas mantenham o mesmo Tree-ID.

O painel que resume tudo como “Policy ativa” elimina o instante mais delicado. Não diz qual PTI foi testada, quanto tempo as duas coexistiram nem se a antiga continuou recebendo tráfego após o corte.

Há outra separação: uma PTI costuma estar vinculada a um serviço multiponto, mas pode carregar vários quando o contexto de serviço os diferencia na Raiz e nas folhas. Uma árvore saudável não prova que o contexto certo alcançou a audiência certa.

O controlador recebe poder, não necessariamente mandato

Operadora, nó ou máquina pode fornecer Raiz, folhas e caminhos. O controlador computa topologia, atribui Replication-SIDs e instala estado por PCEP, BGP, NETCONF/YANG ou outro mecanismo. Também pode executar uma árvore estática fornecida explicitamente.

Isso dá ao controlador poder concreto para ampliar ou reduzir distribuição. Ainda assim, a fonte legítima da audiência pode estar num sistema de contratos ou papéis. Ter permissão técnica para chamar a interface não demonstra autorização institucional para mudar integrantes.

O Policy Mirror de Heng Lu recomenda olhar o código em execução porque ele revela poder real. A mesma ideia impõe cautela: execução é evidência de ação, não certificado automático de legitimidade. A trilha precisa mostrar de onde veio a lista e como ela chegou ao controlador.

Tentativas malsucedidas também devem sobreviver. Um conflito de SID pode impedir a instalação de um segmento. A RFC recomenda motivo, limite de novas tentativas e alerta; em alguns casos, a PTI parcial deve ser desmontada. Se o êxito seguinte sobrescreve a geração anterior, desaparecem o estado incompleto e a prova de sua remoção.

O teste da RFC 9961 tem endereço completo

A RFC 9961 adapta ping e traceroute para SR P2MP Policy com encaminhamento MPLS. A requisição identifica o caminho candidato e uma PTI específica, carregando Raiz, Tree-ID e Instance-ID. O resultado deixa de ser o vago “multicast funciona”.

O próprio documento delimita o que foi observado. O sub-TLV testa uma PTI dentro do caminho candidato, não o caminho candidato abstrato. A especificação se aplica a Replication-SIDs MPLS e não cobre SRv6. O escopo de respondedores pode ser reduzido para evitar processamento desnecessário.

Uma resposta positiva sustenta uma afirmação de data plane, naquele instante e naquela instância. Não prova recepção útil pela aplicação, vigência do contrato, correção do cadastro, ausência de cópias na transição, comportamento SRv6 ou autorização do controlador.

Esse limite torna OAM mais confiável. Um fato estreito pode ser unido a fatos de identidade e decisão. Um selo genérico de saúde só esconde lacunas.

Componentes do recibo de audiência

O recibo começa fora da rede: serviço e contexto, fonte autorizada de integrantes, versão, período de validade, responsável e exclusões. Depois registra a correspondência entre identificadores estáveis e endereços Leaf ou Bud. Endereço reaproveitado não deve herdar silenciosamente o direito do ocupante anterior.

Em seguida vêm <Root, Tree-ID>, a tupla <Protocol-Origin, Originator, Discriminator> do caminho, restrições, objetivo e motivo da seleção. Para as instâncias, registram-se Instance-ID antigo e novo, conjunto exato de Leaves/Buds, geração de configuração, alocação de SID e resultado de instalação por nó.

A observação contém protocolo OAM, limite MPLS quando se usa RFC 9961, PTI alvo, respondedores solicitados, horário e resultado por folha. A transição contém ordem de ativação, intervalo de coexistência, observação de duplicatas, gatilho de rollback e prova de retirada da PTI velha.

O encerramento reconcilia todas as instâncias ativas e de reserva com a população vigente, assina a decisão, fixa validade e enumera o que não foi provado. Hashes tornam substituições perceptíveis, mas não garantem legitimidade da fonte nem honestidade do sensor. Dados de audiência podem permanecer restritos; transparência pública pode usar contagens, datas e exceções.

“Recibo de audiência multiponto” é um conceito editorial deste artigo. Não é objeto definido nas RFCs nem selo de conformidade do IETF.

A remoção precisa de evidência positiva

Inclusões deixam muitos eventos: pedido, configuração, instalação, resposta. Exclusões acabam registradas apenas como ausência. Porém, remover uma audiência exige alcançar PTIs ativas, de backup e gerações parcialmente instaladas.

O fechamento deve provar que a Raiz não direciona mais tráfego à instância antiga, que seus segmentos foram removidos e que folhas excluídas não restaram nos backups. “Inativa” e “apagada” são estados diferentes.

A RFC 9960 também alerta para injeção externa quando a fronteira do domínio SR não está protegida e para loops de replicação criados por configuração incorreta, capazes de gerar tempestade até o fim do TTL ou Hop Limit. Um ping verde não prova esses controles. Eles precisam de evidência própria.

Limites e fontes

As fontes não demonstram implantação por uma operadora nomeada, inclusão indevida, duplicação real, ataque ou ganho medido. O artigo trata de arquitetura publicada e da responsabilidade local que surge na adoção. Cada ambiente pode escolher MPLS, SRv6, árvores estáticas, outro OAM ou não usar P2MP.

A conclusão é deliberadamente estreita. Tree-ID identifica a política de transporte; Instance-ID identifica uma realização; a RFC 9961 observa uma PTI MPLS. O direito de receber vem de outra autoridade e precisa ser preservado ao lado da árvore.