Subject: Aggregation of the overlapping routes and ATOMIC_AGGREGATE

From: "Bruno Rijsman" <[email-masked]>
Date: Thu, 11 Jul 2002 06:47:26 -0400

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

I my experience this is what the major deployed implementations do:

1) If the aggregate is an "as-set" aggregate (i.e. the as-path and
   other path attributes of the aggregate are constructed by
   "summarizing" the attributes of the covered routes) then the
   ATOMIC_AGGREGATE attribute is not attached.

2) If the aggregate is not an "as-set" aggregate (i.e. the as-path
   and other path attributes are constructed as if the aggregate
   route is a locally originated route) then the ATOMIC_AGGREGATE
   attribute is attached.

I have seen nothing in RFC1771 or the current draft that describes
this behavior but -as far as I know- that is what happens in real
life.

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

---

From: Kunihiro Ishiguro <[email-masked]>
Date: Thu, 11 Jul 2002 07:47:09 -0700

>   route is a locally originated route) then the ATOMIC_AGGREGATE

Adding to that, when "as-set" is not specified, created aggregated
route has origin IGP.  For example RFC1771 and the latest draft said

      ORIGIN attribute: If at least one route among routes that are
      aggregated has ORIGIN with the value INCOMPLETE, then the
      aggregated route must have the ORIGIN attribute with the value
      INCOMPLETE. Otherwise, if at least one route among routes that are
      aggregated has ORIGIN with the value EGP, then the aggregated
      route must have the origin attribute with the value EGP. In all
      other case the value of the ORIGIN attribute of the aggregated
      route is INTERNAL.

When "as-set" is specifed above rule is applied but when "as-set" is
not specified, the aggregate route always has orgin IGP like self
originated route.  This is little bit implementation specific but some
people may consider.
-- 
Kunihiro Ishiguro

---

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

>    ATOMIC_AGGREGATE attribute is not attached.

Is this actually the case if one of the contributing routes already
ATOMIC_AGGREGATE?

> this behavior but -as far as I know- that is what happens in real

From draft -17:
: 5.1.6 ATOMIC_AGGREGATE
: 
: 
:    ATOMIC_AGGREGATE is a well-known discretionary attribute.
: 
:    When a router aggregates several routes for the purpose of
:    advertisement to a particular peer, and the AS_PATH of the aggregated
:    route excludes at least some of the AS numbers present in the AS_PATH
:    of the routes that are aggregated, the aggregated route, when
:    advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute.

What was only really mentioned in the more recent drafts was the
option of not generating as-sets in the first place.  Prior to
this, implementations that truncated paths were non-compliant.

-- 
Jeff Haas 
NextHop Technologies