In message <199511211858.AA07417@cat.isi.edu>, Cengiz Alaettinoglu writes:
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.
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