Resumo

  • Nos Segment Types I, J e K, o RFC 9831 permite incluir um campo SRv6 SID com valor zero para indicar comportamento ou estrutura desejados sem especificar a SID concreta.
  • A flag S confirma que o campo veio na mensagem, não que exista um valor executável. O headend ainda resolve a referência com informação SR local e pode rejeitar ausência, impossibilidade ou divergência.
  • Uma cadeia verificável preserva flags, octetos, referência de nó ou adjacência, fontes locais, SID resolvida, motivo de validação, seleção, instalação e observação de pacotes.

O protocolo não usa todo zero como sinônimo

Em sistemas operacionais, o valor zero costuma ser comprimido em uma categoria genérica: vazio. O RFC 9831 dá a esse atalho um custo alto. O significado do zero depende do campo, do tipo de segmento e das flags que o cercam.

Para I, J e K, a flag S sinaliza um campo SID de 16 octetos. Esse campo pode conter o endereço IPv6 zero quando o controlador deseja informar endpoint behavior ou SID structure, mas não a SID. A mensagem não perdeu bytes. Ela distribuiu o trabalho: a origem descreve a intenção e o destino resolve o valor.

Campo ausente é diferente. Sem o campo SID, o bloco de behavior e structure não pode ser incluído. Com campo presente e zero, esse bloco pode orientar a resolução. Com SID não nula, o controlador fornece um valor específico a ser confrontado com o contexto local. Há três estados e três histórias de autoridade.

Transformar os dois primeiros em null apaga a delegação. Transformar os dois últimos em “SID recebida” confunde orientação com instrução. O recibo mínimo guarda S, B, os 128 bits, o tipo e os endereços ou identificadores que dão sentido à referência.

Explícito não quer dizer pré-resolvido

A Segment List sub-TLV representa um caminho explícito até o endpoint; cada Segment sub-TLV representa uma etapa. A palavra explícito fixa a sequência e o tipo da etapa, mas não obriga toda etapa a chegar como o valor final de encaminhamento.

Os tipos C e D descrevem nós IPv4 ou IPv6 a serem resolvidos em rótulos SR-MPLS. E a H descrevem adjacências por endereços e IDs de interface. I a K fazem o equivalente para nós e adjacências SRv6. O RFC 9256 atribui ao headend a resolução desses descritores em label ou SID.

Isso permite que o controlador descreva o caminho sem copiar para cada anúncio toda alocação local e transitória. Uma rede pode alterar sua correspondência interna e continuar recebendo a mesma referência. Mas a execução passa a depender da visão SR do receptor.

Dois headends podem receber bytes idênticos e chegar a respostas diferentes. Um possui a origem do prefixo e a adjacência atual; outro usa informação desatualizada ou não encontra a interface. O anúncio comum não prova resolução comum. A investigação precisa da fonte, versão e hora da informação local, além do resultado.

A, S, B e V marcam etapas, não um veredito

A flag A declara que o campo SR Algorithm tem significado nos tipos aplicáveis. Sem A, o transmissor deve preencher o campo com zero e o receptor deve ignorá-lo. Esse zero não delega a escolha de algoritmo; ele não afirma algoritmo algum.

S declara presença física do campo SID. Não informa se o valor é zero, se existe no headend, se coincide com a referência ou se poderá ser instalado.

B indica a presença do bloco SRv6 endpoint behavior e SID structure para os tipos B, I, J e K. O bloco depende de um campo SID, embora o valor desse campo possa ser zero. Logo, B pode descrever o que se espera de uma SID que o receptor ainda vai descobrir.

V pede verificação da SID pelo SR Policy Manager. Não relata que a verificação terminou. Exibir V=1 como “verificado” converte uma ordem recebida em resultado fabricado.

As quatro flags dividem significado de algoritmo, presença de valor, semântica adicional e dever de verificar. Um único indicador verde elimina justamente a separação necessária para atribuir decisões.

O headend tem direito de discordar

O RFC 9256 descreve a SR-DB como um conjunto conceitual de informação útil para cálculo e validação. A implementação não precisa criar literalmente uma base com esse nome. Precisa, no entanto, de contexto local para associar prefixo, nó, interface ou par de endereços a uma SID vigente.

A verificação falha se uma SID fornecida não aparece na informação SR. Também falha se o contexto de um tipo C–K resolve para uma SID diferente da fornecida. Um segmento que não seja o primeiro pode ainda ser impossível de resolver. Esses motivos distinguem falta local, contradição entre visões e etapa incompleta no caminho.

Em vários domínios, o limite de conhecimento muda a representação. Se o headend não consegue verificar reachability de uma SID remota, o RFC 9256 exige Types A ou B para essa SID; a primeira SID deve sempre ser alcançável. O receptor não recebe autoridade fictícia sobre uma topologia que não conhece.

Ele é mais que um parser. Seleciona os campos aplicáveis, consulta fatos locais, completa ou confronta valores e julga a lista. Autenticar o peer BGP protege a origem da mensagem, não a exatidão de um endereço de nó, interface, behavior ou visão topológica.

Uma lista pode ser bem formada e ainda assim inválida

O RFC 9831 define comprimentos diferentes conforme SID e behavior/structure estejam presentes. Essas regras impedem deslocamentos de leitura e interpretações incorretas dos octetos seguintes. Elas provam forma, não execução.

O tipo define o papel do campo. As flags dizem o que deve ser interpretado. O SRPM valida o conjunto. O RFC 9256 torna inválida uma lista que misture segmentos SR-MPLS e SRv6, mesmo quando cada sub-TLV isolado possui tipo, tamanho e flags corretos.

O RFC 9830 já coloca a validação semântica do caminho fora do BGP. O RFC 9831 diz que as extensões não alteram operações ou fault management da SR Policy. O estudo anterior sobre RFC 9830 tratou da diferença entre transporte BGP e autoridade de encaminhar. Aqui a fronteira está dentro da descrição: antes de selecionar qualquer candidato, um campo presente pode ser trabalho ainda entregue ao receptor.

Código registrado não é SID instalada

A IANA coordena os valores dos tipos C–H e I–K e as flags A e S. Esse registro faz implementações diferentes lerem a mesma gramática. Não faz com que compartilhem implementação, topologia, atualidade ou resultado.

Um código Type J não comprova suporte de um roteador. Um ID de interface não comprova que o link continue igual. Uma SID resolvida não comprova programação. Programação não comprova pacote. O status Experimental do RFC 9831 comprova a publicação de um desenho para implementação e avaliação, não adoção.

Por isso, “suportado”, “resolvido”, “verificado”, “ativo”, “instalado” e “observado” devem ter definições distintas. O primeiro pode parar no parser; o segundo exige consulta; o terceiro exige confronto; o quarto exige seleção; o quinto pertence ao plano de encaminhamento; o sexto exige evidência controlada.

Recibos que preservam a origem do valor

O controlador deve registrar intenção, ordem, tipo, contexto de nó ou link, A/S/B/V, comprimentos, valor original, versão e hora. O registro diz se houve SID não nula, zero para delegar ou omissão do campo.

O headend adiciona fontes SR, versão, valor resolvido, ambiguidades e tempo. A verificação adiciona presença, match, mistura tecnológica e motivo de recusa. Validade do candidato, escolha ativa, instalação, pacote e serviço continuam como recibos seguintes.

Assim, uma delegação sem mapa local volta ao proprietário da informação local; uma SID fornecida em conflito volta à fronteira entre emissor e receptor; uma falha de programação depois de resolução correta volta ao dono do plano de encaminhamento. A disciplina reduz disputa porque não apaga quem decidiu o quê.

Fontes