Sorry for a late reply to this message. Curtis Villamizar (curtis@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