Subject: [IPTEL] Aggregation and Communities

From: "William Parton" <[email-masked]>
Date: Thu, 1 Nov 2001 17:11:09 -0000

Section 5.9.4 of draft 9 of the TRIP spec states the following with regard
to aggregating Communities Routing Attributes:

If a set of routes is to be aggregated and the resultant aggregate does not
carry an Atomic_Aggregate attribute, then the resulting aggregate should
have a Communities attribute that contains the union of the Community
attributes of the aggregated routes. 

What is the aggregate for communities if the resultant aggregate does carry
an Atomic Aggregate attribute?

regards
Will

---

From: Manjunath S Bangalore <[email-masked]>
Date: Tue, 06 Nov 2001 17:53:50 -0800

Will,

 Let me take a shot at this -

 If the resultant aggregate has an AtomicAggregate attribute, then it
indicates that there is a loss of information. This is from the
definition of usage of the AtomicAggregate attribute. This attribute,
when included, indicates that a route may actually  include domains not
listed in the RoutedPath. So, including any set of communities along
with the resultant aggregate in such a case, will make the community
attribute incomplete at best.
  Let us now look into the general usage of communities. Communities are
typically used to group destinations that possibly comprise an alliance;
a subset of LSs in an ITAD that share a common role, for instance,can be
combined under a community, etc. From the paragraph preceding Sec 5.9.1,
an example use of the Communities attribute states that

"It is often useful to advertise advertise both the aggregate route and
the
component more-specific routes that were used to form the aggregate.
These component information are only useful to the neighboring TRIP
peer, and perhaps the ITAD of the neighboring TRIP peer, so it is
desirable to filter out the component routes."

Coming back to our original question, though the standard does not say
what value to use for the Community attribute in a resultant aggregate
that carries the AtomicAggregate attribute, we can use some of the
principles from the example above, and here is one approach: A resultant
aggregate route that carries the AtomicAggregate attribute can be
advertised *without* the Community attribute, and individual component
routes can additionally be advertised to specific neighbors or groups of
neighbors with the appropriate value of the Community attribute. This
way, the neighbors to whom the Community value matters get the
information, which can be used to filter routes.

Regards,
-Manjax

William Parton wrote:

>
>
> Section 5.9.4 of draft 9 of the TRIP spec states the following with
> regard to aggregating Communities Routing Attributes:
>
> If a set of routes is to be aggregated and the resultant aggregate
> does not carry an Atomic_Aggregate attribute, then the resulting
> aggregate should have a Communities attribute that contains the union
> of the Community attributes of the aggregated routes.
>
> What is the aggregate for communities if the resultant aggregate does
> carry an Atomic Aggregate attribute?
>
> regards
> Will