Resumo

  • XRO (Exclude Route Object) vale para o caminho inteiro; EXRS (Explicit Exclusion Route Subobject), dentro de um ERO, vale para um segmento delimitado.
  • No XRO, o bit L limpo significa MUST exclude; o bit L definido significa SHOULD avoid. A segunda forma ainda pode permitir o uso local do recurso.
  • Diversidade é um resultado a verificar no caminho calculado e no caminho observado, não uma promessa transportada por um sinalizador.

O mecanismo e seus limites

O RFC 3209 usa o Explicit Route Object para incluir nós abstratos em um caminho RSVP-TE. O RFC 4874 acrescenta sinalização de exclusão para situações em que a origem não precisa calcular a rota completa na entrada. Um XRO pode identificar prefixos IPv4 ou IPv6, interfaces não numeradas, sistemas autônomos e Shared Risk Link Groups; as formas de prefixo e interface podem distinguir atributos de interface, nó e SRLG. O XRO descreve exclusões para o caminho inteiro. O EXRS fica dentro de um ERO e limita uma parte desse caminho. Portanto, uma proibição global e uma proibição limitada a um segmento não são equivalentes.

Ao escolher um próximo salto ou expandir uma rota explícita frouxa, o nó não deve introduzir recursos cobertos por exclusões obrigatórias e deve minimizar recursos marcados apenas para evitar. Se um XRO obrigatório contradiz uma inclusão no ERO, a exclusão prevalece: a mensagem Path deve ser rejeitada e o erro Routing Problem definido deve ser retornado. Isso não transforma o XRO no autor da rota restante; ele apenas remove candidatos. Se as regras eliminarem todas as opções de encaminhamento, o nó deve retornar um PathErr indicando que a rota foi bloqueada pelo Exclude Route.

Uma implementação ou política também pode rejeitar um XRO complexo demais, com um PathErr específico. Um nó que não suporta XRO pode encaminhá-lo sem inspeção por causa do número de classe do XRO; subobjetos ou atributos não suportados também podem ser ignorados. Assim, a passagem da mensagem não comprova a aplicação da restrição. O Record Route permite ao nó de computação observar violações e tentar novo cálculo. Ele é uma ferramenta de verificação, não uma substituição para o suporte ao objeto.

Domínios, camadas e identificadores

Ao atravessar domínios de computação, exclusões podem ser acrescentadas, removidas ou se tornar irrelevantes quando são resolvidas no domínio ou quando seu escopo muda. O RFC 6001 atualiza o RFC 4874 para GMPLS em múltiplas camadas e regiões, acrescentando subobjetos de exclusão de capacidade de comutação e de rótulos. A diferença entre excluir obrigatoriamente e apenas evitar é preservada. Isso amplia a precisão da restrição entre camadas, mas também aumenta o custo de compatibilidade, de sinalização e de tratamento nas fronteiras.

O RFC 8390 acrescenta subobjetos de diversidade para XRO e EXRS. Eles podem apontar para um identificador de LSP ou caminho de referência atribuído pelo cliente, pelo PCE ou pela rede, mesmo quando quem solicita não conhece todos os recursos detalhados da referência. O RFC distingue diversidade obrigatória de diversidade consultiva, define erros para identificadores inconsistentes ou não suportados e exige que subobjetos de diversidade especificados sejam mantidos através de uma fronteira, mesmo quando uma política de segurança remove informações ordinárias do ERO.

Elias Ward análise: essa abstração pode reduzir a divulgação de topologia e a necessidade de conhecimento do solicitante, mas desloca a responsabilidade de correção para quem resolve o identificador e verifica a referência.

A página congelada de errata do RFC Editor para o RFC 4874 é citada como o registro vigente. Este briefing não faz nenhuma alegação de correção além do estado indicado nesse registro. Também não há alegações de incidentes ou de implantações: o pacote analisa comportamento padronizado.

Poder, beneficiários e custo

O originador pode exercer poder negativo sobre os recursos nomeados. O nó que calcula o caminho conserva a autoridade para escolher entre os recursos restantes ou declarar que não há caminho compatível. A autoridade de implementação downstream e das fronteiras determina se os subobjetos são entendidos, retidos e verificados. Serviços que precisam de diversidade de enlace, nó, SRLG ou caminho de referência são os beneficiários potenciais. Nenhuma dessas mensagens prova, por si só, diversidade física no ambiente real.

Elias Ward análise: uma exclusão obrigatória transforma uma preferência em uma restrição fail-closed, reduz o conjunto viável e pode converter uma configuração possível em falha de estabelecimento. SHOULD avoid preserva mais disponibilidade, mas permite que a política local atravesse o recurso indesejado. Sem exclusões, o caminho pode reutilizar o recurso que se queria evitar. Com uma recomendação, ele ainda pode ser usado. Com excesso de exclusões obrigatórias, pode não existir caminho compatível. Esses contrafactuais não são evidência sobre uma topologia viva, qualidade medida ou resultado de cliente.

Fixtures de verificação e caminho de decisão

As fixtures abaixo são testes concretos para laboratório ou auditoria; não são afirmações sobre uma rede em produção:

  1. Interface: envie um XRO com bit L limpo para excluir uma interface não numerada; confira o próximo salto e o Record Route para verificar sua ausência.
  2. Nó, SRLG e AS: exclua um nó por prefixo IPv4/IPv6, um SRLG e um sistema autônomo; compare o conjunto de candidatos, os erros e o estado depois da fronteira de domínio.
  3. Contradição: inclua no ERO um recurso que o XRO marca como exclusão obrigatória; confirme a rejeição com Routing Problem, em vez de uma troca silenciosa de rota.
  4. Conjunto vazio: exclua todos os próximos saltos possíveis; confirme o PathErr que identifica o bloqueio pelo Exclude Route.
  5. Evitação consultiva: defina o bit L e observe se a política local ainda escolhe o recurso; registre separadamente o resultado de SHOULD avoid e de MUST exclude.
  6. Capacidade: teste XRO complexo demais, subobjeto desconhecido, exclusões de capacidade de comutação e rótulo do RFC 6001 e identificadores de diversidade inconsistentes ou não suportados do RFC 8390; registre rejeição, ignorância ou encaminhamento.
  7. Fronteira e referência: remova informações ordinárias do ERO por política de segurança, confira a retenção do subobjeto de diversidade e valide a rota final com Record Route e com a referência resolvida.

O operador deve primeiro definir se a restrição cobre o caminho inteiro ou apenas um segmento. Depois deve escolher MUST exclude ou SHOULD avoid, verificar suporte no originador, PCE, nó computador e fronteiras, estimar o conjunto viável e o custo de divulgação de topologia, e executar as fixtures. Por fim, deve correlacionar PathErr, Record Route, resolução do identificador e interseção real de recursos. Se a meta for diversidade, ela precisa ser verificada depois da sinalização. O conjunto desconhecido inclui topologia viva, viabilidade, comportamento de fornecedores, adoção, latência de estabelecimento, taxas de falha e impacto no cliente.

Fontes