suggestions for RIPE-81

	(Sorry if you have already received this information
from another list. You can forward this mail to /dev/null.)

	Merit Network Inc. has been running a Routing Registery for
about 3 weeks now. Our software is based on the RIPE database distribution
(beta version), plus some changes we did to meet our requirements. The main 
ones are:
- support of aggregates in the inetnum object.
- extension to the RIPE-81 policy syntax to support US autonomous system
policies (in particular AS 690 - NSFNET)
- development of a 'Policy Server' (called alcd) which is used by 
astrace (a prtraceroute like tool) to query the database (instead of whois). 
The server does the difficult task of parsing the policy, making 
prtraceroute and any other tools easier to design.

	We also developped a few tools to work with the registery.
We'd like to propose our new syntax as an official extension for the 
RIPE-81 document, and ask this working group to discuss/comment/modify 
it and (I hope) accept it.  A detailed description of the syntax is available on
rrdb.merit.edu:pub/meritrr/policy_syntax.txt (FTP anonymous) and the
main extensions are:
	- AS path (limited)
	- Explicit listing of exported/imported networks
	- Per interface policy description
	- More detailed default policy
This syntax is fully backward compatible with RIPE-81 and the software has 
been running in production for 3 weeks without any major problems 
(bugs, bugs... :-). I'd be glad to give a presentation of our registery 
and tools during the next RIPE meeting but in order to give you time to 
read and evaluate our work I have sent this announcement. Following are 
an example of our tools. Enjoy.

		Laurent

PS: Everything (tools, DB software, documentmentation) is available on
rrdb.merit.edu:pub/meritrr.
PS/2: This is part of my action item from the last RIPE meeting to
propose these extensions.

Another prtraceroute (called astrace) output:

(lpj at merit: 71) astrace ftp.ripe.net
Connected to ALC server
traceroute to ns.ripe.net (192.87.45.1) with AS and policy additions

 1 AS 237  eth1.michnet1.mich.net         35.1.1.127      [INT  0      0] 
 2 AS 233  fd-0.enss131.t3.ans.net        192.203.195.1   [INP  1 !RO -1] 
 3 AS 690  t3-1.Cleveland-cnss41.t3.ans.n 140.222.41.2    [!RO -1 !RO -1] 
 4 AS 690  mf-0.Cleveland-cnss40.t3.ans.n 140.222.40.222  [INT  0      0] 
 5 AS 690  t3-1.New-York-cnss32.t3.ans.ne 140.222.32.2    [INT  0      0] 
 6 AS 690  t3-1.Washington-DC-cnss56.t3.a 140.222.56.2    [INT  0      0] 
 7 AS 690  mf-0.Washington-DC-cnss58.t3.a 140.222.56.194  [INT  0      0] 
 8 AS 690  t3-0.enss145.t3.ans.net        140.222.145.1   [INT  0      0] 
 9 AS ???  192.203.229.245                192.203.229.245 [!RO -1 ?AS  0] 
10 AS ???  icm-dc-1-H1/0.icp.net          192.157.65.121  [INT  0      0] 
11 AS ???  192.157.65.226                 192.157.65.226  [INT  0      0] 
12 AS1128  194.41.0.17                    194.41.0.17     [?AS  0 !RO -1] 
13 AS1104  hef-router.nikhef.nl           192.87.4.21     [!RO -1 !RO -1] 
14 AS3333  ns.ripe.net                    192.87.45.1     [!RO -1 !RO -1] 

AS Path followed:  237 233 690 ??? 1128 1104 3333

AS 237 = MichNet
AS 233 = UMnet
AS 690 = NSFNET/ANSNET
AS1128 = SURFNET-AS
AS1104 = SURFNET-AS
AS3333 = RIPE-ASNBLOCK4

Example of an aggregate:

(lpj at merit: 82) whois -h rrdb.merit.edu 192.87/16
inetnum:   192.87/16
netname:   SURFNET-C-AGGR
descr:     SURFnet
descr:     P.O. Box 19035
descr:     NL-3501 DA Utrecht
descr:     NETHERLANDS
country:   NL
aut-sys:   AS1103
nsf-in:    1=1800 2=1133 3=1674 4=1240
changed:   skw at merit.edu 940401
source:    PRDB

	The syntax...

