Aggregation (was Re: Modification of RIPE-181's as-in/as-out attributes)

In message <199511211858.AA07417 at cat.isi.edu>, Cengiz Alaettinoglu writes:
> 
> Sorry for a late reply to this message.
> 
> Curtis Villamizar (curtis at ans.net) on October 27:
> > Add an aggregate-by field and change the holes field in the route
> > object.  The aggregate-by should have <as-expr> [opts] <route-expr>.
> > The AS expression is who forms the aggregate (could be an expression,
> > a macro, whatever).  
> 
> Isn't the AS in the origin attribute of the route performing the
> aggregation? In other words, if a route is aggregated by more than one
> domain, each would have a route object with their AS number in the
> origin. So I am not sure if the <as-expr> in the aggregate-by field
> is useful or not.  

I was thinking of proxy aggregation where you want to accept
everything more specific except some holes and then aggregate it.  In
this case, the origin AS of the more specific prefixes would be
different from the aggregator.  Maybe there is a better way to do
this?

> > The route expression is the routes used to form
> > the aggregate, which might be ThisRoute* (all refines of this route).
> 
> The ripe-181 way of specifying the <route-expr> implicitly was: 
> 	ThisRoute* AND NOT { list of holes }
> 
> I think having the components explicitly specified is a good idea.

If there are holes, you need to know how to route them, not just that
there are holes.  So having separate route objects for the holes is
probably a real good idea.  I was proposing (at NANOG) using a
community to indicate that the AS doing the aggregation must also pass
the component in order to not screw up routing.

There also needs to be greater flexibility in choosing what not to
aggregate.  For example, I may want to form an aggregate and advertise
it to everyone and some other provider might want to form the same
aggregate and advertise it to everyone.  We would have to exclude each
other from the AS set or form an atomic aggregate.  This is also
rather a problem at the border router.  The two aggregating parties
need to form an aggregate and announce to each other and accept and
prefer each other's aggregate.  They also must suppress the two router
loop (which I think most routers do automatically, at least NSS do).

Is this a bad idea?  Otherwise, I can't see how ANS and MCI could
aggregate the customers in Canada that we serve without sending all
the components routes to each other (as an example).  Maybe that is
the best we can do, at least helping other providers and hoping a
third provider will cooperate and allow similar aggregation benefiting
ANS and MCI or hoping that the technique can be applied elsewhere.

> > The opt might be [ATOMIC-AGGR] or some other option.  The holes field
> > needs to specify all the AS that needed components when doing an
> > aggregation over multiple AS.  It needs an optiona <as-expr>.  The
> > holes field should allow a route expression rather than just a single
> > route.  The holes field would the be <route-expr> or <as-expr>
> > <route-expr>.  If the AS expression is omitted it means the hole needs
> > to be routed to the entire world to get routing right.
> 
> I think you are assigning new semantics to the holes field. If X has
> 128/8 and Y has 129/8 and if they decide to form an aggregate 128/7,
> you need the components to be routed in X and Y even though the
> aggregate have no holes. Is this what you are trying to document in
> this field?

Actually, I think I have sematics in mind that are not really
supported yet and I'm looking for ways to express them.

> > The aggregate-by can be used to configure aggregation.  The holes can
> > be used to control full leak of components for multiprovider
> > aggregation.  The holes should be specified reliably enough that
> > export policy of a router can block more specifics of any aggregate.
> > It would be a real nice thing if we could specify:
> > 
> >   route: xxx/8
> >   aggregate-by: EUROPEANS { xxx/8* }
> >   holes: EUROPEANS { xxx/8* }
> > 
> >   route: yyy/8
> >   aggregate-by: NORTHAMERICANS { yyy/8* }
> >   holes: NORTHAMERICANS { yyy/8* }
> > 
> > And have the export (and import) on the routers determined by whether
> > the target AS is in the AS-MACRO.  More likely expressions with one or
> > two AS or a small AS-MACRO would appear in the nearterm.
> 
> Let me see. You want the route object to specify import and export
> policies of domains (looks like advisories to me). I would be more
> comfortable if we defined some operators/functions and specify import
> and export policies using these operators/functions.

No this is aggregation.  If it crosses provider boundaries, then it
needs to be in the route object.  If AS690 forms an aggregate and has
origin AS 690 on the aggregate, then AS690 controls the scope of the
aggregate.  I've proposed we do this by convention by setting some
communities.  I'd rather the route object had explicit support rather
than us relying on communities and conventions.

If I change aggregation, I don't want to edit every as-out line to
reflect the new policy.  I'd rather express it in terms of special
communities and tag the aggregates and components with the community
names.  Part of what I've been suggesting (in nanog) is specially
named communities and usage conventions.

> For example, lets define a function holes_of(<as-no>) which returns
> the route expressions of the holes attributes where the as-no
> appears. Then, 
> 
> 	as-out: to ASfoo announce holes_of(ASfoo)
> 
> would do. The advantage of this is that the route object does not
> specify how that route is imported/exported, yet the information that
> is available there can be used at the discretion of a domain.

How about:

  as-out: to ASfoo announce myAS and not holes_of(myAS)

The way I'm coding it (using communities), it comes out looking more:

  as-out: to ASfoo announce ALL and not ( MyAggr* and not MyComp )

This may not be all that clear.  The intention is announce everything
except block components of aggregates, but don't block specific
components (dual homed sites or other holes).

One problem with the holes is that there are two separate things we
need to express:

  what gets left out when forming the aggregate
  what gets explicitly announced even though it overlaps the aggregate

These can be two different sets.  

> What do you think?

I think we can live with using communities to do what we want to do
except maybe blocking specific things from the aggregation.  There we
may need to block based on AS paths (for example, don't aggregate
anything with MCI in it if you know it overlaps some MCI stuff and you
will need to send the aggregate to MCI).

> Cengiz

Curtis