Resumo

  • O RFC 10018 anuncia um P-tunnel SR P2MP com <Root, Tree-ID> e usa rotas A-D de MVPN ou EVPN para descobrir folhas. Isso prova um estado delimitado do plano de controle; não prova que o controlador instalou um PTI completo nem que todas as folhas receberam o serviço correto.
  • Um encerramento defensável compara, na mesma candidate path e no mesmo Instance-ID, as folhas previstas, anunciadas, aceitas, instaladas, presentes no forwarding, responsivas ao OAM e confirmadas pelo payload. A remoção de uma folha só termina após retirada, desprogramação e quiescência verificadas.

O checklist pode estar completo e o serviço, não

Uma janela de mudança costuma terminar com perguntas binárias: o anúncio subiu? O controlador aceitou? A árvore está ativa? O tráfego voltou? Em P2MP, todas podem receber “sim” enquanto uma folha não recebe nada.

A razão está na própria eficiência do desenho. A Root injeta uma unidade; os nós intermediários geram cópias; várias folhas compartilham grande parte do caminho. Se onze de doze destinos funcionam, o volume agregado, os contadores da Root e a maioria dos testes continuam convincentes. A folha ausente vira um detalhe estatístico, embora possa ser o destino mais crítico.

RFC 10018 organiza esse ambiente. O documento define P-tunnels realizados por instâncias P2MP de Segment Routing para MVPN e EVPN, tanto em SR-MPLS quanto em SRv6. Ele também descreve ingress replication sobre SR, que segue outra cadeia de execução. As rotas BGP Auto-Discovery ligam a associação do serviço ao conjunto de folhas de uma SR P2MP Policy.

O padrão, corretamente, não declara que a sinalização executa todo o sistema. Ele deixa fora de escopo os procedimentos concretos usados pelo módulo de política para acionar o controlador e programar nós. Essa fronteira impede que um sucesso local se aproprie do resultado de todos os demais.

Um identificador comum não transforma vários bancos de estado em um só

O PMSI Tunnel Attribute de um P-tunnel SR P2MP carrega o identificador <Root, Tree-ID>. O Tree-ID é um inteiro sem sinal de 32 bits, único no contexto da Root, e aparece antes do endereço da Root na codificação. A IANA registra 0x0C para SR-MPLS P2MP Tree e 0x0D para SRv6 P2MP Tree.

O par identifica a Policy. Não identifica sozinho a encarnação de forwarding. Conforme o RFC 9960, uma Policy pode ter várias candidate paths. Uma candidate pode ter zero PTIs se o controlador não conseguir calcular uma árvore que satisfaça as restrições. Durante make-before-break, pode ter mais de um PTI, mas apenas um deve estar ativo. Duas instâncias ativas podem duplicar tráfego nas folhas.

Cada PTI possui um Instance-ID de 16 bits. Seus Replication segments são relacionados, no controle, a Root, Tree-ID, Instance-ID e Node-ID. Isso permite distinguir a Policy duradoura de cada topologia calculada e programada.

Sem o Instance-ID, o OAM da árvore antiga pode ser atribuído à nova. Um reconhecimento atrasado de instalação pode fechar a mudança errada. Após reutilização de identificadores, pacotes atrasados e registros antigos podem parecer atuais. O dashboard precisa preservar identidade e época, não apenas um nome amigável.

A-D responde quem se apresentou, não quem recebeu

Em MVPN, a importação da Intra-AS I-PMSI ou Leaf A-D aplicável acrescenta um PE de saída ao conjunto de folhas da entrada; a retirada da rota o remove. O PE de saída entra como Leaf ou Bud ao importar o anúncio relevante e origina uma Leaf A-D quando a flag Leaf Information Required exige.

No EVPN, IMET, S-PMSI e Leaf A-D cumprem a função correspondente. A criação e a remoção da candidate path acompanham a origem e a retirada das rotas que anunciam o P-tunnel.

Esse ciclo é observável, mas ainda não é o plano de dados. O módulo MVPN/EVPN atualiza a SR P2MP Policy e entrega a candidate path e as folhas ao controlador por PCEP, BGP, NETCONF ou outro meio. O RFC 10018 menciona as opções e delimita o mecanismo como fora de escopo.

Há, então, pelo menos três listas: os egress esperados pelo serviço, os egress presentes em A-D e as folhas consumidas pelo controlador. Elas podem ter a mesma quantidade e membros diferentes. Uma folha retirada pode permanecer na revisão do controlador; uma folha nova pode estar no BGP e ausente no cálculo; um destino exigido pelo contrato pode nunca ter passado pela política de importação.

O registro correto inclui versão e horário de cada lista. leaf_count=12 é insuficiente. É preciso saber quais doze, sob qual revisão e qual PTI recebeu essa revisão.

A falha de um Replication segment precisa aparecer como estado de primeira classe

O RFC 9960 prevê instalação bem-sucedida e falha. Um nó deveria informar a confirmação. Um conflito de Replication-SID, por exemplo, pode impedir a instalação, e o nó deveria informar a causa. O controlador deveria tentar novamente com limite, alertar após a falha terminal e pode desmontar o PTI quando alguns segmentos falham. Se a falha está na Root, a desmontagem é recomendada.

Portanto, “calculado”, “enviado”, “aceito por alguns”, “aceito por todos”, “programado no FIB”, “ativado na Root” e “testado por folha” são estados diferentes.

Uma sequência apresentada no RFC 9960 instala primeiro folhas e nós intermediários. Depois das confirmações, instala a Root e pode ativar a instância. A Root funciona como última comporta. O texto não comprova que um controlador específico aplique essa ordem; fornece uma expectativa que o comprador pode exigir ou rejeitar conscientemente.

