Subject: Beating the ATOMIC_AGGREGGATE horse (was Re: [Idr] draft-ietf-as-pathlimit-02)

From: Jeffrey Haas <[email-masked]>
Date: Fri, 16 Feb 2007 13:46:26 -0500

I'm not actively following IDR at the moment, but I'd like to chime in
for the archives.

It should be noted we had similar churn around ATOMIC_AGGREGATE during
some of the earlier drafts that lead up to RFC 4271.  The current RFC
text reflects some of that.

My personal opinion is that if your implementation is going to attach
ATOMIC_AGGREGATE to routes as the result of filtering more specific
routes, do so when you filter for AS_PATHLIMIT.  If you don't do this
generally, then your sin is no greater for AS_PATHLIMIT.

The most important point is raised below in Curtis's reply: 
Don't de-aggregate.

For posterity, consider the following cases:

1. If you learned a less and a more specific route from a peer and you
   choose to install only the less specific route, the installed less
   specific route should have ATOMIC_AGGREGATE added to it.
 
   Note that you can get away with not attaching ATOMIC_AGGREGATE if the
   AS_PATHs are identical.  Arguably, the other path attributes should
   also be identical, but I won't assert this is provable.

1 is our base case.  It's what 1771 more or less said.  In practice, we
only worry about attaching ATOMIC_AGGREGATE when we're truncating the
AS_PATH as part of the process of creating an explicit aggregate, i.e. a
"new route".  1 is a form of "implicit aggregation".

2. RFC 1771 also noted that we care about this when considering routes
   from a given peer.  In the case where one peer gives us the less
   specific route and another peer gives us a more specific route, we
   must trust that we have received the less specific route correctly
   tagged (or not) with ATOMIC_AGGREGATE.  If it isn't so marked, the
   presumption is that we can get to the more specific network via the
   less specific peer.  I suspect we'd find plenty of examples where
   this isn't the case in practice.  I.e. ATOMIC_AGGREGATE should be
   present, but isn't.

There are other cases where implicit aggregation could occur.

3. If you have installed a more and a less specific route in your LocRib
   and choose to advertise only the less specific route via policy to a
   peer, you should probably mark the less specific route you advertise
   with ATOMIC_AGGREGATE - see 1. for possible exceptions.

   This means that anyone who filters more specific routes should be
   generating ATOMIC_AGGREGATE everywhere.  Given that we know that
   filtering of more specifics is common operational practice and we see
   very little in the way of ATOMIC_AGGREGATE in the Internet routing
   table, implements commonly don't do this.  Additionally, we're
   creating extentions to allow such filtering to be pushed - see ORFs.

4. Go back to 1.  If we receive a more specific and a less specific
   route, but only install the less specific route in our Adj-Rib-In
   (ingress filtering), we have a scneario where we might have to add
   ATOMIC_AGGREGATE depending on the results of route selection.
   However, by filtering, we've lost state.  Without requiring that all
   routes be retained (even if ineligible for route selection by
   policy), we can't properly do step 1.  Common practice is to discard
   ineligible routes - see route refresh.

Even if we keep all routes (see 4), "properly" doing ATOMIC_AGGREGATE
imposes a large amount of additional overhead:
- For 1, after you've completed route selection, you must walk your more
  specific routes in the selected route's adj-rib-in and see if we've
  failed to select any more specific route as well.  Similarly, upon
  updating a route that might be more specific, we must walk all less
  specific routes and see if we need to change the marking.

- For 3, when choosing to place your route in the adj-rib-out, you have
  to see if you're also going to be putting more specifics in the
  adj-rib-out and mark routes appropriately.  Consequently, if you are
  incrementally "updating your adj-rib-out" you may need to change
  whether the route is marked or not - i.e. it can flap depending on the
  particulars of your implementation.  This sort of thing isn't always
  atomic.

- For 4, we don't want to keep all of our ineligible routes around.
  We've actually gone to a lot of effort to provide mechanisms to throw
  them away and be able to deal with that.

Summary: We have a number of test cases we could apply to verify
conformance with properly (at least within my understanding) attaching
ATOMIC_AGGREGATE.  I suspect if you take any given implementation and
try those cases, they'll not pass.  The case that's known to pass is
explicit aggregation with path truncation.  

Conclusion: ATOMIC_AGGREGATE has never quite worked in our specs.  At
best, you can mark a route with it and disallow deaggregation.  I'm not
aware of implementations that have policy that allows for this sort of
de-aggregation today, although that may simply be my ignorance.
Presuming the lack of de-aggregation tools, this has been a non-issue.

We could thus include text about ATOMIC_AGGREGATE in AS_PATHLIMIT or any
other spec.  Personally, I think it's better to not mention it.

On Sat, Dec 23, 2006 at 02:25:45PM -0500, Curtis Villamizar wrote:
> Not quite strong enough.  IMHO.
> 
> You should put ATOMIC_AGGREGATE on any prefix that has AS_PATHLIMIT so
> that any downstream aggregator is forced to form an aggregate with
> ATOMIC_AGGREGATE by virtue of the rule in BGP that if a component of
> the aggregate has ATOMIC_AGGREGATE then any less specific aggregate
> formed using it must have ATOMIC_AGGREGATE.
> 
> I suppose the reason for using SHOULD is that eventually aggregators
> that don't understand AS_PATHLIMIT should go away and with it the need
> for these extra ATOMIC_AGGREGATE.
> 
> We're being a bit pedantic about this whole topic if we look at this
> from a practical standpoint since a long time ago we concluded that
> providers were all using ATOMIC_AGGREGATE and tossing the entire
> AS_PATH when forming an aggregate.  Since ATOMIC_AGGREGATE is
> informational in the absense of de-aggregation this is not terribly
> important.
> 
> The only thing that people were doing that was potentially dangerous
> was combining a /x and /y where x<y and forming a new /x and tossing
> the AS_PATH and adding ATOMIC_AGGREGATE.  That was safe in some
> topologies but generally a vary bad practice.
> 
> Do you agree with that?
> 
> Curtis
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr