Internet DRAFT - draft-ardas-rpcl

draft-ardas-rpcl









INTERNET-DRAFT                                             Ardas Cilingiroglu
File name: draft-ardas-rpcl-00.txt                               FORE Systems
                                                              Tony Przygienda
                                               Bell Labs, Lucent Technologies
                                                      Expires : February 1999












                        Routing Policy Configuration Language (RPCL)






     Status Of This Memo

     This document is an Internet-Draft.  Internet-Drafts  are  working  docu-
     ments  of  the Internet Engineering Task Force (IETF), its areas, and its
     working groups.  Note that other groups may also distribute working docu-
     ments as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six months and
     may  be  updated,  replaced, or obsoleted by other documents at any time.
     It is inappropriate to use Internet- Drafts as reference material  or  to
     cite them other than as "work in progress".

     To learn the current status  of  any  Internet-Draft,  please  check  the
     "1id-abstracts.txt"  listing  contained  in  the  Internet- Drafts Shadow
     Directories on ftp.ietf.org (US East Coast),  nic.nordu.net  (Europe),
     ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).











Cilingiroglu, Przygienda    Expires February 1999                     [Page 1]





Internet-Draft                      RPCL                          August 1998


Table Of Contents

   1.0 Introduction ...................................................... 3

   2.0 Basic RPCL Types; Filter, Action and Peering Specifications ....... 4

   2.1 Data Types of Route Attributes .................................... 5

   2.2 Filter Types ...................................................... 6

   2.3 Peering Types ..................................................... 8

   2.4 Filter, Action and Peering Specifications ......................... 9

   3.0 Import Policy Rules ............................................... 10

   4.0 Export Policy Rules ............................................... 14

   5.0 Aggregation Policy Rules .......................................... 17

   6.0 Acknowledgments ................................................... 24

   7.0 Authors' Addresses ................................................ 24

   8.0 References ........................................................ 24

   A. Policy Editor in RPCL .............................................. 25

   A.1 Policy Macros ..................................................... 26

   A.2 Import and Export Policy Configuration ............................ 31

   A.3 Aggregation Policy Configuration .................................. 36

   A.4 Commit Operation .................................................. 37

   B. RPCL Reference ..................................................... 38

   B.1 RPCL Policy Syntax ................................................ 38

   B.2 Policy Editor ..................................................... 41










Cilingiroglu, Przygienda    Expires February 1999                     [Page 2]





Internet-Draft                      RPCL                          August 1998


1. Introduction

   Routing policies define a set of rules and actions to be applied by  proto-
   cols  when they send and receive routing updates.  When a protocol receives
   an updates, routing policies are used to determine if, and with what infor-
   mation  a  route  gets  added  to the Routing Information Base (RIB).  When
   preparing to send a routing update, routing policy is consulted to  see  if
   the  route  is  to be sent and if so, what information is to be included in
   the update.  The Routing Policy Configuration Language (RPCL)  specifies  a
   language for defining routing policies in a router.

   RPCL is derived from the Routing Policy Specification Language  (RPSL)  [1,
   2],  which  is  the  evolving standard for Internet's policy specification.
   RPSL specifies the routing policies, inter-domain  routes,  border  routers
   and  some administrative objects  of an Autonomous System (AS).  Autonomous
   Systems (AS) in the  Internet  registers  its  RPSL  specification  with  a
   cooperatively  maintained  distributed  database,  called  Internet Routing
   Registry (IRR) [3,4]. IRR has the global view of the Internet and its poli-
   cies.  The  IRR  is used to verify the integrity of the Internet's routing,
   and to protect the Internet against accidental and  malicious  distribution
   of  inaccurate  route  information,  such as non-existing routes, incorrect
   aggregation or aggregation boundaries.

   Unlike RPSL, which specifies the policies and other internal objects of  an
   AS,  RPCL  is  used  to configure the policies of an individual router. Its
   syntax and semantics for the policy language is, however, derived from  the
   RPSL. This consistency in policy specification language at the AS level and
   the router level facilitates the conversion from one to the other.

   RPCL is intended to be an extendable language. It provides a uniform syntax
   and  semantics  for policy configuration across various policies and proto-
   cols.  RPCL is designed to be able to add support  for  new  protocols  and
   specifications for new policies.  For example, RPCL currently defines poli-
   cies for unicast protocols, but it can be  extended  to  support  multicast
   protocols as well.

   RPCL currently supports the configuration and evaluation of  the  following
   policies:


      - Import Policy: used by protocols to update  the  content  of  the  RIB
           based  on the routes received. When a protocol receives a route, it
           uses the import policy to determine whether to accept or block  the
           route, and to set the route's attributes (e.g., the route's prefer-
           ence) if the route is accepted.  RIP, OSPF and BGP are example uni-
           cast protocols using import policies.





Cilingiroglu, Przygienda    Expires February 1999                     [Page 3]





Internet-Draft                      RPCL                          August 1998


      - Export Policy: used by protocols to determine what routes and  associ-
           ated  attributes  to send to neighbors based on the contents of the
           RIB. There is a separate policy configured for each protocol  pairs
           (SRC-PR,  DST-PR),  where  DST-PR is the exporting protocol and the
           SRC-PR is the owner protocol of the route considered. Some  example
           protocol pairs are show below:


                           DST PROTOCOL

                       | RIP  | OSPF | BGP  |
               --------+------+------+------+
               Static  |Export|Export|Export|
               --------+------+------+------+
               Direct  |Export|Export|Export|
         SRC   --------+------+------+------+
         PROT  RIP     |Export|Export|Export|
               --------+------+------+------+
               OSPF    |Export| ---- |Export|
               --------+------+------+------+
               BGP     |Export|Export|Export|
               --------+------+------+------+


      - Aggregation Policy: An aggregate route is used to summarize  the  com-
           ponent  routes  of  an  address range. By default when an aggregate
           route is exported to a neighbor, all of its component routes  (i.e.
           routes  that  are more specific than the aggregate) are suppressed.
           This reduces the amount  of  route  propagation  and  controls  the
           growth  of  the  IP  routing  and forwarding tables. Some component
           routes, however, may need to be exported along with  the  aggregate
           to  satisfy  some  topology  constraints  (such as multi-homed com-
           ponents in BGP). Aggregation policy is used by a protocol to deter-
           mine  the  aggregate  routes that a router generates and which com-
           ponent routes to export along with the aggregate. BGP is an example
           protocol using aggregation policy.


2. Basic RPCL Types; Filter, Action and Peering Specifications

   Routes are composed of a set of attributes.  Some attributes are common  to
   all routing protocols, and some are unique to a single protocol.  For exam-
   ple, an address prefix and the preference are common to all routing  proto-
   cols, whereas the tag for RIP and OSPF routes and the aspath for BGP routes
   are protocol specific.






Cilingiroglu, Przygienda    Expires February 1999                     [Page 4]





Internet-Draft                      RPCL                          August 1998


   Policies are configured using policy rules. All policy rules  are  composed
   of the following basic constructs:


      - Filter specification: a logical expression over the route  attributes.
           Filter  specifications are used by the policy rules to select a set
           of routes for a particular operation. For example, the  RIP  import
           rule  "accept (128/8^+ and tag==100)" uses the filter "(128/8^+ and
           tag==100)" to allow the import of the  RIP  routes  that  are  more
           specific than 128/8 and have the tag value of 100.

      - Action specification: an ordered list of commands to set or modify the
           attributes  of  a  route.  For  example, a RIP export rule with the
           action specification  "{tag=10; metric=100}" will set the  tag  and
           metric attributes of a route to 10 and 100, respectively.

      - Peering specification: used by an External  Gateway  Protocols  (EGP),
           such  as  BGP,  to  restrict  the  policy evaluation to a subset of
           peers.  For example, a BGP import rule with a peering "{128.10.5.5,
           AS11}"  will  only be evaluated for the routes coming from the peer
           128.10.5.5 or from a peer in AS11.


2.1 Route Attribute Data Types

   Every route attribute has a specific data type. The route attributes of the
   unicast  routing  protocols and their corresponding data types are shown in
   Figure-1. The basic data types are explained below:

      <ipv4-addr> An IPv4 address is a 32 bit number represented by four 8 bit
           integers   (standard "dotted quad" format).  For example 128.10.9.9
           represents a valid address.

      <prefix> An address prefix is composed of an IPv4  address  followed  by
           its  length, an integer between 0 to 32 which represents the number
           of significant leftmost contiguous  bits  (CIDR-based  addressing).
           Only  the  significant  part of the IPv4 address needs to be speci-
           fied. 0/0, 128.9/16, 150.10.0/16, and 169.144.100/24  are  examples
           of  valid  prefixes,  whereas 128.9/24 is invalid (the IPv4 address
           must include three integers when the mask length is 24).

      <as> An autonomous system (AS) x is denoted by ASx. For  example,  AS312
           represents the AS 312.

      <as-path> AS-path is a BGP attribute that keeps track of the sequence of
           ASes  traversed  by  the  route.  It is represented by a list of AS
           numbers in braces, separated by commas. For example, {AS23,  AS247,
           AS11, AS66} is an AS-path.



Cilingiroglu, Przygienda    Expires February 1999                     [Page 5]





Internet-Draft                      RPCL                          August 1998


      <ospf-type>  OSPF  routes  can  be  of  type   intra-area,   inter-area,
           external-1  or  external-2.  They are represented by the symbols in
           the set {INTRA-AREA, INTER-AREA, EXTERNAL-1, EXTERNAL-2}.

      <comm-list> Community list is a BGP attribute represented by a  list  of
           communities  in  braces,  separated  by  commas.  Each community is
           either a 4-byte unsigned integer, or one of the keywords  NO-EXPORT
           or  NO-ADVERTISE,  or  a list of two 2-byte unsigned integers.  For
           example, {100, NO-EXPORT, {312, 10}, 200} is a community list.

      <peer> A BGP peer is represented by the peer AS and  the  peer  address.
           For  example  AS312 10.9.9.1 represents the peering with the router
           10.9.9.1 in the AS 312.