------------------------------------------------------------------------------

      Copyright (c) 1993 The Regents of the University of Michigan and
      Merit Network, Inc.   All Rights Reserved

 Permission to use, copy, modify, and distribute this software and its 
 documentation for any purpose and without fee is hereby granted, provided 
 that the above copyright notice and this permission notice appear in all 
 copies of the software and derivative works or modified versions thereof, 
 and that both the copyright notice and this permission and disclaimer notice
 appear in supporting documentation. 
  
 THIS SOFTWARE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER 
 EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION WARRANTIES OF 
 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE REGENTS OF THE 
 UNIVERSITY OF MICHIGAN AND MERIT NETWORK, INC. DO NOT WARRANT THAT THE 
 FUNCTIONS CONTAINED IN THE SOFTWARE WILL MEET LICENSEE'S REQUIREMENTS OR 
 THAT OPERATION WILL BE UNINTERRUPTED OR ERROR FREE. The Regents of the 
 University of Michigan and Merit Network, Inc. shall not be liable for any 
 special, indirect, incidental or consequential damages with respect to any 
 claim by Licensee or any third party arising from use of the software. 


-------------------DRAFT DRAFT--------------------------

	Representation of Complex Routing Policies of
		an Autonomous System
		Version 0.0.3
		03-10-94

I.	Background

The community of IP network providers and operators are unanimous
in their desire to define their own routing policies
independent of any core infrastructure of the Internet.
Due to numerous different routing policies which impact the
ability to achieve global connectivity, several groups have
worked together to develop a description language which clearly
expresses the various policies. RIPE-60 and RIPE-81 tackled the
problem of representing the description of routing policies of
European Autonomous Systems.[1,2]  Yu, Chen, and Rekhter defined
a Policy Description Language which describes very 
complex routing policies. [3] In addition, Laurent Joncheray
documented the syntax to describe the policies implemented by
Merit's Route Server. [4]

The RIPE Network Coordination Center has implemented the recommendations
of RIPE-81, and has become a repository for publishing the routing
polices of European ASs. The RIPE NCC and Merit Network Inc. have
collaborated to define a minimum set of attributes which are needed
to represent routing policy, and both organizations will maintain
routing policy information based on this minimum set of attributes.
In addition to the minimum set, Merit will implement and will define
some extensions to the syntax based on previous work [1,2,3,4]
which will permit the description of more complex routing policies.

As RIPE and Merit continue to collaborate to define a syntax
which clearly expressses the routing policies which are implemented
by network service providers and operators, our goal is that the
registration of routing policies, no matter how simple or complex,
will aid the network operators in diagnosing and resolving
routing problems. 

This document focuses on the extensions and defines the attributes
which provide the capability to describe more complex routing
interactions. The more complex routing policies which can be described
include: 
	
	a. announcements and acceptances of routing information at
	   network granularity 
	b. grouping of networks into communities of interest 
	c. syntax to describe peer gateway interactions/preferences 
	d. expansion of the default syntax 
	e. introduction of transit and exclusion syntax 
	f. syntax to assign metrics to outbound and inbound announcements

 
II. Explanation and Examples of the Policy Description 

This section describes the routing policy statements.  For each
statement, the function of the statement is followed by a simple
format explanation.  Examples of how to use the syntax to express policy 
are illustrated and the formal syntax is defined in Appendix C. The yacc 
description in Appendix C is authoritative.

Policy is described by six attributes:

	- 'as-in' and 'as-out' to specify the policy of one AS toward
	its neighbors.
	- 'as-transit' and 'as-exclude' to specify the policy in
	terms of preferred path.
	- 'as-default', to specify the default policy.
	-as-aggr, to describe routing aggregation policy 


1. Definition of some global key words

ANY means any routing information associated with a particular AS.

ASANY means any routing information associated with any AS.

OTHER means any routing information excluding specified routing information.

"net of AS" refers to a net which claims the AS as its home AS.

"net via AS" refers to a net which transits an AS.  


2.  Policy Description Syntax 

2.1. as-in attribute

The as-in attribute describes the policy of importing routing information
from neighboring ASs.

The simple format is 

	as-in: [from] neighborAS:preference... [accept] route

'neighborAS:preference' is a pairing of a neighbor AS number and an
associated metric.  The as-in attribute may contain a list of neighborASs
and preferences. When there is a list of neighborAS:preferences, a comma must 
separate them.  For compatibility with RIPE-81, the colon is optional when 
there is a single neighborAS/preference per as-in attribute.

'neighborAS' is of the form of ASdddd where dddd is the AS number.  

'preference' is the preference at which the route will be
accepted.  It is an integer between 1 and dddd.  The lower the value,
the higher the degree of preference. 

'route' is a list of destinations (or routes) imported from the
neighborAS. 'route' can be:
	- keywords "ANY", "OTHER', 'NONE'
	- an AS number
	- a community name
	- a set of explicit network numbers
