Modification of RIPE-181's as-in/as-out attributes

In message <199510271935.PAA11969 at 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