2.2 Filter Types

   Unicast protocol filters are shown in  Figure-1.  The  following  describes
   some of the arguments used in these filters:

      ANY-ROUTE is a constant that always evaluates to TRUE.

      <prefix-range> is a prefix followed by one of the following range opera-
           tors:

         ^-  is the exclusive more specific operator. It represents  the  more
              specifics  of an address prefix excluding the prefix itself. For
              example, 128.9/16^- includes all of the more specifics  such  as
              128.9.10/24,   128.9.30.48/28,   and   128.9.50.99/32,  but  not
              128.9/16.

         ^+  is the inclusive more specifics operator. It represents the  more
              specifics  of an address prefix including the prefix itself. For
              example 128.9/16^+ will match all of the more specifics and also
              128.9/16 itself.

         ^n  represents all length n specifics of an address prefix. For exam-
              ple,    169.144.128/17^24    will   match   169.144.128/24   and
              169.144.132/24 but not 169.144.132/22 since the mask is not  24,
              and  not 169.144.96/24 since it is not a more specific (17th bit
              does not match).

         ^n-m represents any more specifics of an address prefix with the mask
              length between n to m. For example, 128.9.0/20^24-32, will match
              128.9.10/24 and 128.9.0.22/31, but  not  128.9.10/23  since  the
              mask  is not in the range of 24-32, and not 129.9.34.24/32 since
              it is not a more specific (19th bit does not match).





Cilingiroglu, Przygienda    Expires February 1999                     [Page 6]





Internet-Draft                      RPCL                          August 1998


      <prefix-range-list> is  a  list  of  address  prefix  ranges  in  braces
           separated  by  commas. It is a filter expression and it matches the
           address prefixes that match one of the prefix ranges  specified  in
           the list. For example,

                                       {10.9.1/24}

           will match the prefix 10.9.1/24, and

                     {10.1/16, 10.122/15^-, 11/8^+, 128.10/16^20-32}

           will match
              - route 10.1/16,
              - more specifics of 10.122/15 excluding 10.122/15  itself,  such
              as 10.123/16,
              -  more  specifics  of  11/8  including  11/8  itself,  such  as
              11.144.10/24, and
              - more specifics of 128.10/16 with the mask length between 20 to
              32, such as 128.10.200/22.


      <as-set> is a set of AS numbers in braces separated by commas,  such  as
           {AS12, AS47, AS111}.

      <aspath-regex> is a regular expression on ASes, enclosed in '<' and '>'.
           It is used as a policy filter for the BGP AS-path attribute.

           The regular expression constructs are as follows:
              ASx       matches ASx
              <as-set>  matches any one of the ASes in the set
              .         matches any AS number
              ^         matches to the empty string at the begining of an AS-path
              $         matches to the empty string at the end of an AS-path

           Regular expression operators are as follows:
              Unary postfix operators (left associative)
                 *         zero or more occurances
                 +         one or more occurances
                 ?         zero or one occurance
                 (m)       m occurances
                 (m,)      m or more occurances
                 (m,n)     m to n occurances

              Binary concetanation operator (lower precedence, left associative)
                 is an implicit operator. If A and B are regular expressions,
                 then A B matches an AS-path if A matches some prefix of the
                 AS-path and B matches the rest of the AS-path.




Cilingiroglu, Przygienda    Expires February 1999                     [Page 7]





Internet-Draft                      RPCL                          August 1998


           In the following, examples of <aspath-regex> expression are given
           along with the description of the aspaths that will match them:

              <AS5>                  aspaths that contain AS5
              <AS5 AS7>              aspaths with the subsequence AS5 AS7
              <AS5 .* AS7$>          aspaths containing AS5 and ending
                                     with AS7
              <^AS5 {AS3 AS7}+ AS9$> aspaths starting with AS5 ending with
                                     AS9 and having at least one occurances
                                     of AS3 and/or AS7 in the middle
              <^. AS5 .?$>           aspaths of length 2 or 3 with AS5 as
                                     the 2nd AS
              <{AS7 AS9 AS11}(2,4)$> aspaths with the  last 2 to 4  ASes
                                     being from the set {AS7 AS9 AS11}

2.3 Peering Types
   The basic peering expressions are as follows:

      ANY-PEER is a constant that will identify all peerings  with  the  local
           router.

      <peer-addr> An IPv4 address that uniquely identifies the peering between
           the local router and the peer router with the given address.

      <peer-as> A Peer AS identifies all the peerings between the local router
           and any of its peer routers in the given AS.

      <peer-set> is a set of Peer addresses and Peer ASes. It  identifies  all
           the  peerings  between the local router and any of its peer routers
           whose address or AS is in the given set.

           Some example peering expressions are given below:
             128.10.12.5              : matches the peering between the local
                                        router and its peer router 128.10.12.5.
             AS17                     : matches all peerings between the local
                                        router and any of its peer routers in
                                        AS17.
             {128.10.12.5, 10.9.64.10}: matches two peerings of the local router,
                                        one with the peer router 128.10.12.5 and
                                        the other with 10.9.64.10.
             {AS17, AS99}             : matches all peerings between the local
                                        router and any of its peer routers in
                                        AS17 or AS99.
             {128.10.12.5, 10.9.64.10, AS17, AS99}: matches all peerings that
                                        matches with the peer sets {128.10.12.5,
                                        10.9.64.10} or {AS17, AS99}.





Cilingiroglu, Przygienda    Expires February 1999                     [Page 8]





Internet-Draft                      RPCL                          August 1998


PROT  | Attribute   Type        Filter                      Action
------+---------------------------------------------------------------------------
STATIC| prefix      <prefix>    <prefix-range-list>          ---
------+---------------------------------------------------------------------------
DIRECT| prefix      <prefix>    <prefix-range-list>          ---
------+---------------------------------------------------------------------------
      | prefix      <prefix>    <prefix-range-list>          ---
      | src-gateway <prefix>    src-gtw==<prefix-range-list> ---
RIP   | preference  <integer>        ---                    pref=<integer>
      | metric      [1-15]           ---                    metric=<integer>
      | tag         <integer>   tag==<integer>              tag=<integer>
------+---------------------------------------------------------------------------
      | prefix      <prefix>    <prefix-range-list>          ---
      | preference  <integer>        ---                    pref=<integer>
OSPF  | metric      [1-65535]        ---                    metric=<integer>
      | tag         <integer>   tag==<integer>              tag=<integer>
      | type        <ospf-type> type==<ospf-type>           type=<ospf-type>
------+---------------------------------------------------------------------------
      | prefix      <prefix>    <prefix-range-list>          ---
      | origin      <as>        <as>                         ---
      | source-peer <peer>      src-peer==<peering-spec>     ---
BGP   | preference  <integer>        ---                    pref=<integer>
      | med         <integer>        ---                    med=<integer>
      | dpa         <integer>        ---                    dpa=<integer>
      | as-path     <as-path>   <aspath-regex>              aspath.prepend<as-path>
      | community   <comm-list> comm==<comm-list>           comm=<comm-list>
      |                         comm.contains<comm-list>    comm.=<comm>
      |                                                     comm.append<comm-list>
      |                                                     comm.delete<comm-list>
------+---------------------------------------------------------------------------

      Figure-1: route attributes, with their corresponding data types, filter
                expressions and action commands.

2.4 Filter, Action and Peering Specifications

   For a protocol PR, filter, action and peering specifications are defined as
   follows:

      <PR-filter> is a logical expression using the connectives  AND,  OR  and
           NOT,  and  the  filter  expressions  over  the attributes of the PR
           routes. Filter expressions for  several  protocols  are  listed  in
           Figure-1.  More  details  on  the  syntax  and  semantics are given
           through examples in the following sections.

      <PR-action> is an ordered list of action commands over the attributes of
           the  PR  routes.  Action  command  types  for several protocols are
           listed in Figure-1.



Cilingiroglu, Przygienda    Expires February 1999                     [Page 9]





Internet-Draft                      RPCL                          August 1998


      <PR-import-action> is an ordered list of action commands to be  used  at
           import  time.  The  command types are a subset of the command types
           available in <PR-action>. In Figure-1, commands associated with the
           tag,  metric and type attributes of RIP and OSPF are used at export
           time only. All other command types can be used during import time.

      <PR-export-action> is an ordered list of action commands to be  used  at
           export  time.  The  command types are a subset of the command types
           available in <PR-action>. In Figure-1, commands associated with the
           preference  attribute in RIP and OSPF are used at import time only.
           All other command types can be used during export time.

      <peering> is either ANY-PEER or of  type  <peer-addr>  or  <peer-AS>  or
           <peer-set>.

3. Import Policy Rules

   A routing protocol imports some of the routes that  it  receives  from  its
   neighbor  by  inserting  them into the RIB. Import policy is configured for
   each protocol to determine:

      - which routes should be imported and which ones should  be  blocked  by
      that protocol, and
      - what should be the route attributes of the routes that are imported.

   Import policy is configured using import rules.  The  basic  syntax  of  an
   import rule  for a protocol PR is the following:

    <PR-Import-Rule>:
       [from <peering>] [action <PR-import-action>] accept <PR-filter> |
       [from <peering>] block <PR-filter>

   where [from <peering>] is used by External Gateway Protocols (EGP), such as
   BGP, but not by Internal Gateway Protocols (IGP), such as RIP and OSPF.

   Evaluation of an import rule for the routes received by the protocol PR  is
   as follows:

      - A route matches the import rule, if it matches the <PR-filter> specif-
      ication and, in case PR is an EGP protocol, the peer it is received from
      matches the <peering> specification.

      - A matching rule is applied by taking the action suggested by the  key-
      word  preceding the <PR-filter>, i.e. importing the route if the keyword
      is "accept", and rejecting it if it is "block".  The  attributes  of  an
      accepted route are updated by the <action> specification. It is optional
      and if not specified the default values are used for the attributes.




Cilingiroglu, Przygienda    Expires February 1999                    [Page 10]





Internet-Draft                      RPCL                          August 1998


   In Figure-2, some of the properties of import policies are listed for  pro-
   tocols RIP, OSPF and BGP. They can be summarized as follows:

      - All three protocols need policy configuration for import decisions.

      - Only RIP is allowed to have a block rule, i.e. a rule with the "block"
      keyword.  OSPF and I-BGP (Internal BGP) cannot block routes, because all
      routers running OSPF or I-BGP should have the similar view of  the  net-
      work. E-BGP (External BGP), on the other hand, does not need block rules
      simply because block is the default action to take.

      - If no rule matches a received route, then the default action is taken.
      It  is  to  accept  the route with default attributes if the protocol is
      RIP, OSPF or I-BGP, and to block it if the protocol is E-BGP.


                                 |  RIP  | OSPF  | I-BGP | E-BGP |
                  ---------------+-------+-------+-------+-------+
                  Configuration  |  YES  |  YES  |  YES  |  YES  |
                  ---------------+-------+-------+-------+-------+
                  Block Rule     |  YES  |  ---  |  ---  |  ---  |
                  ---------------+-------+-------+-------+-------+
                  Default-Action |ACCEPT |ACCEPT |ACCEPT |  BLK  |
                  ---------------+-------+-------+-------+-------+

           Figure-2: Properties of Import policies for several protocols



   We now give examples of import rules for RIP, OSPF, and BGP. The  following
   are examples of RIP import rules:

      block {128.9/16^+} and tag==10

   blocks all routes that are more specifics of 128.9/16 (including  128.9/16)
   and have the tag value of 10.

      action pref=10 accept src-gw=={192.100.100/24^+}

   imports all routes that are received  from  a  gateway  where  the  gateway
   address  is  a   more specific of 192.100.100/24. It sets the preference of
   all such routes to 10.

   Example of OSPF import rules are as follows:

      action pref=5 accept ANY-ROUTE

   imports all OSPF routes with a preference of 5.



