In message <199510271935.PAA11969@home.merit.edu>, "Steven J. Richardson" write s:
Actually, I'd like to even extend this further; it would be wonderful to have the "<aut-num>" of both the "as-in" and "as-out" attributes become an expression--called, say, "<as-list expression>"--more like the "<routing policy expression>" which appears later in these attributes.
Whereas the <routing policy expression> evaluates to "a list of one or more ASes, AS Macros, Communities, Route Lists," the <as-list expression> would evaluate to one or more ASs, and would allow the Boolean operators which can be used in the <routing policy expression>.
This is particularly usefule for customers of rps/RIPE-181 who wish to express their policy in the easiest manner--e.g., with NOT, one can specify the set one does _not_ want, as well as the set one wants, and there are a lot of cases where the use of NOT (ASxx ) would be very helpful.
If the <aut-num> -> <as-list> transition makes sense, I think we should wrap the addition of the Boolean operators into this, as well, so that there is a nice, complete syntax for this element of the as-in/as-out attributes (or their equivalent), rather than a "half-baked" version.
How does this sound?
Steve R.
Sounds really nice. If we are making changes to RIPE-181, please also consider the following. Add support for the "ThisAS" described by Cengiz. Add the ability to allow (expression)[=*+]. This would be a comment to some existing software, but otherwise indicate the equivalent to gated exact, refine and normal. Link the RE operators, + (normal) would be a superset of * (refines). It (+) would be the intersection of * and =. If not specified = would be assumed (1.2.3/24 does not indicate 1.2.3.4/32 would be accepted in an as-in). 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). The route expression is the routes used to form the aggregate, which might be ThisRoute* (all refines of this route). 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. 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. We were planning on hacking aggregation with AS-macros and communities and special code for aggregation and export. Having this supported in RIPE-181 would be a Real Good Thing. Another improvement would be to augment as-macro and community. An AS macro contains a list. A community is referenced by the routes in the community. It might be would having the analogous objects: 1) an object that can be referenced from an autnum, like community is referenced by routes, 2) ab object that contains a list of routes, like AS-macro contains a list of AS numbers. The reason has to do with authorization. There is a need for a list of routes under a common administration. There might be a need for an AS collection that can be added to incrementally (less likely). The new objects could be called route-macro and as-community. These seem to be the most pressing. Having a link field in inet-rtr with a protocol, peer router and metric might help configuring the IGP. We currently have this in a remark (and are not using it yet, as is evident since it is wrong in most of our inet-rtr at the moment). Curtis