Re: Modification of RIPE-181's as-in/as-out attributes
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. ==
Date: Tue, 24 Oct 1995 16:11:59 -0400 From: "Steven J. Richardson" <sjr@merit.edu> Message-Id: <199510242011.QAA26472@home.merit.edu> To: rps@isi.edu Subject: Modification of RIPE-181's as-in/as-out attributes Cc: db-wg@ripe.net, sjr@home.merit.edu Status: RO
In the process of reviewing RIPE-181-represented policies, I've noticed an opportunity for what I think would be a useful modification of the as-in/as-out attributes of the aut-num object.
Currently, the syntax for these attributes is given as:
as-in: from <aut-num> <cost> accept <routing policy expression>
as-out: to <aut-num> announce <routing policy expression>
I see policies which would be usefully condensed via allowing the <aut-num> to be an AS *macro*, too.
E.g.:
aut-num: 99999 as-name: SOMEAS ... as-in: from AS10 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS20 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS30 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS40 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS50 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS60 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS70 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS110 150 accept ANY AND NOT {0.0.0.0/0} as-in: from AS120 150 accept ANY AND NOT {0.0.0.0/0} as-in: from AS130 150 accept ANY AND NOT {0.0.0.0/0} as-in: from AS140 150 accept ANY AND NOT {0.0.0.0/0} as-in: from AS150 150 accept ANY AND NOT {0.0.0.0/0} as-in: from AS160 150 accept ANY AND NOT {0.0.0.0/0} as-in: from AS170 150 accept ANY AND NOT {0.0.0.0/0}
could be equivalent to:
aut-num: 99999 ... as-in: from AS-SOMEAS-100-NO-DEFAULT 100 accept ANY AND NOT {0.0.0.0/0} as-in: from AS-SOMEAS-150-NO-DEFAULT 150 accept ANY AND NOT {0.0.0.0/0}
with the macro definitions:
as-macro: AS-SOMEAS-100-NO-DEFAULT descr: ASs which AS-99999 accepts at pref. 100 (any but descr: the default route) as-list: AS110 AS120 AS130 AS140 AS150 AS160 AS170 ...
as-macro: AS-SOMEAS-150-NO-DEFAULT descr: ASs which AS-99999 accepts at pref. 150 (any but descr: the default route) as-list: AS10 AS20 AS30 AS40 AS50 AS60 AS70 ...
(The same could be said of as-out lines.)
What do you think?
Steve Richardson/Merit
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
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
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
Curtis, Thanks for the clarification. Comments below. Curtis Villamizar (curtis@ans.net) on November 21:
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?
In the proxy aggregation case, both the components and the aggregate needs to be registered. The components would be registered by the originators using their AS numbers, and aggregate would be registered by the proxy using the proxy's AS number.
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)
fine.
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
OK. Let say there are four components, one of them is originated by ANS x/24, 2 by MCI y/24 & z/24 and 1 not allocated w/24 (a true hole). Lets assume the aggregate is v/22. Hence the following route objects: route: x/24 origin: AS690 route: y/24 origin: AS3561 route: z/24 origin: AS3561 route: v/22 origin: AS690 holes: {w/24} component: {x/24} exhange-within AS-expr1 # AS expr specifies which AS's # need these components component: {y/24, z/24} exhange-within AS-expr2 route: v/22 origin: AS3561 holes: {w/24} component: {y/24, z/24} exhange-within AS-expr3 component: {x/24} exhange-within AS-expr4 If AS-expr always and only contains the AS's that originate the components then we do not need the component attribute since a database lookup can tell us this information. But I suppose if ANS and MCI are not direct neighbors, or for efficiency, the AS-expr may need to include other transit AS's. Both holes and component attributes may specify route list returning expressions, e.g. component: {v/22}* AND AS3561 exhange-within AS690 AS3561 If there is a component which is not covered by a component attribute the AS-expr for it is NOT ANY (i.e. that component is not announced any where).
From these objects, one can generate configs (aggregate v/22* AND NOT {w/24}, and appropriate as-out lines using some functions of these route objects like holes_of or components_of, etc).
The route object definition is backward compatible with Ripe181. What do you think? Lets further discuss this at IETF.
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
Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz
participants (3)
-
Cengiz Alaettinoglu -
Curtis Villamizar -
Steven J. Richardson