Cilingiroglu, Przygienda    Expires February 1999                    [Page 11]





Internet-Draft                      RPCL                          August 1998


      action pref=10
      accept {10.3/16^-, 20/8^+} and (type==INTER-AREA or tag==100)

   imports any more specifics of 10.3/16 (excluding 10.3/16) and more  specif-
   ics  of  20/8  (including 20/8) that are of type INTER-AREA or have the tag
   value 100.  All imported routes will be assigned the preference 10.

   Examples of BGP Import rules are as follows:

      from 10.9.9.6 action pref=1 accept AS11 or {128.9/16^+}

   imports all routes received from the peer router 10.9.9.6, that are  either
   originated  from AS11 or match 128.9/16^+. All imported routes will get the
   preference 1.

      from {10.9.9.1, 10.9.9.5, AS17, AS25}
      action med=0; community.append(3261,NO-EXPORT); aspath.append(AS5)
      accept {169.9/16^24-32} and <^AS11 AS26 .* AS7> and
             community.contains(10250)

   imports all routes that:
      - are received from the peer router 10.9.9.1 or 10.9.9.5, or from a peer
      router that is in AS17 or AS25, and
      - are more specifics of 169.9/16 with a length between 24 to 32, and
      - have an aspath that starts with AS11, AS26 and contains AS7, and
      - have a community list that contains the community 10250.

   All routes that are imported will  have  the  following  changes  in  their
   attributes:
      - multi-exit-discriminator set to 0
      - community-list appended with the community 3261 and NO-EXPORT
      - aspath appended with AS5.

   So far only the basic forms of import rules are described. They can also be
   structured.  The  two  types of structured rules, compound rules and refine
   rules, are described below.

   A compound rule is of the form:

      <PR-Import-Compound-Rule>: {<PR-Import-Rule>; <PR-Import-Rule>; ...}

   It is an ordered list of import rules with the following semantics:

      - A route matches a compound rule if it matches  at  least  one  of  the
      rules in its list, and
      - if there are matching rules, then the first such rule  is  applied  to
      the route.




Cilingiroglu, Przygienda    Expires February 1999                    [Page 12]





Internet-Draft                      RPCL                          August 1998


   As an example, consider the following BGP rule:

      {
        from 10.9.9.5 action pref=1;  accept ANY-ROUTE;
        from AS5      action pref=5;  accept AS5;
        from AS5      action pref=10; accept ANY-ROUTE;
      }

   Assume that the router 10.9.9.5 is in AS 5.  The  above  rule  imports  any
   route coming  from AS 5, but with different preferences. Routes coming from
   the peer router 10.9.9.5 are given the preference 1.  If  they  are  coming
   from another peer router in AS 5, then the ones that are originated by AS 5
   are given the preference 5, and all the others are given the preference 10.

   The other type of structured rule is a refine rule with the following  syn-
   tax:

        <PR-Import-Refine-Rule>: <PR-Import-Rule> refine <PR-Import-Rule>

   It is used to refine, i.e. extend, one rule by another one.  Its  semantics
   is as follows:

      -A route matches a refine rule if it matches the component rules on both
      sides.
      -If it matches, then the rule on the left is  applied  followed  by  the
      rule on the right. One restriction in refine rules is that rules on both
      sides should be composed of either all accept rules or all block  rules.
      Otherwise,  the  semantics become ambigious if an accept rule matches on
      one side and a block rule on the other.

   Consider the following examples of BGP import rules:

      from AS5 action pref=1; accept <^AS12>
      refine
         from 10.9.9.5
         action community.append(1210);
         accept {10/8^+} and <AS39>

   Assume that the router 10.9.9.5  is  in  AS  5.  Then  the  above  rule  is
   equivalent to

      from 10.9.9.5
      action pref=1; community.append(1210);
      accept {10/8^+} and <^AS12 .* AS39>

   Notice that the two rules on both sides of the refine are combined by  and-
   ing  their peering and the filter specifications and appending their action
   specifications.



Cilingiroglu, Przygienda    Expires February 1999                    [Page 13]





Internet-Draft                      RPCL                          August 1998


   from ANY-PEER accept AS5;
      refine
        {
          from ANY-PEER action pref=1;  accept community.contains(1210);
          from ANY-PEER action pref=5;  accept community.contains(1410);
          from ANY-PEER action pref=10; accept ANY-ROUTE;
        }
        refine
          {
            from 10.9.9.5 action med=100; accept ANY-ROUTE;
            from AS5      action med=50;  accept ANY-ROUTE;
            from ANY-PEER action med=0;   accept ANY-ROUTE;
          }

   imports all routes that are originated by AS5, but with  different  prefer-
   ence  and  med   values based on the content of their community strings and
   the peers that they are  received  from,  respectively.  Specifically,  the
   routes  that  have  the community 1210 are given the preference 1, the ones
   that have the community 1410 are given the preference 5, and all the others
   are  given  the preference 10. Similarly, the routes that are received from
   the peer router 10.9.9.5 are given the med value 100,  the  ones  that  are
   received  from  another  peer router in AS 5 are given the med value of 50,
   and the ones that are received from elsewhere are given the med value of 0.

   Finally, the full syntax of an import rule for protocol PR is:

    <PR-Import-Rule>:
       [from <peering>] [action <PR-import-action>] accept <PR-filter> |
       [from <peering>] block <PR-filter>                              |
       {<PR-Import-Rule>; <PR-Import-Rule>; ...}                       |
       <PR-Import-Rule> refine <PR-Import-Rule>


4. Export Policy Rules

   A routing protocol exports (i.e. advertizes) some of the routes in the  RIB
   to its neighbors. The exported route might belong to the exporting protocol
   or to another protocol. Export policy is configured from a protocol  SRC_PR
   (the  owner  protocol)  to  a  protocol  DST_PR (the exporting protocol) to
   determine:

      -which SRC_PR routes should be exported by DST_PR protocol to its neigh-
      bors, which ones should be blocked, and
      -with what attributes should the routes be  exported.  Notice  that  the
      SRC_PR  routes  will be exported as DST_PR routes, therefore they should
      be exported with DST_PR attributes.





Cilingiroglu, Przygienda    Expires February 1999                    [Page 14]





Internet-Draft                      RPCL                          August 1998


   Export policy is configured using export rules. The  syntax  of  an  export
   rule from a protocol SRC_PR to a protocol DST_PR is as follows:

   <SRC_PR-to-DST_PR-export-rule>:
     [to <peering>] [action <DST_PR-export-action>] announce <SRC_PR-filter> |
     [to <peering>] block <SRC_PR-filter>

   where [to <peering>] is used by External Gateway Protocols,  such  as  BGP,
   but not by Internal Gateway Protocols, such as RIP and OSPF.

   The evaluation of an export policy rule is similar to the import rules. For
   a  rule  from protocol SRC_PR to protocol DST_PR, the rule evaluation is as
   follows:

      -A SRC_PR route matches the export rule,  if  it  matches  the  <SRC_PR-
      filter>  and, in case DST_PR is an EGP protocol, the peer that the route
      is sent to matches the <peering> specification.

      -Matching routes are exported if the <SRC_PR-filter> is preceded by  the
      keyword  "announce",  and  they are blocked otherwise. An exported route
      will be a DST_PR route, and some its  attributes  will  be  set  by  the
      optional  <DST_PR-export-action>,  and  the others will take its default
      values.

                    SRC PROTOCOL                         SRC PROTOCOL

                | RIP |OSPF | BGP |               |  RIP | OSPF |  BGP |
      ----------+-----+-----+-----+       --------+------+------+------+
      Static    | YES | YES | YES |       Static  | BLK  | BLK  | BLK  |
      ----------+-----+-----+-----+       --------+------+------+------+
      Direct    | YES | YES | YES |       Direct  | BLK  | BLK  | BLK  |
 DST  ----------+-----+-----+-----+  DST  --------+------+------+------+
 PROT RIP       | YES | YES | YES |  PROT RIP     |ACCEPT| BLK  | BLK  |
      ----------+-----+-----+-----+       --------+------+------+------+
      OSPF      | YES | --- | YES |       OSPF    | BLK  |ACCEPT| BLK  |
      ----------+-----+-----+-----+       --------+------+------+------+
      BGP       | YES | YES | YES |       I-BGP   | BLK  | BLK  |ACCEPT|
      ----------+-----+-----+-----+       --------+------+------+------+
      Block Rule| YES | --- | --- |       E-BGP   | BLK  | BLK  | BLK  |
      ----------+-----+-----+-----+       --------+------+------+------+
    (a) Configuration and Block Rule             (b) Default-Action

        Figure-3: Properties of Export policies for several protocols


   In Figure-3, some properties of export policies are listed for some of  the
   protocol pairs. They can be summarized as follows:




Cilingiroglu, Przygienda    Expires February 1999                    [Page 15]





Internet-Draft                      RPCL                          August 1998


      -Export policy need not be configured for every protocol pair. For exam-
      ple, OSPF has to export all OSPF internal routes to all of its neighbors
      without any attribute change. Therefore, there is no  policy  configura-
      tion needed for an export from OSPF to OSPF.

      -Only RIP is allowed to have a block rule. The other  protocols  do  not
      have  it  either  because  they  cannot  block any route from export, or
      because their default actions are block and they don't need it.

      -The default action is taken in case no rule matches the route. It is to
      export  the route with default attributes, in case RIP, OSPF or I-BGP is
      exporting its own route, and it is to block for all other cases.

   Following are examples of export policy rules:

   The following rule from RIP to RIP

      action tag=100; metric=1210
      announce tgt-gw=={120.100/16^+} and src-gw=={196.122.44/24^+}

   is used by RIP to export all  RIP  routes  received  from  a  gateway  that
   matches  196.122.44/24^+,  to a gateway that matches 120.100/16^+. All such
   routes are exported with the tag value of 100 and the metric value of 1210.

   The rule from BGP to RIP

      action tag=200;
      announce src-peer==AS11 or AS11

   is used by RIP to export BGP routes that are either originated by AS 11  or
   received  from  a  peer in AS 11. All such routes are exported with the tag
   value of 200.

   The rule from BGP to OSPF

      action tag=100; type=EXTERNAL-2;
      announce community.contains(3210)

   is used by OSPF to export BGP routes that has the community 3210, with  the
   tag value of 100 and the OSPF type EXTERNAL 2.

   The rule from RIP to BGP

      to AS11
      action med=10; aspath.append(AS9);
      announce {120.100/16^+} and src-gw=={196.122.44.12}

   is used by BGP to export RIP routes to peers in AS 11,  that  are  received



