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

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.  

> 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.

> 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?

> 
> 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.

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.

What do you think?

Cengiz

-- 
Cengiz Alaettinoglu       Information Sciences Institute
(310) 822-1511            University of Southern California
http://www.isi.edu/div7/people/cengiz