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]