Cilingiroglu, Przygienda    Expires February 1999                    [Page 16]





Internet-Draft                      RPCL                          August 1998


   from  the gateway 196.122.44.12 and match 120.100/16^+. All such routes are
   exported with a med value of 10 and with AS9 appended to their aspath.

   The rule from BGP to BGP

      to {12.10.10.3, 12.10.10.7, AS11}
      action community.append(NO-EXPORT)
      announce <^AS19 .* AS54>

   is used by BGP to export BGP routes that have an aspath starting with AS 19
   and  including AS 54, to peers 12.10.10.3, 12.10.10.7 or the ones in AS 11.
   Routes are exported with NO-EXPORT community appended  to  their  community
   string.

   Export rules can be compounded and refined just like import rules. The full
   syntax for an export rule is the following:

   <SRC_PR-to-DST_PR-export-rule>:
      [to <peering>] [action <DST_PR-export-action>] announce <SRC_PR-filter> |
      [to <peering>] block <SRC_PR-filter>                                    |
      {<SRC_PR-to-DST_PR-Export-Rule>; <SRC_PR-to-DST_PR-Export-Rule>; ...}   |
      <SRC_PR-to-DST_PR-Export-Rule> refine <SRC_PR-to-DST_PR-Export-Rule>


5. Aggregation Policy Rules

   An aggregate route is used to summarize the component routes of an  address
   range. By default when an aggregate route is exported to a neighbor, all of
   its component routes (i.e. routes that are more specific  than  the  aggre-
   gate)  are  suppressed.   This  reduces the amount of route propagation and
   controls the growth of the IP routing and forwarding tables. Some component
   routes,  however,  may  need  to  be  exported  along with the aggregate to
   satisfy some topology constraints (such as multi-homed components in  BGP).
   Aggregation  policy is used by a protocol to determine the aggregate routes
   that a router generates and which component routes to export along with the
   aggregate.

   Some protocols, such as BGP, perform aggregation via a  configured  policy.
   Based on  the current state of the RIB, the configured aggregation rules of
   a protocol PR determine:

      -what aggregates to generate and the route attributes  of  those  aggre-
      gates (aggregate activation evaluation)
      -in case PR exports an aggregate route to a  neighbor,  what  components
      (i.e.  more  specifics) to export along with the aggregate and what com-
      ponents to suppress (aggregate export evaluation)

   The syntax of an aggregation rule for a protocol PR is as follows:



Cilingiroglu, Przygienda    Expires February 1999                    [Page 17]





Internet-Draft                      RPCL                          August 1998


      <PR-aggregation-rule>:
         aggregate into     <prefix>
         triggered by       AND/OR of HC{<prefix-range-list>} and
                                      EX{<prefix-range-list>}
         components         ATOMIC | [protocol <PR_1>] <PR_1-filter>
                                    [[protocol <PR_2>] <PR_2-filter>] ...
         action             <PR-action>
         export components  from <PR_1> <PR_1-to-PR-export-rule>
                           [from <PR_2> <PR_2-to-PR-export-rule>] ...
         holes              <prefix-range-list>

   The semantics of an aggregation rule for a protocol PR is best described by
   explaining each of its attributes as follows:


      aggregate: specifies the prefix of the aggregate for which the  rule  is
           defined.


      trigger: determines, along with the components attribute, the conditions
           needed to generate the aggregate. The trigger requires certain pre-
           fix ranges to be present and certain others to be absent in the RIB
           as a precondition for generation.

           The trigger is specified by a logical expression using the  connec-
           tives  AND  and  OR, and the constructs HC (Have-Components) and EX
           (EXclude) defined as follows:

              HC{<prefix-range-list>}: true iff there is a matching route
                                       in the RIB for every
                                       prefix-range in the list.

              EX{<prefix-range-list>}: true iff there is no matching route
                                       in the RIB for any of the
                                       prefix-ranges in the list.

           The aggregate route is generated and put  into  the  RIB  when  the
           trigger  condition  becomes  true, and removed from the RIB when it
           becomes false. For example, the rule

             aggregate into 10/8
             triggered by   HC{10.1/16^24-32, 10.2.2/24^+} AND EX{11/8^+}

           specifies that the aggregate 10/8 will be added to the RIB only  if
           there  are  routes  matching  10.1/16^24-32 and 10.2.2/24^+, and no
           routes matching 11/8^+ in the RIB.





Cilingiroglu, Przygienda    Expires February 1999                    [Page 18]





Internet-Draft                      RPCL                          August 1998


      components: determines the route attributes of the aggregate, if  it  is
           generated. This attribute has the following syntax:

              components ATOMIC | [protocol <PR_1>] <PR_1-filter>
                                 [[protocol <PR_2>] <PR_2-filter>] ...

           The components attribute is either specified by the keyword  ATOMIC
           or  by a list of filters and their corresponding protocols.  In the
           former case attributes of  the  aggregate  are  assigned  to  their
           default  values,  and in the latter they are computed from a subset
           of the component routes, called attribute-components.

           Attribute-components consist of the more specifics of the aggregate
           that  match one of the filters and are learned from the correspond-
           ing protocol. If the protocol is omitted in front of a filter  then
           it defaults to any protocol.

           The properties of the attribute computation are as follows:

              - the computation might result in a conflict of some of the com-
              ponent  attributes, in which case the aggregate will not be gen-
              erated. An example conflict is the  case  where  the  routes  in
              attribute-components do not have the same next-hop.
              - the attributes of the aggregate have to be  re-computed  every
              time  the  state  of the attribute-components change (i.e. a new
              component passes the components filter),  when  a  component  no
              longer  passes  the components filter, or when a component still
              passes the components filter but  had  a  change  in  its  route
              attributes.
              - if no trigger attribute  is  specified,  then  the  components
              attribute is used to decide whether to generate the aggregate or
              not. It will be generated only if  the  attribute-components  is
              not  empty  (i.e.  at least one of the more specifics in the RIB
              matches the components filter).

           For example,

              aggregate into 128.64/10
              components
                 protocol BGP  {128/8^+}
                 protocol OSPF {128.70/15^16-24} and type==INTER-AREA

           uses BGP routes that are more specifics of 128.64/10 and inter-area
           OSPF  routes  that  match  128.70/15^16-24  for computing the route
           attributes of the aggregate 128.64/10. Notice that since  the  more
           specifics  are exclusively used in the computation, all filters are
           implicitly ANDed with {128.64/10^-}.




Cilingiroglu, Przygienda    Expires February 1999                    [Page 19]





Internet-Draft                      RPCL                          August 1998


      action: a list of PR actions applied each time the route  attributes  of
           the  aggregate  are (re-)evaluated. The action attribute is used to
           modify some of the attributes that are either set to their  default
           values (i.e. ATOMIC) or computed from the more specifics.

           For example,

              action  {comm.delete(NO-EXPORT); med=100}

           if present, removes the NO-EXPORT community from the community list
           of the aggregate and set its med to 100.


      export components: allows some of the more  specific  components  of  an
           aggregate  to  be  exported.  In  general, when a set of routes are
           aggregated, the intent is to export only the aggregate and suppress
           all  the  more  specifics.   However, to satisfy some topology con-
           straints such as a multi-homed  component,  this  attribute  allows
           some  of the components to be exported. Using the export components
           attribute a list of export policy rules from a number of  protocols
           to  the  protocol  PR  (the aggregator protocol) is specified.  The
           export components attribute is of the form:

              export components  from <PR_1> <PR_1-to-PR-export-rule>
                                [from <PR_2> <PR_2-to-PR-export-rule>] ...

           The following specifies the evaluation of an aggregate and its more
           specifics for export:

              - Every time the aggregate is generated or has a change  in  its
              attributes:
                 - it is (re)evaluated for export to all the neighbors.
                 - to the neighbors that the aggregate was exported before but
                 blocked now, the export of more specifics are evaluated using
                 the configured export policy.
                 - to the neighbors that the aggregate was not exported before
                 but  exported now, the export of more specifics are evaluated
                 using the export components of  the  corresponding  aggregate
                 rule.

              - When the aggregate is removed from the RIB (either because the
              trigger became false or the component attributes conflict):
                 - to the neighbors that the aggregate  was  exported  before,
                 the  export of more specifics are evaluated using the config-
                 ured export policy.

           The following are some examples of the export components attribute:




Cilingiroglu, Przygienda    Expires February 1999                    [Page 20]





Internet-Draft                      RPCL                          August 1998


              aggregate into     10/8
              export components  from ANY-PROTOCOL announce {10.1/16^-}

           specifies that when the aggregate 10/8 is exported to  a  neighbor,
           all  the more specifics are suppressed from export to that neighbor
           except the ones that are also more specifics of 10.1/16.

              aggregate into 128.100/16
              export components
                 from OSPF
                    to {AS17, AS126} action dpa=50 announce ANY-ROUTE

           is a BGP aggregate rule where OSPF more specifics of 128.100/16 are
           exported  to  the  peers in AS17 or AS126 along with the aggregate,
           and in all other cases the more specifics are suppressed.


      holes: a prefix range list that specifies the holes  in  the  aggregate,
           i.e.   the  more  specific address ranges not reachable through the
           aggregate route (perhaps they are not allocated).  Holes  attribute
           has no functional role, it is for diagnostic purposes only.

   Here is an example BGP aggregation rule that uses all the rule attributes:

      aggregate into     10/8
      triggered by       HC{10.1/16^24-32, 10.2.2/24^+} AND EX{11/8^+}
      components         protocol RIP  {10.3/16^+} AND
                                       src-gw=={50.10/16^+}
                         protocol BGP  AS5
                         protocol OSPF ANY-ROUTE
      action             {med=100; community.delete(NO-EXPORT);}
      export components  from OSPF
                            to {AS10, 128.10.9.9} announce ANY-ROUTE
                         from BGP
                            to {AS10} announce AS5
      holes              {10.100.100/24^+}


   In case of overlapping aggregation rules, where the aggregate of  one  rule
   is  a  lesser  specific of another one, the semantics of rule evaluation is
   extended as follows:

      - activation evaluation: is performed starting from  the  rule  for  the
           most  specific  aggregate  to  the rule for the least specific one.
           This ensures that, the activation evaluation for an aggregate  will
           consider  the  most  current  activation state of the more specific
           aggregates (i.e. whether they are present in the  RIB  or  not  and
           their route attributes if they are in the RIB).