Routes can be grouped together by the following operators to
form expressions:
	- 'OR' or '||' or ','
		for example, "route1 OR route2" means we accept networks
		belonging to route1 OR route2; the union of the routes
	- 'NOTIN' or '/'
		for example, "route1 NOTIN route2" means we accept
		networks belonging to route1 but not to route2
	- 'NOT' or '!'
		for example, "NOT route1" means we accept networks
		not belonging to route1
	- 'AND' or '&&'
		for example, "route1 AND route2" means we accept networks
		belonging to route1 AND route2; the intersection of the
		routes

A note of caution, the word 'AND' may be very confusing with the current
common usage of this word. The recommendation is to avoid using 'AND'
unless you have carefully checked what the results will be.  The use
of 'AND' may result in many inconsistencies in the policy.

The expressions can be grouped with parentheses.  For compatibility
with the syntax of RIPE-81, if no operator is present between two
routes, the statement will be interpreted with an 'OR' operator.
For instance, "AS690 AS1133" will be interpreted as "AS690 OR AS1133."

Words in [ ] are optional.  Their purpose is to increase the readability
of the statement.

In the appendix, a more complex syntax is defined to describe different
routing policies at different border routers.   A DB selector value is 
also defined.  The DB Selector is used to select and AS or network
from any database based on its attributes.

Examples:

2.1.1.  AS183 accepts ANY routes known to AS690 with preference 1

aut-num: AS183 	
as-in:	from AS690:1 accept ANY

An alternative way to express this is similar to the RIPE-81 format:

aut-num: AS183
as-in: AS690 1 ANY


2.1.2. AS183 accepts all the routes of AS237 from AS690 with preference 1

aut-num: AS183
as-in:  from AS690:1 accept AS237

This may also be expressed:

aut-num: AS183
as-in: AS690 1 AS237

In this example, AS183 only accepts routes associated with AS237.  AS183
does not accept nets from AS690 or any other AS.

2.1.3. AS183 accepts routes of AS237 from AS690 with preference 1 and from
AS 701 with preference 2

aut-num: AS183
as-in: from AS690:1, AS701:2 accept AS237

The following format is also acceptable.

aut-num: AS183
as-in: AS690 1 AS237
as-in: AS701 2 AS237

2.1.4. AS183 accepts routes of AS237 from AS690 with a preference 1
and from AS701 accepts routes from AS237 and AS233 with a preference 2.
AS690 also announces nets from AS233, but AS183 does not accept
those routes from AS690.

aut-num: AS183
as-in: from AS690:1 accept AS237
as-in: from AS701:2 accept AS237, AS233

2.1.5. AS183 accepts 35/8 and 192.12.18/24 from AS 690 with preference 3 

aut-num: AS183
as-in: from AS690:3 accept {35/8, 192.12.18/24}

This introduces the capability of describing access lists based on network
granularity.  Examples 2.1.1-2.1.4 describe access lists that are
based on AS granularity.

2.1.6. AS 183 accepts all nets which belong to the CIX community. 

aut-num: AS183
as-in: from AS690:1 accept CIX_COMMUNITY

The community name CIX_COMMUNITY adds the ability to group networks
from various ASs into communities so that routing policies can
be described for those communities independent of the AS.


2.2.  as-out 

The as-out attribute describes the policy of exporting routing information
to neighboring ASs.

The simple format is:

	as-out: [to] neighborAS:metric... [announce] route

'neighborAS:metric' is a pairing of a neighbor AS number and an
associated metric.  The as-out attribute may contain a list of neighborASs
and metrics.  The colon is optional when there is a single neighborAS:metric 
per as-in statement.  When there is a list of neighborAS:metrics, a comma must
separate them.

'neighborAS' is of the form of ASdddd where dddd is the AS number.

'metric' is the degree of preference at which the AS wants other ASs
to accept the routes.  It is an integer between 1 and dddd.  The lower 
the value, the higher the degree of preference. Designating a preference
in the as-out statement is optional.

'route' is a list of destinations (or routes) exported to the
neighbor AS. It has the same format as defined for the as-in
attribute.

Words in [ ] are optional.  Their purpose is to increase the readability
of the statement.

Examples:

2.2.1. AS 690 advertises routes of AS237 and AS233 to AS 200

aut-num: AS690
as-out: to AS200 announce AS237, AS233

The syntax defined by RIPE-81 is also acceptable.

aut-num: AS690
as-out: AS200 AS237 AS233

2.2.2. AS200 advertises routes of AS200 and AS201 as primary and secondary 
     respectively to AS690

aut-num: AS200
as-out: to AS690:1 announce AS200
as-out: to AS690:2 announce AS201

With the addition of the preference option to the as-out
statement, advisory information can be offered to neighboring
ASs. This capability is an extension to the as-out syntax.

2.2.3. AS200 advertises all routes to AS 1000

