Sprint BGP filters in 207.x.x.x?

If we had a good method for people to indicate routes that they didn't want to
be aggregated, then more proxy aggregation could be done safely.

If I may... The idea of using a routing registry for
this purpose has been suggested before. I still think
it is a valid approach. Could be very useful in assisting
with better proxy aggregation for all.

Let me just say I think the RR has some good uses, i.e.
finding out what people intended the routing to look like, etc.

I don't really understand how a RR can help with proxy aggregation
seeing as the route objects really only provide origin AS
and regular aggregation.

It seems to me dual homed sites which are the concence of
proxy aggregation, can be detected with a reasonably full set
of routes, i.e. the second from AS from the origin in the ASPATH
being different. (Or some split in the path outside of an
AS communinity or confederation).

But I don't fully understand all the details of this, so I'm
sure someone can correct me if I'm wrong.

Jeremy Porter <jerry@fc.net> writes:

  > I don't really understand how a RR can help with proxy aggregation
  > seeing as the route objects really only provide origin AS
  > and regular aggregation.

It can help in several ways:

1) If you proxy aggregate you put in a route object for the aggregate.
This infiormation can be used to track down the cause of problems
caused by proxy aggregation.

2) The route object can also contain information about "holes" in an
aggregate, which can be quite useful when evaluating aggregation
strategies.

3) The routing registry also contains 'aut-num' objects describing the
routing policy of each AS: who they peer with, which routes they announce
and accept. Given this information the consequences of proxy aggragation
can be evaluated/simulated before putting a proxy aggregation in place.

Daniel