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

[Cengiz Alaettinoglu cengiz@localhost]

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@localhost on the CC line.

------- start of digest (3 messages) (RFC 934 encapsulation) -------
From: Cengiz Alaettinoglu cengiz@localhost
To: rps@localhost
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@localhost


- ------- start of forwarded message (RFC 934 encapsulation) -------
Posted-Date: Tue, 17 Oct 1995 10:19:16 -0700
From: Cengiz Alaettinoglu cengiz@localhost
To: Curtis Villamizar curtis@localhost, Craig Labovitz labovit@localhost,
        Marten Terpstra marten@localhost, Tony Bates tony@localhost,
        Daniel.Karrenberg@localhost, Jessica Yu jyy@localhost
Cc: Cengiz Alaettinoglu cengiz@localhost
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@localhost
To: rps@localhost
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@localhost


- ------- start of forwarded message (RFC 934 encapsulation) -------
Message-Id: <199510171914.PAA07399@localhost
From: Jessica Yu jyy@localhost
To: cengiz@localhost
Cc: curtis@localhost, labovit@localhost, marten@localhost, tony@localhost,
        Daniel.Karrenberg@localhost, jyy@localhost
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@localhost
To: rps@localhost
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@localhost


- ------- start of forwarded message (RFC 934 encapsulation) -------
Message-Id: <199510171949.PAA06754@localhost
From: Curtis Villamizar curtis@localhost
To: Cengiz Alaettinoglu cengiz@localhost
Cc: Curtis Villamizar curtis@localhost, Craig Labovitz labovit@localhost,
        Marten Terpstra marten@localhost, Tony Bates tony@localhost,
        Daniel.Karrenberg@localhost, Jessica Yu jyy@localhost
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@localhost, 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