aut-num: AS200
as-out: to AS1000 announce ANY

An alternative way to express this is:

aut-num: AS200
as-out: AS1000 ANY

2.2.4. AS690 advertises only nets 35/8, 192.1.1/24 to ASs 1000 and AS1001.
AS1000 and AS1001 have intersecting sets of routes and AS690 wants to
establish symmetric traffic flows to the intersection from nets
35/8 and 192.1.1/24. Therefore, AS690 would like AS1000 to accept
these two nets with a higher preference than AS1001. 

aut-num: AS690
as-out: AS1000:1 announce {35/8,192.1.1/24}   
as-out: AS1001:2 announce {35/8,192.1.1/24}

This routing statement is possible due to the addition of metrics 
to the as-out statement and the ability to express announcments
with a finer granularity than AS.

2.2.5. AS690 advertises all the CIX routes to AS200 with preference 5 and other
routes with preference 1.

aut-num: AS690
as-out: to AS200:5 announce CIX_COMMUNITY
as-out: to AS200:1 announce OTHER 

OTHER means ANY routes except CIX route. Whenever there is a
statement which uses OTHER, an additional statement is expected.

or this same policy may be expressed using the 'NOTIN' operator:

aut-num: AS690
as-out: to AS200:1 announce ANY/CIX_COMMUNITY
  

2.3. Default

There are four commonly employed types of default policies: 

	a. Static default
	b. Point to a net from a neighborAS as default 
	c. Accept 0.0.0.0 from a neighborAS
	d. advertise 0.0.0.0 to a neighborAS  

Case d is clearly expressible in the as-out policy statement.
The 'as-default' attribute permits non-ambiguous expression
of cases a,b, and c.

The simple format of a default statement is:

	as-default: neighborAS:preference... default_policy 

'neighborAS:preference' is a pairing of a neighbor AS number and an
associated metric.  The as-default attribute may contain a list of neighborASs
and preferences.  When there is a list of neighborAS:preferences, a comma 
must separate them.

'neighborAS' is of the form of ASdddd where dddd is the AS number
and is the neighbor AS to which default is pointed. It is possible
to have several neighbor ASs to which an AS defaults.

'preference' is the degree of preference which is placed on the
default announcement. It is an integer between 1 and dddd.  The lower
the value, the higher the degree of preference.

'default policy' defines the means of implementing default. The options
are either static, acceptance of 0/0, or the default based upon a
specified ip address. 

Examples:

2.3.1.  AS 1000 points a static default to its neighbor AS 690.

aut-num:  AS1000
as-default: AS690:1 static

or alternatively,

aut-num:  AS1000
as-default: AS690 static

2.3.2.  AS 1002 points default at 140.222/16 which it accepts from AS690. 

aut-num:  AS1002
as-default: AS690:1 {140.222/16}

2.3.3.  AS 1001 accepts 0/0 as default from AS690

aut-num:  AS1001
as-default: AS690:1 {0/0}

2.3.4. AS 1005 points primary default at 140.222/16 from AS690 and points a
     static default to AS266 as a secondary default.

aut-num: AS1005
as-default: AS690:1 {140.222/16} 
as-default: AS266:2 static  


2.4. as-exclude

'as-exclude' describes the transit policy of an AS.  This is a special case
which rejects traffic paths which include the excluded AS.  It allow an AS 
to define a policy which applies not only the neighbor ASs but ASs in the path.
Therefore it is a complimentary statement of the as-in statement which does 
not deal AS path information. 

Simple format:
	as-exclude: [exclude] AS [to] [destination]

'AS' is the AS number in the path which the source AS prefers not to traverse. 
'destination' has the same meaning and format as the 'route' list in 'as-in';
however, if no destination is designated, the source AS never wants to
transit the excluded AS no matter what the destination.  The words in [ ] are
optional.   

Examples:

2.4.1. AS 600 never wants to transit AS400 to reach destinations in AS237

aut-num: AS600
as-exclude: exclude AS400 to AS237

2.4.2. AS150 never wants to traverse AS690 to reach CIX routes.

aut-num: AS150
as-exclude: exclude AS690 to CIX_COMMUNITY

The as-exclude statement is only advisory.

2.5. as-transit 

as-transit describes the transit preferences of an AS.  It allows an AS 
to describe its path preference in order to reach certain destinations.
The AS specified here does not need to be a neighbor AS.  Knowledge of
these preferences is especially useful when source based routing (such 
as SDRP) is employed for policy routing.  If the as-transit statement
is employed, only the specified routing paths will be permitted. Any
other routing paths that may exist to destinations from the source
AS will be ignored.

Simple format:

	as-transit: [transit] AS:preference [to] destination

