Followup on de-aggregation (was Re: ISPs who de-aggregate intentionally?)

Fri Sep 13 20:39:07 UTC 2002

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