This is the promised summary of changes of document to help focus discussion at the forthcoming RIPE meeting. URL: ftp://ftp.ripe.net/ripe/drafts/ripe-81++.changes.txt -- Text version URL: ftp://ftp.ripe.net/ripe/drafts/ripe-81++.changes.ps -- PS version --Tony. Summary of changes in RIPE-81++ from previous RIPE Meeting. Tony Bates 23rd August, 1994 1. Introduction In an effort to focus discussion for the forthcoming RIPE meeting in Lisbon in September I have made a brief outline of the changes to the RIPE-81++ draft from the last RIPE meeting. It is divided into two sections; basic and major changes. The major changes section will be most relevant for the forthcoming RIPE meeting and in par- ticular the RIPE routing working group. The latest RIPE-81++ draft is available from: URL: ftp://ftp.ripe.net/ripe/drafts/ripe-81++.{ps,txt} 2. Basic Agreed Changes This sections details the changes that were agreed and have been fully incorporated into the current draft of RIPE-81++. All the changes are with respect to the RIPE-81++ proposal tabled at the RIPE meeting in Amsterdam in May, 1994. In each case only very brief detail is given as these changes have been agreed by consensus. Network Lists. Add the use of network lists in the routing policy expression com- ponent. This will be in the form proposed by Merit. i.e. list of nets separate by commas within braces: { 35.0.0.0/8, 192.87.45.0/24 } Extension to "default" attribute There is a set of additional OPTIONAL components added to the default attribute. See RIPE-81++ for more details.  - 2 - Syntactic SUGAR We added in the additional reserved words to make the syntax clearer. NOTE: the reserved words will all be in lower-case to dis- tinguish them from special policy keywords and communities. Here is a summary of current SUGAR to add and where. accept announce exclude from to transit Examples of the usage of the reserved words are: as-in: from neighborAS accept route as-out: to neighborAS announce route as-exclude: exclude ASpath to destination as-transit: transit ASpath to destination default: from neighborAS accept route default: to neighborAS announce route Note: that as-transit is an experimental attribute. See below. Network Representation We used the "prefix length" notation documented in the classless proposal paper. i.e. 35.0.0.0/8 192.87.45.0/24 "as-reject" changed to "as-exclude" The text remained the same. The name of the attribute changed. 3. Major Changes This section details the major changes with respect to the draft  - 3 - presented at the RIPE meeting in Amsterdam in May, 1994. The "component" attribute is gone The component attribute was dropped as it was deemed to be too com- plex to understand and too difficult to maintain and guard. The out- come of this is two new attributes and one new object that facili- tate the functionality of the component attribute 1) withdrawn attribute Often is is useful to show a route that has been withdrawn from the routing table. The has become very important now that CIDR is deployed as service providers start to withdraw more specific routes from an aggregate. 2) hole attribute For tools in can be very useful to indicate "holes" in a CIDR aggregate where there is currently no expected connectivity. 3) inet-rtr object This allows you to detail the interfaces of a router as well as the AS the router belong to. This is extremely useful for routes/networks which fall into the category of what used to be called "inter-as networks" described by the proposed to be obsoleted "ias-int" attribute in the "inetnum" object. This object is described in: Bates, T., "Specifying an `Internet Router' in the Routing Registry", July, 1994. DRAFT. URL: ftp://ftp.ripe.net/drafts/inet-rtr.{ps,txt} The "interas-in" and "interas-out" attributes. This is an additional set of attributes added to detail local poli- cies between any two ASes which have more than one interconnecting link. This description is necessary only if the ASs are connected in more than one way and the routing policy and differs at these two connections. Example: LINK1 193.0.1.1 +----------+ 193.0.1.2 | | AS1------AS2== ==AS3-----AS4 | | 193.0.1.5 +----------+ 193.0.1.6 LINK2  - 4 - Descriptions of interas policies do not replace the global pol- icy described in as-in, as-out and other policy attributes which always describes the global policy between the two ASes. The interas-in/out attributes only specify local variations to the glo- bal policy described in the other attributes. If the global policy mentions more routes than the local policy then local preferences for these routes are assumed to be equal for all links. A simple extendable syntax has been defined for this additional information. For details of this refer to the ripe-81++ draft. Possible outstanding issues with interas-in/interas-out A major discussion point came from these attributes The ordering There were two styles of ordering proposed. A) interas-in: <my id> [from] ASxx <neighbor id> <pref> <pol- icy> B) interas-in: [from] ASxxx <my id> <neighbor id> <pref> <pol- icy> Fortunately, an executive decision has been made by the chair of the RIPE routing group to go with option B. The main reason behind this is for consistency with the as-in and as-out attri- butes. Clarification of evaluation of operators. Some text has been added to clarify the ordering of how the logical operators are evaluated in routing policy expressions and what they actually mean. It was recognised that ripe-81++ was weak on this point. This text is taken verbatim from the ripe-81++ draft: .... <routing policy expression> can take the following formats. 1. A list of one or more ASes, AS Macros, Communities or Net- work Lists. A Network List is a list of network numbers in prefix length format, separated by commas, and surrounded by curly brackets (braces, i.e. `{' and '}'). Examples:  - 5 - as-in: from AS1103 100 accept AS1103 as-in: from AS786 105 accept AS1103 as-in: from AS786 10 accept AS786 HEPNET as-in: from AS1755 110 accept AS1103 AS786 as-in: from AS3333 100 accept {192.87.45.0/16, 128.141.0.0/16} 2. A set of KEYWORDS. The following KEYWORD is currently defined: ANY this means anything the neighbour AS knows. 3. A logical expression of either 1 or 2 above The current logical operators are defined as: AND OR NOT This operators are defined as true BOOLEAN operators even if the operands themselves do not appear to be BOOLEAN. Their operations are defined as follows: Operator Operation Example OR UNION AS1 OR AS2 | +-> all routes in AS1 or AS2. AND INTERSECTION AS1 AND HEPNET | +-> a route in AS1 and belonging to community HEPNET. NOT COMPLEMENT NOT AS3 | +-> any route except AS3 routes. Rules are grouped together using parenthesis i.e "(" and ")". The ordering of evaluation of operators and there associa- tion is as follows: Operator Associativity () left to right NOT right to left AND left to right OR left to right  - 6 - NOTE: if no logical operator is given between ASes, AS- macros, Communities, Network Lists and KEYWORDS it is implicitly evaluated as an `OR' operation. The OR can be left out for conciseness. However, please note the opera- tors are still evaluated as below so make sure you include parentheses whenever needed. To highlight this here is a simple example. If we denoted a policy of for example; from AS1755 I accept all routes except routes from AS1, A2 and AS3 and you enter the following as-in line. as-in: from AS1755 100 accept NOT AS1 AS2 AS3 This will be evaluated as: as-in: from AS1755 100 accept NOT AS1 OR AS2 OR AS3 Which in turn would be evaluated like this: (NOT AS1) OR AS2 OR AS3 -> ((ANY except AS1) union AS2) union AS3) --> (ANY except AS1) This is clearly incorrect and not the desired result. The correct syntax should be: as-in: from AS1755 100 accept NOT (AS1 AS2 AS3) Producing the following evaluation: NOT (AS1 OR AS2 OR AS3) -> (ANY) except (union of AS1, AS2, AS3) Which depicts the desired routing policy. Note that can also be written as below which is perhaps somewhat clearer: as-in: from AS1755 100 accept ANY AND NOT (AS1 OR AS2 OR AS3)