A summary of changes of RIPE-81++ from last RIPE meeting

[Tony Bates <]

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)