Subject: Aggregation of the overlapping routes and ATOMIC_AGGREGATE

From: "Fryczke, Pawel" <[email-masked]>
Date: Thu, 11 Jul 2002 12:32:14 +0200

Latest BGP draft states:
"If a BGP speaker receives overlapping routes, the Decision Process
MUST consider both routes based on the configured acceptance policy.
If both a less and a more specific route are accepted, then the
Decision Process MUST either install both the less and the more
specific routes or it MUST aggregate the two routes and install the
aggregated route, provided that both routes have the same value of
the NEXT_HOP attribute.
If a BGP speaker chooses to aggregate, then it MUST add
ATOMIC_AGGREGATE attribute to the route."

What does happen if BGP router installs both routes in RIB and next
aggregates them ?
Should ATOMIC_AGGREGATE be added to aggregate or not ?

Consider scenario:
BGP Router is configured to aggregate routes 192.0.0.0/8
This router receives 2 NLRIs: 192.0.0.0/8 and 192.1.0.0/16
Received NLRIs are installed in RIB, but are suppressed by aggregation and
are not advertised.
As a result of aggregation the router sends update that contains only one
NLRI: 192.0.0.0/8
Does this update should contain ATOMIC_AGGREGATE attached ?

Why does RFC assume that aggregation is done during decision process?
It is possible to aggregate during update process or some other process,
isn't it?

Pawel

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 16 Jul 2002 11:39:33 -0400

> Received NLRIs are installed in RIB, but are suppressed by aggregation and

Assuming you mean "suppresed by export policy because they
are contributors to an aggregate"...

> Does this update should contain ATOMIC_AGGREGATE attached ?

According to the spec?  No.
Logically, yes.
An attempt was made to address this in -16, but it was determined
that the rules of whether or not AA was to be attached to make
proper semantic (rather than spec-defined) sense imposed the necessity
of keeping too much state.

My recommendation - treat AA as a piece of fluff.  Add it like
everyone else does when suppressing as's from an aggregated as-path.
Also add it when you suppress more specifics in your adj-ribs-in if
you want to be compliant, but its work that is unappreciated by
the Internet at large.

> Why does RFC assume that aggregation is done during decision process?

Logically, because routes are installed in LocRib/Adj-Ribs-Out during
this phase and Update-Send just sends Adj-Ribs-Out.

-- 
Jeff Haas 
NextHop Technologies