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

[Job Snijders <[e-mail]>]

Hi Group,

Section 3 currently is as following:

	"""
    3.  Aggregation

    If a range of routes is aggregated and the resulting aggregates
    attribute section does not carry the ATOMIC_AGGREGATE attribute,
    then the resulting aggregate should have a Large Communities path
    attribute which contains all of the large communities from all of
    the aggregated routes.
    """

Jeff made the following comment:

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?

Kind regards,

Job