Resumo

  • draft-ietf-pce-flexible-grid-17 foi publicado em 13 de setembro de 2026, ainda em IESG Evaluation para Proposed Standard e pautado para a teleconferência de 17 de setembro.
  • A revisão 16 propunha duas entradas sob o PCEP Error-Type 24, chamado no texto de Routing Problem; no registro vigente da IANA, 24 significa LSP instantiation error.
  • Um DISCUSS observou que PathErr e Error Code são termos de RSVP-TE. A revisão 17 eliminou as duas regras e o pedido de alocação, mas preservou um Error-Type novo e separado para incapacidade de calcular RSA.
  • A correção evita que um número carregue duas autoridades. Como também retira dois sinais do fio, registros de implementação precisam conservar versão, mensagem, condição e significado.

O formulário de alfândega com dois produtos no mesmo código

Um código aduaneiro não funciona porque o número “parece” adequado. Ele funciona porque uma tabela pública vincula número, categoria e procedimento. Se um manual local usa o mesmo código para outra mercadoria, o desembaraço deixa de ser interoperável mesmo que os dois documentos estejam bem escritos.

A revisão 16 de PCEP Extension for Flexible Grid Networks produzia o equivalente no plano de controle. O documento define objetos e TLVs para que um Path Computation Client peça a um Path Computation Element uma rota e uma faixa de espectro óptico. O pedido pode indicar simetria e um método de seleção, como First-Fit ou Random.

Caso o PCE não suportasse a simetria ou o método, a revisão 16 mandava gerar um PathErr com Error Code 24, Routing Problem, usando um de dois subcódigos novos. A seção 9.9 solicitava que a IANA registrasse essas entradas sob o Error-Type 24 de PCEP.

Só que o registro PCEP da IANA já associa o tipo 24 a LSP instantiation error, conforme a RFC 8281. A especificação-base RFC 5440 chama a mensagem de erro PCEP de PCErr e seus campos de Error-Type e Error-value. PathErr, Error Code e Routing Problem são vocabulário de RSVP-TE. O defeito ligava a semântica de um protocolo ao número ocupado de outro namespace.

Em 9 de setembro, o Routing Area Director Gunter Van de Velde registrou a colisão em um DISCUSS. O histórico no Datatracker mostra ainda perguntas sobre formato, contêiner e posição do Spectrum Allocation TLV e sobre o valor zero e a política de futuras alocações. Outro DISCUSS, de Mohamed Boucadair, tratou de exceções de política, tamanho fixo, parsing de identificadores de enlace, descoberta e política do registro. São questões formais a resolver; não são uma decisão antecipada contra o documento.

A revisão nova deixa um vazio deliberado

Na revisão 17, o parágrafo que prescrevia as duas respostas PathErr foi retirado. A seção 9.9 e sua tabela também sumiram. O diff oficial não mostra realocação para outro número. As duas respostas específicas deixaram de integrar o contrato desta versão.

Permanecem sinais diferentes. O rascunho ainda pede um novo Error-Type, sem número definitivo, chamado Flexi-Grid RSA Error, com Error-value 1 para RSA computation not supported; a revisão 17 acrescenta o valor 0 como Unassigned. Um bit separado de NO-PATH-VECTOR informa que nenhum caminho satisfez todas as restrições de espectro. Não saber calcular RSA, calcular sem achar rota viável e recusar um atributo são fatos operacionais distintos.

Outras mudanças respondem a comentários objetivos. O Frequency Slot Selection TLV passa a ter comprimento obrigatório de quatro. O índice n pode ser positivo, negativo ou zero. O Label Set deve ser devolvido quando não houver erro de política ou validação. A Inclusive Range contém exatamente dois registros de identificador de enlace. O texto usa o nome ERO Hop Attributes subobject da RFC 7570, e a seção de segurança inclui a atualização TLS da RFC 9916.

Isso não autoriza declarar todos os DISCUSS resolvidos. O exame também pediu regras de colocação, ordenação, associação, modificação e limite de tamanho do TLV. Corrigir o nome de um contêiner não prova que toda essa lista foi atendida. O que a evidência sustenta é mais restrito: o conflito do tipo 24 foi removido e o estado de revisão da IANA voltou de IANA OK - Actions Needed para Version Changed - Review Needed.

A agenda não é o resultado da reunião

O registro no Datatracker mantém o texto como documento do PCE Working Group enviado ao IESG para Proposed Standard. A API marca a revisão 17 às 09:57:08 UTC de 13 de setembro. O estado continuava IESG Evaluation e a teleconferência estava agendada para o dia 17. Nova versão não remove DISCUSS automaticamente, não aprova o rascunho nem entrega códigos finais.

A IANA voltou a examinar as ações porque elas mudaram. Version Changed - Review Needed não significa rejeição. A RFC 8126 define políticas de registro possíveis, mas o processo ainda precisa fixar qual política regerá cada espaço novo.

Também mudou a explicação sobre descoberta. A revisão 16 dizia evitar uma nova capability de PCEP OPEN mediante uma abordagem por erros, ao mesmo tempo que citava a descoberta OSPF e IS-IS das RFC 5088 e RFC 5089. A revisão 17 apaga a defesa da abordagem por erro e mantém que a descoberta pode anunciar capacidade Flexi-Grid RSA. É uma correção textual, não uma medição de redes implantadas.

A Última Chamada também apontava a declaração IPR 3053. Ela é uma notificação processual, não uma conclusão sobre validade, essencialidade, infração, necessidade ou preço de licença.

Um recibo para o código que entrou e para o que saiu

Quando um diagnóstico é criado, movido ou removido, o histórico mínimo deve guardar o conjunto anterior — protocolo, mensagem, Error-Type, Error-value e condição —, a linha vigente do registro, a objeção de revisão e o novo conjunto ou a remoção explícita. Hashes dos rascunhos, versão do software, teste em pacote, estados da IANA e do ballot e data de ativação fecham o vínculo com a operação.

Essa é minha recomendação editorial, não uma norma do IETF. O Policy Mirror de Heng Lu mostra por que texto atual, cópia implantada e caminho de execução precisam estar juntos. Uma especificação inicial mínima pode padronizar o recibo sem centralizar a política do operador. E a disciplina de realidade, não defesa de causa impede confundir mudança no documento com incidente comprovado.

Não há falha pública de interoperabilidade nem captura mostrando esses dois erros em produção. A notícia é a intervenção verificável do processo antes da aprovação: a colisão foi encontrada e o contrato proposto mudou.

Fontes