Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt

[Jeffrey Haas <[e-mail]>]

> On Oct 6, 2016, at 1:27 PM, Job Snijders <[e-mail]> wrote:
> 
> On Wed, Oct 05, 2016 at 11:46:06AM -0400, Jeffrey Haas wrote:
>> I am also unclear on the semantics of why atomic aggregate impacts
>> whether merging happens or not.  (Please don't make me break out 10+
>> year old points as to why AA has been broken from day one.)
> 
> Are you asking whether the aggregate is a merge/union of the
> contributors in case the ATOMIC_AGGREGATE is absent?
> 
> The text was inspired by RFC4360:
> 
>    """
>    6.  Operations
>    <snip>
> 
>    By default if a range of routes is to be aggregated and the
>    resultant aggregates path attributes do not carry the
>    ATOMIC_AGGREGATE attribute, then the resulting aggregate should have
>    an Extended Communities path attribute that contains the set union
>    of all the Extended Communities from all of the aggregated routes.
>    The default behavior could be overridden via local configuration, in
>    which case handling the Extended Communities attribute in the
>    presence of route aggregation becomes a matter of the local policy
>    of the BGP speaker that performs the aggregation.
>    """
> 
> Should a variant of this RFC4360 text be included in the Large BGP
> Communities specification? Or is ATOMIC_AGGREGATE dead and should
> section 3 just be removed?

To be clear, the above statement is largely fine modulo the atomic_aggregate comment.

I'm even fine with a simple cut and paste with appropriate substitutions from 4360, but think that at this point atomic_aggregate is largely just a dead thing.  Considering it just complicates matters unnecessarily.

-- Jeff