Subject: [Idr] "Show of hands" on non transitive extended communities handling

From: Pierre Francois <[email-masked]>
Date: Tue, 16 Nov 2010 11:57:55 +0100

Hi,

Could I "see show of hands" on the ML on who does not consider the handling
of non transitive extended communities described below as the right one ?

I've been told that there is a third BGP implementation that is not handling 
them this way, so I'm asking myself whether

- RFC 4360 is unclear and draft-decraene-idr-rfc4360-clarification should be 
refreshed.

or

- I'm the only one understanding 4360 this way and the behaviors we saw when 
testing are the compliant ones. (In which case I'm asking myself about the 
usability of non transitive extended communities in SP networks.)

I had understood that an implementation of 4360 would have to

- Accept non transitive communities received over an eBGP session
- Remove such communities when propagating paths from iBGP to eBGP (of course 
not the ones tagged by the ASBR propagating the path itself).

That is: You can send non transitive communities out of your AS, and your 
neighbor will accept them. When propagating a path over eBGP, you're not allowed 
to leave a community that was tagged by the neighboring AS which propagated that 
path to you.

This is basically doing on communities what you do on paths tagged with NO_EXPORT.

Regards,

Pierre.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 16 Nov 2010 14:03:30 +0100

Hi Pierre,

Let me try to explain my understanding of AS non-transitive community.

AS non-transitive extended communities are added on ingress to the 
domain and carried over within domain with prefixes till the other side 
ASBRs. They are then dropped and not allowed to be send to other peering 
domians.

Therefor I do consider that sending non-transitive extended community 
over EBGP session is an error and we should not use them this way.

I do not find an analogy of comparing them to NO_EXPORT of well-known 
standard community as a correct one.

That is why some implementations when receiving AS non-transitive 
extended communities over EBGP session drop them on inbound assuming 
that some error/bug has caused them to be send over domian's boundary in 
the first place.

Many thx,
R.

> I've been told that there is a third BGP implementation that is not
> handling them this way, so I'm asking myself whether
>
> - RFC 4360 is unclear and draft-decraene-idr-rfc4360-clarification
> should be refreshed.
>
> or
>
> - I'm the only one understanding 4360 this way and the behaviors we saw
> when testing are the compliant ones. (In which case I'm asking myself
> about the usability of non transitive extended communities in SP networks.)
>
> - Remove such communities when propagating paths from iBGP to eBGP (of
> course not the ones tagged by the ASBR propagating the path itself).
>
> That is: You can send non transitive communities out of your AS, and
> your neighbor will accept them. When propagating a path over eBGP,
> you're not allowed to leave a community that was tagged by the
> neighboring AS which propagated that path to you.
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Pierre Francois <[email-masked]>
Date: Tue, 16 Nov 2010 14:45:18 +0100

Robert,

Tony's "what you have been observing during your tests are bugs" during my
draft-decraene-idr-rfc4360-clarification-00 talk in Hiroshima, which was 
basically observing what you've just described, makes me think that this draft
wasn't that useless after all.

I'll refresh it.

Regards,

Pierre.

On 16/11/10 14:03, Robert Raszuk wrote:
> AS non-transitive extended communities are added on ingress to the domain and
> carried over within domain with prefixes till the other side ASBRs. They are
> then dropped and not allowed to be send to other peering domians.
>
> Therefor I do consider that sending non-transitive extended community over EBGP
> session is an error and we should not use them this way.
>
> I do not find an analogy of comparing them to NO_EXPORT of well-known standard
> community as a correct one.
>
> That is why some implementations when receiving AS non-transitive extended
> communities over EBGP session drop them on inbound assuming that some error/bug
> has caused them to be send over domian's boundary in the first place.
>
> Many thx,
> R.
>
>
>> Hi,
>>