Aggregation (was Re: Modification of RIPE-181's as-in/as-out attributes)
- Previous message (by thread): NEW *BETA* release RIPE database: ripe-dbase-1.1beta.tar.gz
- Next message (by thread): Aggregation (was Re: Modification of RIPE-181's as-in/as-out attributes)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Cengiz Alaettinoglu
cengiz at ISI.EDU
Tue Nov 21 19:58:27 CET 1995
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
- Previous message (by thread): NEW *BETA* release RIPE database: ripe-dbase-1.1beta.tar.gz
- Next message (by thread): Aggregation (was Re: Modification of RIPE-181's as-in/as-out attributes)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]