Cilingiroglu, Przygienda    Expires February 1999                    [Page 21]





Internet-Draft                      RPCL                          August 1998


      - export evaluation: a route is exported to a neighbor iff:
              - it is the least specific aggregate in the RIB that passes  the
              export policy, or
              - it passes the export components attribute  of  an  aggregation
              rule whose aggregate is exported, or
              - there are no aggregates of this route that passes  the  export
              policy, but the route itself passes it.

           Notice  that  the  above  conditions  describe  chains  of  routes,
           A1,A2,...,An,Rn+1, where:
              - all Ai are active aggregates, and
              - A1 is the least specific aggregate in the RIB that passes  the
              export policy, and
              - each Ai is a more specific of Ai-1 and Ai  passes  the  export
              components of Aj for some j<i, and
              - Rn+1 is a non-aggregate route which  passes  the  export  com-
              ponents of Aj for some j<n+1.

   Consider the following example of overlapping aggregate rules for BGP:

      aggregate into 10/8
      triggered by
         HC{10.3/16, 10.16/15, 10.72.3/24}
      export components
         from BGP to {AS2} announce {10.3/16}
         from BGP to {AS1, AS2} announce {10.16/12^12-15}

      aggregate into 10.16/15
      triggered by
         HC{10.16/16}
      export components
         from BGP to {AS1, AS2} announce {10.16/15^16}

      aggregate into 10.16/16
      triggered by
         HC{10.16.0/18^+, 10.16.128/18^+}
      export components
         from RIP to ANY-PEER announce {10.16.100/24^+}

      aggregate into 10.17/16
      triggered by
         HC{10.17/16^-}
      export components
         from OSPF to {AS2} announce {10.17/16^24}

      aggregate into 10.3/16
      triggered by
         HC{10.3/16^-}



Cilingiroglu, Przygienda    Expires February 1999                    [Page 22]





Internet-Draft                      RPCL                          August 1998


   The aggregate rules form the following tree:

                           10/8
                             |
                      +------+------+
                      |             |
                   10.16/15      10.3/16
                      |
                 +----+----+
                 |         |
             10.16/16   10.17/16

   Activation evaluation for the aggregates proceed bottom up (i.e., from  the
   leaf  nodes to the root node). For example, consider the activation evalua-
   tion of 10/8 (assuming no conflicts in route attributes):

      - 10/8 will be generated only if 10.3/16, 10.16/15, and  10.72.3/24  are
      all  in  the  RIB.  Notice  that  10.3/16 and 10.16/15 can themselves be
      active aggregates or non-aggregate routes exported from a neighbor.
      - if 10.3/16 is an active aggregate then the  generation  of  10/8  also
      depends on the existance of a route in the RIB that matches 10.3/16^-.
      - similarly, if 10.16/15 is an active aggregate then the  generation  of
      10/8  depends  on  the  existance  of  a  route  in the RIB that matches
      10.16.0/18^+ and another one that matches 10.16.128/18^+.

   Export evaluation, on the other hand, is performed top down (i.e. from  the
   least  specific active aggregate to the most specific). For example, in the
   above configured policy, the following  routes  will  be  exported  to  AS1
   (assuming that all aggregates  are active and 10/8 passes the export policy
   for AS1):

      - 10/8 is the least specific aggregate that passes the export policy, so
      it will be exported.
      - 10.16/15 will be exported, since it passes the  export  components  of
      the rule for 10/8
      - Both 10.16/16 and 10.17/16 will  be  exported,  since  they  pass  the
      export components of the rule for 10.16/15.
      - Any RIP route that matches 10.16.100/24^+ will also be exported, since
      it matches the export components of the rule for 10.16/16.












Cilingiroglu, Przygienda    Expires February 1999                    [Page 23]





Internet-Draft                      RPCL                          August 1998


6. Acknowledgments

   We would like to thank Rob Coltun and Sanjay  Wadhwa  for  their  contribu-
   tions, valuable comments and suggestions.

7. Authors' Addresses

   Ardas Cilingiroglu
   FORE Systems
   1595 Spring Hill rd. 5th floor,
   Vienna, VA 22182
   acilingi@fore.com

   Tony Przygienda
   Bell Labs, Lucent Technologies
   101 Crawfords Corner rd.
   Holmdel, NJ 07733-3030
   prz@dnrc.bell-labs.com

8. References

   [1] C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer,
       M. Terpstra, and C. Villamizar. "Routing Policy Specification
       Language (RPSL)". Request for Comment RFC-2280, January 1998.

   [2] Alaettinouglu, C., Meyer, D., and J.  Schmitz. "Application of
       Routing Policy Specification Language (RPSL) on the Internet",
       Work in Progress.

   [3] Internet Routing Registry. Procedures.
       http://www.ra.net/RADB.tools.docs/,
       http://www.ripe.net/db/doc.html.

   [4] A. M. R. Magee. "RIPE NCC Database Documentation".  Technical
       Report RIPE-157, RIPE, RIPE NCC, Amsterdam, Netherlands, May
       1997.















Cilingiroglu, Przygienda    Expires February 1999                    [Page 24]





Internet-Draft                      RPCL                          August 1998


APPENDIX A. A Policy Editor for RPCL

   Previous sections have described the syntax and semantics of a language  to
   specify  routing  policies.  This section describes an editor to to be used
   for configuring RPCL policies on a router.

   On a physical router device, there can be multiple IP instances, where each
   instance identifies the implementation of a logical router with its own RIB
   running its own instances of routing protocols and policies. The command

      (1) set ip-instance <ip-inst-id>

   is used to set the current ip instance on a  physical  router  device.  The
   commands  following (1) are used to configure the protocols and policies of
   the logical router specified by the given IP instance.

   Each IP instance stores its routing policies in a database, where each pol-
   icy  of  a  protocol  is  configured on a separate global policy table. The
   names and contents of these tables are listed below:


      IMPORT-<PR>: defines the ordered list of import rules used by the proto-
           col  <PR> to decide which of the received routes to import and with
           what route attributes. This list is of the form:

              IMPORT-<PR> :
                   {<PR-Import-Rule>; <PR-Import-Rule>; ... }


      EXPORT-<SRC_PR>-<DST_PR>: defines the ordered list of export rules  used
           by  the protocol <DST_PR> to decide which <SRC_PR> routes to export
           to a neighbor and with what route attributes. This list is  of  the
           form:

              EXPORT-<SRC_PR>-<DST_PR> :
                   {<SRC_PR-to-DST_PR-Export-Rule>;
                    <SRC_PR-to-DST_PR-Export-Rule>; ... }


      AGGREGATE-<PR>: defines the unordered set of aggregation rules  used  by
           the  protocol  <PR>  to decide what <PR> aggregates to generate and
           which more specifics of these aggregates to suppress  from  export.
           This set is of the form:

              AGGREGATE-<PR>:
                  {<PR-Aggregation-Rule>; <PR-Aggregation-Rule>; ... }





Cilingiroglu, Przygienda    Expires February 1999                    [Page 25]





Internet-Draft                      RPCL                          August 1998


   Rules in an import or export table are ordered. When a  protocol  evaluates
   its  import or export policy for a route, the decision is taken by applying
   the first matching rule in the corresponding global  policy  table.  If  no
   rule  in  the  table matches, then the appropriate default action is taken.
   Default actions depend on the policy and the protocols involved,  and  they
   are shown in Figures 2 and 3.

   Rules in an aggregation policy table, on the other hand, are  not  ordered.
   Every  time  the  state  of  the RIB changes (i.e. some route R gets added,
   removed or changed), all aggregation rules that define an aggregate  for  R
   are  evaluated  in  the  order  of the most specific aggregate to the least
   specific one.

   Initially, when the router is started, all global tables  are  empty.  This
   means  that  the  default  actions  will be taken for all import and export
   decisions, and no aggregate will be generated. Later, policies are  config-
   ured  (and  re-configured)  by changing the contents of their corresponding
   global tables.

   Parts of global tables that are repeatedly used can be defined as a  macro.
   The  macros are explained in section A.1. Configuration commands to insert,
   remove and reorder policy rules in a global policy table are given in  sec-
   tions A.2 and A.3.

   Changing the contents of the policy database is an expensive operation. All
   current policy decisions that might get affected by the policy changes have
   to be re-evaluated by the protocols. Therefore, changes in the database (as
   requested  by the configuration commands that are issued) are not committed
   after each configuration command but delayed until an explicit commit  com-
   mand is specified. The details of commiting is explained in A.4.

A.1 Policy Macros

   Some policy pieces that are used repeatedly during policy configuration can
   be defined as a macro. The generic syntax of a macro is:

      define <macro-name> <object>

   All macro references, <macro-name>, in the configuration  are  replaced  by
   its object definition, <object>.

   Naming of macros are restricted based on the type of the policy piece  they
   define.  Each macro name is made up of two parts separated by the character
   hyphen "-". The first part is a constant string specifying the type of  the
   policy  piece, and the second part is a free string of 8 characters assign-
   ing a unique name to the macro. For  example  "peer-internal"  is  a  valid
   macro name where "peer" specifies that it defines a peer set and "internal"
   results in a unique name for the macro.



Cilingiroglu, Przygienda    Expires February 1999                    [Page 26]