'AS' is the AS that your AS prefers to transit.
'preference' is the degree of preference to transit this AS.  The lower
value has the higher degree of preference. 


'destination' has the same meaning and format as the 'route' list in 'as-in'.
word in [ ] is optional.

Examples:
   
2.5.1. To reach destinations of AS237, AS 500 prefers to transit AS300 rather
than AS400 

aut-num: AS500
as-transit: transit AS300:1, AS400:2 to AS237

This statement means that AS500 prefers to only use paths via AS300 and
AS400 to destinations from AS237.

2.5.2. To reach destinations of AS237, AS600 prefers to transit AS300 and 
not other ASes.  That is if a path via AS300 is unavailable, AS600 would 
rather not use any other path to reach destinations from AS237.

aut-num: AS600
as-transit: transit AS300:1 to AS237

If not explicitly expressed as in 2.5.3, this statement will be interpreted
as a not transit to any.

2.5.3. To reach destinations  of AS237, AS700 prefers to transit AS300 and 
will transit any other AS as backup. 

aut-num: AS700
as-transit: transit AS300:1, ASANY:3 to AS237

Any integer may be selected to represent preference. In the case
of 'ASANY:3', the integer need only be larger than one. 

2.5.4. AS250 would like to use AS300 as primary and AS400 as secondary to
reach net 35/8.  For other networks, it use AS400 as primary and AS300
as secondary.

aut-num: AS250
as-transit: transit AS300:1, AS400:2 to {35/8}
as-transit: transit AS400:1, AS300:1 to OTHER   

2.6 as-aggr

This policy statement will allow the description of the AS policy
concerning aggregation in relationship to CIDR.  The detailed syntax
will be defined when more experience with CIDR is gained.
 


I. Appendix A  Extended Functions

A.1. Express Routing Policy at Border Router Level Within an AS 

It is not unusual that two ASs have multiple interconnections and therefore,
each AS will have more than one border router peering with more than one
corresponding border router from the other AS.  The routing exchange policy 
of each peer need not be identical. That requires the ability to
describe the import and export routing policy between the two ASs at the border 
router level.  The as-in and as-out statements defined in this appendix provide 
such function.

Example 1:

AS 200 connects to AS690 at two locations.  At the east coast, AS200 has
router 192.12.18.1/32 peering with a border router of AS690. At the west coast, 
AS200 has router 192.13.254.1/32 peering with another border router of AS690.
To any destination of AS237, AS 200 prefers to use its west coast connection
to AS 690 as primary and its east coast connection as secondary. 
That means AS 200 will prefer routes of AS 237 imported via AS690 at 
the west coast rather than from the east coast connection.  

aut-num: AS200
as-in: <192.13.254.1> from AS690:1 accept AS237
as-in: <192.12.18.1> from AS690:2 accept AS237

This concept is consistent with developments which are being proposed for
RIPE-81.

Example 2:

The connections between AS200 and AS690 are the same as described above.  AS200
also has connections to AS120 at the west coast and AS130 at the east coast.  
AS 200 would like AS 690 to use the west coast connection as primary and east 
coast connection as secondary for reaching destinations in AS120.  In other 
words, AS 200 will advertise networks of AS120 to AS690 at west coast with 
a lower metric than the outbound metric at the east coast. 

aut-num: AS200
as-out: <192.13.254.1> to AS690:1 announce AS120
as-out: <192.12.18.1> to AS690:2 announce AS120

This is another concept which is under development for inclusion in RIPE-81.

Example 3:

AS300 and AS500 each have two routers connected to a DMZ network.  

			 /  AS 300       \		
			/		  \	
		192.12.80.1		192.12.80.2
	             |                       |
	-----------------------------------------------
		|			|
	    192.12.80.100           192.12.80.101
		     \                    /
		      \     AS 500       /


192.12.80.1 and 192.12.80.2 both peer with both 192.12.80.100 and
192.12.80.101.  AS 300 can be used to reach AS120 and AS130.

The policy of AS300 is to load share between its two border routers 192.12.80.1
and 192.12.80.2 for the traffic coming from AS500 to destinations of AS120 and
AS130.

aut-num: AS300
as-out: <192.12.80.1> to AS500<192.12.80.100>:1 announce AS120
as-out: <192.12.80.1> to AS500<192.12.80.101>:2 announce AS120
as-out: <192.12.80.2> to AS500<192.12.80.100>:2 announce AS130
as-out: <192.12.80.2> to AS500<192.12.80.101>:1 announce AS130 


A.2. DataBase Selector

This function will take advantage of information registed in other Routing
Registries. The format is:

                database_name '{' selector_expression '}'

- 'database_name' is a name of an 'official' (or known - to be defined)
database.
- The selector_expression is an expression of the form:

                attribute_name operator attribute_value

