Resumo

  • O ingresso solicita bloqueio e teste direcionado, mas não estabelece sozinho o estado resultante.
  • O egresso confirma o bloqueio; o nó-alvo, seja o egresso ou um nó intermediário, valida o bit A e a identidade explícita.
  • A LSP não pode ser desbloqueada antes da saída confirmada do loopback; Resv, RRO Hop Attributes e erros OAM Problem devem ser correlacionados.

Como a autoridade é distribuída

Para solicitar o bloqueio, o ingresso envia uma mensagem Path com o bit A e o bit Reflect de ADMIN_STATUS definidos. O egresso tenta retirar a LSP do serviço do cliente. Se conseguir, retorna Resv com A definido; se falhar, retorna OAM Problem / Lock Failure, e as mensagens Resv subsequentes mantêm A limpo. Enquanto a LSP estiver bloqueada, Path e Resv subsequentes devem manter A. Para desbloquear, o ingresso limpa A no Path. O sucesso aparece em Resv com A limpo; a falha produz OAM Problem / Unlock Failure e os Resv seguintes mantêm o estado bloqueado.

Com o bloqueio confirmado, o ingresso pode pedir loopback no egresso ou em um nó intermediário. RFC 7570 ERO Hop Attributes fornece o mecanismo de endereçamento por salto. O alvo, porém, não executa apenas porque o ingresso pediu: primeiro verifica se A está definido. Se não estiver, deve ignorar o pedido. Depois verifica se o subobjeto ERO imediatamente anterior a ERO Hop Attributes identifica explicitamente a entidade de loopback desejada. Sem essa identidade, ou com identidade ambígua, o pedido deve ser ignorado e pode gerar Bad EXPLICIT_ROUTE.

Para identificadores de prefixo IPv4 e IPv6, a validação exige, respectivamente, comprimento de host de 32 e 128 bits. Um /24 ou /64 não é uma identidade de host válida para essa finalidade. Quando o item anterior é um label subobject, o bit U seleciona a direção do loopback. Essas são regras de validação do protocolo, não uma afirmação de que qualquer implantação utiliza esses recursos da mesma maneira.

RFC 6435 é a base funcional para bloqueio e loopback: o bloqueio retira o caminho de transporte do serviço do cliente, embora possa permitir OAM e tráfego de teste; o loopback devolve os dados de teste recebidos para que o originador valide a integridade do caminho. RFC 7570 carrega o endereçamento e a evidência por salto. Não deve ser confundido com a sequência de autorização definida por RFC 7571. RFC 5420 trata do processamento de flags de atributos, RFC 3473 fornece o contexto de ADMIN_STATUS e RFC 7260 fornece a base dos valores OAM Problem usados por RFC 7571.

Loopback é o bit 13 de Attribute Flags em Path e RRO Attributes, não em Resv. Quando o loopback funciona e o nó adiciona um subobjeto RFC 7570 RRO Hop Attributes, ele define o Loopback flag e mantém A. Uma falha gera OAM Problem / Loopback Failure. O bit 13 não é o bit A de ADMIN_STATUS: um sinaliza o estado de loopback solicitado ou reportado, enquanto o outro sinaliza o estado de bloqueio. Nenhum deles é um erro OAM Problem. Para sair do loopback, o ingresso limpa o Loopback flag e conserva A. O sucesso é reportado com o flag limpo no RRO; a falha produz Exit Loopback Failure.

O ingresso não deve pedir desbloqueio durante o loopback, e o egresso deve ignorar esse pedido.

Beneficiários e custos

O beneficiário operacional é a equipe de OAM, que pode isolar a integridade do caminho até um nó nomeado, enquanto o tráfego do cliente fica retido e o tráfego de teste é deliberadamente devolvido. O custo é uma condição coordenada fora de serviço, com várias transições ordenadas e resultados de falha distintos. O RRO pode revelar informações sobre nós que uma política de fronteira considera confidenciais. Portanto, não se deve presumir que todos os domínios exponham o estado de loopback sem filtragem.

Os fatos normativos devem permanecer separados da análise e do desconhecido. O conjunto de fontes não informa quais fornecedores ou operadores implementam o sinal de bloqueio ou loopback. Também não fornece prevalência de implantação, duração de indisponibilidade, taxa de falhas, latência, impacto de cliente ou valor comercial. Não escolhe janela de manutenção, padrão de teste, limiar de aceitação nem decisão de restauração. A página de errata congelada é apenas o snapshot atual da busca de errata de RFC 7571; o pacote não faz uma alegação adicional de correção.

Fixtures de verificação L3

  1. Fixture de bloqueio: capture o Path de entrada com A=1 e Reflect=1 e o Resv de saída com A=1. Sem a confirmação A=1 no Resv, não promova o estado a LOCKED e não trate o loopback como autorizado.
  2. Fixture de identidade: coloque no ERO um identificador IPv4/32 ou IPv6/128, seguido imediatamente por ERO Hop Attributes RFC 7570. Teste também /24, /64 e a ausência do subobjeto explícito; os casos inválidos devem ser ignorados ou produzir Bad EXPLICIT_ROUTE.
  3. Fixture de direção: execute label subobject com U=0 e U=1 e confirme a direção selecionada. Não transforme esse resultado em alegação universal de implantação.
  4. Fixture de sucesso: com A=1, faça o alvo devolver o tráfego de teste e definir Loopback bit 13 em RRO Hop Attributes. Depois limpe somente o bit de loopback, mantenha A=1, confirme o flag limpo no RRO e só então envie o pedido de desbloqueio.
  5. Fixture de erro: injete separadamente Lock Failure, Loopback Failure, Exit Loopback Failure e Unlock Failure. Correlacione o OAM Problem, o A no Resv e o flag no RRO; nenhum sinal isolado substitui a cadeia completa.
  6. Fixture contrafactual: tente loopback com A=0, com alvo ambíguo, após falha de loopback, após falha de saída e desbloqueio antes da saída. Em cada caso, confirme que o próximo estado não é inferido nem avançado automaticamente.

Fontes