Internet-Draft                      RPCL                          August 1998


   Some macros define attributes of a policy rule. Their syntax  are  as  fol-
   lows:

      (2) define peer-<str8>  <peer-set>

      (3) define fltr-<str8>  <filter>

      (4) define act-<str8>   <action>

   The following is an example of their use:

      define peer-nghbors {as17, 128,166.9.9, as57}

      define fltr-for128  {128.176/20^+, 128.0/9^20-24} and
                          (as12 or <as12>)

      define act-for128   {pref=10; aspath.prepend(as99)}

   Using the above macros one can define the following BGP import rule:

      from peer-nghbors
      action act-for128
      accept (fltr-for128 and {as217, as61, as126})

   which expands to

      from {as17, 128,166.9.9, as57}
      action {pref=10; aspath.prepend(as99)}
      accept ({128.176/20^+, 128.0/9^20-24} and
              (as12 or <as12>) and
              {as217, as61, as126})

   Macros may also be used for defining list of policy rules. The following is
   the syntax for import, export and aggregation rule lists, respectively:

      (5) define imp-<str8>
             protocol <PR>
             {<PR-Import-Rule>; <PR-Import-Rule>; ... }

      (6) define exp-<str8>
             protocol <SRC_PR> into <DST_PR>
             {<SRC_PR-to-DST_PR-Export-Rule>;
              <SRC_PR-to-DST_PR-Export-Rule>; ... }

      (7) define aggr-<str8>
             protocol <PR>
             {<PR-Aggregation-Rule>; <PR-Aggregation-Rule>; ... }




Cilingiroglu, Przygienda    Expires February 1999                    [Page 27]





Internet-Draft                      RPCL                          August 1998


   As explained before, rules in an import or export policy list are  ordered.
   When defining a macro, this ordering is explicitly specified by listing the
   rules. However, macros can also be  modified  by  inserting/removing  rules
   to/from them, in which case the ordering has to be specified implicitly. An
   integer, called a rule number, is assigned to individual rules of  a  macro
   to  impose  this ordering. A rule with a smaller rule number comes before a
   rule with a larger one. Rule numbers are also used to refer to the rules of
   an  import  or  export policy macro. The syntax for rule referrals can take
   the following forms:

      <macro-name>: refers to all the rules of that macro.

      <macro-name> <rule-num>: refers to the rule  in  <macro-name>  with  the
           rule number <rule-num>.

      <macro-name> <rule-num-1>-<rule-num-2>:  refers  to  all  the  rules  in
           <macro-name>  with  the  rule  number  in  between <rule-num-1> and
           <rule-num-2>, both inclusive.

   For example, "imp-mypol 5-7" refers to the rules in imp-mypol with the rule
   numbers 5, 6 or 7. In rule referrals, the character "$" denotes the maximum
   rule number used in a macro. For example "exp-pol5 $" refers  to  the  last
   rule in exp-pol5.

   Initially, when an import or export policy  macro  is  defined,  rules  are
   assigned  consecutive  rule numbers starting from 1. Later the contents and
   the rule numbers of macros can be modified using the following commands:

      (8) insert imp-<str8>
             {<PR-Import-Rule>; <PR-Import-Rule>; ... }
             [<rule-num>]

            appends the specified import rules after imp-<str8>  [<rule-num>].
            If  <rule-num>  is  not specified it defaults to $, i.e. rules are
            appended to the end. The inserted rules are  assigned  consecutive
            rule  numbers starting from the <rule-num> plus one. If any of the
            rule numbers are already assigned to another rule, then the inser-
            tion  is  aborted.  In such cases, the move command has to be used
            first to open up the space for insertion.

      (9) remove imp-<str8>
             <rule-num>[-<rule-num>]

            removes the rules that  match  imp-<str8>  <rule-num>[-<rule-num>]
            from the macro imp-<str8>.

      (10) move imp-<str8>
              <rule-num>[-<rule-num>]  up | down  <num>



Cilingiroglu, Przygienda    Expires February 1999                    [Page 28]





Internet-Draft                      RPCL                          August 1998


            assigns new rule  numbers  to  the  rules  that  match  imp-<str8>
            <rule-num>[-<rule-num>].  If "up" is specified in the command, the
            rules are assigned their current rule numbers  plus  <num>.  Simi-
            larly,  if  "down"  is  specified, they are assigned their current
            rule numbers minus <num>. If any  of  the  new  rule  numbers  are
            already  assigned  to  another  rule,  then  the move operation is
            aborted. Notice that move does not change the relative ordering of
            the  rules in a macro. It is used to open up the rule number space
            for inserting new rules.

      (11) compact imp-<str8>

            is useful when rule numbers are too sparse  in  a  macro.  Without
            changing  the  current rule ordering, they assign new rule numbers
            to the rules incrementally starting from 1.

   The commands that modify export macros have the same semantics as  that  of
   import macros. They are listed below:

      (12) insert exp-<str8>
              {<SRC_PR-to-DST_PR-Export-Rule>;
               <SRC_PR-to-DST_PR-Export-Rule>; ... }
              [<rule-num>]

      (13) remove exp-<str8>
              <rule-num>[-<rule-num>]

      (14) move exp-<str8>
              <rule-num>[-<rule-num>]  up | down  <num>

      (15) compact exp-<str8>

   An example import/export macro definition and modification is given  below.
   Text following the character "#" in a line are considered comments and they
   are used to explain the affects of the example commands.

       # Rules are not specified explicitly, but represented by identifiers
       # such as R1, R2 etc. Numbers shown before each rule denotes its rule
       # number. The content of the macro is shown after each configuration
       # command as if they are committed right away.

      define imp-as57pol  protocol bgp  {R1; R2; R3; R4}

       #   Initially the content of imp-as57pol is
       #
       #     imp-as57pol = {
       #                     (1) R1; (2) R2; (3) R3; (4) R4
       #                   }



Cilingiroglu, Przygienda    Expires February 1999                    [Page 29]





Internet-Draft                      RPCL                          August 1998


      insert imp-as57pol  {Y1; Y2}  2

       #     rejected because rule numbers 3 and 4 are in use

      move imp-as57pol  3-$  down 3

       #     imp-as57pol = {
       #                     (1) R1; (2) R2; (6) R3; (7) R4
       #                   }

      insert imp-as57pol  {Y1; Y2}  2

       #     imp-as57pol = {
       #                     (1) R1; (2) R2; (3) Y1; (4) Y2; (6) R3; (7) R4
       #                   }

      remove imp-as57pol  4-6

       #     imp-as57pol = {
       #                     (1) R1; (2) R2; (3) Y1; (7) R4
       #                   }

      compact imp-as57pol

       #     imp-as57pol = {
       #                     (1) R1; (2) R2; (3) Y1; (4) R4
       #                   }

   Since aggregation policy rules are not ordered, there  is  no  rule  number
   assigned  to  the  individual  rules. Instead, rules can be referred by the
   aggregation prefix that it defines. The syntax for  an  aggregation  policy
   macro  definition is already given in (7). The commands to modify an aggre-
   gation macro are described below:

      (16) insert aggr-<str8>
              {<PR-Aggregation-Rule>; <PR-Aggregation-Rule>; ... }

            adds the specified aggregation rules to aggr-<str8>.

      (17) remove aggr-<str8>
              <prefix-range-list>

            removes the aggregation rules  from  aggr-<str8>  that  define  an
            aggregate matching <prefix-range-list>.

   An example aggregation macro definition and modification is given below.





Cilingiroglu, Przygienda    Expires February 1999                    [Page 30]





Internet-Draft                      RPCL                          August 1998


       # For brevity, the rules are not completely specified. The content of
       # the macro is shown after some of the commands as if changes are
       # committed right away.

      define aggr-net10
         protocol bgp
         {
           aggregate 10/8  ...;
           aggregate 10.9.9/24  ...;
           aggregate 10.10.9/24  ...;
         }

      insert aggr-net10
         {
           aggregate 10.10/16  ...;
           aggregate 10.10.9.128/25  ...;
           aggregate 10.20/16  ...;
         }

       #       aggr-net10 = {
       #                       aggregate 10/8  ...;
       #                       aggregate 10.10/16  ...;
       #                       aggregate 10.20/16  ...;
       #                       aggregate 10.9.9/24  ...;
       #                       aggregate 10.10.9/24  ...;
       #                       aggregate 10.10.9.128/25  ...;
       #                    }

      remove aggr-net10  {10.0/12^16-24}

       #       aggr-net10 = {
       #                       aggregate 10/8  ...;
       #                       aggregate 10.10.9.128/25  ...;
       #                       aggregate 10.20/16  ...;
       #                    }

A.2 Import and Export Policy Configuration

   Import policy for a  protocol  <PR>  is  configured  in  the  global  table
   IMPORT-<PR>.  Similarly, export policy from a protocol <SRC_PR> to a proto-
   col <DST_PR> is configured in the  global  table  EXPORT-<SRC_PR>-<DST_PR>.
   These global tables are made up of policy macros, where the ordering of the
   rules is specified hierarchically as follows:

      - the ordering within the rules of a member macro is determined  by  the
      rule numbers
      - the ordering of the member macros is  determined  by  unique  integers
      assigned to individual macros, named macro numbers. In the global table,



Cilingiroglu, Przygienda    Expires February 1999                    [Page 31]





Internet-Draft                      RPCL                          August 1998


      the rules of a member macro with a smaller macro number comes before the
      rules of a member macro with a larger one.

   Assigning unique macro numbers to member macros allow another way to  refer
   to them, in addition to using macro names. The syntax is as follows:

      import-<PR> <macro-num>: refers to the import macro  for  protocol  <PR>
           that  is  inserted  into  import-<PR> with the macro number <macro-
           num>.

      export-<SRC_PR>-<DST_PR> <macro-num>: refers to the export macro for the
           protocol  pair  (<SRC_PR>,  <DST_PR>) that is inserted into export-
           <SRC_PR>-<DST_PR> with the macro number <macro-num>.

   A member macro in a global table can be assigned  a  new  macro  number  in
   order  to reorder its rules relative to the rest of the global table.  When
   this happens, referring to the macro from the global table  changes,  using
   the new macro number.

   Not all macros that are used in a global table have to  be  defined  previ-
   ously.   Some  macros  are  defined  on  the fly by listing their rules and
   inserting them into a global table with a unique macro number. Such  macros
   are  called  on-the-fly  macros  and they do not have macro names. They are
   temporary in the sense that when such a macro is removed  from  the  global
   table,  its definition is lost. To prevent that, an on-the-fly macro can be
   changed into a permenant one by assigning a macro name to it.

   Notice that global tables for import and export policies are  tightly  cou-
   pled  with  their  member  macros. Any change in a macro changes the global
   policy tables that it is a member of, which in turn changes the correspond-
   ing  protocol  policies.  To decouple a global table from one of its member
   macros, the member macro can be replaced by an exact copy of it and can  be
   given  a  new macro name or can be made an on-the-fly macro. This operation
   does not change the rules that are in the global table, but prevents future
   changes in the decoupled macro to be reflected to the global table and vice
   versa.

   Import and Export policies are configured using the following commands:

      (18) insert-macro import-<PR>
              imp-<str8>  <macro-num>

            inserts the macro imp-<str8> into the  table  import-<PR>  with  a
            unique macro number <macro-num>. If the protocol in the imp-<str8>
            definition does not match with <PR>, or the <macro-num> is already
            assigned  to  another  macro, the insertion operation is rejected.
            Notice that after this operation, imp-<str8> can also be  referred
            as import-<PR> <macro-num>.



