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
