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

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 at isi.edu on the CC line.

------- start of digest (3 messages) (RFC 934 encapsulation) -------
From: Cengiz Alaettinoglu <cengiz at ISI.EDU>
To: rps at 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 at cat.isi.edu>


- ------- start of forwarded message (RFC 934 encapsulation) -------
Posted-Date: Tue, 17 Oct 1995 10:19:16 -0700
From: Cengiz Alaettinoglu <cengiz at ISI.EDU>
To: Curtis Villamizar <curtis at ans.net>, Craig Labovitz <labovit at merit.edu>,
        Marten Terpstra <marten at baynetworks.com>, Tony Bates <tony at mci.net>,
        Daniel.Karrenberg at ripe.net, Jessica Yu <jyy at ans.net>
Cc: Cengiz Alaettinoglu <cengiz at 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 at ISI.EDU>
To: rps at 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 at cat.isi.edu>


- ------- start of forwarded message (RFC 934 encapsulation) -------
Message-Id: <199510171914.PAA07399 at cannes.aa.ans.net>
From: Jessica Yu <jyy at ans.net>
To: cengiz at ISI.EDU
Cc: curtis at ans.net, labovit at merit.edu, marten at baynetworks.com, tony at mci.net,
        Daniel.Karrenberg at ripe.net, jyy at 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 at ISI.EDU>
To: rps at 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 at cat.isi.edu>


- ------- start of forwarded message (RFC 934 encapsulation) -------
Message-Id: <199510171949.PAA06754 at brookfield.ans.net>
From: Curtis Villamizar <curtis at ans.net>
To: Cengiz Alaettinoglu <cengiz at ISI.EDU>
Cc: Curtis Villamizar <curtis at ans.net>, Craig Labovitz <labovit at merit.edu>,
        Marten Terpstra <marten at baynetworks.com>, Tony Bates <tony at ns.mci.net>,
        Daniel.Karrenberg at ripe.net, Jessica Yu <jyy at 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 at 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