O status agregado só é útil se houver uma regra verificável por trás dele. A operação precisa de Node-ID, Replication-SID, revisão solicitada, confirmação ou rejeição, motivo, tentativas e estado terminal. ACTIVE sem esse detalhamento é um rótulo de interface.

Chegar ao PE correto ainda não define a entrega correta

O Tree-SID identifica o PTI no plano de dados. A Root encapsula, os nós de provedor replicam e a folha remove o Tree-SID. Quando um P-tunnel é dedicado a uma única MVPN, esse identificador pode bastar para descobrir o contexto. Quando a árvore é compartilhada, um label MPLS atribuído upstream ou um SRv6 Multicast Service SID separa os serviços.

O RFC 10018 define End.DTMC4, End.DTMC6 e End.DTMC46, registrados pela IANA como 76, 77 e 78, e estabelece condições de transposição em SRv6. Um pacote pode percorrer a árvore certa e falhar na consulta da tabela multicast, na formação do service SID ou no vínculo local com a MVPN.

O EVPN acrescenta o split horizon para Ethernet Segments multihomed. O objetivo é evitar tráfego BUM duplicado. Em SR-MPLS, o label ESI precisa ocupar a posição correta; em SRv6, Arg.FE2 participa do comportamento End.DT2M. Uma folha que recebe duas cópias indevidas não está saudável só porque “recebeu”.

Por isso, o canário final deve carregar contexto: PTI, folha, MVPN/EVI, identificador de serviço, expectativa de cópias e resultado do payload. O Tree-SID é uma instrução de forwarding, não uma autorização de tenant nem um recibo do aplicativo.

Ingress replication é um modo distinto, não um PTI simplificado

Na ingress replication, o PE de entrada cria uma cópia por saída e usa forwarding unicast. O módulo SR P2MP Policy e o controlador não participam. A prova passa pela associação do egress, pelo identificador de serviço, pela policy unicast/SR-TE e pela cópia individual.

No P2MP, a prova passa pelo controlador, pelo PTI, pelos Replication segments e pelo OAM de árvore. A engenharia de tráfego também muda: em IR, os casos previstos podem usar tratamento por egress; no PTI, a replicação ocorre dentro da árvore, então a entrada dita um tratamento para o conjunto.

Se uma recuperação troca P2MP por IR, o evento precisa registrar o instante em que a Root parou de injetar, quando as cópias individuais começaram, a eventual sobreposição e quando o estado P2MP foi removido. Restaurar sem registrar a fronteira pode produzir duplicação.

OAM deve apontar para a instância, não para uma ideia de árvore

RFC 9961 define ping e traceroute para uma candidate path e um PTI específicos. Os probes seguem os Replication segments e obtêm respostas das folhas. Uma implementação deveria permitir teste por candidate e por PTI, inclusive inativo.

Isso importa no make-before-break: a resposta da instância antiga não valida a nova, ainda que Root e Tree-ID sejam iguais. O resultado deve armazenar Instance-ID, conjunto esperado, horário e resposta de cada folha.

Quando Replication segments não são adjacentes, o OAM P2MP testa a estrutura de replicação e o OAM unicast precisa testar o caminho que os conecta. O RFC 9961 deixa essa detecção unicast fora do seu próprio escopo. Um resultado não substitui o outro.

O probe ainda não é a aplicação. Ele não prova o service SID de produção, a perda, o jitter, o split horizon nem o consumo do conteúdo. É necessário um canário de payload por folha: sequência conhecida, marca de conteúdo verificável, contador ligado ao contexto ou confirmação aplicativa, sempre relacionado à mesma época do PTI.

O fechamento pode ser expresso como conjuntos

Uma operação madura mantém:

  • E: saídas exigidas pelo serviço;
  • A: saídas presentes em A-D/Leaf A-D;
  • C: folhas aceitas pelo controlador na candidate atual;
  • I: folhas com caminho completo de Replication segments instalado no PTI;
  • F: folhas presentes no forwarding da instância ativa;
  • O: folhas que respondem ao OAM da candidate e Instance-ID exatos;
  • D: folhas que recebem o payload no contexto MVPN/EVI correto;
  • W: folhas removidas com retirada, desprogramação e quiescência provadas.

Um serviço estrito pode exigir E = A = C = I = F = O = D. Se admite subconjunto, precisa nomeá-lo e registrar dono, motivo, impacto, vencimento e condição de retorno. A saída termina quando a folha deixou os conjuntos ativos e entrou em W.

As diferenças encaminham o incidente: E − A aponta para provisionamento/A-D; A − C, para ingestão do controlador; C − I, para instalação; I − F, para a validade do reconhecimento; F − O, para o caminho; O − D, para contexto ou aplicação.

Comparar apenas tamanhos produz falsos positivos. Doze respostas, uma delas de uma folha antiga, não cobrem doze destinos atuais.

O que as fontes não autorizam afirmar

Os RFCs e registros sustentam o desenho técnico. Não demonstram implantação por uma operadora, suporte integral de um produto, prevalência, conformidade atual ou um incidente real igual ao exemplo.

Um código IANA comprova significado atribuído, não implementação. Standards Track não é ordem de adoção. A IETF define semântica comum, mas não controla o PTI de uma rede.

A separação é coerente com a primazia do código em execução de Lu Heng: a alegação institucional precisa responder ao efeito observável. A especificação inicial mínima e decisão futura localizada preserva a outra metade: os operadores mantêm a decisão de adotar, tolerar parcialidade e assumir risco.

O estado em execução tampouco é automaticamente correto. Uma folha retirada que continua recebendo é um fato — e justamente o fato que demonstra falha da autoridade de retirada.

Fontes