Resumo

  • O rascunho individual de 28 de outubro propõe dois tipos de TLV PCEP FlowSpec para examinar a estrutura de SIDs SRv6 comuns e comprimidos. As duas pontas precisam anunciar uma nova capacidade S antes de trocar essas regras.
  • O PCC deve responder com PCErr tipo 30 se a capacidade não foi negociada ou se o componente é malformado. O valor exigido é TBD_EV, ausente das solicitações à IANA. O registro atual já separa “não suportado” de “malformado”.

Um comando minucioso encontra um campo em branco

O novo texto aproxima o controlador PCE do conteúdo de um endereço IPv6. Um TLV permite casar locator, função e argumento de um SID SRv6 convencional. O outro trata os campos de um contêiner de SID comprimidos. É uma instrução mais fina do que olhar o endereço de destino inteiro: o controlador especifica o recorte e o cliente PCEP no roteador aplica a seleção ao tráfego.

Para entrar, a regra precisa de consentimento técnico dos dois lados. PCE e PCC anunciam o bit S durante a abertura da sessão. Somente com as duas declarações os novos TLVs podem circular. O PCC também confere se a soma dos comprimentos dos campos declarados cabe em 128 bits. Uma soma acima desse limite torna a estrutura inválida. São verificações locais que dão ao roteador uma forma objetiva de impedir uma ordem que não entende ou que não cabe no endereço.

O texto tropeça justamente na resposta. A seção 5.2 obriga o PCC a enviar PCErr de Error-Type 30 com Error-Value TBD_EV para uma regra não negociada ou malformada. Na seção 7, o pedido à IANA cobre o bit S e os dois números de TLV. Não cobre esse Error-Value. O registro oficial de PCEP atribui os valores 1 a 5 ao tipo 30 e deixa 6 a 255 livres. Portanto, a instrução “envie TBD_EV” ainda não se traduz em um número de protocolo comum.

O próprio alicerce da proposta oferece uma escolha. A RFC 9168 usa valor 1 para FlowSpec não suportado e valor 2 para FlowSpec malformado. O rascunho SRv6 reúne as duas causas sob um nome só. Seus autores podem manter a distinção com 1 e 2 ou registrar um valor específico que una as situações. Falta decidir e escrever a decisão tanto na regra de erro quanto, se houver número novo, no pedido de alocação.

Essa distinção muda a fila de trabalho de uma equipe de rede. Uma resposta de função não suportada pede revisão do inventário de capacidades daquele roteador. Uma resposta de regra malformada manda examinar o gerador da política e seus comprimentos de campo. Se a automação recebe um número inventado, pode repetir uma ordem que o equipamento nunca aceitou ou culpar o equipamento por um pacote de controle mal construído. O recibo de erro orienta a correção seguinte.

Num teste entre fornecedores, o defeito mais revelador seria uma regra rejeitada. O controlador precisa saber se esbarrou numa capacidade ausente ou se mandou um mapa de campos defeituoso. Se cada implementação inventar um número provisório, a função de segurança local vira um retorno opaco. A recusa acontece; o recibo não viaja de maneira confiável.

O Datatracker registra esta versão como Internet-Draft individual. Uma próxima versão que nomeie os valores existentes ou solicite outro à IANA resolverá a lacuna. O critério para ler a correção é simples: o número exigido na seção 5.2 precisa existir na especificação e no registro correspondente.

Fontes