I have done it again and forgot to forward these messages to db-wg the first time. Here it is. If you reply to these messages, please include rps@isi.edu on the CC line. ------- start of digest (3 messages) (RFC 934 encapsulation) ------- From: Cengiz Alaettinoglu <cengiz@ISI.EDU> To: rps@ISI.EDU Subject: [Cengiz Alaettinoglu]:Use of AS-Macros in event parameters and keyword ThisAS Date: Tue, 24 Oct 1995 19:05:34 -0700 Message-Id: <199510250205.AA02012@cat.isi.edu> - ------- start of forwarded message (RFC 934 encapsulation) ------- Posted-Date: Tue, 17 Oct 1995 10:19:16 -0700 From: Cengiz Alaettinoglu <cengiz@ISI.EDU> To: Curtis Villamizar <curtis@ans.net>, Craig Labovitz <labovit@merit.edu>, Marten Terpstra <marten@baynetworks.com>, Tony Bates <tony@mci.net>, Daniel.Karrenberg@ripe.net, Jessica Yu <jyy@ans.net> Cc: Cengiz Alaettinoglu <cengiz@ISI.EDU> Subject: Use of AS-Macros in event parameters and keyword ThisAS Date: Tue, 17 Oct 1995 10:19:16 -0700 Hi folks, Remember in Stockholm IETF we aggreed to have the following event parameters: event-name peer-as local-int remote-int import/as-in * * * AS# * * AS# address * AS# address address What about adding AS-MACROS to this list: event-name peer-as local-int remote-int import/as-in AS# | AS-MACRO | * * * AS# | AS-MACRO | * address * AS# | AS-MACRO | * address address With this, one can write: as-out: to AS-ANS-CUSTOMERS * * announce ANY AND NOT {0.0.0.0/0} If AS-ANS-CUSTOMERS expands to AS1 AS2, this is semantically equivalent to: as-out: to AS1 * * announce ANY AND NOT {0.0.0.0/0} as-out: to AS2 * * announce ANY AND NOT {0.0.0.0/0} Also a new keyword ThisAS: when * or AS-MACRO is used instead of an AS no in an event parameter, ThisAS is replaced by the AS# in the AS-MACRO expansion. For example: as-in: from AS-ANS-CUSTOMERS * * accept <ThisAS$> AND ThisAS AND NOT {0/0} is equivalent to: as-in: from AS1 * * accept <AS1$> AND AS1 AND NOT {0/0} as-in: from AS2 * * accept <AS2$> AND AS2 AND NOT {0/0} The main advantage of this one is scaling. most policies in the IRR can be written using these. The main disadvantage is that the language is getting more constructs, people need to learn more. I think this is OK, since one can still specify his/her policies without knowing this feature. One of our design goals is that simple policies can be specified without knowing the whole language, yet language is more expressive for those who are willing to take the extra step. I would like to know your opinions on this before I forward this message to the rps list. Also, let me know if you can think of a better keyword than ThisAS. Credits: Use of AS-MACROS in event parameters is originally Curtis's idea. Generalization with ThisAS is mine. Cengiz - - -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz.home - ------- end ------- Cengiz - -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz.home ------------------------------ From: Cengiz Alaettinoglu <cengiz@ISI.EDU> To: rps@ISI.EDU Subject: [Jessica Yu]:Re: Use of AS-Macros in event parameters and keyword ThisAS Date: Tue, 24 Oct 1995 19:06:03 -0700 Message-Id: <199510250206.AA02017@cat.isi.edu> - ------- start of forwarded message (RFC 934 encapsulation) ------- Message-Id: <199510171914.PAA07399@cannes.aa.ans.net> From: Jessica Yu <jyy@ans.net> To: cengiz@ISI.EDU Cc: curtis@ans.net, labovit@merit.edu, marten@baynetworks.com, tony@mci.net, Daniel.Karrenberg@ripe.net, jyy@ans.net Subject: Re: Use of AS-Macros in event parameters and keyword ThisAS Date: Tue, 17 Oct 1995 15:14:17 -0400 I think both are good ideas especially the AS-Macros one. Are there any tools out there which will be effected due to this change? I know the tool which constructs a topology diagram based on as-in/out information would be affected with this change. Not sure if such tool exists already though we have been talking about it for a long time. --Jessica - ------- end ------- Cengiz - -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz.home ------------------------------ From: Cengiz Alaettinoglu <cengiz@ISI.EDU> To: rps@ISI.EDU Subject: [Curtis Villamizar]:Re: Use of AS-Macros in event parameters and keyword ThisAS Date: Tue, 24 Oct 1995 19:07:37 -0700 Message-Id: <199510250207.AA02021@cat.isi.edu> - ------- start of forwarded message (RFC 934 encapsulation) ------- Message-Id: <199510171949.PAA06754@brookfield.ans.net> From: Curtis Villamizar <curtis@ans.net> To: Cengiz Alaettinoglu <cengiz@ISI.EDU> Cc: Curtis Villamizar <curtis@ans.net>, Craig Labovitz <labovit@merit.edu>, Marten Terpstra <marten@baynetworks.com>, Tony Bates <tony@ns.mci.net>, Daniel.Karrenberg@ripe.net, Jessica Yu <jyy@ans.net> Subject: Re: Use of AS-Macros in event parameters and keyword ThisAS Date: Tue, 17 Oct 1995 15:49:36 -0400 In message <199510171719.AA20102@cat.isi.edu>, Cengiz Alaettinoglu writes:
What about adding AS-MACROS to this list:
event-name peer-as local-int remote-int import/as-in AS# | AS-MACRO | * * * AS# | AS-MACRO | * address * AS# | AS-MACRO | * address address
With this, one can write: as-out: to AS-ANS-CUSTOMERS * * announce ANY AND NOT {0.0.0.0/0}
If AS-ANS-CUSTOMERS expands to AS1 AS2, this is semantically equivalent to: as-out: to AS1 * * announce ANY AND NOT {0.0.0.0/0} as-out: to AS2 * * announce ANY AND NOT {0.0.0.0/0}
Also a new keyword ThisAS: when * or AS-MACRO is used instead of an AS no in an event parameter, ThisAS is replaced by the AS# in the AS-MACRO expansion. For example:
as-in: from AS-ANS-CUSTOMERS * * accept <ThisAS$> AND ThisAS AND NOT {0/0}
is equivalent to:
as-in: from AS1 * * accept <AS1$> AND AS1 AND NOT {0/0} as-in: from AS2 * * accept <AS2$> AND AS2 AND NOT {0/0}
The main advantage of this one is scaling. most policies in the IRR can be written using these.
This is a small incremental change that does help quite a bit. The problem is really that there are a few customer types and generally all customers of the same type get the same treatment. type routes full-routing no-transit all ANS direct (with-transit) customers full-routing with-transit everything partial-routing no-transit subset of ANS customers (mostly dual homed) partial-routing with-transit subset of everything (mostly dual homed) default (always with-transit) There is no convenient way to express this in RIPE-181 (or RPSL). The idea is if an AS falls into one of a few special AS-Macros it gets certain predefined export treatment. The treatment itself can be expressed using AS-Macros. For example, full-routing no-transit would get ANS-TRANSIT-CUSTOMERS. There is currently no way to say: as-out: to ( AS690-TRANSIT-CUSTOMERS and AS690-WANT-FULL-ROUTES ) \ * * announce ( AS690-TRANSIT-CUSTOMERS \ and not ( ThisAS or <ThisAS$> or AS690-VPNS \ or AS690-AGGR++ or AS690-PROXY++ \ or ( AS690-IGPONLY++ \ and not ThisAS-IGPONLY++ ) ) ) The others would be similar. There might have to be an "and not AS690-SPECIAL-CASES" somewhere. I would imagine that an AS that is expanded into two or more different expressions would be an considered an ambiquity error. There is another issue that Cengiz did not touch on. In forming and handling aggregates and forming export policy, often all more specific routes of a given aggregate need to be handled in some way, but it is easier if we don't have to name them all. This applies to next hop refinement, simple aggregation, proxy aggregation, and aggregation across providers. Gated has the refines keyword which I've shown above as ++. I've also shown ThisAS-IGPONLY++ to indicate an AS that is part of a multiprovider aggregate. Expanding this to something like AS3561-IGPONLY++ would be a nice feature. The more we hack stuff like this into our tools, the less what is registered in the IRR will reflect reality. We need these kinds of features to keep our routing sane without making our people go insane so we might as well put them into RPSL. For RIPE-181 this will be hacked into special code that uses AS macros and communities (although right now export is done by hand, a rather tedious task). A real useful change to RIPE-181 to support this would be to allow AS-Macros and community names to allow digits and [_-] but not the form AS\d+ (in perl RE notation). Curtis - ------- end ------- Cengiz - -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz.home ------- end ------- Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz.home