Resumo

  • O OR lógico de RFC 9252 continua válido apenas quando Route Type 1 e Route Type 3 anunciam estruturas SID idênticas; RFC 9819 define a construção quando isso não ocorre.
  • O Inclusive Multicast anuncia LOC:FUNC e o offset do argumento. O Ethernet A-D per ES fornece Arg.FE2. AL igual confirma o tamanho esperado, não uma identidade de layout.
  • Um SID bem formado não confirma aceitação pela política, instalação local, execução de End.DT2M, exclusão correta de interfaces nem entrega BUM sem duplicação.

Há uma diferença entre somar informação e compor autoridade. Duas mensagens BGP podem ser válidas isoladamente e ainda não autorizar a operação que usa uma parte de cada uma. Foi essa falha que RFC 9819 tornou explícita ao atualizar RFC 9252.

RFC 9252 descrevia um OR bit a bit entre o ESI Filtering Argument da rota Ethernet A-D per ES e o SID End.DT2M da rota Inclusive Multicast Ethernet Tag. A operação funciona quando os campos ocupam as mesmas posições. Testes de implementação e interoperabilidade revelaram que a especificação permitia interpretações ambíguas e que a estrutura uniforme não era universal.

RFC 9819 mantém o caminho compatível onde o layout é idêntico. Fora dele, o ingress PE precisa construir o SID de modo consciente: usar o LOC:FUNC e a estrutura anunciados por Route Type 3, extrair o ARG de Route Type 1 e inserir os bits no offset pertencente ao primeiro.

O significado local de Arg.FE2

RFC 8986 define End.DT2M para desencapsular uma carga Ethernet e inundá-la numa tabela L2. Arg.FE2 referencia um mapeamento local para ESI e exclui uma interface ou conjunto de interfaces da inundação. Assim se mantém o split horizon em cenários de multihoming e E-Tree.

O argumento não é um nome global do segmento. Quem instancia o comportamento aloca o valor localmente. Para outro nó usá-lo, o anúncio precisa carregar valor, tamanho, comportamento e associação aos SIDs aplicáveis. O endpoint dono de LOC:FUNC informa ainda LBL, LNL, FL e AL no SRv6 SID Structure Sub-Sub-TLV.

Quando ESI filtering está ativo, Route Type 3 anuncia End.DT2M LOC:FUNC para o broadcast domain e um AL não zero; Route Type 1 anuncia o ARG e o mesmo AL. O egress precisa usar o mesmo AL em todos os Ethernet Segments locais com attachment circuits no mesmo broadcast domain.

Isso não obriga FL a ser igual. O exemplo de RFC 9819 apresenta um ARG de 16 bits para dois bridge domains, um com Function de 32 bits e outro com Function de 16 bits. O ponto de inserção muda. Fazer OR sem observar a estrutura equivale a escolher uma interpretação sem registrá-la.

O receptor deve distinguir ausência de erro

Se Type 3 sinaliza AL=0, o serviço não espera esse argumento. O ingress forma LOC:FUNC, zera os bits posteriores e ignora SID e estrutura da rota A-D.

Se Type 3 sinaliza AL não zero, o ingress procura a rota A-D per ES correspondente e verifica End.DT2M. Ausência da informação ou AL=0 em Type 1 significa que nenhum ARG utilizável chegou. O SID vira LOC:FUNC-only; se o ambiente esperava filtering, a implementação deveria registrar o fato.

Dois AL não zero e diferentes indicam erro de configuração. RFC 9819 exige que o BUM daquele Ethernet Segment não seja encaminhado, pois pode haver loop. Dois AL iguais permitem a inserção do argumento no offset LBL + LNL + FL declarado por Type 3. Os bits após o fim da estrutura precisam ficar em zero.

Uma plataforma de observabilidade deveria expor esses resultados como estados diferentes. AL=0 intencional, argumento ausente, mismatch bloqueante e construção válida não pertencem a uma única cor verde.

Um par de rotas tem endereço e época

RFC 7432 fornece o contexto para a associação: RD, RT, Ethernet Tag, ESI, PE de origem, next hop e withdrawals. Esses elementos impedem que o ARG de um ES seja unido ao LOC:FUNC de outro serviço. Também ajudam a responder se a dupla ainda é atual depois de uma retirada e nova divulgação.

O recibo de composição deve listar os dois paths selecionados e o momento observado. Uma tabela local atual não demonstra que a programação de hardware, um cache ou o endpoint remoto processou a mesma geração. Quando RFC 8365 local bias substitui o ESI filtering, o ARG não entra na composição.

Os flavors comprimidos de RFC 9800 podem coexistir com os não comprimidos sob as verificações de AL de RFC 9819. O behavior continua sendo parte da identidade. A Transposition Scheme de RFC 9252 também permanece: TPOS-O, TPOS-L e a capacidade do campo MPLS precisam de validação própria.

A prova continua depois do endereço

Construir um endereço não prova que ele foi escolhido. O software pode não suportar o novo procedimento, aplicar política diferente, preferir outro path ou falhar na escrita do dataplane. O ingress deve mostrar a rota selecionada, o algoritmo usado e o SID efetivamente programado.

No egress, a evidência deve encontrar o local SID correto, o flavor End.DT2M, a tabela L2 e o mapeamento atual de Arg.FE2. Em seguida, um teste de pacote precisa verificar desencapsulamento, flooding e OIFs excluídas. Só a observação do serviço pode confirmar que os receptores previstos receberam a carga e que o segmento de origem não recebeu uma cópia proibida.

Essas etapas formam oito recibos: identidade/frescor; behavior/estrutura; associação; SID construído; aceitação local; estado programado; execução; resultado. RFC 9819 disciplina o centro da cadeia, não substitui suas pontas.

Este recorte não repete RFC 10018, que acompanha políticas P2MP e entrega por folha; RFC 9830, sobre seleção de candidate path; RFC 9863, sobre Color em PCEP; ou RFC 10039, sobre D-PATH. Aqui a questão é se componentes distribuídos podem formar o Service SID pretendido antes de qualquer afirmação sobre a árvore ou o cliente.

A especificação inicial mínima de Lu Heng inspira a leitura editorial: regras comuns precisam ser determinísticas e localmente verificáveis. Running-Code Primacy separa publicação de adoção, enquanto Reality Layers impede confundir uma declaração simbólica com efeito físico. Essa interpretação não é atribuída ao IETF.

Fontes