Re: [Idr] "Show of hands" on non transitive extended communitieshandling

Shyam,

If the behavior of re-attaching that community has been explicitly configured by 
the operator, I don't see a problem w.r.t. RFC 4360.

"draft-decraene-idr-rfc4360-clarification" indeed talks about 
attaching/originating non-transitive communities on the outbound policy.

As the ASBR is supposed to strip off non transitive communities that are not 
locally originated, before propagating over eBGP, doing this at the outbound 
filters ensures that they will actually make it over the session.

Other origination methods are fine if they can provide this same behavior.

Regards,

Pierre.

On 09/12/10 09:34, Shyam Sethuram (shsethur) wrote:
> Pierre,
> Pls see inline...
>
> thanks--shyam
>
>> -----Original Message-----
>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of
> Pierre Francois
>> Sent: Tuesday, November 16, 2010 2:58 AM
>> To: idr
>> Subject: [Idr] "Show of hands" on non transitive extended
> communitieshandling
>>
>>
>> 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.
>
> The border router would still be able to make a local decision to
> re-attach
> the exact same community received on an iBGP path and send it out
> towards an eBGP peer. This would still be 'legal' (something similar to
> recognised
> optional transitive attributes), right ?
>
> I see that "draft-decraene-idr-rfc4360-clarification" talks about
> attaching
> a non-transitive community on the outbound policy. But I guess it should
> not
> matter what method a router uses to originate/attach a community ?
>
> shyam
>
>>
>> This is basically doing on communities what you do on paths tagged with
> NO_EXPORT.
>>
>> Regards,
>>
>> Pierre.
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>