Cilingiroglu, Przygienda    Expires February 1999                    [Page 32]





Internet-Draft                      RPCL                          August 1998


      (19) insert-macro import-<PR>
              {<PR-Import-Rule>; ...}  <macro-num>

            inserts an on-the-fly macro into  the  table  import-<PR>  with  a
            unique macro number <macro-num>. The rules of the macro are speci-
            fied explicitly in the  command.   Like  (18),  the  operation  is
            rejected  if  <macro-num>  is  already  in  use.  Notice  that the
            inserted on-the-fly macro can  only  be  referred  as  import-<PR>
            <macro-num>.

      (20) remove-macro import-<PR>
              <macro-num>

            removes the macro referred by  import-<PR>  <macro-num>  from  the
            table  import-<PR>.   If  the removed macro is defined on-the-fly,
            then its definition is lost after this operation. To prevent this,
            link operation can be used as described below.

      (21) move-macro import-<PR>
              <src-macro-num> to <dst-macro-num>

            relocates the macro referred  by  import-<PR>  <src-macro-num>  by
            assigning a new macro number, <dst-macro-num>, to it. This changes
            the ordering of the rules in this macro relative to  the  rest  of
            the  rules  in the table import-<PR>. It also changes the way this
            macro is referred, from import-<PR> <src-macro-num> to import-<PR>
            <dst-macro-num>.

      (22) insert import-<PR>
              {<PR-Import-Rule>; ...}  <macro-num>[.<rule-num>]
      (23) remove import-<PR>
              <macro-num>.<rule-num>[-<rule-num>]
      (24) move import-<PR>
              <macro-num>.<rule-num>[-<rule-num>]  up | down  <num>
      (25) compact import-<PR>  <macro-num>

            commands (22)-(25) are used to change the contents of import  mac-
            ros. Their semantics are the same as the commands (8)-(11), except
            that here the macros are referred by their macro  numbers  instead
            of their macro names.

      (26) link import-<PR>  <macro-num> to imp-<str8>

            replaces the macro that is  inserted  in  import-<PR>  <macro-num>
            with  a  fresh  copy of it, and assigns the name imp-<str8> to the
            new copy. If the replaced macro was already assigned a name  (i.e.
            was  not  an  on-the-fly macro), then this operation decouples the
            global table import-<PR>  from  the  replaced  macro,  meaning  no



Cilingiroglu, Przygienda    Expires February 1999                    [Page 33]





Internet-Draft                      RPCL                          August 1998


            changes in one will affect the other. If the replaced macro was an
            on-the-fly macro, then the operation makes it permanent, i.e.  the
            macro  definition  will  not  be lost after it is removed from the
            global table import-<PR>.

      (27) unlink import-<PR>  <macro-num> from imp-<str8>

            replaces the macro that is  inserted  in  import-<PR>  <macro-num>
            with  a  fresh on-the-fly copy of it. It decouples the import-<PR>
            from the replaced macro.  Notice that since the  new  copy  is  an
            on-the-fly  macro, its definition will be lost after it is removed
            from the global table import-<PR>.

   The commands to configure export policies have the same semantics  as  that
   of import policies. They are listed below:

      (28) insert-macro  export-<SRC_PR>-<DST_PR>
              exp-<str8>  <macro-num>

      (29) insert-macro  export-<SRC_PR>-<DST_PR>
              {<SRC_PR-to-DST_PR-Export-Rule>; ...}  <macro-num>

      (30) remove-macro  export-<SRC_PR>-<DST_PR>
              <macro-num>

      (31) move-macro  export-<SRC_PR>-<DST_PR>
              <src-macro-num> to <dst-macro-num>

      (32) insert  export-<SRC_PR>-<DST_PR>
              {<SRC_PR-to-DST_PR-Export-Rule>; ...}  <macro-num>[.<rule-num>]

      (33) remove  export-<SRC_PR>-<DST_PR>
              <macro-num>.<rule-num>[-<rule-num>]

      (34) move  export-<SRC_PR>-<DST_PR>
              <macro-num>.<rule-num>[-<rule-num>]  up | down  <num>

      (35) compact  export-<SRC_PR>-<DST_PR>  <macro-num>

      (36) link  export-<SRC_PR>-<DST_PR>  <macro-num> to exp-<str8>

      (37) unlink  export-<SRC_PR>-<DST_PR>  <macro-num> from exp-<str8>

   An example is shown below for an import policy configuration of BGP:







Cilingiroglu, Przygienda    Expires February 1999                    [Page 34]





Internet-Draft                      RPCL                          August 1998


       # For brevity, the rules are not explicitly specified but represented
       # by identifiers such as R1, R2 etc.
       # The example assumes that initially the IMPORT-BGP is empty.
       # The contents of the global table and some of the macros are shown after
       # some of the commands as if the changes are committed right away.

      define imp-rippol  protocol rip  {M1; M2}

      define imp-bgppol  protocol bgp  {X1; X2; X3}

      insert-macro import-bgp  imp-rippol  100

       #     rejected because of the mismatch of protocols

      insert-macro import-bgp  imp-bgppol  100

      insert-macro import-bgp  {Y1; Y2}  100

       #     rejected because macro is 100 is already in use

      insert import-bgp  {Y1; Y2} 100

       #     IMPORT-BGP =                imp-bgppol =
       #        {                           {
       #          (100 = imp-bgppol)          (1) X1;
       #              (1) X1;                 (2) X2;
       #              (2) X2;                 (3) X3;
       #              (3) X3;                 (4) Y1;
       #              (4) Y1;                 (5) Y2;
       #              (5) Y2;               }
       #        }

      move import-bgp  3-$  down 1

      insert import-bgp  {Z1}  2

      insert-macro import-bgp  {R1; R2}  200

       #     IMPORT-BGP =                imp-bgppol =
       #        {                           {
       #          (100 = imp-bgppol)          (1) X1;
       #              (1) X1;                 (2) X2;
       #              (2) X2;                 (3) Z1;
       #              (3) Z1;                 (4) X3;
       #              (4) X3;                 (5) Y1;
       #              (5) Y1;                 (6) Y2;
       #              (6) Y2;               }
       #



Cilingiroglu, Przygienda    Expires February 1999                    [Page 35]





Internet-Draft                      RPCL                          August 1998


       #          (200 = ON-THE-FLY)
       #              (1) R1;
       #              (2) R2;
       #        }

      move-macro import-bgp  100 to 500

      unlink import-bgp  500 from imp-bgppol

      link import-bgp  200 to imp-newrules

       #     IMPORT-BGP =                imp-bgppol =      imp-newrules =
       #        {                           {                 {
       #          (200 = imp-newrules)        (1) X1;           (1) R1;
       #              (1) R1;                 (2) X2;           (2) R2;
       #              (2) R2;                 (3) Z1;         }
       #                                      (4) X3;
       #          (500 = ON-THE-FLY)          (5) Y1;
       #              (1) X1;                 (6) Y2;
       #              (2) X2;               }
       #              (3) Z1;
       #              (4) X3;
       #              (5) Y1;
       #              (6) Y2;
       #        }

      remove import-bgp  500  3-6

      remove imp-bgppol  1-3

      remove-macro import-bgp  200

       #     IMPORT-BGP =                imp-bgppol =      imp-newrules =
       #        {                           {                 {
       #          (500 = ON-THE-FLY)          (4) X3;           (1) R1;
       #              (1) X1;                 (5) Y1;           (2) R2;
       #              (2) X2;                 (6) Y2;         }
       #        }                           }

A.3 Aggregation Policy Configuration

   The aggregation policy for a protocol <PR>  is  configured  in  the  global
   table  AGGREGATE-<PR>. Aggregation tables are different than the import and
   export tables in the following ways:

      - Rules in a global aggregation table are not ordered.
      - There is no rule number assigned to  individual  rules.  Instead,  the
      rules are referred by the aggregate prefix that they define.



Cilingiroglu, Przygienda    Expires February 1999                    [Page 36]





Internet-Draft                      RPCL                          August 1998


      - Global aggregation tables are not  coupled  with  aggregation  macros.
      When  a  macro  is inserted into a global aggregation table, the current
      contents of the macro is copied into the global  table.  Future  changes
      made in the macro are not reflected into the global table.

   The following are the commands to configure an aggregation policy:

      (38) insert aggregate-<PR>
              {<PR-Aggregation-Rule>; <PR-Aggregation-Rule>; ... }

            adds  the  specified  aggregation  rules  to  the   global   table
            aggregate-<PR>.

      (39) insert aggregate-<PR>
              aggr-<str8>

            creates a copy of the rules in aggr-<str8> and adds  them  to  the
            global  table  aggregate-<PR>. Note that, the global table and the
            macro each have their own copies of the rules, and therefore there
            is no coupling between them.

      (40) remove aggregate-<PR>
              <prefix-range-list>

            removes all the rules from the table aggregate-<PR> that define an
            aggregate matching <prefix-range-list>.

      (41) remove aggregate-<PR>
              aggr-<str8>

            removes all the rules  from  the  table  aggregate-<PR>  that  was
            inserted from the macro aggr-<str8>.

A.4 Commit Operation

   Any run-time policy change of a protocol results in an expensive series  of
   operations.  All  current  policy  decisions that might get affected by the
   policy change have to be re-evaluated by the protocol. Therefore,  changing
   the  global  policy tables after each command is very inefficient. Instead,
   all changes are committed simultaneously at well-defined  points  in  time.
   The following command is used for this purpose:

      (42) commit [changes]

            changes all the policies of all the  protocols  according  to  the
            commands that are issued between the previous commit operation and
            now.




Cilingiroglu, Przygienda    Expires February 1999                    [Page 37]





Internet-Draft                      RPCL                          August 1998


APPENDIX B. RPCL Reference

   This appendix section provides the complete syntax of  RPCL  in  BNF  form.
   The  first  subsection, B.1, gives the syntax of RPCL policy rules, and the
   next subsection, B.2, gives the syntax of the RPCL policy editor.

B.1 RPCL Policy Syntax

