[GTER] BGP4 Communities e ASN32

[Andre Gustavo de C. Albuquerque]

2011/3/1 Henrique de Moraes Holschuh <henrique.holschuh at ima.sp.gov.br>
...

>  Não tenho ideia se houve bom senso por parte dos implementadores de
>>> pilha BGP4 de automaticamente implementar busca em comunidades RFC5668
>>> sem precisar incluir um novo comando de match.
>>>
>>
>> Quagga já tinha suporte ao draft, deve implementar RFC 5668.
>>
>
> A minha colocação está mais em como _utilizar_ as communities RFC 5668... o
> certo seria ser 100% transparente:  Se a configuração informa uma community
> em um filtro ou ação, cujo o primeiro campo requer 32 bits, usar a RFC 5668.
>  Se informar um filtro com máscara/wildcard, fazer os testes de match tanto
> nas communities tradicionais quanto nas RFC 5668 (precisaria fazer o
> sign-extend da máscara nesse caso) de cada rota.
>
> Ou seja, seria inteiramente transparente para o usuário.


As extended communities transitivas têm seu uso concentrado até hoje em
ambientes de VPNs L3 ou L2.
Sua concepção previu um campo que define o tipo da community, com 1 ou 2
bytes, seguido dos valores da community em si, com 7 ou 6 bytes. A
interpretação destes valores depende do tipo da extended community. Sendo
assim, a discussão sobre utilização de 2 ou 4 octetos como representação de
ASN dentro de uma ext-community depende mesmo da definição desta.

No caso específico desta RFC, foram estendidos dois atributos: Route-Target
e Route-Origin (aka: Site of Origin). Estas ext-communities têm sido
utilizadas extensivamente em L3VPNs (RFC4364).

Abs, Gustavo