idnits 2.17.1 draft-ardas-rpcl-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 398 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 631 instances of too long lines in the document, the longest one being 11 characters in excess of 72. == There are 15 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 18 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...-Drafts are ...' == Line 13 has weird spacing: '... ments of t...' == Line 18 has weird spacing: '... may be u...' == Line 19 has weird spacing: '...aterial or t...' == Line 22 has weird spacing: '... status of a...' == (393 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1999) is 9195 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1-15' on line 1736 -- Looks like a reference, but probably isn't: '1-65535' on line 1738 -- Looks like a reference, but probably isn't: '0-255' on line 1754 -- Looks like a reference, but probably isn't: '0-32' on line 1763 -- Looks like a reference, but probably isn't: 'A-Z' on line 1880 -- Looks like a reference, but probably isn't: '0-9' on line 1880 == Unused Reference: '1' is defined on line 1072, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1076, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2280 (ref. '1') (Obsoleted by RFC 2622) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 13 errors (**), 0 flaws (~~), 11 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Ardas Cilingiroglu 3 File name: draft-ardas-rpcl-00.txt FORE Systems 4 Tony Przygienda 5 Bell Labs, Lucent Technologies 6 Expires : February 1999 8 Routing Policy Configuration Language (RPCL) 10 Status Of This Memo 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and its 14 working groups. Note that other groups may also distribute working docu- 15 ments as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months and 18 may be updated, replaced, or obsoleted by other documents at any time. 19 It is inappropriate to use Internet- Drafts as reference material or to 20 cite them other than as "work in progress". 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 24 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 25 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 Table Of Contents 29 1.0 Introduction ...................................................... 3 31 2.0 Basic RPCL Types; Filter, Action and Peering Specifications ....... 4 33 2.1 Data Types of Route Attributes .................................... 5 35 2.2 Filter Types ...................................................... 6 37 2.3 Peering Types ..................................................... 8 39 2.4 Filter, Action and Peering Specifications ......................... 9 41 3.0 Import Policy Rules ............................................... 10 43 4.0 Export Policy Rules ............................................... 14 45 5.0 Aggregation Policy Rules .......................................... 17 47 6.0 Acknowledgments ................................................... 24 49 7.0 Authors' Addresses ................................................ 24 51 8.0 References ........................................................ 24 53 A. Policy Editor in RPCL .............................................. 25 55 A.1 Policy Macros ..................................................... 26 57 A.2 Import and Export Policy Configuration ............................ 31 59 A.3 Aggregation Policy Configuration .................................. 36 61 A.4 Commit Operation .................................................. 37 63 B. RPCL Reference ..................................................... 38 65 B.1 RPCL Policy Syntax ................................................ 38 67 B.2 Policy Editor ..................................................... 41 69 1. Introduction 71 Routing policies define a set of rules and actions to be applied by proto- 72 cols when they send and receive routing updates. When a protocol receives 73 an updates, routing policies are used to determine if, and with what infor- 74 mation a route gets added to the Routing Information Base (RIB). When 75 preparing to send a routing update, routing policy is consulted to see if 76 the route is to be sent and if so, what information is to be included in 77 the update. The Routing Policy Configuration Language (RPCL) specifies a 78 language for defining routing policies in a router. 80 RPCL is derived from the Routing Policy Specification Language (RPSL) [1, 81 2], which is the evolving standard for Internet's policy specification. 82 RPSL specifies the routing policies, inter-domain routes, border routers 83 and some administrative objects of an Autonomous System (AS). Autonomous 84 Systems (AS) in the Internet registers its RPSL specification with a 85 cooperatively maintained distributed database, called Internet Routing 86 Registry (IRR) [3,4]. IRR has the global view of the Internet and its poli- 87 cies. The IRR is used to verify the integrity of the Internet's routing, 88 and to protect the Internet against accidental and malicious distribution 89 of inaccurate route information, such as non-existing routes, incorrect 90 aggregation or aggregation boundaries. 92 Unlike RPSL, which specifies the policies and other internal objects of an 93 AS, RPCL is used to configure the policies of an individual router. Its 94 syntax and semantics for the policy language is, however, derived from the 95 RPSL. This consistency in policy specification language at the AS level and 96 the router level facilitates the conversion from one to the other. 98 RPCL is intended to be an extendable language. It provides a uniform syntax 99 and semantics for policy configuration across various policies and proto- 100 cols. RPCL is designed to be able to add support for new protocols and 101 specifications for new policies. For example, RPCL currently defines poli- 102 cies for unicast protocols, but it can be extended to support multicast 103 protocols as well. 105 RPCL currently supports the configuration and evaluation of the following 106 policies: 108 - Import Policy: used by protocols to update the content of the RIB 109 based on the routes received. When a protocol receives a route, it 110 uses the import policy to determine whether to accept or block the 111 route, and to set the route's attributes (e.g., the route's prefer- 112 ence) if the route is accepted. RIP, OSPF and BGP are example uni- 113 cast protocols using import policies. 115 - Export Policy: used by protocols to determine what routes and associ- 116 ated attributes to send to neighbors based on the contents of the 117 RIB. There is a separate policy configured for each protocol pairs 118 (SRC-PR, DST-PR), where DST-PR is the exporting protocol and the 119 SRC-PR is the owner protocol of the route considered. Some example 120 protocol pairs are show below: 122 DST PROTOCOL 124 | RIP | OSPF | BGP | 125 --------+------+------+------+ 126 Static |Export|Export|Export| 127 --------+------+------+------+ 128 Direct |Export|Export|Export| 129 SRC --------+------+------+------+ 130 PROT RIP |Export|Export|Export| 131 --------+------+------+------+ 132 OSPF |Export| ---- |Export| 133 --------+------+------+------+ 134 BGP |Export|Export|Export| 135 --------+------+------+------+ 137 - Aggregation Policy: An aggregate route is used to summarize the com- 138 ponent routes of an address range. By default when an aggregate 139 route is exported to a neighbor, all of its component routes (i.e. 140 routes that are more specific than the aggregate) are suppressed. 141 This reduces the amount of route propagation and controls the 142 growth of the IP routing and forwarding tables. Some component 143 routes, however, may need to be exported along with the aggregate 144 to satisfy some topology constraints (such as multi-homed com- 145 ponents in BGP). Aggregation policy is used by a protocol to deter- 146 mine the aggregate routes that a router generates and which com- 147 ponent routes to export along with the aggregate. BGP is an example 148 protocol using aggregation policy. 150 2. Basic RPCL Types; Filter, Action and Peering Specifications 152 Routes are composed of a set of attributes. Some attributes are common to 153 all routing protocols, and some are unique to a single protocol. For exam- 154 ple, an address prefix and the preference are common to all routing proto- 155 cols, whereas the tag for RIP and OSPF routes and the aspath for BGP routes 156 are protocol specific. 158 Policies are configured using policy rules. All policy rules are composed 159 of the following basic constructs: 161 - Filter specification: a logical expression over the route attributes. 162 Filter specifications are used by the policy rules to select a set 163 of routes for a particular operation. For example, the RIP import 164 rule "accept (128/8^+ and tag==100)" uses the filter "(128/8^+ and 165 tag==100)" to allow the import of the RIP routes that are more 166 specific than 128/8 and have the tag value of 100. 168 - Action specification: an ordered list of commands to set or modify the 169 attributes of a route. For example, a RIP export rule with the 170 action specification "{tag=10; metric=100}" will set the tag and 171 metric attributes of a route to 10 and 100, respectively. 173 - Peering specification: used by an External Gateway Protocols (EGP), 174 such as BGP, to restrict the policy evaluation to a subset of 175 peers. For example, a BGP import rule with a peering "{128.10.5.5, 176 AS11}" will only be evaluated for the routes coming from the peer 177 128.10.5.5 or from a peer in AS11. 179 2.1 Route Attribute Data Types 181 Every route attribute has a specific data type. The route attributes of the 182 unicast routing protocols and their corresponding data types are shown in 183 Figure-1. The basic data types are explained below: 185 An IPv4 address is a 32 bit number represented by four 8 bit 186 integers (standard "dotted quad" format). For example 128.10.9.9 187 represents a valid address. 189 An address prefix is composed of an IPv4 address followed by 190 its length, an integer between 0 to 32 which represents the number 191 of significant leftmost contiguous bits (CIDR-based addressing). 192 Only the significant part of the IPv4 address needs to be speci- 193 fied. 0/0, 128.9/16, 150.10.0/16, and 169.144.100/24 are examples 194 of valid prefixes, whereas 128.9/24 is invalid (the IPv4 address 195 must include three integers when the mask length is 24). 197 An autonomous system (AS) x is denoted by ASx. For example, AS312 198 represents the AS 312. 200 AS-path is a BGP attribute that keeps track of the sequence of 201 ASes traversed by the route. It is represented by a list of AS 202 numbers in braces, separated by commas. For example, {AS23, AS247, 203 AS11, AS66} is an AS-path. 205 OSPF routes can be of type intra-area, inter-area, 206 external-1 or external-2. They are represented by the symbols in 207 the set {INTRA-AREA, INTER-AREA, EXTERNAL-1, EXTERNAL-2}. 209 Community list is a BGP attribute represented by a list of 210 communities in braces, separated by commas. Each community is 211 either a 4-byte unsigned integer, or one of the keywords NO-EXPORT 212 or NO-ADVERTISE, or a list of two 2-byte unsigned integers. For 213 example, {100, NO-EXPORT, {312, 10}, 200} is a community list. 215 A BGP peer is represented by the peer AS and the peer address. 216 For example AS312 10.9.9.1 represents the peering with the router 217 10.9.9.1 in the AS 312. 219 2.2 Filter Types 221 Unicast protocol filters are shown in Figure-1. The following describes 222 some of the arguments used in these filters: 224 ANY-ROUTE is a constant that always evaluates to TRUE. 226 is a prefix followed by one of the following range opera- 227 tors: 229 ^- is the exclusive more specific operator. It represents the more 230 specifics of an address prefix excluding the prefix itself. For 231 example, 128.9/16^- includes all of the more specifics such as 232 128.9.10/24, 128.9.30.48/28, and 128.9.50.99/32, but not 233 128.9/16. 235 ^+ is the inclusive more specifics operator. It represents the more 236 specifics of an address prefix including the prefix itself. For 237 example 128.9/16^+ will match all of the more specifics and also 238 128.9/16 itself. 240 ^n represents all length n specifics of an address prefix. For exam- 241 ple, 169.144.128/17^24 will match 169.144.128/24 and 242 169.144.132/24 but not 169.144.132/22 since the mask is not 24, 243 and not 169.144.96/24 since it is not a more specific (17th bit 244 does not match). 246 ^n-m represents any more specifics of an address prefix with the mask 247 length between n to m. For example, 128.9.0/20^24-32, will match 248 128.9.10/24 and 128.9.0.22/31, but not 128.9.10/23 since the 249 mask is not in the range of 24-32, and not 129.9.34.24/32 since 250 it is not a more specific (19th bit does not match). 252 is a list of address prefix ranges in braces 253 separated by commas. It is a filter expression and it matches the 254 address prefixes that match one of the prefix ranges specified in 255 the list. For example, 257 {10.9.1/24} 259 will match the prefix 10.9.1/24, and 261 {10.1/16, 10.122/15^-, 11/8^+, 128.10/16^20-32} 263 will match 264 - route 10.1/16, 265 - more specifics of 10.122/15 excluding 10.122/15 itself, such 266 as 10.123/16, 267 - more specifics of 11/8 including 11/8 itself, such as 268 11.144.10/24, and 269 - more specifics of 128.10/16 with the mask length between 20 to 270 32, such as 128.10.200/22. 272 is a set of AS numbers in braces separated by commas, such as 273 {AS12, AS47, AS111}. 275 is a regular expression on ASes, enclosed in '<' and '>'. 276 It is used as a policy filter for the BGP AS-path attribute. 278 The regular expression constructs are as follows: 279 ASx matches ASx 280 matches any one of the ASes in the set 281 . matches any AS number 282 ^ matches to the empty string at the begining of an AS-path 283 $ matches to the empty string at the end of an AS-path 285 Regular expression operators are as follows: 286 Unary postfix operators (left associative) 287 * zero or more occurances 288 + one or more occurances 289 ? zero or one occurance 290 (m) m occurances 291 (m,) m or more occurances 292 (m,n) m to n occurances 294 Binary concetanation operator (lower precedence, left associative) 295 is an implicit operator. If A and B are regular expressions, 296 then A B matches an AS-path if A matches some prefix of the 297 AS-path and B matches the rest of the AS-path. 299 In the following, examples of expression are given 300 along with the description of the aspaths that will match them: 302 aspaths that contain AS5 303 aspaths with the subsequence AS5 AS7 304 aspaths containing AS5 and ending 305 with AS7 306 <^AS5 {AS3 AS7}+ AS9$> aspaths starting with AS5 ending with 307 AS9 and having at least one occurances 308 of AS3 and/or AS7 in the middle 309 <^. AS5 .?$> aspaths of length 2 or 3 with AS5 as 310 the 2nd AS 311 <{AS7 AS9 AS11}(2,4)$> aspaths with the last 2 to 4 ASes 312 being from the set {AS7 AS9 AS11} 314 2.3 Peering Types 315 The basic peering expressions are as follows: 317 ANY-PEER is a constant that will identify all peerings with the local 318 router. 320 An IPv4 address that uniquely identifies the peering between 321 the local router and the peer router with the given address. 323 A Peer AS identifies all the peerings between the local router 324 and any of its peer routers in the given AS. 326 is a set of Peer addresses and Peer ASes. It identifies all 327 the peerings between the local router and any of its peer routers 328 whose address or AS is in the given set. 330 Some example peering expressions are given below: 331 128.10.12.5 : matches the peering between the local 332 router and its peer router 128.10.12.5. 333 AS17 : matches all peerings between the local 334 router and any of its peer routers in 335 AS17. 336 {128.10.12.5, 10.9.64.10}: matches two peerings of the local router, 337 one with the peer router 128.10.12.5 and 338 the other with 10.9.64.10. 339 {AS17, AS99} : matches all peerings between the local 340 router and any of its peer routers in 341 AS17 or AS99. 342 {128.10.12.5, 10.9.64.10, AS17, AS99}: matches all peerings that 343 matches with the peer sets {128.10.12.5, 344 10.9.64.10} or {AS17, AS99}. 346 PROT | Attribute Type Filter Action 347 ------+--------------------------------------------------------------------------- 348 STATIC| prefix --- 349 ------+--------------------------------------------------------------------------- 350 DIRECT| prefix --- 351 ------+--------------------------------------------------------------------------- 352 | prefix --- 353 | src-gateway src-gtw== --- 354 RIP | preference --- pref= 355 | metric [1-15] --- metric= 356 | tag tag== tag= 357 ------+--------------------------------------------------------------------------- 358 | prefix --- 359 | preference --- pref= 360 OSPF | metric [1-65535] --- metric= 361 | tag tag== tag= 362 | type type== type= 363 ------+--------------------------------------------------------------------------- 364 | prefix --- 365 | origin --- 366 | source-peer src-peer== --- 367 BGP | preference --- pref= 368 | med --- med= 369 | dpa --- dpa= 370 | as-path aspath.prepend 371 | community comm== comm= 372 | comm.contains comm.= 373 | comm.append 374 | comm.delete 375 ------+--------------------------------------------------------------------------- 377 Figure-1: route attributes, with their corresponding data types, filter 378 expressions and action commands. 380 2.4 Filter, Action and Peering Specifications 382 For a protocol PR, filter, action and peering specifications are defined as 383 follows: 385 is a logical expression using the connectives AND, OR and 386 NOT, and the filter expressions over the attributes of the PR 387 routes. Filter expressions for several protocols are listed in 388 Figure-1. More details on the syntax and semantics are given 389 through examples in the following sections. 391 is an ordered list of action commands over the attributes of 392 the PR routes. Action command types for several protocols are 393 listed in Figure-1. 395 is an ordered list of action commands to be used at 396 import time. The command types are a subset of the command types 397 available in . In Figure-1, commands associated with the 398 tag, metric and type attributes of RIP and OSPF are used at export 399 time only. All other command types can be used during import time. 401 is an ordered list of action commands to be used at 402 export time. The command types are a subset of the command types 403 available in . In Figure-1, commands associated with the 404 preference attribute in RIP and OSPF are used at import time only. 405 All other command types can be used during export time. 407 is either ANY-PEER or of type or or 408 . 410 3. Import Policy Rules 412 A routing protocol imports some of the routes that it receives from its 413 neighbor by inserting them into the RIB. Import policy is configured for 414 each protocol to determine: 416 - which routes should be imported and which ones should be blocked by 417 that protocol, and 418 - what should be the route attributes of the routes that are imported. 420 Import policy is configured using import rules. The basic syntax of an 421 import rule for a protocol PR is the following: 423 : 424 [from ] [action ] accept | 425 [from ] block 427 where [from ] is used by External Gateway Protocols (EGP), such as 428 BGP, but not by Internal Gateway Protocols (IGP), such as RIP and OSPF. 430 Evaluation of an import rule for the routes received by the protocol PR is 431 as follows: 433 - A route matches the import rule, if it matches the specif- 434 ication and, in case PR is an EGP protocol, the peer it is received from 435 matches the specification. 437 - A matching rule is applied by taking the action suggested by the key- 438 word preceding the , i.e. importing the route if the keyword 439 is "accept", and rejecting it if it is "block". The attributes of an 440 accepted route are updated by the specification. It is optional 441 and if not specified the default values are used for the attributes. 443 In Figure-2, some of the properties of import policies are listed for pro- 444 tocols RIP, OSPF and BGP. They can be summarized as follows: 446 - All three protocols need policy configuration for import decisions. 448 - Only RIP is allowed to have a block rule, i.e. a rule with the "block" 449 keyword. OSPF and I-BGP (Internal BGP) cannot block routes, because all 450 routers running OSPF or I-BGP should have the similar view of the net- 451 work. E-BGP (External BGP), on the other hand, does not need block rules 452 simply because block is the default action to take. 454 - If no rule matches a received route, then the default action is taken. 455 It is to accept the route with default attributes if the protocol is 456 RIP, OSPF or I-BGP, and to block it if the protocol is E-BGP. 458 | RIP | OSPF | I-BGP | E-BGP | 459 ---------------+-------+-------+-------+-------+ 460 Configuration | YES | YES | YES | YES | 461 ---------------+-------+-------+-------+-------+ 462 Block Rule | YES | --- | --- | --- | 463 ---------------+-------+-------+-------+-------+ 464 Default-Action |ACCEPT |ACCEPT |ACCEPT | BLK | 465 ---------------+-------+-------+-------+-------+ 467 Figure-2: Properties of Import policies for several protocols 469 We now give examples of import rules for RIP, OSPF, and BGP. The following 470 are examples of RIP import rules: 472 block {128.9/16^+} and tag==10 474 blocks all routes that are more specifics of 128.9/16 (including 128.9/16) 475 and have the tag value of 10. 477 action pref=10 accept src-gw=={192.100.100/24^+} 479 imports all routes that are received from a gateway where the gateway 480 address is a more specific of 192.100.100/24. It sets the preference of 481 all such routes to 10. 483 Example of OSPF import rules are as follows: 485 action pref=5 accept ANY-ROUTE 487 imports all OSPF routes with a preference of 5. 489 action pref=10 490 accept {10.3/16^-, 20/8^+} and (type==INTER-AREA or tag==100) 492 imports any more specifics of 10.3/16 (excluding 10.3/16) and more specif- 493 ics of 20/8 (including 20/8) that are of type INTER-AREA or have the tag 494 value 100. All imported routes will be assigned the preference 10. 496 Examples of BGP Import rules are as follows: 498 from 10.9.9.6 action pref=1 accept AS11 or {128.9/16^+} 500 imports all routes received from the peer router 10.9.9.6, that are either 501 originated from AS11 or match 128.9/16^+. All imported routes will get the 502 preference 1. 504 from {10.9.9.1, 10.9.9.5, AS17, AS25} 505 action med=0; community.append(3261,NO-EXPORT); aspath.append(AS5) 506 accept {169.9/16^24-32} and <^AS11 AS26 .* AS7> and 507 community.contains(10250) 509 imports all routes that: 510 - are received from the peer router 10.9.9.1 or 10.9.9.5, or from a peer 511 router that is in AS17 or AS25, and 512 - are more specifics of 169.9/16 with a length between 24 to 32, and 513 - have an aspath that starts with AS11, AS26 and contains AS7, and 514 - have a community list that contains the community 10250. 516 All routes that are imported will have the following changes in their 517 attributes: 518 - multi-exit-discriminator set to 0 519 - community-list appended with the community 3261 and NO-EXPORT 520 - aspath appended with AS5. 522 So far only the basic forms of import rules are described. They can also be 523 structured. The two types of structured rules, compound rules and refine 524 rules, are described below. 526 A compound rule is of the form: 528 : {; ; ...} 530 It is an ordered list of import rules with the following semantics: 532 - A route matches a compound rule if it matches at least one of the 533 rules in its list, and 534 - if there are matching rules, then the first such rule is applied to 535 the route. 537 As an example, consider the following BGP rule: 539 { 540 from 10.9.9.5 action pref=1; accept ANY-ROUTE; 541 from AS5 action pref=5; accept AS5; 542 from AS5 action pref=10; accept ANY-ROUTE; 543 } 545 Assume that the router 10.9.9.5 is in AS 5. The above rule imports any 546 route coming from AS 5, but with different preferences. Routes coming from 547 the peer router 10.9.9.5 are given the preference 1. If they are coming 548 from another peer router in AS 5, then the ones that are originated by AS 5 549 are given the preference 5, and all the others are given the preference 10. 551 The other type of structured rule is a refine rule with the following syn- 552 tax: 554 : refine 556 It is used to refine, i.e. extend, one rule by another one. Its semantics 557 is as follows: 559 -A route matches a refine rule if it matches the component rules on both 560 sides. 561 -If it matches, then the rule on the left is applied followed by the 562 rule on the right. One restriction in refine rules is that rules on both 563 sides should be composed of either all accept rules or all block rules. 564 Otherwise, the semantics become ambigious if an accept rule matches on 565 one side and a block rule on the other. 567 Consider the following examples of BGP import rules: 569 from AS5 action pref=1; accept <^AS12> 570 refine 571 from 10.9.9.5 572 action community.append(1210); 573 accept {10/8^+} and 575 Assume that the router 10.9.9.5 is in AS 5. Then the above rule is 576 equivalent to 578 from 10.9.9.5 579 action pref=1; community.append(1210); 580 accept {10/8^+} and <^AS12 .* AS39> 582 Notice that the two rules on both sides of the refine are combined by and- 583 ing their peering and the filter specifications and appending their action 584 specifications. 586 from ANY-PEER accept AS5; 587 refine 588 { 589 from ANY-PEER action pref=1; accept community.contains(1210); 590 from ANY-PEER action pref=5; accept community.contains(1410); 591 from ANY-PEER action pref=10; accept ANY-ROUTE; 592 } 593 refine 594 { 595 from 10.9.9.5 action med=100; accept ANY-ROUTE; 596 from AS5 action med=50; accept ANY-ROUTE; 597 from ANY-PEER action med=0; accept ANY-ROUTE; 598 } 600 imports all routes that are originated by AS5, but with different prefer- 601 ence and med values based on the content of their community strings and 602 the peers that they are received from, respectively. Specifically, the 603 routes that have the community 1210 are given the preference 1, the ones 604 that have the community 1410 are given the preference 5, and all the others 605 are given the preference 10. Similarly, the routes that are received from 606 the peer router 10.9.9.5 are given the med value 100, the ones that are 607 received from another peer router in AS 5 are given the med value of 50, 608 and the ones that are received from elsewhere are given the med value of 0. 610 Finally, the full syntax of an import rule for protocol PR is: 612 : 613 [from ] [action ] accept | 614 [from ] block | 615 {; ; ...} | 616 refine 618 4. Export Policy Rules 620 A routing protocol exports (i.e. advertizes) some of the routes in the RIB 621 to its neighbors. The exported route might belong to the exporting protocol 622 or to another protocol. Export policy is configured from a protocol SRC_PR 623 (the owner protocol) to a protocol DST_PR (the exporting protocol) to 624 determine: 626 -which SRC_PR routes should be exported by DST_PR protocol to its neigh- 627 bors, which ones should be blocked, and 628 -with what attributes should the routes be exported. Notice that the 629 SRC_PR routes will be exported as DST_PR routes, therefore they should 630 be exported with DST_PR attributes. 632 Export policy is configured using export rules. The syntax of an export 633 rule from a protocol SRC_PR to a protocol DST_PR is as follows: 635 : 636 [to ] [action ] announce | 637 [to ] block 639 where [to ] is used by External Gateway Protocols, such as BGP, 640 but not by Internal Gateway Protocols, such as RIP and OSPF. 642 The evaluation of an export policy rule is similar to the import rules. For 643 a rule from protocol SRC_PR to protocol DST_PR, the rule evaluation is as 644 follows: 646 -A SRC_PR route matches the export rule, if it matches the and, in case DST_PR is an EGP protocol, the peer that the route 648 is sent to matches the specification. 650 -Matching routes are exported if the is preceded by the 651 keyword "announce", and they are blocked otherwise. An exported route 652 will be a DST_PR route, and some its attributes will be set by the 653 optional , and the others will take its default 654 values. 656 SRC PROTOCOL SRC PROTOCOL 658 | RIP |OSPF | BGP | | RIP | OSPF | BGP | 659 ----------+-----+-----+-----+ --------+------+------+------+ 660 Static | YES | YES | YES | Static | BLK | BLK | BLK | 661 ----------+-----+-----+-----+ --------+------+------+------+ 662 Direct | YES | YES | YES | Direct | BLK | BLK | BLK | 663 DST ----------+-----+-----+-----+ DST --------+------+------+------+ 664 PROT RIP | YES | YES | YES | PROT RIP |ACCEPT| BLK | BLK | 665 ----------+-----+-----+-----+ --------+------+------+------+ 666 OSPF | YES | --- | YES | OSPF | BLK |ACCEPT| BLK | 667 ----------+-----+-----+-----+ --------+------+------+------+ 668 BGP | YES | YES | YES | I-BGP | BLK | BLK |ACCEPT| 669 ----------+-----+-----+-----+ --------+------+------+------+ 670 Block Rule| YES | --- | --- | E-BGP | BLK | BLK | BLK | 671 ----------+-----+-----+-----+ --------+------+------+------+ 672 (a) Configuration and Block Rule (b) Default-Action 674 Figure-3: Properties of Export policies for several protocols 676 In Figure-3, some properties of export policies are listed for some of the 677 protocol pairs. They can be summarized as follows: 679 -Export policy need not be configured for every protocol pair. For exam- 680 ple, OSPF has to export all OSPF internal routes to all of its neighbors 681 without any attribute change. Therefore, there is no policy configura- 682 tion needed for an export from OSPF to OSPF. 684 -Only RIP is allowed to have a block rule. The other protocols do not 685 have it either because they cannot block any route from export, or 686 because their default actions are block and they don't need it. 688 -The default action is taken in case no rule matches the route. It is to 689 export the route with default attributes, in case RIP, OSPF or I-BGP is 690 exporting its own route, and it is to block for all other cases. 692 Following are examples of export policy rules: 694 The following rule from RIP to RIP 696 action tag=100; metric=1210 697 announce tgt-gw=={120.100/16^+} and src-gw=={196.122.44/24^+} 699 is used by RIP to export all RIP routes received from a gateway that 700 matches 196.122.44/24^+, to a gateway that matches 120.100/16^+. All such 701 routes are exported with the tag value of 100 and the metric value of 1210. 703 The rule from BGP to RIP 705 action tag=200; 706 announce src-peer==AS11 or AS11 708 is used by RIP to export BGP routes that are either originated by AS 11 or 709 received from a peer in AS 11. All such routes are exported with the tag 710 value of 200. 712 The rule from BGP to OSPF 714 action tag=100; type=EXTERNAL-2; 715 announce community.contains(3210) 717 is used by OSPF to export BGP routes that has the community 3210, with the 718 tag value of 100 and the OSPF type EXTERNAL 2. 720 The rule from RIP to BGP 722 to AS11 723 action med=10; aspath.append(AS9); 724 announce {120.100/16^+} and src-gw=={196.122.44.12} 726 is used by BGP to export RIP routes to peers in AS 11, that are received 727 from the gateway 196.122.44.12 and match 120.100/16^+. All such routes are 728 exported with a med value of 10 and with AS9 appended to their aspath. 730 The rule from BGP to BGP 732 to {12.10.10.3, 12.10.10.7, AS11} 733 action community.append(NO-EXPORT) 734 announce <^AS19 .* AS54> 736 is used by BGP to export BGP routes that have an aspath starting with AS 19 737 and including AS 54, to peers 12.10.10.3, 12.10.10.7 or the ones in AS 11. 738 Routes are exported with NO-EXPORT community appended to their community 739 string. 741 Export rules can be compounded and refined just like import rules. The full 742 syntax for an export rule is the following: 744 : 745 [to ] [action ] announce | 746 [to ] block | 747 {; ; ...} | 748 refine 750 5. Aggregation Policy Rules 752 An aggregate route is used to summarize the component routes of an address 753 range. By default when an aggregate route is exported to a neighbor, all of 754 its component routes (i.e. routes that are more specific than the aggre- 755 gate) are suppressed. This reduces the amount of route propagation and 756 controls the growth of the IP routing and forwarding tables. Some component 757 routes, however, may need to be exported along with the aggregate to 758 satisfy some topology constraints (such as multi-homed components in BGP). 759 Aggregation policy is used by a protocol to determine the aggregate routes 760 that a router generates and which component routes to export along with the 761 aggregate. 763 Some protocols, such as BGP, perform aggregation via a configured policy. 764 Based on the current state of the RIB, the configured aggregation rules of 765 a protocol PR determine: 767 -what aggregates to generate and the route attributes of those aggre- 768 gates (aggregate activation evaluation) 769 -in case PR exports an aggregate route to a neighbor, what components 770 (i.e. more specifics) to export along with the aggregate and what com- 771 ponents to suppress (aggregate export evaluation) 773 The syntax of an aggregation rule for a protocol PR is as follows: 775 : 776 aggregate into 777 triggered by AND/OR of HC{} and 778 EX{} 779 components ATOMIC | [protocol ] 780 [[protocol ] ] ... 781 action 782 export components from 783 [from ] ... 784 holes 786 The semantics of an aggregation rule for a protocol PR is best described by 787 explaining each of its attributes as follows: 789 aggregate: specifies the prefix of the aggregate for which the rule is 790 defined. 792 trigger: determines, along with the components attribute, the conditions 793 needed to generate the aggregate. The trigger requires certain pre- 794 fix ranges to be present and certain others to be absent in the RIB 795 as a precondition for generation. 797 The trigger is specified by a logical expression using the connec- 798 tives AND and OR, and the constructs HC (Have-Components) and EX 799 (EXclude) defined as follows: 801 HC{}: true iff there is a matching route 802 in the RIB for every 803 prefix-range in the list. 805 EX{}: true iff there is no matching route 806 in the RIB for any of the 807 prefix-ranges in the list. 809 The aggregate route is generated and put into the RIB when the 810 trigger condition becomes true, and removed from the RIB when it 811 becomes false. For example, the rule 813 aggregate into 10/8 814 triggered by HC{10.1/16^24-32, 10.2.2/24^+} AND EX{11/8^+} 816 specifies that the aggregate 10/8 will be added to the RIB only if 817 there are routes matching 10.1/16^24-32 and 10.2.2/24^+, and no 818 routes matching 11/8^+ in the RIB. 820 components: determines the route attributes of the aggregate, if it is 821 generated. This attribute has the following syntax: 823 components ATOMIC | [protocol ] 824 [[protocol ] ] ... 826 The components attribute is either specified by the keyword ATOMIC 827 or by a list of filters and their corresponding protocols. In the 828 former case attributes of the aggregate are assigned to their 829 default values, and in the latter they are computed from a subset 830 of the component routes, called attribute-components. 832 Attribute-components consist of the more specifics of the aggregate 833 that match one of the filters and are learned from the correspond- 834 ing protocol. If the protocol is omitted in front of a filter then 835 it defaults to any protocol. 837 The properties of the attribute computation are as follows: 839 - the computation might result in a conflict of some of the com- 840 ponent attributes, in which case the aggregate will not be gen- 841 erated. An example conflict is the case where the routes in 842 attribute-components do not have the same next-hop. 843 - the attributes of the aggregate have to be re-computed every 844 time the state of the attribute-components change (i.e. a new 845 component passes the components filter), when a component no 846 longer passes the components filter, or when a component still 847 passes the components filter but had a change in its route 848 attributes. 849 - if no trigger attribute is specified, then the components 850 attribute is used to decide whether to generate the aggregate or 851 not. It will be generated only if the attribute-components is 852 not empty (i.e. at least one of the more specifics in the RIB 853 matches the components filter). 855 For example, 857 aggregate into 128.64/10 858 components 859 protocol BGP {128/8^+} 860 protocol OSPF {128.70/15^16-24} and type==INTER-AREA 862 uses BGP routes that are more specifics of 128.64/10 and inter-area 863 OSPF routes that match 128.70/15^16-24 for computing the route 864 attributes of the aggregate 128.64/10. Notice that since the more 865 specifics are exclusively used in the computation, all filters are 866 implicitly ANDed with {128.64/10^-}. 868 action: a list of PR actions applied each time the route attributes of 869 the aggregate are (re-)evaluated. The action attribute is used to 870 modify some of the attributes that are either set to their default 871 values (i.e. ATOMIC) or computed from the more specifics. 873 For example, 875 action {comm.delete(NO-EXPORT); med=100} 877 if present, removes the NO-EXPORT community from the community list 878 of the aggregate and set its med to 100. 880 export components: allows some of the more specific components of an 881 aggregate to be exported. In general, when a set of routes are 882 aggregated, the intent is to export only the aggregate and suppress 883 all the more specifics. However, to satisfy some topology con- 884 straints such as a multi-homed component, this attribute allows 885 some of the components to be exported. Using the export components 886 attribute a list of export policy rules from a number of protocols 887 to the protocol PR (the aggregator protocol) is specified. The 888 export components attribute is of the form: 890 export components from 891 [from ] ... 893 The following specifies the evaluation of an aggregate and its more 894 specifics for export: 896 - Every time the aggregate is generated or has a change in its 897 attributes: 898 - it is (re)evaluated for export to all the neighbors. 899 - to the neighbors that the aggregate was exported before but 900 blocked now, the export of more specifics are evaluated using 901 the configured export policy. 902 - to the neighbors that the aggregate was not exported before 903 but exported now, the export of more specifics are evaluated 904 using the export components of the corresponding aggregate 905 rule. 907 - When the aggregate is removed from the RIB (either because the 908 trigger became false or the component attributes conflict): 909 - to the neighbors that the aggregate was exported before, 910 the export of more specifics are evaluated using the config- 911 ured export policy. 913 The following are some examples of the export components attribute: 915 aggregate into 10/8 916 export components from ANY-PROTOCOL announce {10.1/16^-} 918 specifies that when the aggregate 10/8 is exported to a neighbor, 919 all the more specifics are suppressed from export to that neighbor 920 except the ones that are also more specifics of 10.1/16. 922 aggregate into 128.100/16 923 export components 924 from OSPF 925 to {AS17, AS126} action dpa=50 announce ANY-ROUTE 927 is a BGP aggregate rule where OSPF more specifics of 128.100/16 are 928 exported to the peers in AS17 or AS126 along with the aggregate, 929 and in all other cases the more specifics are suppressed. 931 holes: a prefix range list that specifies the holes in the aggregate, 932 i.e. the more specific address ranges not reachable through the 933 aggregate route (perhaps they are not allocated). Holes attribute 934 has no functional role, it is for diagnostic purposes only. 936 Here is an example BGP aggregation rule that uses all the rule attributes: 938 aggregate into 10/8 939 triggered by HC{10.1/16^24-32, 10.2.2/24^+} AND EX{11/8^+} 940 components protocol RIP {10.3/16^+} AND 941 src-gw=={50.10/16^+} 942 protocol BGP AS5 943 protocol OSPF ANY-ROUTE 944 action {med=100; community.delete(NO-EXPORT);} 945 export components from OSPF 946 to {AS10, 128.10.9.9} announce ANY-ROUTE 947 from BGP 948 to {AS10} announce AS5 949 holes {10.100.100/24^+} 951 In case of overlapping aggregation rules, where the aggregate of one rule 952 is a lesser specific of another one, the semantics of rule evaluation is 953 extended as follows: 955 - activation evaluation: is performed starting from the rule for the 956 most specific aggregate to the rule for the least specific one. 957 This ensures that, the activation evaluation for an aggregate will 958 consider the most current activation state of the more specific 959 aggregates (i.e. whether they are present in the RIB or not and 960 their route attributes if they are in the RIB). 962 - export evaluation: a route is exported to a neighbor iff: 963 - it is the least specific aggregate in the RIB that passes the 964 export policy, or 965 - it passes the export components attribute of an aggregation 966 rule whose aggregate is exported, or 967 - there are no aggregates of this route that passes the export 968 policy, but the route itself passes it. 970 Notice that the above conditions describe chains of routes, 971 A1,A2,...,An,Rn+1, where: 972 - all Ai are active aggregates, and 973 - A1 is the least specific aggregate in the RIB that passes the 974 export policy, and 975 - each Ai is a more specific of Ai-1 and Ai passes the export 976 components of Aj for some j 1100 is used to set the current ip instance on a physical router device. The 1101 commands following (1) are used to configure the protocols and policies of 1102 the logical router specified by the given IP instance. 1104 Each IP instance stores its routing policies in a database, where each pol- 1105 icy of a protocol is configured on a separate global policy table. The 1106 names and contents of these tables are listed below: 1108 IMPORT-: defines the ordered list of import rules used by the proto- 1109 col to decide which of the received routes to import and with 1110 what route attributes. This list is of the form: 1112 IMPORT- : 1113 {; ; ... } 1115 EXPORT--: defines the ordered list of export rules used 1116 by the protocol to decide which routes to export 1117 to a neighbor and with what route attributes. This list is of the 1118 form: 1120 EXPORT-- : 1121 {; 1122 ; ... } 1124 AGGREGATE-: defines the unordered set of aggregation rules used by 1125 the protocol to decide what aggregates to generate and 1126 which more specifics of these aggregates to suppress from export. 1127 This set is of the form: 1129 AGGREGATE-: 1130 {; ; ... } 1132 Rules in an import or export table are ordered. When a protocol evaluates 1133 its import or export policy for a route, the decision is taken by applying 1134 the first matching rule in the corresponding global policy table. If no 1135 rule in the table matches, then the appropriate default action is taken. 1136 Default actions depend on the policy and the protocols involved, and they 1137 are shown in Figures 2 and 3. 1139 Rules in an aggregation policy table, on the other hand, are not ordered. 1140 Every time the state of the RIB changes (i.e. some route R gets added, 1141 removed or changed), all aggregation rules that define an aggregate for R 1142 are evaluated in the order of the most specific aggregate to the least 1143 specific one. 1145 Initially, when the router is started, all global tables are empty. This 1146 means that the default actions will be taken for all import and export 1147 decisions, and no aggregate will be generated. Later, policies are config- 1148 ured (and re-configured) by changing the contents of their corresponding 1149 global tables. 1151 Parts of global tables that are repeatedly used can be defined as a macro. 1152 The macros are explained in section A.1. Configuration commands to insert, 1153 remove and reorder policy rules in a global policy table are given in sec- 1154 tions A.2 and A.3. 1156 Changing the contents of the policy database is an expensive operation. All 1157 current policy decisions that might get affected by the policy changes have 1158 to be re-evaluated by the protocols. Therefore, changes in the database (as 1159 requested by the configuration commands that are issued) are not committed 1160 after each configuration command but delayed until an explicit commit com- 1161 mand is specified. The details of commiting is explained in A.4. 1163 A.1 Policy Macros 1165 Some policy pieces that are used repeatedly during policy configuration can 1166 be defined as a macro. The generic syntax of a macro is: 1168 define 1170 All macro references, , in the configuration are replaced by 1171 its object definition, . 1173 Naming of macros are restricted based on the type of the policy piece they 1174 define. Each macro name is made up of two parts separated by the character 1175 hyphen "-". The first part is a constant string specifying the type of the 1176 policy piece, and the second part is a free string of 8 characters assign- 1177 ing a unique name to the macro. For example "peer-internal" is a valid 1178 macro name where "peer" specifies that it defines a peer set and "internal" 1179 results in a unique name for the macro. 1181 Some macros define attributes of a policy rule. Their syntax are as fol- 1182 lows: 1184 (2) define peer- 1186 (3) define fltr- 1188 (4) define act- 1190 The following is an example of their use: 1192 define peer-nghbors {as17, 128,166.9.9, as57} 1194 define fltr-for128 {128.176/20^+, 128.0/9^20-24} and 1195 (as12 or ) 1197 define act-for128 {pref=10; aspath.prepend(as99)} 1199 Using the above macros one can define the following BGP import rule: 1201 from peer-nghbors 1202 action act-for128 1203 accept (fltr-for128 and {as217, as61, as126}) 1205 which expands to 1207 from {as17, 128,166.9.9, as57} 1208 action {pref=10; aspath.prepend(as99)} 1209 accept ({128.176/20^+, 128.0/9^20-24} and 1210 (as12 or ) and 1211 {as217, as61, as126}) 1213 Macros may also be used for defining list of policy rules. The following is 1214 the syntax for import, export and aggregation rule lists, respectively: 1216 (5) define imp- 1217 protocol 1218 {; ; ... } 1220 (6) define exp- 1221 protocol into 1222 {; 1223 ; ... } 1225 (7) define aggr- 1226 protocol 1227 {; ; ... } 1229 As explained before, rules in an import or export policy list are ordered. 1230 When defining a macro, this ordering is explicitly specified by listing the 1231 rules. However, macros can also be modified by inserting/removing rules 1232 to/from them, in which case the ordering has to be specified implicitly. An 1233 integer, called a rule number, is assigned to individual rules of a macro 1234 to impose this ordering. A rule with a smaller rule number comes before a 1235 rule with a larger one. Rule numbers are also used to refer to the rules of 1236 an import or export policy macro. The syntax for rule referrals can take 1237 the following forms: 1239 : refers to all the rules of that macro. 1241 : refers to the rule in with the 1242 rule number . 1244 -: refers to all the rules in 1245 with the rule number in between and 1246 , both inclusive. 1248 For example, "imp-mypol 5-7" refers to the rules in imp-mypol with the rule 1249 numbers 5, 6 or 7. In rule referrals, the character "$" denotes the maximum 1250 rule number used in a macro. For example "exp-pol5 $" refers to the last 1251 rule in exp-pol5. 1253 Initially, when an import or export policy macro is defined, rules are 1254 assigned consecutive rule numbers starting from 1. Later the contents and 1255 the rule numbers of macros can be modified using the following commands: 1257 (8) insert imp- 1258 {; ; ... } 1259 [] 1261 appends the specified import rules after imp- []. 1262 If is not specified it defaults to $, i.e. rules are 1263 appended to the end. The inserted rules are assigned consecutive 1264 rule numbers starting from the plus one. If any of the 1265 rule numbers are already assigned to another rule, then the inser- 1266 tion is aborted. In such cases, the move command has to be used 1267 first to open up the space for insertion. 1269 (9) remove imp- 1270 [-] 1272 removes the rules that match imp- [-] 1273 from the macro imp-. 1275 (10) move imp- 1276 [-] up | down 1278 assigns new rule numbers to the rules that match imp- 1279 [-]. If "up" is specified in the command, the 1280 rules are assigned their current rule numbers plus . Simi- 1281 larly, if "down" is specified, they are assigned their current 1282 rule numbers minus . If any of the new rule numbers are 1283 already assigned to another rule, then the move operation is 1284 aborted. Notice that move does not change the relative ordering of 1285 the rules in a macro. It is used to open up the rule number space 1286 for inserting new rules. 1288 (11) compact imp- 1290 is useful when rule numbers are too sparse in a macro. Without 1291 changing the current rule ordering, they assign new rule numbers 1292 to the rules incrementally starting from 1. 1294 The commands that modify export macros have the same semantics as that of 1295 import macros. They are listed below: 1297 (12) insert exp- 1298 {; 1299 ; ... } 1300 [] 1302 (13) remove exp- 1303 [-] 1305 (14) move exp- 1306 [-] up | down 1308 (15) compact exp- 1310 An example import/export macro definition and modification is given below. 1311 Text following the character "#" in a line are considered comments and they 1312 are used to explain the affects of the example commands. 1314 # Rules are not specified explicitly, but represented by identifiers 1315 # such as R1, R2 etc. Numbers shown before each rule denotes its rule 1316 # number. The content of the macro is shown after each configuration 1317 # command as if they are committed right away. 1319 define imp-as57pol protocol bgp {R1; R2; R3; R4} 1321 # Initially the content of imp-as57pol is 1322 # 1323 # imp-as57pol = { 1324 # (1) R1; (2) R2; (3) R3; (4) R4 1325 # } 1327 insert imp-as57pol {Y1; Y2} 2 1329 # rejected because rule numbers 3 and 4 are in use 1331 move imp-as57pol 3-$ down 3 1333 # imp-as57pol = { 1334 # (1) R1; (2) R2; (6) R3; (7) R4 1335 # } 1337 insert imp-as57pol {Y1; Y2} 2 1339 # imp-as57pol = { 1340 # (1) R1; (2) R2; (3) Y1; (4) Y2; (6) R3; (7) R4 1341 # } 1343 remove imp-as57pol 4-6 1345 # imp-as57pol = { 1346 # (1) R1; (2) R2; (3) Y1; (7) R4 1347 # } 1349 compact imp-as57pol 1351 # imp-as57pol = { 1352 # (1) R1; (2) R2; (3) Y1; (4) R4 1353 # } 1355 Since aggregation policy rules are not ordered, there is no rule number 1356 assigned to the individual rules. Instead, rules can be referred by the 1357 aggregation prefix that it defines. The syntax for an aggregation policy 1358 macro definition is already given in (7). The commands to modify an aggre- 1359 gation macro are described below: 1361 (16) insert aggr- 1362 {; ; ... } 1364 adds the specified aggregation rules to aggr-. 1366 (17) remove aggr- 1367 1369 removes the aggregation rules from aggr- that define an 1370 aggregate matching . 1372 An example aggregation macro definition and modification is given below. 1374 # For brevity, the rules are not completely specified. The content of 1375 # the macro is shown after some of the commands as if changes are 1376 # committed right away. 1378 define aggr-net10 1379 protocol bgp 1380 { 1381 aggregate 10/8 ...; 1382 aggregate 10.9.9/24 ...; 1383 aggregate 10.10.9/24 ...; 1384 } 1386 insert aggr-net10 1387 { 1388 aggregate 10.10/16 ...; 1389 aggregate 10.10.9.128/25 ...; 1390 aggregate 10.20/16 ...; 1391 } 1393 # aggr-net10 = { 1394 # aggregate 10/8 ...; 1395 # aggregate 10.10/16 ...; 1396 # aggregate 10.20/16 ...; 1397 # aggregate 10.9.9/24 ...; 1398 # aggregate 10.10.9/24 ...; 1399 # aggregate 10.10.9.128/25 ...; 1400 # } 1402 remove aggr-net10 {10.0/12^16-24} 1404 # aggr-net10 = { 1405 # aggregate 10/8 ...; 1406 # aggregate 10.10.9.128/25 ...; 1407 # aggregate 10.20/16 ...; 1408 # } 1410 A.2 Import and Export Policy Configuration 1412 Import policy for a protocol is configured in the global table 1413 IMPORT-. Similarly, export policy from a protocol to a proto- 1414 col is configured in the global table EXPORT--. 1415 These global tables are made up of policy macros, where the ordering of the 1416 rules is specified hierarchically as follows: 1418 - the ordering within the rules of a member macro is determined by the 1419 rule numbers 1420 - the ordering of the member macros is determined by unique integers 1421 assigned to individual macros, named macro numbers. In the global table, 1422 the rules of a member macro with a smaller macro number comes before the 1423 rules of a member macro with a larger one. 1425 Assigning unique macro numbers to member macros allow another way to refer 1426 to them, in addition to using macro names. The syntax is as follows: 1428 import- : refers to the import macro for protocol 1429 that is inserted into import- with the macro number . 1432 export-- : refers to the export macro for the 1433 protocol pair (, ) that is inserted into export- 1434 - with the macro number . 1436 A member macro in a global table can be assigned a new macro number in 1437 order to reorder its rules relative to the rest of the global table. When 1438 this happens, referring to the macro from the global table changes, using 1439 the new macro number. 1441 Not all macros that are used in a global table have to be defined previ- 1442 ously. Some macros are defined on the fly by listing their rules and 1443 inserting them into a global table with a unique macro number. Such macros 1444 are called on-the-fly macros and they do not have macro names. They are 1445 temporary in the sense that when such a macro is removed from the global 1446 table, its definition is lost. To prevent that, an on-the-fly macro can be 1447 changed into a permenant one by assigning a macro name to it. 1449 Notice that global tables for import and export policies are tightly cou- 1450 pled with their member macros. Any change in a macro changes the global 1451 policy tables that it is a member of, which in turn changes the correspond- 1452 ing protocol policies. To decouple a global table from one of its member 1453 macros, the member macro can be replaced by an exact copy of it and can be 1454 given a new macro name or can be made an on-the-fly macro. This operation 1455 does not change the rules that are in the global table, but prevents future 1456 changes in the decoupled macro to be reflected to the global table and vice 1457 versa. 1459 Import and Export policies are configured using the following commands: 1461 (18) insert-macro import- 1462 imp- 1464 inserts the macro imp- into the table import- with a 1465 unique macro number . If the protocol in the imp- 1466 definition does not match with , or the is already 1467 assigned to another macro, the insertion operation is rejected. 1468 Notice that after this operation, imp- can also be referred 1469 as import- . 1471 (19) insert-macro import- 1472 {; ...} 1474 inserts an on-the-fly macro into the table import- with a 1475 unique macro number . The rules of the macro are speci- 1476 fied explicitly in the command. Like (18), the operation is 1477 rejected if is already in use. Notice that the 1478 inserted on-the-fly macro can only be referred as import- 1479 . 1481 (20) remove-macro import- 1482 1484 removes the macro referred by import- from the 1485 table import-. If the removed macro is defined on-the-fly, 1486 then its definition is lost after this operation. To prevent this, 1487 link operation can be used as described below. 1489 (21) move-macro import- 1490 to 1492 relocates the macro referred by import- by 1493 assigning a new macro number, , to it. This changes 1494 the ordering of the rules in this macro relative to the rest of 1495 the rules in the table import-. It also changes the way this 1496 macro is referred, from import- to import- 1497 . 1499 (22) insert import- 1500 {; ...} [.] 1501 (23) remove import- 1502 .[-] 1503 (24) move import- 1504 .[-] up | down 1505 (25) compact import- 1507 commands (22)-(25) are used to change the contents of import mac- 1508 ros. Their semantics are the same as the commands (8)-(11), except 1509 that here the macros are referred by their macro numbers instead 1510 of their macro names. 1512 (26) link import- to imp- 1514 replaces the macro that is inserted in import- 1515 with a fresh copy of it, and assigns the name imp- to the 1516 new copy. If the replaced macro was already assigned a name (i.e. 1517 was not an on-the-fly macro), then this operation decouples the 1518 global table import- from the replaced macro, meaning no 1519 changes in one will affect the other. If the replaced macro was an 1520 on-the-fly macro, then the operation makes it permanent, i.e. the 1521 macro definition will not be lost after it is removed from the 1522 global table import-. 1524 (27) unlink import- from imp- 1526 replaces the macro that is inserted in import- 1527 with a fresh on-the-fly copy of it. It decouples the import- 1528 from the replaced macro. Notice that since the new copy is an 1529 on-the-fly macro, its definition will be lost after it is removed 1530 from the global table import-. 1532 The commands to configure export policies have the same semantics as that 1533 of import policies. They are listed below: 1535 (28) insert-macro export-- 1536 exp- 1538 (29) insert-macro export-- 1539 {; ...} 1541 (30) remove-macro export-- 1542 1544 (31) move-macro export-- 1545 to 1547 (32) insert export-- 1548 {; ...} [.] 1550 (33) remove export-- 1551 .[-] 1553 (34) move export-- 1554 .[-] up | down 1556 (35) compact export-- 1558 (36) link export-- to exp- 1560 (37) unlink export-- from exp- 1562 An example is shown below for an import policy configuration of BGP: 1564 # For brevity, the rules are not explicitly specified but represented 1565 # by identifiers such as R1, R2 etc. 1566 # The example assumes that initially the IMPORT-BGP is empty. 1567 # The contents of the global table and some of the macros are shown after 1568 # some of the commands as if the changes are committed right away. 1570 define imp-rippol protocol rip {M1; M2} 1572 define imp-bgppol protocol bgp {X1; X2; X3} 1574 insert-macro import-bgp imp-rippol 100 1576 # rejected because of the mismatch of protocols 1578 insert-macro import-bgp imp-bgppol 100 1580 insert-macro import-bgp {Y1; Y2} 100 1582 # rejected because macro is 100 is already in use 1584 insert import-bgp {Y1; Y2} 100 1586 # IMPORT-BGP = imp-bgppol = 1587 # { { 1588 # (100 = imp-bgppol) (1) X1; 1589 # (1) X1; (2) X2; 1590 # (2) X2; (3) X3; 1591 # (3) X3; (4) Y1; 1592 # (4) Y1; (5) Y2; 1593 # (5) Y2; } 1594 # } 1596 move import-bgp 3-$ down 1 1598 insert import-bgp {Z1} 2 1600 insert-macro import-bgp {R1; R2} 200 1602 # IMPORT-BGP = imp-bgppol = 1603 # { { 1604 # (100 = imp-bgppol) (1) X1; 1605 # (1) X1; (2) X2; 1606 # (2) X2; (3) Z1; 1607 # (3) Z1; (4) X3; 1608 # (4) X3; (5) Y1; 1609 # (5) Y1; (6) Y2; 1610 # (6) Y2; } 1611 # 1612 # (200 = ON-THE-FLY) 1613 # (1) R1; 1614 # (2) R2; 1615 # } 1617 move-macro import-bgp 100 to 500 1619 unlink import-bgp 500 from imp-bgppol 1621 link import-bgp 200 to imp-newrules 1623 # IMPORT-BGP = imp-bgppol = imp-newrules = 1624 # { { { 1625 # (200 = imp-newrules) (1) X1; (1) R1; 1626 # (1) R1; (2) X2; (2) R2; 1627 # (2) R2; (3) Z1; } 1628 # (4) X3; 1629 # (500 = ON-THE-FLY) (5) Y1; 1630 # (1) X1; (6) Y2; 1631 # (2) X2; } 1632 # (3) Z1; 1633 # (4) X3; 1634 # (5) Y1; 1635 # (6) Y2; 1636 # } 1638 remove import-bgp 500 3-6 1640 remove imp-bgppol 1-3 1642 remove-macro import-bgp 200 1644 # IMPORT-BGP = imp-bgppol = imp-newrules = 1645 # { { { 1646 # (500 = ON-THE-FLY) (4) X3; (1) R1; 1647 # (1) X1; (5) Y1; (2) R2; 1648 # (2) X2; (6) Y2; } 1649 # } } 1651 A.3 Aggregation Policy Configuration 1653 The aggregation policy for a protocol is configured in the global 1654 table AGGREGATE-. Aggregation tables are different than the import and 1655 export tables in the following ways: 1657 - Rules in a global aggregation table are not ordered. 1658 - There is no rule number assigned to individual rules. Instead, the 1659 rules are referred by the aggregate prefix that they define. 1661 - Global aggregation tables are not coupled with aggregation macros. 1662 When a macro is inserted into a global aggregation table, the current 1663 contents of the macro is copied into the global table. Future changes 1664 made in the macro are not reflected into the global table. 1666 The following are the commands to configure an aggregation policy: 1668 (38) insert aggregate- 1669 {; ; ... } 1671 adds the specified aggregation rules to the global table 1672 aggregate-. 1674 (39) insert aggregate- 1675 aggr- 1677 creates a copy of the rules in aggr- and adds them to the 1678 global table aggregate-. Note that, the global table and the 1679 macro each have their own copies of the rules, and therefore there 1680 is no coupling between them. 1682 (40) remove aggregate- 1683 1685 removes all the rules from the table aggregate- that define an 1686 aggregate matching . 1688 (41) remove aggregate- 1689 aggr- 1691 removes all the rules from the table aggregate- that was 1692 inserted from the macro aggr-. 1694 A.4 Commit Operation 1696 Any run-time policy change of a protocol results in an expensive series of 1697 operations. All current policy decisions that might get affected by the 1698 policy change have to be re-evaluated by the protocol. Therefore, changing 1699 the global policy tables after each command is very inefficient. Instead, 1700 all changes are committed simultaneously at well-defined points in time. 1701 The following command is used for this purpose: 1703 (42) commit [changes] 1705 changes all the policies of all the protocols according to the 1706 commands that are issued between the previous commit operation and 1707 now. 1709 APPENDIX B. RPCL Reference 1711 This appendix section provides the complete syntax of RPCL in BNF form. 1712 The first subsection, B.1, gives the syntax of RPCL policy rules, and the 1713 next subsection, B.2, gives the syntax of the RPCL policy editor. 1715 B.1 RPCL Policy Syntax 1717 B.1.1 Basic Types 1719 : [0-255] | 1720 [0-255].[0-255] | 1721 [0-255].[0-255].[0-255] | 1722 [0-255].[0-255].[0-255].[0-255] 1724 : [0-32] 1726 : STATIC | DIRECT | RIP | OSPF | BGP 1728 : RIP | OSPF | BGP 1730 : / 1732 : 1734 : 1736 : [1-15] 1738 : [1-65535] 1740 : INTRA-AREA | INTER-AREA | EXTERNAL-1 | EXTERNAL-2 1742 : AS 1744 : {, , ..., } 1746 : {, , ..., } 1748 : 1750 : {, , ... } 1752 : 1754 : [0-255].[0-255].[0-255].[0-255] 1756 : 1757 : | 1759 : {, , ... } 1761 B.1.2 Filter Types 1763 # m and n are [0-32] 1764 : [ ^- | ^+ | ^m | ^m-n ] 1766 : {, , ... } | 1767 1769 : | | | . 1771 : * | + | ? | (m) | (m,) | (m,n) | 1773 : 1775 : '<' [^] ... [$] '>' 1777 B.1.3 Policy Filters 1779 : 1781 : 1783 : | 1784 src-gw== | 1785 tag== 1787 : | 1788 type== | 1789 tag== 1791 : | 1792 | 1793 | 1794 | 1795 community == | 1796 community.contains 1798 B.1.4 Policy Actions 1800 : 1801 pref= 1803 : 1804 {; ; ...} 1806 : 1807 tag= | 1808 metric= 1810 : 1811 {; ; ...} 1813 : 1814 pref= 1816 : 1817 {; ; ...} 1819 : 1820 tag= | 1821 metric= | 1822 type= 1824 : 1825 {; ; ...} 1827 : 1828 pref= | 1829 med= | 1830 dpa= | 1831 aspath.prepend | 1832 community= | 1833 community.= | # append a single community 1834 community.append | # append multiple communities 1835 community.delete # delete the ones that exist 1837 : 1838 {, , ...} 1840 : 1841 {, , ...} 1843 B.1.5 Policy Peering Specification 1845 : | | 1847 B.1.6 Policy Rules 1849 : 1850 [from ] [action ] accept | 1851 [from ] block | 1852 {; ; ...} | 1853 refine 1855 : 1856 [to ] [action ] announce | 1857 [to ] block | 1858 {; ; ...} | 1859 refine 1861 : 1862 aggregate into 1864 triggered by AND/OR of HC{} and 1865 EX{} 1867 components ATOMIC | 1868 [protocol ] 1869 [[protocol ] ] ... 1871 action 1873 export components from 1874 [from ] ... 1876 holes 1878 B.2 Policy Editor 1880 : string of {[a-z], [A-Z], [0-9], "-", "_"} of length 8 1882 B.2.1 Policy Attribute Macros 1884 define peer- 1886 define fltr- 1888 define act- 1890 undefine peer- 1892 undefine fltr- 1894 undefine act- 1896 show peer[-] 1898 show fltr[-] 1900 show act[-] 1902 B.2.2 Import Policy Macros 1903 define imp- 1904 protocol 1905 {; ; ... } 1907 undefine imp- 1909 insert imp- 1910 {; ; ... } 1911 [] 1913 remove imp- 1914 [-] 1916 move imp- 1917 [-] up | down 1919 compact imp- 1921 show imp[-] 1923 B.2.3 Export Policy Macros 1925 define exp- 1926 protocol into 1927 {; ; 1929 undefine exp- 1931 insert exp- 1932 {; ; ... } 1933 [] 1935 remove exp- 1936 [-] 1938 move exp- 1939 [-] up | down 1941 compact exp- 1943 show exp[-] 1945 B.2.4 Aggregation Policy Macros 1947 define aggr- 1948 protocol 1949 {; ; ... } 1951 undefine aggr- 1953 insert aggr- 1954 {; ; ... } 1956 remove aggr- 1957 1959 show aggr[-] [] [forest] 1961 B.2.5 Import Policy Configuration 1963 insert-macro import- 1964 imp- 1966 insert-macro import- 1967 {; ...} 1969 remove-macro import- 1970 1972 move-macro import- 1973 to 1975 insert import- 1976 {; ...} [.] 1978 remove import- 1979 .[-] 1981 move import- 1982 .[-] up | down 1984 compact import- 1986 link import- to imp- 1988 unlink import- from imp- 1990 show import- [] 1992 B.2.6 Export Policy Configuration 1994 insert-macro export-- 1995 exp- 1997 insert-macro export-- 1998 {; ...} 2000 remove-macro export-- 2001 2003 move-macro export-- 2004 to 2006 insert export-- 2007 {; ...} [.] 2009 remove export-- 2010 .[-] 2012 move export-- 2013 .[-] up | down 2015 compact export-- 2017 link export-- to exp- 2019 unlink export-- from exp- 2021 show export-- [] 2023 B.2.7 Aggregation Policy Configuration 2025 insert aggregate- 2026 {; ; ... } 2028 insert aggregate- 2029 aggr- 2031 remove aggregate- 2032 2034 remove aggregate- 2035 aggr- 2037 show aggregate- [] [forest] 2039 B.2.8 Commit Operation 2041 commit [changes]