- attribute_name is the name of any attribute (e.g 'country', 'source',
'connect') supported in the database,
- operator is '==' (equal) or != (different)
attribute_value is the value to be compared.

This syntax permits the selection of networks in a database based 
on their attributes. For instance to select only the French 
networks:

        RIPE_DB { cc == FR }

In order to maintain compatibility with the RIPE-81 format we added
an alias named LOCAL which is merely

        RIPE_DB { co == LOCAL }

Examples:

A.2.1. AS 690 accept from AS 701 all networks in the NSFNET database
with 701 as the primary announcing AS:

aut-num: 690
as-in: from AS701:100 accept NSF_DB { aslist == 1:701 }

A.2.2. Accept all german networks and all networks from AS 513

aut-num: 690
as-in: from AS701:100 accept AS513 OR RIPE_DB { cc == DE }


II.  Appendix B References:

[1]  RIPE-60
[2]  RIPE-81
[3]  Yu, Chen, Rekhter document
[4]  Joncheray document

III. Appendix C  Syntax in BNF and Yacc

C.1 BNF syntax

policy = *(policy_attribute)

policy_attribute = as_in_attribute
		   / as_out_attribute
		   / as_transit_attribute
		   / as_exclude_attribute
		   / as_default_attribute

as_in_attribute = KW_AS_IN  ":" *(interface) *(kw_from) aslist_pref_noany
		*(kw_accept) accept_list
as_out_attribute = KW_AS_OUT ":" *(interface) *(kw_to) aslist_nopref_any
		*(kw_announce) announce_list
as_transit_attribute = KW_AS_TRANSIC ":" *(kw_transit) aslist_nopref_any
		*(kw_to) transit_list
as_exclude_attribute = KW_AS_EXCLUDE ":" *(kw_exclude) aslist_nopref_any
		*(kw_to) exclude_list
as_default_attribute = KW_AS_DEFAULT ":" aslist_nopref_noany default_type

interface = "<" interface_addr ">"

default_type = KW_STATIC \ *(kw_net) ip_netmask_addr

/* Preference optional, ASANY not allowed */
aslist_nopref_noany:      as_number interface
                        / as_number interface INTEGER           /* RIPE-81 */
                        / *(as_number_pref)
/* Preference mandatory, ASANY not allowed */
aslist_pref_noany:        as_number interface INTEGER           /* RIPE-81 */
                        / *(as_number_pref)
/* Preference mandatory, ASANY allowed */
aslist_pref_any:          as_number_any interface INTEGER       /* RIPE-81 */
                        / *(as_number_any_pref)
/* Preference optional, ASANY allowed */
aslist_nopref_any:        as_number_any interface
                        / as_number_any interface INTEGER       /* RIPE-81 */
                        / *(as_number_any_pref)

as_number_pref = as_number interface ':' INTEGER
as_number_any_pref = as_number_any interface ':' INTEGER
as_number = AS_NUMBER

accept_list = accept_item bin_operator accept_list
	     / accept_item bin_operator accept_list
	     / un_operator accept_list
	     / "(" accept_list ")"

accept_item = AS_NUMBER
	      / community
	      / ip_net_set
	      / db_reference
	      / KW_DEFAULT
	      / KW_ANY
	      / KW_NONE
	      / KW_OTHER

community = STRING

ip_net_set = "{" ip_netmask_addr *("," ip_netmask_addr) "}"

db_reference = STRING               /* We do not know yet */

bin_operator =  /* Nothing. It is a pain in the b... (RIPE-81). Means "OR" ?? */
		/ KW_OR
		/ ","		/* Means OR */
		/ KW_AND
un_operator = KW_NOT

announce_list = accept_list		/* Same as as_in? */

interface_addr = dotted_ip_addr
ip_net_addr = dotted_ip_addr / INTEGER				/*  = -( */
dotted_ip_addr = DOTTED_IP_ADDR;
ip_netmask_addr = ip_net_addr / (ip_net_addr "/" ip_net_addr)

kw_from = KW_FROM
kw_to = KW_TO
kw_accept = KW_ACCEPT
kw_announce = KW_ANNOUNCE
kw_transit = KW_TRANSIT
kw_exclude = KW_EXCLUDE
kw_net = KW_NET

