Summary

  • A versão de 28 de outubro de draft-ietf-idr-rt-derived-community-13 descreve uma Extended Community derivada de Route Target. Ela mantém os campos Global Administrator e Local Administrator, mas troca o subtipo. Pelo texto da própria minuta, o marcador identifica seu RT de origem sem restringir a distribuição de rotas nem provocar sua importação em VRFs. O documento está em avaliação no IESG e pretende ser Informational.
  • A IANA já lista seis atribuições relacionadas, citando a minuta predecessora de 2021. A revisão pede atualização das referências e novos valores. Um código registrado não define por si o que cada receptor fará com a rota.

A etiqueta que não é chave

O exemplo do documento usa uma VPN atendida por dez roteadores de borda. Seu Route Target comum faz com que todos importem as rotas da VPN em suas VRFs. Surge outra rota que precisa ser associada àquela VPN, mas entregue somente a alguns dos dez. Repetir o RT comum no anúncio pode convocar a distribuição para todos. Criar um RT novo para cada subconjunto pulveriza em várias identidades a mesma associação à VPN. A solução proposta preserva o nome da relação e retira a ordem de entrega.

A comunidade derivada conserva os valores administrativos do RT original e muda o subtipo. O receptor pode reconhecer de qual RT ela nasceu. A seção 2, porém, diz que a presença desse marcador, por força desta minuta, não afeta a propagação nem importa a rota em uma VRF. Ele não pode ser carregado na informação de participação de RT definida pelo RFC 4684; políticas que procuram Route Targets não coincidem com a comunidade derivada. A etiqueta aponta para a chave, sem abrir a fechadura.

O contraste repousa no RFC 4360, que descreve o Route Target como identificador dos roteadores que podem receber as rotas que o carregam. A nova comunidade aproveita seus números para falar de uma VPN comum entre subconjuntos distintos. A mudança de subtipo mantém a autorização de distribuição e importação no RT verdadeiro. Ler somente os campos numéricos e ignorar o subtipo transforma parentesco em permissão.

O registro dá o código; outro texto dá o verbo

Os registros BGP da IANA já mostram RT-derived-EC em tabelas com subtipo 0x15 e um tipo IPv6 0x0015. A minuta conta seis atribuições e observa que suas referências apontam para a versão individual de 2021. Pede sua atualização, a mudança de nome do item EVPN e novas atribuições para um RT IPv6 baseado em UUID e dois Transport Classes. Estas últimas aparecem como pedidos no texto em avaliação, não como atribuições concluídas.

Há uma armadilha adicional para quem programa a correspondência. Os valores 0x02 para RT e 0x15 para derivado são comuns, mas o documento os chama de convenção. A tabela 1 determina os pares válidos. Um RT IPv6 da tabela usa 0x0011 e seu derivado ainda aguarda valor. A forma visual de uma sequência não substitui o tipo, o subtipo e a linha correta do registro.

Também não há uma ação geral prescrita para todo receptor. Cada documento que empregar a comunidade derivada deve dizer os AFI/SAFI e tipos de rota em que ela aparece, além do que o destinatário fará. A minuta fornece um vocabulário estável; a política de uso posterior decide o comportamento. Atribuir um valor pela IANA não equivale a instalar uma rota, selecionar um destino ou demonstrar entrega em produção.

Em 28 de outubro, o Datatracker classificava o texto como Internet-Draft em IESG Evaluation, com revisão da IANA pendente depois da mudança de versão. Os originais comprovam a semântica proposta e os códigos existentes; não apresentam um incidente de vazamento causado por confusão entre as etiquetas.