Resumo

  • O rascunho -13 copia os valores de administrador de uma Route Target para outro subtipo de Extended Community, mas não dá à cópia efeito sobre a distribuição de rotas nem sobre a importação para uma VRF.
  • A cópia transitiva pode cruzar uma fronteira entre AS; um filtro eBGP baseado no subtipo da Route Target talvez não a reconheça.

No BGP, as etiquetas são pequenas. As funções que elas carregam não são intercambiáveis.

Uma Route Target (RT) pode indicar a qual VPN uma rota pertence. Na rede, também pode limitar quais roteadores recebem a rota e fazer uma VRF configurada para aceitar aquela RT importá-la. Uma Extended Community comum pode carregar uma marca relacionada sem assumir esses poderes. A diferença aparece quando uma rota precisa ser associada a uma VPN em apenas parte dos roteadores PE.

Esse é o cenário do rascunho -13, atualizado em 28 de outubro. Imagine dez roteadores PE importando rotas VPN com RT1. Outra rota deve ser associada a essa VPN em um subconjunto deles, mas sua distribuição fica sob controle de outra RT, a RT3. Reutilizar RT1 como marca de associação sugeriria que todos os roteadores que importam RT1 deveriam receber a rota. Criar uma marca diferente para cada subconjunto multiplicaria etiquetas para a mesma VPN.

A solução proposta é uma Extended Community derivada: manter os valores Global Administrator e Local Administrator da RT, trocar o subtipo e chamar o resultado de RT-derived EC. Os valores remetem à RT; o subtipo diferente deixa claro que a cópia não é uma RT.

O limite está escrito no rascunho. Uma RT-derived EC não restringe a propagação da rota, não provoca sua importação em uma VRF e não corresponde a uma política que procure a RT relacionada. Também não pode ser transportada no NLRI Route Target Membership definido pela RFC 4684. O rascunho define a correspondência e os códigos; outro documento precisa definir o que o receptor fará com ela.

O problema surge na fronteira. O rascunho preserva o octeto de maior ordem do campo Type; portanto, uma RT-derived EC correspondente a uma RT transitiva também permanece transitiva. Na ausência de uma política que determine o contrário, ela pode atravessar fronteiras entre AS. Uma regra criada para filtrar ou reescrever o subtipo da RT não captura automaticamente o subtipo derivado. Os mesmos valores de administrador global e local, mas outro código e outro resultado de correspondência.

O rascunho registra a atribuição do subtipo 0x15 em vários registros de Extended Community, inclusive formatos transitivos específicos de AS. Não atribui esse valor a todos os formatos possíveis de RT; outras correspondências seguem solicitadas ou pendentes. A RFC 4360 explica por que campos de tipo ajudam a estruturar políticas para Extended Communities. Aqui, justamente o subtipo diferente pode fazer o filtro ignorar um valor da mesma família.

Em 30 de outubro, uma revisão do Operations Directorate do IETF avaliou a versão 13 e pediu uma seção própria de considerações operacionais. Gen Chen citou filtragem inter-AS e risco de vazamento, limites de escopo e o comportamento de BGP legado; observou que operadores podem filtrar o subtipo 0x15 em fronteiras eBGP quando não quiserem propagá-lo. É uma recomendação de revisão, não evidência de que tenha ocorrido um vazamento. O comentário aponta a distância entre definir uma codificação e explicar seu comportamento em redes com equipamentos diferentes.

Em 2 de novembro, o rascunho está em avaliação pelo IESG e consta da teleconferência de 5 de novembro. Um documento informativo pode fixar quais bits correspondem, mas não definir quem deve filtrá-los, como os equipamentos antigos vão reagir ou como cada uso futuro será contido. O subtipo ocupa um byte; mapear as políticas exige bem mais trabalho.

Fontes: rascunho -13 · revisão do Operations Directorate · RFC 4360 · RFC 4684