Resumo

  • O rascunho do grupo SPRING põe 200 Mbps sobre duas Segment Lists de capacidade máxima presumida de 100 Mbps cada. Se uma falha, o critério recomendado pela RFC 9256 ainda pode declarar CP1 válido: uma lista continuou viva, mas a conta da capacidade deixou de fechar.
  • O texto propõe um número mínimo de listas válidas e uma soma mínima de seus pesos. O operador ganha uma maneira de retirar CP1 da seleção antes da perda total; precisa manter os limites coerentes com a carga e com a capacidade que realmente possui.

A placa diz aberto; a ponte perdeu metade

O caminho CP1 do exemplo publicado pelo grupo SPRING parece confortável no primeiro quadro. Duas Segment Lists, SL1 e SL2, dividem igualmente uma carga de 200 Mbps. Cada uma tem peso 1 e capacidade máxima presumida de 100 Mbps. O hash por fluxo manda metade para cada lado. Quando uma lista deixa de ser válida, a sobrevivente não vira uma rota de 200 Mbps. Mesmo assim, CP1 pode continuar ativo pelo critério recomendado na RFC 9256: ao menos uma lista constituinte continua válida.

Há uma diferença entre ter uma saída e ter a largura necessária. A arquitetura responde à primeira pergunta. A equipe que prometeu transportar a carga responde pela segunda. Se o painel mostra apenas «válido», as duas respostas se misturam em uma palavra conveniente. No exemplo, essa conveniência custa 100 Mbps de capacidade presumida exatamente quando o tráfego mais precisa dela.

A SR Policy POL1 tem CP1 e CP2. CP1 vence pela preferência mais alta enquanto for válido. Pela RFC 9256, um candidato explícito se torna inválido quando já não possui nenhuma Segment List válida. A perda de uma lista pode, portanto, manter CP1 à frente de CP2. O rascunho não informa quanta capacidade CP2 possui. Tampouco oferece uma medição do resultado após uma eventual troca. A política de contingência não pode ser deduzida do simples nome da alternativa.

Dois limites para uma decisão mais cedo

O primeiro parâmetro novo é o número mínimo de Segment Lists válidas, em oito bits. Configure 2 no exemplo e CP1 perde a validade quando SL1 ou SL2 cai. O valor 0 elimina a exigência adicional de contagem; 0xff exige que todas permaneçam válidas. O segundo parâmetro, de 32 bits, é o peso cumulativo mínimo das listas ainda válidas. Se ambas pesam 1, o mínimo 2 também reprova CP1 quando uma cai e a soma chega a 1. Zero elimina a exigência de peso; 0xffffffff exige todas as listas. Os dois testes têm de ser satisfeitos quando configurados. Com ambos em zero, vale o mecanismo da RFC 9256.

Contar listas facilita a auditoria e ignora diferenças de largura. Duas listas vivas podem não ter capacidade equivalente. Somar pesos aceita mais nuance, mas peso é uma medida relativa de distribuição de tráfego, não um medidor em Mbps. A correspondência entre peso 1 e 100 Mbps funciona porque os autores a estabelecem para este exemplo. Se o limite físico muda e os pesos ficam congelados, uma soma de 2 pode passar no teste e fracassar diante da carga real. O valor precisa de uma história: que capacidade ele representa, quando foi revisto e quem aprovou a hipótese.

O rascunho permite que o headend receba os parâmetros por configuração, PCEP ou BGP. As extensões específicas de protocolo ficam para outro documento; não há pedido de alocação à IANA neste. Isso deixa aberta uma escolha operacional importante. O controlador pode recomendar uma cifra, mas o operador que vende ou depende da capacidade tem de definir a tolerância. E precisa comparar a cifra pretendida com a efetivamente instalada no headend. Uma divergência entre 2 e 0 altera o momento em que CP1 sai de cena.

A palavra inválido muda de andar

As regras de resolução e verificação da RFC 9256 podem invalidar uma Segment List. Outra lista válida pode manter o candidato CP1 em jogo. A SR Policy inteira só fica inválida quando todos os candidatos ficam inválidos. Uma mudança de validade manda executar novamente a seleção; o candidato válido de maior preferência pode assumir. O novo limite atua entre a falha da lista e a falha da política. Sua função é remover cedo o candidato que já perdeu a capacidade presumida, não declarar que a política toda morreu.

Por isso a discussão difere do comportamento opcional Drop-Upon-Invalid, que trata uma SR Policy já inválida. O momento desconfortável vem antes: CP1 ainda tem uma lista viva e conserva o rótulo verde, enquanto a carga do exemplo já não cabe na capacidade daquela lista. Tornar CP1 inválido abre a seleção para CP2; não prova que CP2 suporta os 200 Mbps. Uma substituição segura exige sua própria conta.

O rascunho não oferece rastros de uma implantação, medições de congestionamento ou histórico de limiares em produção. Para medir um efeito real seria preciso juntar esses registros à capacidade dos caminhos e à carga observada. A evidência atual mostra um desencaixe lógico e dois controles propostos, não uma falha atribuída a uma rede específica.

Quem assinou o número?

Um registro útil da falha de SL1 mostraria a carga atribuída a CP1, o estado de cada lista, a contagem e a soma dos pesos ainda válidos, os limites aplicados e o sistema que os forneceu. Se a capacidade mudar, a revisão do peso e do limite também deve aparecer. O operador então consegue distinguir uma decisão correta do headend de uma hipótese antiga embutida nos parâmetros. O indicador verde volta a ser uma observação delimitada, em vez de uma promessa sem assinatura.

Fontes