[GTER] Communities no IX.br

Sun Nov 13 11:38:05 -02 2016

Caro Henrique,

Sobre o exemplos e padrões concordo plenamente com você é já estamos
fazendo tutorias e templates. Durante a semana de infraestrutura estarei
ministrando um tutorial sobre o uso das Communities e vamos subir os
exemplos. Esse tutorial irá acontecer no dia 7/12 e já está com
inscrições abertas. 

Gostaria de avisar que a ideia do documento é que ele não seja
autocontido, digo a leitura das RFC e documentos acessórios é necessário. 

Durante o IX.br fórum farei uma apresentação sobre as Communities e vou
tentar consolidar as considerações recebidas e como vamos caminhar com a
implantação do serviço.

Grato,

Em 11/11/16 17:03, Henrique de Moraes Holschuh escreveu:
> Caros,
>
> Seguem algumas sugestões e considerações referentes ao documento sobre o
> uso de communities no IX.br. 
>
>
> Seção "1. Objetivos":
>
> Eu proponho para consideração da equipe do IX.br o seguinte objetivo
> extra:
>
> 7.  sugerir padrões de configuração, para os participantes do ATM do
> IX.br, para a implementação de funcionalidades baseadas em communities.
>
>
> Seção 2.1, path hiding:
>
> Como sugestão, talvez fosse interessante alterar o último parágrafo para
> deixar mais claro como o esquema "multiplas RIBs" funciona, e que o
> "aumento de 50% nos prefixos anunciados" não é geral, e sim para quem,
> por filtar ou ser filtrado, está sendo vítima de path-hiding ?
>
> Segue uma sugestão de explicação simplificada (baseada em uma que já
> enviei nesta thread):
>
> *Antes das alterações propostas neste documento:*
>
> O route-server do IX.br filtra, por participante, o *resultado* da
> convergência BGP (escolha da melhor rota) em uma RIB global que é a
> mesma para todos (e contém apenas a "melhor" rota na visão *global* do
> route-server).  Ele só tem duas escolhas para cada prefixo na RIB
> global: ou propaga a melhor rota, ou não propaga nada.
>
> Quando um participante não puder, devido a filtros, receber a "melhor
> rota" do ponto de vista da RIB global do route-server, ele não recebe
> rota alguma.  Trata-se do "path hiding".
>
> *Depois das alterações propostas neste documento:*
>
> O route-server do IX.br cria uma RIB específica para cada participante,
> e aplica os filtros relevantes para aquele participante *antes* de
> convergir o BGP (escolher a melhor rota) na RIB específica participante.
>  A escolha da melhor rota para cada prefixo só levou em considerações as
> rotas que poderiam ser anunciadas (propagadas) para aquele participante.
>
> Portanto, o participante tem muito maior chance de receber alguma rota
> para cada prefixo, e o "path hiding" é minimizado ou evitado.
>
>
> Seção 3, communities:
>
> Acredito que muitos não conheçam a fundo como as extended communities
> funcionam.  Mesmo quem as usa em MPLS VPN muitas vezes não tem
> conhecimento dos detalhes.
>
> Seria muito interessante descrever brevemente as extended communities
> relevantes para o IX.br, que suponho que serão subtipos específicos das
> "2-octet AS specific BGP extended communitiy" descrita no RFC 4360 ("BGP
> extended communities attribute"), e suas versões para ASN de 32-bits,
> descrita pelo RFC 5668 ("4-octet AS specific BGP extended community").
>
> Em particular, "extended communities" não funcionam da mesma forma que
> as communities tradicionais (RFC 1997). Quem funcionaria de forma
> similar às communities tradicionais seriam as "large communities", que
> ainda estão em estado de "draft" na IETF [1].
>
> [1] https://tools.ietf.org/html/draft-ietf-idr-large-community-06
>
>
> Seção 4, detalhes das communities:
>
> Gostaria de propor para consideração que o IX.br utilize *apenas* as
> 2-octet e 4-octet AS specific extended communities, não utilizando as
> BGP communities básicas (RFC 1997).
>
> Desta forma, tanto as configurações quanto os requerimentos de
> funcionalidade de roteador seriam homogêneos para os AS que possuam um
> ASN de 16-bits (como o do IX.br) e os que possuam ASN de 32-bits (como
> os de boa parte dos participantes).
>
> Há algum valor nesta homogeneidade: nem todo roteador/versão de firmware
> tem suporte decente à extended communities.  Se não houver exigência de
> patamar mínimo para que os membros do IX.br possam fazer uso destas
> novas funcionalidades, corre-se o risco de estender no tempo a
> dificuldade operacional dos ASNs de 32-bits.
>
> Esta provavelmente será uma proposta controversa, mas alguém tinha que
> colocar na mesa para ser discutida.
>
> Cabe lembrar aos membros do IX.br que a necessidade *técnica* de suporte
> a 2-octet e 4-octet AS specific extended communities é definida pela
> existência de membros com ASN de 32-bits, ou seja, é um fato consumado. 
> Evitar isso implica em publicar o "mapa da gambiarra" (uso de ASN de
> 16-bits privado para simbolizar cada membro que tem um ASN de 32-bits) e
> desistir da transparência à communities por parte do route-server para
> (quase) todo o espaço de ASN privado 16-bits.  Não acredito que a equipe
> do IX.br aceitaria esta alternativa (e com razão!).
>
> Ou seja, as alternativas são: (a) "obriga o suporte à extended
> community", ou (b) "vai ter membro que não consegue ativar um filtro
> direcionado a um ASN de 32-bit nem processar a identificação de origem
> adicionada pelo IX.br quando a origem possuir ASN de 32-bits".
>
>
> Seção 4, política 1 e 2:
>
> Sugiro já definir exatamente o formato da extended community
> (transitividade, tipo+subtipo).  Como serão removidas pelo route-server,
> faz sentido definir que sejam não-transitivas.
>
>
> Seção 4, política 3:
>
> É uma pena que o RFC 4384/BCP 114 "BGP Communities for Data Collection"
> não tenha previsto IXPs.  Não seria o caso de escrever uma extensão do
> mesmo, alterando um dos valores reservados de <R> [BCP 114, p.6] para
> significar que a origem da rota é um IXP,  usar o campo <AS> para
> identificar qual IXP, e definir que para este <R>, o campo <CC> [BCP
> 114, p.6] conteria informação com sentido determinado pelo IXP (no caso
> do IX.br, o código de cidade/área) ?
>
> Assim, o namespace 26162:<algo> fica livre para alguma outra utilização.
>
> Suponho que serão utilizadas 2-octet AS-specific extended communities do
> tipo RO (route origin) para identificar o ASN que originou a rota para o
> route-server?   Ou será utilizado algum outro subtipo para evitar
> confusão com o uso de RO para MPLS VPNs?
>
> Sendo o caso, sugiro já definir exatamente o formato da extended
> community (transitividade, tipo+subtipo, etc).
>
>
> Seção 4, política 4:
>
> Sugiro criar uma seção do documento dedicada à community de RTBH
> (blackhole), descrevendo as boas práticas que são sugeridas para
> implementação por parte dos *participantes* do IX.br, etc.
>
> Penso que o documento poderia deixar explicito que os route-servers
> podem não ser transparentes a communities dentro do espaço de ASN do
> NIC.br e IX.br, inclusive porque, pelas boas práticas, o uso desta parte
> do espaço de communities é regido pelo NIC.br/IX.br.
>
> Recomendo reservar uma pequena faixa de ASN privados (65000 a 65010 e
> 64600 a 64610, por exemplo) para implementação futura de funcionalidade
> do IX.br.  Os route-servers não devem ser transparente à nenhum tipo de
> community (RFC 1997, extended, large[1], etc) que contenha estes ASNs no
> campo de global administrator (para RFC1997, "primeira parte" da
> community).
>
> [1] https://tools.ietf.org/html/draft-ietf-idr-large-community-06
>
>
> Seção 5:
>
> Por segurança operacional, talvez faça sentido considerar um passo de
> "ativação" da transparência à communities, controlada diretamente pelo
> participante do IX.br ?
>
> Neste caso, aconteceria algo do tipo:
>
> Passo 1: O serviço é disponibilizado pelo IX.br nos route-servers, mas
> todas as sessões dos membros estão, inicialmente, configuradas para o
> estado "descarte bidirecional de communities pelo route-server", ou
> seja, não há alteração de comportamento.
>
> Passo 2: Cada membro revisa sua configuração, e quanto achar que está
> devidamente ajustada, ele libera a transparência à communities no
> route-server, através do painel de self-service no meu.ix.br.
>
> Novas conexões ao IX.br já seriam provisionadas com a transparência
> habilitada e travada (não pode ser desabilitada).
>
>
> Seção 7:
>
> Acredito que seja útil adicionar as referências:
>
> RFC 5668 - 4-octet AS Specific BGP Extended Community
> RFC 5701 - IPv6 Address Specific BGP Extended Community Attribute
> RFC 6666 - A Discard Prefix for IPv6
> RFC 7999 - BLACKHOLE Community
>
>
>
> PS: acredito que será realmente necessário publicar exemplos de como
> utilizar e gerar cada um dos tipos de extended community implementadas
> pelo IX.br ou de implementação sugerida para os participantes
> (blackhole), para as plataformas de roteamento mais utilizadas no IX.br.
>  A documentação é, em geral, muito esparsa neste ponto: só se acha
> facilmente receitas de bolo para MPLS VPN.
>

-- 
NIC.br | Lucenildo Aquino Júnior
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537R.: 4122
INOC 22548*552
www.nic.br <http://nic.br>