extensions for routing registry

Elise,
	Firtly a few quick comments. Unfortunately, you've caught
Marten and myself at a fairly bad time as we leave for a ski trip
to France (Courchevel for Laurents benefit ;-)) for 8 days as of
tomorrow morning so we won't be able to 
get as much discussion going as I guess we'd like to. However, firstly
let me say this looks very good and in general it seems much in line
with discussions we've had recently. Please take my comments as
constructive. My general view is the one we've always been slightly at
odds about which is "complexity v clarity". However, I think if we
agree on some of the wording to warn where the more complex bits are
we could in fact expand  RIPE-81 with these (or some at least)
additions.

			--Tony.

 Elise Gerich <epg at merit.edu> writes:
  * Hi all,
  * Well, we have wordsmithed and armwrestled and are finally ready
  * to share the routing policy document with you all for your
  * comments and review. Please send your comments to rr-imp at ripe.net.
  * Happy reading.
  *         --Elise, Jessica, and Laurent
  * 
  * 
  * -------------------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.
  * 
Whilst this is implicitly correct. We need to actually ratify this at
least in the sense that SPs need to be able to have a document
describing this minimum set of attributes be that RIPE-81++ plus your
extensions or RIPE-81++ as is.

  * 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
  *
As I see it then the new bits are d, e but slight adjustments to a, c
and f.  
  *  
  * 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.
Does this mean the yacc syntax is the only correct syntax
definition.

  * 
  * 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.
  * 
This to me is a little confusing. ANY means any to me. In your context
ANY appears to be the same as specifying an AS. ASANY is what we have
as ANY.

  * OTHER means any routing information excluding specified routing information
  * .
  * 
How is OTHER evaluated ? What I mean is, is it evaluated with
respect to your rule or just a convenient way of saying ANY (well
ASANY in your syntax) and NOT blah ?

  * "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 mu
  * st 
  * 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,

is dddd the same as the AS dddd ? (no I guess ?)

  * 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
I'm sort of confused here as well. I guess this comes from my one net
one AS idea which you dont have. You need to say up front that this 
is different from RIPE-81 if you
have expressions that support this concept.  Plus I think "/" 
can certainly cause confusion (with SPs idea of the look of a CIDR route).

  * 	- 'NOT' or '!'
  * 		for example, "NOT route1" means we accept networks
  * 		not belonging to route1
Actualy - reads then as ANY and NOT. Doesn't this mean 
we do not accept networks beloning to route1 or is this splitting a hair not
there ? 
  * 	- '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.
  * 
Right.

  * 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."
  *
Right this is something I added to our stuff a while back (still in
draft, I sent it to Laurent yesterday actually) to attempt to make it
clearer)
 
  * 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
                                                     an
  * 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
  *
Okay, but for the syntax I guess somehow you have to show that
neighborAS:preference and 
neighbourAS preference 
as the compatible, probobly in the Yacc right ?

  * 
  * 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.
  *
Of course this can be done with a community as well right ? Also, when
do you stop this list and turn it into a community list anyway just
for clarity, 10, 1000, ?
 
  * 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:metri
  * c 
  * per as-in statement.  When there is a list of neighborAS:metrics, a comma m
  * ust
  * 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.
  *
I would like to see this metric part noted as advisory information as
well and clearly that as this is all it is and not enforceable at all.
 
  * '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 o
  * ther
  * 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
  *   
  * 
Some general things. I'm not sure the verbosity of optional "to,
announce, accept" really adds much. As an operator I want the tools to
do things for me and if I need verbosity get them to put in there. 
These are all directly implicted so if needed get the server to do it.
 
  * 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  
  *
This gets back to the old chesnut of implementation specifc details
in the policy.
I would like to see the default_policy part ptional. I also see 
other ways of deriving default like if an interface is up for example
(dynamicly derived) and so on.

  * 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 neighbor
  * ASs
  * 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 p
  * ath.
  * 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 traver
  * se. 
  * '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 [ ] a
  * re
  * 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.
  *
Well I kind of like this a it an advisory that we all agreed on.
How does this syntax look like I want a list of exclude ASs ?
aut-num: AS15
as-exclude: AS690
as-exclude: AS1133


  * 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.
  * 
This again implies knowledge of the topology but I do like it as an
advisory so it gives operators who really are doing this a better way
of expressing there policies (which also implies it is non-advisory I
guess).
Plus do you allow real path rather than a single transit AS.

  * 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 rath
  * er
  * 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 bo
  * rder 
  * router level.  The as-in and as-out statements defined in this appendix pro
  * vide 
  * 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 co
  * ast, 
  * AS200 has router 192.13.254.1/32 peering with another border router of AS69
  * 0.
  * To any destination of AS237, AS 200 prefers to use its west coast connectio
  * n
  * 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.  A
  * S200
  * 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 ea
  * st 
  * 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 
  * 
I see why you might like this but hasn't it just gone into an area of
complexity you don't want in the registry. I do see it but I do not
think it will be used except by a few very large transit sites and
then could easily map this information in another way. The only tool
where this might help is in prtracerotue I guess.
  * 
  * 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 }
  * 
  * 
Again this is fine except for the level of complexity it adds to the
representation.
 
  * II.  Appendix B References:
  * 
  * [1]  RIPE-60
  * [2]  RIPE-81
  * [3]  Yu, Chen, Rekhter document
  * [4]  Joncheray document
  *
Wont comment on this.
 
  * 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_an
  * nounce announce_list;
  * 
  * as_transit_attribute:	  KW_AS_TRANSIC ':' kw_transit aslist_nopref_an
  * y kw_to transit_list;
  * 
  * as_exclude_attribute:	  KW_AS_EXCLUDE ':' kw_exclude aslist_nopref_an
  * y  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 kn
  * ow yet */
  * 
  * bin_operator:			/* Nothing. It is a pain in the b... (R
  * IPE-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;
  * 
  * ^#.*			;
  * 
  * .			;
  * 



-------- Logged at  Thu Feb 17 22:53:18 MET 1994  ---------