KW_AS_IN = "as-in" / "AS-IN"
KW_AS_OUT = "as-out" / "AS-OUT"
KW_AS_TRANSIC = "as-transit" / "AS-TRANSIT"
KW_AS_EXCLUDE = "as-exclude" / "AS-EXCLUDE"
KW_AS_DEFAULT = "^default" / "as-default" / "AS-DEFAULT" :-)
KW_STATIC = "static" / "STATIC"
KW_NET = "net" / "NET"
KW_DEFAULT = "default" / "DEFAULT"
KW_ANY = "any"/ "ANY"
KW_NONE = "none" / "NONE"
KW_OTHER = "other" / "OTHER"
KW_ACCEPT = "accept" / "ACCEPT"
KW_ANNOUNCE = "announce" / "ANNOUNCE"
KW_TO = "to" / "TO"
KW_FROM = "from" / "FROM"
KW_TRANSIT = "transit" / "TRANSIT"
KW_EXCLUDE = "exclude" / "EXCLUDE"

KW_OR = "or" / "OR" / "||"
KW_AND = "and" / "AND" / "&&"
KW_NOT = "not" / "NOT" / "!"
KW_EXC = "notin" / "NOTIN" / '^'

INTEGER = 1*DIGIT

AS_NUMBER = ("AS" / "as") (INTEGER / "ANY")
STRING = ????
DOTTED_IP_ADDR = DIGIT *(DIGIT / ".")




C.2 Yacc & lex syntax (authoritative)

%token KW_AS_IN KW_AS_OUT KW_AS_TRANSIC KW_AS_EXCLUDE
%token AS_NUMBER DOTTED_IP_ADDR NULLNET KW_ASANY KW_DEFAULT
%token KW_STATIC KW_NET KW_AS_DEFAULT KW_ANY KW_NONE KW_OTHER
%token STRING INTEGER
%token KW_OR KW_AND KW_NOT KW_NOTIN
%token KW_ACCEPT KW_ANNOUNCE KW_TO KW_FROM KW_TRANSIT KW_EXCLUDE

%left NETMASK

%%

policy:				/* Nothing */
			| policy_attribute_list
			;

policy_attribute_list:	  policy_attribute
			| policy_attribute_list policy_attribute
			;

policy_attribute:	  as_in_attribute
			| as_out_attribute
			| as_transit_attribute
			| as_exclude_attribute
			| as_default_attribute
			;

as_in_attribute:	  KW_AS_IN  ':' interface kw_from aslist_pref_noany kw_accept accept_list;

as_out_attribute:	  KW_AS_OUT ':' interface kw_to aslist_nopref_any kw_announce announce_list;

as_transit_attribute:	  KW_AS_TRANSIC ':' kw_transit aslist_nopref_any kw_to transit_list;

as_exclude_attribute:	  KW_AS_EXCLUDE ':' kw_exclude aslist_nopref_any  kw_to exclude_list;

as_default_attribute:  KW_AS_DEFAULT ':' aslist_nopref_noany default_type;


/* Types of AS lists: with/without ASANY and with/without preference */
/* Preference optional, ASANY not allowed */
aslist_nopref_noany:	  as_number interface
			| as_number interface INTEGER           /* RIPE-81 */
			| as_number_nopref_list
			;
/* Preference mandatory, ASANY not allowed */
aslist_pref_noany:	  as_number interface INTEGER           /* RIPE-81 */
			| as_number_list
			;
/* Preference mandatory, ASANY allowed */
aslist_pref_any:	  as_number_any interface INTEGER       /* RIPE-81 */
			| as_number_any_list
			;
/* Preference optional, ASANY allowed */
aslist_nopref_any:	  as_number_any interface
			| as_number_any interface INTEGER       /* RIPE-81 */
			| as_number_nopref_any_list
			;

as_number_list:		  as_number_pref
			| as_number_list ',' as_number_pref
			;
as_number_any_list:	  as_number_any_pref
			| as_number_any_list ',' as_number_any_pref
			;
as_number_nopref_list:	  as_number_nopref
			| as_number_nopref_list ',' as_number_nopref
			;
as_number_nopref_any_list: as_number_nopref_any
			| as_number_nopref_any_list ',' as_number_nopref_any
			;

as_number_pref:		  as_number interface ':' INTEGER;
as_number_nopref:	  as_number interface
			| as_number interface ':' INTEGER
			;
as_number_any_pref:	  as_number_any interface ':' INTEGER;
as_number_nopref_any:	  as_number_any interface
			| as_number_any interface ':' INTEGER
			;


default_type:		  	/* Nothing. To be compatible with RIPE-81 */
			| KW_STATIC
			| KW_NET ip_netmask_addr
			| ip_net_set
			;

accept_list:		  accept_item
			| accept_item bin_operator accept_list
			| un_operator accept_list
			| '(' accept_list ')'
			;

accept_item:		  as_number
			| community
			| ip_net_set
			| db_reference
			| KW_DEFAULT
			| KW_ANY
			| KW_NONE
			| KW_OTHER
			;