B.1.1 Basic Types

   <IPv4Addr>: [0-255] |
               [0-255].[0-255] |
               [0-255].[0-255].[0-255] |
               [0-255].[0-255].[0-255].[0-255]

   <Mask>: [0-32]

   <protocol>: STATIC | DIRECT | RIP | OSPF | BGP

   <policy-protocol>: RIP | OSPF | BGP

   <prefix>: <IPv4Addr>/<Mask>

   <preference>: <integer>

   <tag> : <integer>

   <rip-metric>: [1-15]

   <ospf-metric>: [1-65535]

   <ospf-type>: INTRA-AREA | INTER-AREA | EXTERNAL-1 | EXTERNAL-2

   <as>: AS<integer>

   <as-set>: {<as>, <as>, ..., <as>}

   <as-path>: {<as>, <as>, ..., <as>}

   <community>: <integer>

   <comm-list>: {<community>, <community>, ... }

   <peer-AS>: <as>

   <peer-IPv4Addr>: [0-255].[0-255].[0-255].[0-255]

   <bgp-peer>: <peer-AS> <peer-IPv4Addr>



Cilingiroglu, Przygienda    Expires February 1999                    [Page 38]





Internet-Draft                      RPCL                          August 1998


   <peer-element>: <peer-AS> | <peer-IPv4Addr>

   <peer-set>: {<peer-element>, <peer-element>, ... }

B.1.2 Filter Types

   # m and n are [0-32]
   <prefix-range>: <prefix> [ ^- | ^+ | ^m | ^m-n ]

   <prefix-range-list>: {<prefix-range>, <prefix-range>, ... } |
                        <pfx-setname>

   <aspath-regex-member>: <as> | <as-set> | <as-setname> | .

   <aspath-regex-operator>: * | + | ? | (m) | (m,) | (m,n) | <empty>

   <aspath-unit>: <aspath-regex-member> <aspath-regex-operator>

   <aspath-regex>: '<' [^] <aspath-unit> <aspath-unit> ... [$] '>'

B.1.3 Policy Filters

   <STATIC-filter>: <prefix-range-list>

   <DIRECT-filter>: <prefix-range-list>

   <RIP-filter>: <prefix-range-list> |
                 src-gw==<prefix-range-list> |
                 tag==<tag>

   <OSPF-filter>: <prefix-range-list> |
                  type==<ospf-type> |
                  tag==<tag>

   <BGP-filter>: <prefix-range-list> |
                 <aspath-regex> |
                 <as> |
                 <as-set> |
                 community == <comm-list> |
                 community.contains <comm-list>

B.1.4 Policy Actions

   <RIP-import-single-action>:
      pref=<preference>

   <RIP-import-action>:
      {<RIP-import-single-action>; <RIP-import-single-action>; ...}



Cilingiroglu, Przygienda    Expires February 1999                    [Page 39]





Internet-Draft                      RPCL                          August 1998


   <RIP-export-single-action>:
      tag=<tag> |
      metric=<rip-metric>

   <RIP-export-action>:
      {<RIP-export-single-action>; <RIP-export-single-action>; ...}

   <OSPF-import-single-action>:
      pref=<preference>

   <OSPF-import-action>:
      {<OSPF-import-single-action>; <OSPF-import-single-action>; ...}

   <OSPF-export-single-action>:
      tag=<tag> |
      metric=<ospf-metric> |
      type=<ospf-type>

   <OSPF-export-action>:
      {<OSPF-export-single-action>; <OSPF-export-single-action>; ...}

   <BGP-single-action>:
      pref=<preference> |
      med=<med> |
      dpa=<dpa> |
      aspath.prepend <peer-AS-list> |
      community=<comm-list> |
      community.=<comm> |             # append a single community
      community.append <comm-list> |  # append multiple communities
      community.delete <comm-list>    # delete the ones that exist

   <BGP-import-action>:
      {<BGP-single-action>, <BGP-single-action>, ...}

   <BGP-export-action>:
      {<BGP-single-action>, <BGP-single-action>, ...}

B.1.5 Policy Peering Specification

   <peering>: <peer-AS> | <peer-IPv4Addr> | <peer-set>

B.1.6 Policy Rules

   <PR-import-rule>:
      [from <peering>] [action <PR-import-action>] accept <PR-filter> |
      [from <peering>] block <PR-filter>                              |
      {<PR-Import-Rule>; <PR-Import-Rule>; ...}                       |
      <PR-Import-Rule> refine <PR-Import-Rule>



Cilingiroglu, Przygienda    Expires February 1999                    [Page 40]





Internet-Draft                      RPCL                          August 1998


   <SRC_PR-to-DST_PR-export-rule>:
      [to <peering>] [action <DST_PR-export-action>] announce <SRC_PR-filter> |
      [to <peering>] block <SRC_PR-filter>                                    |
      {<SRC_PR-to-DST_PR-Export-Rule>; <SRC_PR-to-DST_PR-Export-Rule>; ...}   |
      <SRC_PR-to-DST_PR-Export-Rule> refine <SRC_PR-to-DST_PR-Export-Rule>

   <PR-aggregation-rule>:
      aggregate into     <prefix>

      triggered by       AND/OR of HC{<prefix-range-list>} and
                                   EX{<prefix-range-list>}

      components         ATOMIC |
                        [protocol <PR_1>] <PR_1-filter>
                       [[protocol <PR_2>] <PR_2-filter>] ...

      action             <PR-action>

      export components  from <PR_1> <PR_1-to-PR-export-rule>
                        [from <PR_2> <PR_2-to-PR-export-rule>] ...

      holes              <prefix-range-list>

B.2 Policy Editor

   <str8> : string of {[a-z], [A-Z], [0-9], "-", "_"} of length 8

B.2.1 Policy Attribute Macros

   define peer-<str8>  <peer-set>

   define fltr-<str8>  <filter>

   define act-<str8>   <action>

   undefine peer-<str8>

   undefine fltr-<str8>

   undefine act-<str8>

   show peer[-<str8>]

   show fltr[-<str8>]

   show act[-<str8>]

B.2.2 Import Policy Macros



Cilingiroglu, Przygienda    Expires February 1999                    [Page 41]





Internet-Draft                      RPCL                          August 1998


   define imp-<str8>
       protocol <PR>
       {<PR-Import-Rule>; <PR-Import-Rule>; ... }

   undefine imp-<str8>

   insert imp-<str8>
       {<PR-Import-Rule>; <PR-Import-Rule>; ... }
       [<rule-num>]

   remove imp-<str8>
       <rule-num>[-<rule-num>]

   move imp-<str8>
       <rule-num>[-<rule-num>]  up | down  <num>

   compact imp-<str8>

   show imp[-<str8>]

B.2.3 Export Policy Macros

   define exp-<str8>
       protocol <SRC_PR> into <DST_PR>
       {<SRC_PR-to-DST_PR-Export-Rule>; <SRC_PR-to-DST_PR-Export-Rule>;

   undefine exp-<str8>

   insert exp-<str8>
       {<SRC_PR-to-DST_PR-Export-Rule>; <SRC_PR-to-DST_PR-Export-Rule>; ... }
       [<rule-num>]

   remove exp-<str8>
       <rule-num>[-<rule-num>]

   move exp-<str8>
       <rule-num>[-<rule-num>]  up | down  <num>

   compact exp-<str8>

   show exp[-<str8>]

B.2.4 Aggregation Policy Macros

   define aggr-<str8>
       protocol <PR>
       {<PR-Aggregation-Rule>; <PR-Aggregation-Rule>; ... }




Cilingiroglu, Przygienda    Expires February 1999                    [Page 42]





Internet-Draft                      RPCL                          August 1998


   undefine aggr-<str8>

   insert aggr-<str8>
       {<PR-Aggregation-Rule>; <PR-Aggregation-Rule>; ... }

   remove aggr-<str8>
       <prefix-range-list>

   show aggr[-<str8>] [<prefix-range-list>] [forest]

B.2.5 Import Policy Configuration

   insert-macro import-<PR>
       imp-<str8>  <macro-num>

   insert-macro import-<PR>
       {<PR-Import-Rule>; ...}  <macro-num>

   remove-macro import-<PR>
       <macro-num>

   move-macro import-<PR>
       <src-macro-num> to <dst-macro-num>

   insert import-<PR>
       {<PR-Import-Rule>; ...}  <macro-num>[.<rule-num>]

   remove import-<PR>
       <macro-num>.<rule-num>[-<rule-num>]

   move import-<PR>
       <macro-num>.<rule-num>[-<rule-num>]  up | down  <num>

   compact import-<PR>  <macro-num>

   link import-<PR>  <macro-num> to imp-<str8>

   unlink import-<PR>  <macro-num> from imp-<str8>

   show import-<PR> [<macro-num>]

B.2.6 Export Policy Configuration

   insert-macro  export-<SRC_PR>-<DST_PR>
       exp-<str8>  <macro-num>

   insert-macro  export-<SRC_PR>-<DST_PR>
       {<SRC_PR-to-DST_PR-Export-Rule>; ...}  <macro-num>



Cilingiroglu, Przygienda    Expires February 1999                    [Page 43]





Internet-Draft                      RPCL                          August 1998


   remove-macro  export-<SRC_PR>-<DST_PR>
       <macro-num>

   move-macro  export-<SRC_PR>-<DST_PR>
       <src-macro-num> to <dst-macro-num>

   insert  export-<SRC_PR>-<DST_PR>
       {<SRC_PR-to-DST_PR-Export-Rule>; ...}  <macro-num>[.<rule-num>]

   remove  export-<SRC_PR>-<DST_PR>
       <macro-num>.<rule-num>[-<rule-num>]

   move  export-<SRC_PR>-<DST_PR>
       <macro-num>.<rule-num>[-<rule-num>]  up | down  <num>

   compact  export-<SRC_PR>-<DST_PR>  <macro-num>

   link  export-<SRC_PR>-<DST_PR>  <macro-num> to exp-<str8>

   unlink  export-<SRC_PR>-<DST_PR>  <macro-num> from exp-<str8>

   show export-<SRC_PR>-<DST_PR> [<macro-num>]

B.2.7 Aggregation Policy Configuration

   insert aggregate-<PR>
       {<PR-Aggregation-Rule>; <PR-Aggregation-Rule>; ... }

   insert aggregate-<PR>
       aggr-<str8>

   remove aggregate-<PR>
       <prefix-range-list>

   remove aggregate-<PR>
       aggr-<str8>

   show aggregate-<PR> [<prefix-range-list>] [forest]

B.2.8 Commit Operation

   commit [changes]









Cilingiroglu, Przygienda    Expires February 1999                    [Page 44]