Resumo

  • O ERO Hop Attributes do RFC 7570 é um contêiner opcional, de tipo 35, que transporta um ou mais Hop Attributes TLVs. Seu alcance nasce da posição no ERO, não de uma autorização genérica para todo o caminho.
  • O subobjeto pode seguir o subobjeto ERO que identifica o hop ou os subobjetos de rótulo associados a esse hop. Os atributos se aplicam ao subobjeto ou subobjetos ERO imediatamente anteriores. O documento que define cada atributo deve dizer quais tipos anteriores são válidos, se a ordem importa, como interpretá-la e quais modificações são permitidas.
  • O bit R importa as regras de processamento do RFC 5420: com R=1, a verificação é required; com R=0, é optional. O bit não define o significado substantivo do atributo nem transforma a solicitação em autoridade sobre outros hops.

O mecanismo de escopo

O ingresso coloca o Hop Attributes ao lado de uma etapa ERO já expressa para pedir que o nó endereçado processe aquele atributo. É uma decisão de escopo, não uma concessão de poder sobre a LSP inteira. O RFC 3209 trata o ERO como a sequência de nós abstratos solicitada e o RRO como informação de rota coletada; RRO não é um canal de autorização. Assim, um serviço que precisa de um comportamento em um trânsito específico pode pedi-lo naquele hop sem exigir que todos os nós da LSP compreendam o mesmo atributo.

O tipo 35 tem comprimento variável, e o comprimento do subobjeto limita o conteúdo agregado dos TLVs. Se um nó encontra o ERO Hop Attributes durante o processamento e não o suporta, deve retornar Routing Error / Bad EXPLICIT_ROUTE PathErr, com o ERO truncado no subobjeto ofensivo. O RFC 3209 também distingue o momento do encontro: um subobjeto ERO não reconhecido durante o processamento normal produz Bad Explicit Route Object; um subobjeto ainda não encontrado é encaminhado. Portanto, processamento opcional não torna comprimento inválido ou subobjeto malformado aceitável por definição.

O Attribute Flags TLV do RFC 5420 pode ser carregado dentro do ERO Hop Attributes, mas somente flags definidas como válidas nesse contexto produzem efeito. Flags inválidas são ignoradas silenciosamente; flags desconhecidas devem provocar Unknown Attributes Bit PathErr. “Desconhecida” e “inválida” não são a mesma coisa, e nenhuma das duas categorias deve ser confundida com o bit R. O nó pode rejeitar o pedido por erros existentes de policy-control ou admission-control. Quando os procedimentos do TLV definidor permitirem, também pode modificar o atributo solicitado. O fato de o alcance ser por hop não dá ao ingresso autoridade ilimitada.

Duas formas de relatório, duas perguntas

Atributos de toda a LSP sinalizados em LSP_ATTRIBUTES ou LSP_REQUIRED_ATTRIBUTES devem, em regra, ser reportados em RRO Attributes do RFC 5420. Atributos sinalizados somente em ERO Hop Attributes devem, em regra, ser reportados em RRO Hop Attributes. O último é um subobjeto opcional de tipo 35 do RRO e pode carregar TLVs processados ou adicionais. Porém, a obrigação de relatar conformidade precisa estar no documento que define o atributo. Uma LSP estabelecida, sozinha, não prova que um atributo opcional de hop foi processado como solicitado.

Nós de trânsito normalmente encaminham o RRO Hop Attributes sem alteração. Uma borda de domínio pode remover ou modificar informações por política de confidencialidade ou de tamanho de mensagem. Nós de ingresso mais antigos podem descartar informação RRO que não reconhecem. Logo, RRO Hop Attributes é evidência condicional, editável por política e específica do hop, não prova imutável. O RFC 7571 oferece apenas um exemplo delimitado: usa o mecanismo para direcionar um pedido de OAM loopback a um nó e usa RRO Hop Attributes para relatar o estado. Isso não redefine o significado genérico do contêiner do RFC 7570.

Fixtures de verificação em nível de pacote

  1. Escopo: monte IPv4-prefix(A) -> Label(A) -> Hop Attributes(type=35, R=clear, TLV=X) -> IPv4-prefix(B). No Path capturado, confirme que X se associa a A e ao rótulo, não a B nem à LSP inteira.
  2. Bit R: envie o mesmo TLV válido com R=0 e R=1. Registre as trilhas optional e required, sem inferir o significado operacional de X a partir do bit.
  3. Posição e ordem: coloque o tipo 35 após um tipo anterior não permitido pelo documento do atributo e troque a ordem de TLVs cuja ordem seja significativa. Registre rejeição ou interpretação; o RFC 7570 não fornece a ordem específica de cada atributo.
  4. Suporte: faça o nó alvo encontrar um tipo 35 que não suporta. Verifique Routing Error / Bad EXPLICIT_ROUTE PathErr e o ERO truncado no subobjeto ofensivo. Compare com um subobjeto ERO desconhecido ainda não encontrado, que pode ser encaminhado.
  5. Flags: envie separadamente flags válidas, inválidas e desconhecidas. Confirme que a inválida é ignorada e verifique se a desconhecida gera Unknown Attributes Bit PathErr.
  6. RRO: sinalize um atributo de LSP inteira e outro somente no hop. Verifique o primeiro em RFC 5420 RRO Attributes e o segundo em RRO Hop Attributes; trate-o como prova de conformidade apenas se o documento definidor exigir relatório. Em uma borda, remova o RRO e registre a perda de visibilidade.
  7. Contrafactuais: com R=0 e sem relatório RRO definido para o atributo, não trate a configuração bem-sucedida como prova de execução. Com R=1 e subobjeto não suportado ou malformado, espere que a configuração possa ser rejeitada.

Fontes

O conjunto de fontes não estabelece quais fornecedores ou operadores implementam ERO ou RRO Hop Attributes. Também não fornece prevalência de implantação, taxas de falha, medições de crescimento de mensagens ou dados de impacto para clientes. A página de errata foi preservada como snapshot; não há afirmação de correção além desse registro.