BIRD 2.0.0: RFC8097 extended communities and rpki-light

[Job Snijders]

Dear all,

On Tue, Dec 12, 2017 at 06:47:44PM +0100, Pier Carlo Chiodi wrote:
> while I was running some tests on BIRD 2.0.0 I've noticed that the
> handling of RFC8097 extended communities is different from 1.6.3.
> 
> Scenario:
> - AS10 announces a route to the route server;
> - the route server adds the (0x4300, 0, 1) ext community (RFC8097);
> - AS20 receives the route;
> - clients are always both on 1.6.3.
> 
> This is the filter I'm using:
> 
> filter from_client {
> 	bgp_ext_community.add((unknown 0x4300, 0, 1));
> 	accept;
> }
> 
> The results I get follow:
> 
> - when 1.6.3 is used on the route server, BIRD treats the community
>   strictly according to RFC4360:
> 
>    If a route has a non-transitivity extended community, then before
>    advertising the route across the Autonomous System boundary the
>    community SHOULD be removed from the route.

Hmm... I think it is in everyone's best interest that non-transitive BGP
extended communities are actually treated as non-transitive (like in
1.6.3). This prevents surprises.

> - when 2.0.0 is used, the community is treated accordingly to
>   draft-ietf-sidrops-route-server-rpki-light-02 and is propagated to the
>   client.
> 
> Since I didn't find any reference to RFC8097/rpki-light on the web site,
> I was wondering if I missed something or if this is the expected
> behaviour.

Please note that draft-ietf-sidrops-route-server-rpki-light is still
heavily in flux, and the authors indicated that they'd move towards
using a transitive extended community and abandon the non-transitive
extended communities in the current revision of the draft.

Kind regards,

Job