transit_list:		  accept_list;
exclude_list:		  accept_list;

community:		  STRING;		/* Anything alse? */

ip_net_set:		  '{' ip_net_list '}';

db_reference:		  STRING '{' '}';               /* We do not know yet */

bin_operator:			/* Nothing. It is a pain in the b... (RIPE-81). Means 'OR' ?? */
			| KW_OR
			| ','		/* Means OR */
			| KW_AND
			| '/'
			| KW_NOTIN
			;

un_operator:		  KW_NOT
			;

announce_list:		  accept_list;		/* Same as as_in? */

interface_addr:		  dotted_ip_addr;

ip_net_addr:		  dotted_ip_addr
			| INTEGER				/* :-( */
			;
dotted_ip_addr:		  DOTTED_IP_ADDR;

ip_netmask_addr:	  ip_net_addr
			| NULLNET				/* 0/0 */
			| ip_net_addr '/' ip_net_addr
			;

ip_net_list:		  ip_netmask_addr
			| ip_netmask_addr ',' ip_net_list
			;

as_number_any:		  as_number
			| KW_ASANY
			;

as_number:		  AS_NUMBER;

interface:		  	/* Nothing. This is optional */
			| '<' interface_addr '>'
			;

kw_from:		  	/* Nothing. This is optional */
			| KW_FROM
			;
kw_to:				/* Nothing. This is optional */
			| KW_TO
			;
kw_accept:			/* Nothing. This is optional */
			| KW_ACCEPT
			;
kw_announce:			/* Nothing. This is optional */
			| KW_ANNOUNCE
			;
kw_transit:			/* Nothing. This is optional */
			| KW_TRANSIT
			;
kw_exclude:			/* Nothing. This is optional */
			| KW_EXCLUDE
			;


%%

/* Lex syntax */

punctuation	[<>:,;{}\.\(\)/]
integer		[0-9]+
string		[A-Za-z_][A-Za-z_0-9-]*
dotted_ip	[0-9][0-9\.]*
asnumber	as[0-9]+
ASnumber	AS[0-9]+

%%

as-in			return(KW_AS_IN);
AS-IN			return(KW_AS_IN);
as-out			return(KW_AS_OUT);
AS-OUT			return(KW_AS_OUT);
as-transit		return(KW_AS_TRANSIC);
AS-TRANSIT		return(KW_AS_TRANSIC);
as-exclude		return(KW_AS_EXCLUDE);
AS-EXCLUDE		return(KW_AS_EXCLUDE);
^default		return(KW_AS_DEFAULT);
as-default		return(KW_AS_DEFAULT);
AS-DEFAULT		return(KW_AS_DEFAULT);
static			return(KW_STATIC);
STATIC			return(KW_STATIC);
net			return(KW_NET);
NET			return(KW_NET);
default			return(KW_DEFAULT);
DEFAULT			return(KW_DEFAULT);
any			return(KW_ANY);
ANY			return(KW_ANY);
none			return(KW_NONE);
NONE			return(KW_NONE);
other			return(KW_OTHER);
OTHER			return(KW_OTHER);
accept			return(KW_ACCEPT);
ACCEPT			return(KW_ACCEPT);
announce		return(KW_ANNOUNCE);
ANNOUNCE		return(KW_ANNOUNCE);
to			return(KW_TO);
TO			return(KW_TO);
from			return(KW_FROM);
FROM			return(KW_FROM);
transit			return(KW_TRANSIT);
TRANSIT			return(KW_TRANSIT);
exclude			return(KW_EXCLUDE);
EXCLUDE			return(KW_EXCLUDE);

or			return(KW_OR);
OR			return(KW_OR);
\|\|			return(KW_OR);
and			return(KW_AND);
AND			return(KW_AND);
&&			return(KW_AND);
not			return(KW_NOT);
NOT			return(KW_NOT);
!			return(KW_NOT);
NOTIN			return(KW_NOTIN);
notin			return(KW_NOTIN);

0\/0			return(NULLNET);
{integer}		return(INTEGER);

{asnumber}		return(AS_NUMBER);
{ASnumber}		return(AS_NUMBER);
ASANY			return(KW_ASANY);
{string}		return(STRING);
{dotted_ip}		return(DOTTED_IP_ADDR);

{punctuation}		return(yytext[0]);

\n                      ++current_lex_line;

^#.*			;

.			;






-- 
Laurent Joncheray,                                 E-Mail: lpj at merit.edu
    Merit Network Inc, 1071 Beal Avenue,           Phone:  +1 (313) 936 2065
    Ann Arbor, MI 48109, USA                       Fax:    +1 (313) 747 3745
"This is the end, Beautiful friend. This is the end, My only friend, the end" JM