Resumo

  • A revisão 03 do rascunho do grupo PCE propõe negociar capacidade S-BFD em OPEN e carregar o pedido por LSP em LSPA. O PCE inicia ou atualiza; o PCC relata.
  • B=1 exige um discriminador remoto. Para B=0, o tratamento dos parâmetros diverge entre seções, e a ausência do TLV aparece apenas como alternativa sugerida por uma nota do editor.

O comando atravessa uma fronteira física

O Path Computation Element, PCE, calcula e coordena caminhos. O Path Computation Client, PCC, mantém o caminho no equipamento que pode executar a detecção de falhas. A proposta de extensão PCEP coloca a configuração de Seamless Bidirectional Forwarding Detection, S-BFD, nessa conversa. Isso abre uma opção prática para quem administra muitos LSPs. Também cria uma armadilha para painéis centralizados: o PCE pode ter enviado a instrução certa e o PCC ainda não ter aplicado a configuração que o painel anuncia.

O primeiro teste não envolve um LSP específico. Na formação da sessão, o rascunho permite que um participante envie o LSP-S-BFD-Capability TLV no objeto OPEN. Receber B=1 nessa capacidade significa que o par pode trocar os novos TLVs. Se a capacidade não chega, ou chega com B=0, o outro lado não deve enviar TLVs S-BFD no objeto LSPA em direção a esse par. A lista de tipos de estabelecimento de caminho admitidos para S-BFD também precisa estar contida na lista suportada pela sessão PCEP. Um tipo fora da lista leva a PCErr de tipo 21, valor 2, e ao encerramento da sessão. Sem um tipo em comum, o mecanismo proposto não configura S-BFD via PCEP para LSPs criados entre aqueles participantes.

É um limite de interoperabilidade, não um botão geral para toda a máquina. O PCC pode decidir por política local usar S-BFD. E a negociação bem-sucedida em OPEN não aplica S-BFD a nenhum LSP por conta própria. Ela responde se os dois lados conseguem trocar a gramática proposta. Um inventário que diz apenas “S-BFD suportado” deixa em branco a pergunta operacional: em qual caminho, com quais valores e com qual resultado?

O pedido por caminho usa outro TLV, dentro de LSPA. O PCC o envia em PCRpt; o PCE, em PCInit ou PCUpd. O B que aparece nesse LSP-S-BFD TLV tem trabalho diferente do B em OPEN. Um negocia capacidade entre participantes; o outro indica o estado solicitado para um LSP. O nome de uma flag não substitui sua posição no protocolo. Quem agrupa os dois B em uma única célula de monitoramento troca precisão por uma conveniência que acabará cobrada no plantão.

O “ligado” vem com discriminador

No TLV do LSP, B=1 pede que S-BFD seja aplicado ao caminho. O rascunho exige, nesse caso, um sub-TLV com o discriminador remoto e propõe erro se ele faltar. Há ainda um sub-TLV opcional com intervalo mínimo de transmissão e multiplicador de 1 a 255. Assim, o registro útil da solicitação não termina em “enviado B=1”. Ele inclui o discriminador e os parâmetros que o receptor recebeu. Uma configuração pedida sem o valor obrigatório não vira válida só porque o controlador pintou seu ícone de verde.

O caminho de volta precisa ser lido com a mesma disciplina. A seção 4.3.2.1 diz que B=0 remove S-BFD em uma atualização feita pelo PCE ou impede sua aplicação em um LSP iniciado pelo PCE. A seção 4.2 manda o PCC ignorar uma atualização B=0 caso não houvesse S-BFD aplicado àquele caminho. Para um caminho iniciado pelo PCC, o PCE pode ignorar um B=0 na mesma situação. O ato de pedir a remoção e a remoção de algo que estava funcionando são acontecimentos diferentes. Um deles está na mensagem; o outro está no estado do equipamento.

Onde o texto fica realmente caro é no sub-TLV de parâmetros enviado junto com B=0. A seção 4.2 diz que o participante pode ignorá-lo e que ignorar ou guardar a configuração cabe à implementação. A seção 4.3.2.2 diz que ele deve ignorá-lo. Em seguida, uma nota do editor propõe uma alternativa: se o LSP-S-BFD TLV não for recebido, retirar S-BFD do LSP que já o tinha. A nota não é uma regra escolhida. Um B=0 explícito e a ausência total do campo são eventos diferentes no fio. Transformar ausência em ordem exige uma decisão comum, não um palpite do software de gestão.

O rascunho também define recusas que dão pistas melhores que um ícone vermelho. Um participante que recebe o TLV por LSP sem ter recebido a capacidade do par deve ignorar o conteúdo e devolver PCErr de tipo 19. Multiplicador fora de 1 a 255 leva a erro de tipo 23. Os novos valores e os tipos de TLV solicitados à IANA permanecem como TBD na própria seção de atribuições. O motivo do erro pode ser identificado; os números futuros ainda não devem ser vendidos como códigos registrados.

Há outra fronteira no grupo de associação. A seção 6 observa que algumas implementações exigem os mesmos parâmetros S-BFD para LSPs do mesmo grupo. Se intervalo mínimo, multiplicador ou discriminador remoto diferirem, o participante deveria retornar erro de associação de tipo 26. O qualificador importa. Ele descreve uma limitação possível em produtos concretos, não uma obrigação universal para qualquer grupo no protocolo. Um controlador pode montar uma combinação que seu modelo aceita e o PCC local rejeita. Para descobrir qual regra venceu, é preciso ler a resposta, não adivinhar a partir da intenção central.

RFC 7880 apresenta o mecanismo S-BFD. RFC 8231 e RFC 8281 dão o contexto do PCEP com estado e de LSPs iniciados pelo PCE; RFC 9050 descreve o PCE como controlador central. Esses documentos explicam a arquitetura em que uma ordem remota faz sentido. A extensão de S-BFD continua sendo um rascunho. A revisão 02 e a 03 diferem em data, validade e numeração, sem resolver os verbos conflitantes da desativação. A capa nova não reescreveu o botão.

Uma avaliação operacional precisa acompanhar o mesmo LSP em seis pontos: capacidade OPEN, tipos de caminho em comum, PCInit ou PCUpd enviado pelo PCE, PCRpt do PCC, configuração efetiva e estado da sessão S-BFD. A primeira dupla permite a conversa. A mensagem mostra a solicitação. O relatório mostra a versão do PCC. Os dois últimos pontos mostram o que a máquina aplicou e está executando. Uma conclusão sobre a saúde do caminho precisa de observações próprias. O controlador, sozinho, sabe apenas o que ordenou.

As fontes oficiais aqui reunidas não trazem uma captura de interoperabilidade que ligue uma mensagem B=0 ou B=1 a relatório, configuração e sessão de um PCC identificado. Uma captura com esses quatro registros resolveria a questão para aquela implementação. O texto comum ainda precisa resolver a questão para todas as implementações: ignorar parâmetros é escolha ou dever, e omitir o TLV é silêncio ou ordem de retirada?

Fontes