Re: When can NLRI and Withdrawn Route info be modified?

Brad Smith <brad@cse.ucsc.edu> Fri, 03 May 1996 21:58 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28101; 3 May 96 17:58 EDT
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa28096; 3 May 96 17:58 EDT
Received: from p-o.ans.net by CNRI.Reston.VA.US id aa23538; 3 May 96 17:58 EDT
Received: (from majordom@localhost) by p-o.ans.net (8.7.5/8.7.3) id VAA14874 for bgp-outgoing; Fri, 3 May 1996 21:43:22 GMT
X-Authentication-Warning: p-o.ans.net: majordom set sender to bgp-owner using -f
Date: Fri, 3 May 1996 14:43:15 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Brad Smith <brad@cse.ucsc.edu>
Message-Id: <199605032143.OAA03815@toltec.cse.ucsc.edu>
To: pst@cisco.com
Subject: Re: When can NLRI and Withdrawn Route info be modified?
Cc: bgp@ans.net
X-Orig-Sender: bgp-owner@ans.net
Precedence: bulk
Reply-To: bgp@ans.net

>   The answer to the following may be obvious, by definition, but I want
>   to make sure I understand... is it true that an ATOMIC_AGGREGATE will
>   only be generated in a situation where an AGGREGATE attribute would
>   also be generated? (Even writing this I realize that it could be read
>   as "is it true that aggregation is done only when aggregation is being
>   done"... but I'll leave the question on the table:).
> 
> There is no such thing as an aggregate attribute.  There's no real way to
> tell if a route is an aggregate or not.  There are intelligent guesses
> (does it have an AA, or are there any AS sets in the path), but those aren't
> sure things and should not be relied upon.

Ooops... I meant "AGGREGATOR".  The (short) section in the RFC describing
this says:

    AGGREGATOR is an optional transitive attribute which may be included
    in updates which are formed by aggregation (see Section 9.2.4.2).  A
    BGP speaker which performs route aggregation may add the AGGREGATOR
    attribute which shall contain its own AS number and IP address.

Is this also not widely implemented?

Thanks,

Brad