Apologies in advance for the overly-detailed nature of this post. I'd like to thank the individuals who responded to me regarding de-aggregation in BGP. Overall, I had about 40 responses. In general, the responses were encouraging. Largely this was because most of the people who responded didn't know what kind of de-aggregation I was talking about. If you will indulge me a minute: ISPs are typically assigned some netblock to make their internal allocations from. This netblock is divided into subnets which are internally used at various POPs, etc. But overall, unless some portions of this block are re-allocated to customers outside a given AS, a given netblock can be thought to belong to an AS. Best Current Practice is to advertise this netblock, or at least some portion of it and *not* to advertise the individual subnets. In general, aggregation is your friend and will make the Net a happy place. But as we all know, providers will often advertise their internal more- specific routes for a variety of purposes. The biggest one is for traffic engineering purposes. The majority of the respondents noted that when they do this form of "de-aggregation" (or what I prefer to just call "leaking more-specifics"), they will usually mark them with the NO_EXPORT community and typically only advertise them to peers and their direct upstreams. In other cases, the NO_EXPORT community isn't added with the explicit purpose of engineering incoming traffic. While advertising your more specific routes is a degenerate form of de-aggregation, the form I was looking for was explicit de-aggregation of routes where the more specific did not previously exist. This could, at its worst, be a form of proxy de-aggregation by a second party. Of the respondents, only three cases ever showed up for this: 1. The ones who remember the bad-old days of BGP3 and classful networks where it was necessary to do this at your BGP4->3 borders. 2. Where routes were de-aggregated internally to better shape traffic flows, typically setting NO_ADVERTISE so as to not accidentally alter the intended announcements of the ISP. Note that this was the subject of a NANOG presentation: http://www.nanog.org/mtg-0206/ppt/abley/ 3. Doing this form of de-aggregation intentionally at your border and advertising the more specifics in order to mitigate a routing DoS due to someone claiming your address space. ---- What brought about this question? The BGP-4 specification (draft-ietf-idr-bgp4-17, rfc1771, rfc1654) was largely crafted to add support for CIDR to Internet routing. Aggregation was a relatively new thing. As part of the transition, it was necessary for networks who aggregated to be able to de-aggregate their networks into classful networks. In any case where de-aggregation happens, there is the possibility that either one of the generated more specifics will make it back to the networks that have previously announced the component networks. This can cause forwarding loops. So long as those AS's are reflected in the AS_PATH, its a non-issue since their routers will drop the announcements. The BGP-4 specification, knowing this was an issue, provided two mechanisms to prevent this from being an issue. The first is that when an aggregate is synthesized (explicit aggregation, say via an "aggregate" statement in your router), the AS_PATH attribute would also be aggregated. The second case deals with implicit aggregation. If you have a less specific and a more specific route, and choose to announce only the less specific route, you have implicitly aggregated it. For example: R1: 10/8 AS_PATH 1 2 3 4 5 R2: 10/24 AS_PATH 6 7 If you announce only R1 or even only install R1 in your routing table, you have an imiplicit aggregation scenario. In the above example, if you only announce R1, you have a component that will follow a different path. In these cases, the BGP Path Attribute ATOMIC_AGGREGATE was intended to be added to signal that you should not de-aggregate this route since path information has been lost that could lead to forwarding loops. The base BGP-4 specification (rfc 1771) provided adding ATOMIC_AGGREGATE only in the case where you had a more and a less specific route from a given peer. The current draft-ietf-idr-bgp4-17 covers the case seen commonly today where a truncated AS_PATH due to creating an explicit aggregate (default Cisco behavior without the as-set option, the default "full" behavior in Juniper and the "brief" behavior from GateD) will add ATOMIC_AGGREGATE as well. The first case in the above paragraph is not implemented by any of the above implementations. The second case is implemented by all of them. The missing third case (from the specification) where the implicit aggregation is done on export isn't covered in the spec and thus wouldn't be implemented. There is a strong argument against actually implementing ATOMIC_AGGREGATE as defined in the spec, and especially so if you add in the missing case from the specification. This argument mainly comes down to the fact that a lot of additional memory would be wasted for almost no benefit. Implications: The BGP specification should be revised to reflect reality: No one fully implements ATOMIC_AGGREGATE. The existing case where AS_PATHs are truncated should be left in the specification and the implicit aggregation cases should be removed. The specification should be revised to note the situation ATOMIC_AGGREGATE was intended to deal with but recommend due to lack of implementation that operators be strongly discouraged from explicitly de-aggregating due to the dangers of forwarding loops. Thanks for your input and your patience. Any feedback on this analysis would be appreciated. (And this all started as an attempt to properly document ATOMIC_AGGREGATE in the BGP MIB. :-) -- Jeff Haas NextHop Technologies