idnits 2.17.1 draft-ietf-rps-appl-rpsl-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 265 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 33 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 336 has weird spacing: '...ltering on...' == Line 657 has weird spacing: '... router bgp...' == Line 790 has weird spacing: '...neither of t...' == Line 791 has weird spacing: '...ication or a...' == Line 1027 has weird spacing: '... router bgp...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (May 20, 1999) is 9108 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** 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' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 1654 (ref. '7') (Obsoleted by RFC 1771) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Downref: Normative reference to an Informational RFC: RFC 1998 (ref. '9') Summary: 14 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft David Meyer 2 Expires November 20, 1999 Cisco Systems 3 draft-ietf-rps-appl-rpsl-05.txt Joachim Schmitz 4 DFN-NOC 5 Carol Orange 6 RIPE NCC 7 Mark Prior 8 Connect 9 Cengiz Alaettinoglu 10 USC/ISI 11 May 20, 1999 13 Using RPSL in Practice 15 Status of this Memo: 17 This document is an Internet-Draft and is in full conformance with all 18 provisions of Section 10 of RFC2026. 20 Copyright (C) The Internet Society (1998). All Rights Reserved. 22 Internet-Drafts are working documents of the Internet Engineering Task Force 23 (IETF), its areas, and its working groups. Note that other groups may also 24 distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months and 27 may be updated, replaced, or obsoleted by other documents at any time. It 28 is inappropriate to use Internet-Drafts as reference material or to cite 29 them other than as 'work in progress.' 31 The list of current Internet-Drafts can be accessed at 32 34 The list of Internet-Draft Shadow Directories can be accessed at 35 . 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC 2119. 41 Abstract 43 This document is a tutorial on using the Routing Policy Specification 44 Language (RPSL) to describe routing policies in the Internet Routing 45 Registry (IRR). We explain how to specify various routing policies and 46 configurations using RPSL, how to register these policies in the IRR, and 47 how to analyze them using the routing policy analysis tools, for example to 48 generate vendor specific router configurations. 50 1 Introduction 52 This document is a tutorial on using the Routing Policy Specification 53 Language (RPSL) to describe routing policies in the Internet Routing 54 Registry (IRR). We explain how to specify various routing policies and 55 configurations using RPSL, how to register these policies in the IRR, and 56 how to analyze them using the routing policy analysis tools, for example to 57 generate vendor specific router configurations. This document is targeted 58 towards an Internet/Network Service Provider (ISP/NSP) engineer who 59 understands Internet routing, but is new to RPSL and to the IRR. Readers are 60 referred to the RPSL reference document [1] for completeness. It is also 61 good to have that document at hand while working through this tutorial. 63 The IRR is a repository of routing policies. Currently, the IRR repository 64 is a set of five repositories maintained at the following sites: the CA*Net 65 registry in Canada, the ANS, CW and RADB registries in the United States of 66 America, and the RIPE registry in Europe. The five repositories are run 67 independently. However, each site exchanges its data with the others 68 regularly (at least once a day and as often as every ten minutes). CW, 69 Ca*Net and ANS are private registries which contain the routing policies of 70 the networks and the customer networks of CW, Ca*Net, and ANS respectively. 71 RADB and RIPE are both public registries, and any ISP can publish their 72 policies in these registries. 74 The registries all maintain up-to-date copies of one another's data. At any 75 of the sites, the five registries can be inspected as a set. One should 76 refrain from registering his/her data in more than one of the registries, as 77 this practice leads almost invariably to inconsistencies in the data. The 78 user trying to interpret the data is left in a confusing (at best) 79 situation. CW, ANS and CA*Net customers are generally required to register 80 their policies in their provider's registry. Others may register policies 81 either at the RIPE or RADB registry, as preferred. 83 RPSL is based on RIPE-181 [2, 3], a language used to register routing 84 policies and configurations in the IRR. Operational use of RIPE-181 has 85 shown that it is sometimes difficult (or impossible) to express a routing 86 policy which is used in practice. RPSL has been developed to address these 87 shortcomings and to provide a language which can be further extended as the 88 need arises. RPSL obsoletes RIPE-181. 90 RPSL constructs are expressed in one or more database "objects" which are 91 registered in one of the registries described above. Each database object 92 contains some routing policy information and some necessary administrative 93 data. For example, an address prefix routed in the inter-domain mesh is 94 specified in a route object, and the peering policies of an AS are specified 95 in an aut-num object. The database objects are related to each other by 96 reference. For example, a route object must refer to the aut-num object for 97 the AS in which it is originated. Implicitly, these relationships define 98 sets of objects, which can be used to specify policies effecting all 99 members. For example, we can specify a policy for all routes of an ISP, by 100 referring to the AS number in which the routes are registered to be 101 originated. 103 When objects are registered in the IRR, they become available for others to 104 query using a whois service. Figure 1 illustrates the use of the whois 105 command to obtain the route object for 128.223.0.0/16. The output of the 106 whois command is the ASCII representation of the route object. The syntax 107 and semantics of the route object are described in Appendix A.3. Registered 108 policies can also be compared with others for consistency and they can be 109 used to diagnose operational routing problems in the Internet. 111 % whois -h radb.ra.net 128.223.0.0/16 112 route: 128.223.0.0/16 113 descr: UONet 114 descr: University of Oregon 115 descr: Computing Center 116 descr: Eugene, OR 97403-1212 117 descr: USA 118 origin: AS3582 119 mnt-by: MAINT-AS3582 120 changed: meyer@ns.uoregon.edu 19960222 121 source: RADB 123 Figure 1: whois command and a route object. 125 The RAToolSet [6] is a suite of tools which can be used to analyze the 126 routing registry data. It includes tools to configure routers (RtConfig), 127 tools to analyze paths on the Internet (prpath and prtraceroute), and tools 128 to compare, validate and register RPSL objects (roe, aoe and prcheck). 130 In the following section, we will describe how common routing policies can 131 be expressed in RPSL. The objects themselves are described in Appendix A. 132 Authoritative information on the IRR objects, however, should be sought in 133 RFC-2280, and authoritative information on general database objects (person, 134 role, and maintainers) and on querying and updating the registry databases, 135 should be sought in RIPE-157 [4]. Section 3.2 describes the use of RtConfig 136 to generate vendor specific router configurations. 138 2 Specifying Policy in RPSL 140 The key purpose of RPSL is to allow you to specify your routing 141 configuration in the public Internet Routing Registry (IRR), so that you and 142 others can check your policies and announcements for consistency. Moreover, 143 in the process of setting policies and configuring routers, you take the 144 policies and configurations of others into account. 146 In this section, we begin by showing how some simple peering policies can be 147 expressed in RPSL. We will build on that to introduce various database 148 objects that will be needed in order to register policies in the IRR, and to 149 show how more complex policies can be expressed. 151 2.1 Common Peering Policies 153 The peering policies of an AS are registered in an aut-num object which 154 looks something like that in Figure 2. We will focus on the semantics of 155 the import and export attributes in which peering policies are expressed. 156 We will also describe some of the other key attributes in the aut-num 157 object, but the reader should refer to RFC-2280 or to RIPE-157 for the 158 definitive descriptions. 160 Now consider Figure 3. The peering policies expressed in the AS2 aut-num 161 object in Figure 2 are typical for a small service provider providing 162 connectivity for a customer AS3 and using AS1 for transit. That is, AS2 163 only accepts announcements from AS3 which: 165 o are originated in AS3; and 167 o have path length 1 (<^AS3$> means that AS3 is the first and last path 168 member)(1). 170 To AS1, AS2 announces only those routes which originate in their AS or in 171 their customer's AS. 173 In the example above, ``accept ANY'' in the import attribute indicates that 174 AS2 will accept any announcements that AS1 sends, and ``announce ANY'' in 175 the export attribute indicates that any route that AS2 has in its routing 177 ------------------------------ 178 1. AS-PATH regular expressions are POSIX compliant regular expressions. 180 aut-num: AS2 181 as-name: CAT-NET 182 descr: Catatonic State University 183 ... 184 import: from AS1 accept ANY 185 import: from AS3 accept <^AS3$> 186 export: to AS3 announce ANY 187 export: to AS1 announce AS2 AS3 188 ... 189 admin-c: AO36-RIPE 190 tech-c: CO19-RIPE 191 mnt-by: OPS4-RIPE 192 changed: orange@ripe.net 193 source: RIPE 195 Figure 2: Autonomous System Object 197 AS1--------AS2--------AS3 198 | | 199 | | 200 AS4--------AS5 202 Figure 3: Some Neighboring ASes. 204 table will be passed on to AS3. Assuming that AS1 announces ``ANY'' to AS2, 205 AS2 is taking full routing from AS1. 207 Note that with this peering arrangement, if AS1 adds or deletes route 208 objects, there is no need to update any of the aut-num objects to continue 209 the full routing policy. Added (or deleted) route objects will implicitly 210 update AS1's and AS2's policies. 212 While the peering policy specified in Figure 2 for AS2 is common, in 213 practice many peering agreements are more complex. Before we consider more 214 examples, however, let's first consider the aut-num object itself. Note 215 that it is just a set of attribute labels and values which can be submitted 216 to one of the registry databases. This particular object is specified as 217 being in (or headed for) the RIPE registry (see the last line in Figure 2). 218 The source should be specified as one of ANS, CANET, CW, RADB, or RIPE 219 depending on the registry in which the object is maintained. The source 220 attribute must be specified in every database object. 222 It is also worth noting that this object is ``maintained by'' OPS4-RIPE (the 223 value of the mnt-by attribute), which references a ``mntner'' object. 224 Because the aut-num object may be used for router configuration and other 225 operational purposes, the readers need to be able to count on the validity 226 of its contents. It is therefore required that a mntner be specified in the 227 aut-num and in most other database objects, which means you must create a 228 mntner object before you can register your peering policies. For brief 229 information on the ``mntner'' object and object writeability, see Appendix A 230 of this document. For more extensive information on how to set up and use a 231 mntner to protect your database objects, see Section 2.3 of RIPE-157. 233 2.2 ISP Customer - Transit Provider Policies 235 It is not uncommon for an ISP to acquire connectivity from a transit 236 provider which announces all routes to it, which it in turn passes on to its 237 customers to allow them to access hosts on the global Internet. Meanwhile, 238 the ISP will generally announce the routes of its customers networks to the 239 transit ISP, making them accessible on the global Internet. This is the 240 service that is specified in Figure 2 for AS3. 242 Consider again Figure 3. Suppose now that AS2 wants to provide the same 243 service to AS4. Clearly, it would be easy to modify the import and export 244 lines in the aut-num object for AS2 (Figure 2) to those shown in Figure 4. 246 import: from AS1 accept ANY 247 import: from AS3 accept <^AS3$> 248 import: from AS4 accept <^AS4$> 249 export: to AS3 announce ANY 250 export: to AS4 announce ANY 251 export: to AS1 announce AS2 AS3 AS4 253 Figure 4: Policy for AS3 and AS4 in the AS2 as-num object 255 These changes are trivial to make of course, but clearly as the number of 256 AS2 customers grows, it becomes more difficult to keep track of, and to 257 prevent errors. Note also that if AS1 is selective about only accepting 258 routes from the customers of AS2 from AS2, the aut-num object for AS1 would 259 have to be adjusted to accommodate AS2's new customer. 261 By using the RPSL ``as-set'' object, we can simplify this significantly. In 262 Figure 5, we describe the customers of AS2. Having this set to work with, 263 we can now rewrite the policies in Figure 2 as shown in Figure 6. 265 Note that if the aut-num object for AS1 contains the line: 267 as-set: AS2:AS-CUSTOMERS 268 members: AS3 AS4 269 ... 270 changed: orange@ripe.net 271 source: RIPE 273 Figure 5: The as-set object 275 import: from AS1 accept ANY 276 import: from AS2:AS-CUSTOMERS accept <^AS2:AS-CUSTOMERS$> 277 export: to AS2:AS-CUSTOMERS announce ANY 278 export: to AS1 announce AS2 AS2:AS-CUSTOMERS 280 Figure 6: Policy in the AS2 aut-num object for all AS2 customers 282 import: from AS2 accept <^AS2+ AS2:AS-CUSTOMERS*$> 284 then no changes will need to be made to the aut-num objects for AS1 or AS2 285 as the AS2 customer base grows. The AS numbers for new customers can simply 286 be added to the as-set AS2:AS-CUSTOMERS, and everything will work as for the 287 existing customers. Clearly in terms of readability, scalability and 288 maintainability, this is a far better mechanism when compared to adding 289 policy for the customer AS's to the aut-num objects directly. The policy in 290 this particular example states that AS1 will accept route announcements from 291 AS2 in which the first element of the path is AS2, followed by more 292 occurrences of AS2, and then 0 or more occurrences of any AS2 customer (e.g. 293 any member of the as-set AS2:AS-CUSTOMERS). 295 Alternatively, one may wish to limit the routes one accepts from a peer, 296 especially if the peer is a customer. This is recommended for several 297 reasons, such as preventing the improper use of unassigned address space, 298 and of course malicious use of another organization's address space. 300 Such filtering can be expressed in various ways in RPSL. Suppose the address 301 space 7.7.0.0/16 has been allocated to the ISP managing AS3 for assignment 302 to its customers. AS3 may want to announce part or all of this block on the 303 global Internet. Suppose AS2 wants to be certain that it only accepts 304 announcements from AS3 for address space that has been properly allocated to 305 AS3. AS2 might then modify the AS3 import line in Figure 2 to read: 307 import: from AS3 accept { 7.7.0.0/16^16-19 } 309 which states that route announcements for this address block will be 310 accepted from AS3 if they are of length upto /19. This of course will have 311 to be modified if and when AS3 gets more address space. Moreover, it is 312 again clear that for an ISP with a growing or changing customer base, this 313 mechanism will not scale well. 315 route-set: AS2:RS-ROUTES:AS3 316 members: 7.7.0.0/16^16-19 317 ... 318 changed: orange@ripe.net 319 source: RIPE 321 Figure 7: The route-set object 323 Luckily RPSL supports the notion of a ``route-set'' which, as shown in 324 Figure 7, can be used to specify the set of routes that will be accepted 325 from a given customer. Given this set (and a similar one for AS4), the 326 manager of AS2 can now filter on the address space that will be accepted 327 from their customers by modifying the import lines in the AS2 aut-num object 328 as shown in Figure 8. 330 import: from AS1 accept ANY 331 import: from AS3 accept AS2:RS-ROUTES:AS3 332 import: from AS4 accept AS2:RS-ROUTES:AS4 333 export: to AS2:AS-CUSTOMERS announce ANY 334 export: to AS1 announce AS2 AS2:AS-CUSTOMERS 336 Figure 8: Policy in the AS2 aut-num object for address based filtering on 337 AS2 customers 339 Note that this is now only slightly more complex than the example in 340 Figure 6. Furthermore, nothing need be changed in the AS2 aut-num object 341 due to address space changes for a customer, and this filtering can be 342 supported without any changes to the AS1 aut-num object. The additional 343 complexity is due to the two route set names being different, otherwise we 344 could have combined the two import statements into one. Please note that 345 the set names are constructed hierarchically. The first AS number denotes 346 whose sets these are, and the last AS number parameterize these sets for 347 each peer. RPSL allows the peer's AS number to be replaced by the keyword 348 PeerAS. Hence, 349 import: from AS3 accept AS2:RS-ROUTES:PeerAS 350 import: from AS4 accept AS2:RS-ROUTES:PeerAS 352 has the same meaning as the corresponding import statements in Figure 6. 353 This lets us combine the two import statements into one as shown in 354 Figure 9. 356 import: from AS1 accept ANY 357 import: from AS2:AS-CUSTOMERS accept AS2:RS-ROUTES:PeerAS 358 export: to AS2:AS-CUSTOMERS announce ANY 359 export: to AS1 announce AS2 AS2:AS-CUSTOMERS 361 Figure 9: Policy in the AS2 aut-num object using PeerAS 363 2.3 Including Interfaces in Peering Definitions 365 In the above examples peerings were only given among ASes. However, the 366 peerings may be described in much more detail by RPSL, where peerings can be 367 specified between physical routers using IP addresses in the import and 368 export attributes. Figure 10 shows a simple example in which AS1 and AS2 369 are connected to an exchange point IX. While AS1 has only one connection to 370 the exchange point via a router interface with IP address 7.7.7.1, AS2 has 371 two different connections with IP address 7.7.7.2 and 7.7.7.3. The first AS 372 may then define its routing policy in more detail by specifying its boundary 373 router. 375 aut-num: AS1 376 import: from AS2 at 7.7.7.1 accept <^AS2$> 377 ... 379 +--------------------+ +--------------------+ 380 | 7.7.7.1 |-----+ +-----| 7.7.7.2 | 381 | | | | | | 382 | AS1 | ======== | AS2 | 383 | | IX | | | 384 | | +-----| 7.7.7.3 | 385 +--------------------+ +--------------------+ 387 Figure 10: Including interfaces in peerings definitions 389 Because AS1 has only one connection to the exchange point in this example, 390 this specification does not differ from that in which no boundary router is 391 specified. However, AS1 might want to choose to accept only those 392 announcements from AS2 which come from the router with IP address 7.7.7.2 393 and disregard those announcements from router 7.7.7.3. AS1 can specify this 394 routing policy as follows: 396 aut-num: AS1 397 import: from AS2 7.7.7.2 at 7.7.7.1 accept <^AS2$> 398 ... 400 By selecting certain pairs of routers in a peering specification, others can 401 be denied. If no routers are included in a policy clause then it is assumed 402 that the policy applies to all peerings among the ASes involved. 404 2.4 Describing Simple Backup Connections 406 The specification of peerings among ASes is not limited to one router for 407 each AS. In figure 10 one of the two connections of AS2 to the exchange 408 point IX might be used as backup in case the other connection fails. Let us 409 assume that AS1 wants to use the connection to router 7.7.7.2 of AS2 during 410 regular operations, and router 7.7.7.3 as backup. In a router configuration 411 this may be done by setting a local preference. The equivalent in RPSL is a 412 corresponding action definition in the peering description. The action 413 definitions are inserted directly before the accept keyword. 415 aut-num: AS1 416 import: from AS2 7.7.7.2 at 7.7.7.1 action pref=10; 417 from AS2 7.7.7.3 at 7.7.7.1 action pref=20; 418 accept <^AS2$> 419 ... 421 pref is opposite to local-pref in that the smaller values are preferred over 422 larger values. Actions may also be defined without specifying IP addresses 423 of routers. If no routers are included in the policy clause then it is 424 assumed that the actions are carried out for all peerings among the ASes 425 involved. 427 In the previous example AS1 controls where it sends its traffic and which 428 connection is used as backup. However, AS2 may also define a backup 429 connection in an export clause: 431 aut-num: AS2 432 export: to AS1 7.7.7.1 at 7.7.7.2 action med=10; 433 to AS1 7.7.7.1 at 7.7.7.3 action med=20; 434 announce <^AS2$> 436 The definition given here for AS2 is the symmetric counterpart to the 437 routing policy of AS1. The selection of routing information is done by 438 setting the multi exit discriminator metric med. Actually, med metrics will 439 not be used in practice like this; they are more suitable for load balancing 440 including backups. For more details on med metrics refer to the BGP-4 441 RFC [7]. To use the med to achieve load balancing, one often sets it to the 442 ``IGP metric''. This is specified in RPSL as: 444 aut-num: AS2 445 export: to AS1 action med=igp_cost; announce <^AS2$> 447 Hence, both routers will set the med to the IGP metric at that router, 448 causing some routes to be preferred at one of the routers and other routes 449 at the other router. 451 2.5 Multi-Home Routing Policies using the community Attribute 453 RFC 1998 [9] describes the use of the BGP community attribute to provide 454 support for load balancing and backup connections of multi-homed autonomous 455 systems. In this section, we use stepwise refinement of an example to 456 illustrate how those policies might be specified using RPSL. 458 The basic premise of RFC 1998 is to use the BGP community attribute to allow 459 a customer to configure the BGP ``LOCAL_PREF'' on a provider's routers. 460 This will allow the customer to influence the provider's route selection, 461 normally by lowering the BGP ``LOCAL_PREF'' to indicate backup arrangements. 463 In this example, we illustrate how AS1 (the provider) might specify their 464 policy so that a customer (AS4) connected to two of AS1's direct customers 465 (AS2 and AS3) might signal to AS1 which connection is to be preferred. 467 AS1's base policy is to only accept routes from customers that are 468 originated by the customer, or by the customer's customers. This leads to a 469 policy such as: 471 aut-num: AS1 472 import: from AS2 473 accept (AS2 OR AS4) AND <^AS2+ AS4*$> 474 import: from AS3 475 accept (AS3 OR AS4) AND <^AS3+ AS4*$> 476 import: from AS5 477 accept AS5 AND <^AS5+$> 479 Note that AS4 is a customer of AS2 and AS3, and AS5 does not have its own 480 customers. 482 Now suppose we want to add some policy to describe that if a customer tags a 483 route with community 1:1 then AS1 will act on this to reduce the BGP 484 ``LOCAL_PREF'' by 10. 486 aut-num: AS1 487 import: from AS2 488 action pref=10; 489 accept (AS2 OR AS4) AND <^AS2+ AS4*$> AND community.contains(1:1) 490 import: from AS2 491 action pref=0; 492 accept (AS2 OR AS4) AND <^AS2+ AS4*$> 493 import: from AS3 494 action pref=10; 495 accept (AS3 OR AS4) AND <^AS3+ AS4*$> AND community.contains(1:1) 496 import: from AS3 497 action pref=0; 498 accept (AS3 OR AS4) AND <^AS3+ AS4*$> 499 import: from AS5 500 action pref=10; 501 accept AS5 AND <^AS5+$> AND community.contains(1:1) 502 import: from AS5 503 action pref=0; 504 accept AS5 AND <^AS5+$> 506 We can see here that basically we are adding identical statements for each 507 peering to the policy. This is the ideal candidate for RPSL's refine 508 statement. This will make the policy more concise and avoid some of the 509 potential for errors as more peering statements are added in the future: 511 aut-num: AS1 512 import: { 513 from AS-ANY 514 action pref=10; 515 accept community.contains(1:1); 516 from AS-ANY 517 action pref=0; 518 accept ANY; 519 } refine { 520 from AS2 accept (AS2 OR AS4) AND <^AS2+ AS4*$>; 521 from AS3 accept (AS3 OR AS4) AND <^AS3+ AS4*$>; 522 from AS5 accept AS5 AND <^AS5+$>; 523 } 525 Now, we can clearly see that any route that has been accepted from a 526 customer that contains the community 1:1 will have it's local preference 527 value reduced by 10. 529 The refinement has cleaned up some of the policy but we still have a large 530 number of individual policies representing the same basic provider policy 531 ``from the customer, accept customer routes''. These can be simplified by 532 using AS sets. 534 First, we will collect together all of AS1's customers into a single AS set, 535 AS1:AS-CUSTOMERS. We use a hierarchical set name that start with AS1 to 536 avoid possible set name clashes in IRR with other ASes: 538 as-set: AS1:AS-CUSTOMERS 539 members: AS2, AS3, AS5 541 We also define one set for each customer which lists the AS numbers of any 542 of their customers. 544 as-set: AS1:AS-CUSTOMERS:AS2 545 members: AS4 547 as-set: AS1:AS-CUSTOMERS:AS3 548 members: AS4 550 as-set: AS1:AS-CUSTOMERS:AS5 551 members: # AS5 has no customers yet, so keep blank for now 553 We can now use the keyword PeerAS with these AS sets to simplify the policy 554 further: 556 aut-num: AS1 557 import: { 558 from AS-ANY 559 action pref=10; 560 accept community.contains(1:1); 561 from AS-ANY 562 action pref=0; 563 accept ANY; 564 } refine { 565 from AS1:AS-CUSTOMERS 566 accept (PeerAS OR AS1:AS-CUSTOMER:PeerAS) 567 AND <^PeerAS+ AS1:AS-CUSTOMER:PeerAS*$> 568 } 570 The use of PeerAS with AS1:AS-CUSTOMERS is basically equivalent to looping 571 over the members of AS1:AS-CUSTOMERS, expanding the policy by replacing 572 PeerAS with a member from the set AS1:AS-CUSTOMERS. 574 To illustrate how this policy might be utilised by AS4 , we present the 575 following policy fragment: 577 aut-num: AS4 578 export: to AS2 579 action community.append(1:1); 580 announce AS1 581 export: to AS3 582 announce AS1 584 Here, AS4 is signalling AS1 to prefer the routes from AS3. 586 3 Tools 588 In this section, we briefly introduce a number of tools which can be used to 589 inspect data in the database, to determine optimal routing policies, and 590 enter new data. 592 3.1 The aut-num Object Editor 594 All the examples shown in the previous sections may well be edited by hand. 595 They may be extracted one by one from the IRR using the whois program, 596 edited, and then handed back to the registry robots. However, again the 597 RAToolSet [6] provides a very nice tool which makes working with aut-num 598 objects much easier: the aut-num object editor aoe (please see Figure 11). 600 file=aoe.ps 602 Figure 11: Autonomous System object editor (aoe). 604 The aut-num object editor has a graphical user interface to view and 605 manipulate aut-num objects registered at any IRR. New aut-num objects may be 606 generated using templates and submitted to the registries. Moreover, the 607 routing policy from the databases may be compared to real life peerings. 608 Therefore, aoe is highly recommended as an interface to the IRR for aut-num 609 objects. Further information on aoe is available together with the 610 RAToolSet [6]. 612 3.2 Router Configuration Using RtConfig 614 RtConfig is a tool developed by the Routing Arbiter project [8] to generate 615 vendor specific router configurations from the policy data held in the 616 various IRRs. RtConfig currently supports Cisco, gated and RSd 617 configuration formats. It has been publicly available since late 1994, and 618 is currently being used by many sites for router configuration. The next 619 section describes a methodology for generating vendor specific router 620 configurations using RtConfig.(2) 622 3.3 Using RtConfig 624 The general paradigm for using RtConfig involves registering policy in an 625 IRR, building a RtConfig source file, then running running RtConfig against 626 the source file and the IRR database to create vendor specific router 627 configuration for the specified policy. The source file will contain vendor 628 specific commands as well as RtConfig commands. To make a source file, pick 629 up one of your router configuration files and replace the vendor specific 630 policy configuration commands with the RtConfig commands. 632 Commands beginning with @RtConfig instruct RtConfig to perform special 633 operations. An example source file is shown in Figure 12. In this example, 634 commands such as ``@RtConfig import AS3582 198.32.162.1 AS3701 635 198.32.162.2'' instruct RtConfig to generate vendor specific import policies 636 where the router 198.32.162.1 in AS3582 is importing routes from router 637 198.32.162.2 in AS3701. The other @RtConfig commands instruct the RtConfig 638 to use certain names and numbers in the output that it generates (please 639 refer to RtConfig manual [8] for additional information). 641 Once a source file is created, the file is processed by RtConfig (the 642 default IRR is the RADB, and the default vendor is Cisco; however, command 643 line options can be used to override these values). The result of running 644 RtConfig on the source file in Figure 12 is shown in Figure 21 in 645 Appendix B. 647 A RPSL Database Objects 649 In this appendix, we introduce the RPSL objects required to implement many 650 typical Internet routing policies. RFC-2280 and RIPE-157 provide the 651 authoritative description for these objects and for the RPSL syntax, but 652 this appendix will often be sufficient in practice. 654 ------------------------------ 655 2. Discussion of RtConfig internals is beyond the scope of this document. 657 router bgp 3582 658 network 128.223.0.0 659 ! 660 ! Start with access-list 100 661 ! 662 @RtConfig set cisco_access_list_no = 100 663 ! 664 ! NERO 665 neighbor 198.32.162.2 remote-as 3701 666 @RtConfig set cisco_map_name = "AS3701-EXPORT" 667 @RtConfig export AS3582 198.32.162.1 AS3701 198.32.162.2 668 @RtConfig set cisco_map_name = "AS3701-IMPORT" 669 @RtConfig import AS3582 198.32.162.1 AS3701 198.32.162.2 670 ! 671 ! WNA/VERIO 672 neighbor 198.32.162.6 remote-as 2914 673 @RtConfig set cisco_map_name = "AS2914-EXPORT" 674 @RtConfig export AS3582 198.32.162.1 AS2914 198.32.162.6 675 @RtConfig set cisco_map_name = "AS2914-IMPORT" 676 @RtConfig import AS3582 198.32.162.1 AS2914 198.32.162.6 677 ... 679 Figure 12: RtConfig Template File 681 The frequently needed objects are: 683 o maintainer objects (mntner) 685 o autonomous system number objects (aut-num) 687 o route objects (route) 689 o set objects (as-set, route-set) 691 and they are described in the following sections. To make your routing 692 policies and configuration public, these objects should be registered in 693 exactly one of the IRR registries. 695 In general, you can register your information by sending the appropriate 696 objects to an email address for the registry you use. The email should 697 consist of the objects you want to have registered or modified, separated by 698 empty lines, and preceded by some kind of authentication details (see 699 below). The registry robot processes your mail and enters new objects into 700 the database, deletes old ones (upon request), or makes the requested 701 modifications. 703 You will receive a response indicating the status of your submission. As 704 the emails are handled automatically, the response is generally very fast. 705 However, it should be remembered that a significant number of updates are 706 also sometimes submitted to the database (by other robots), so the response 707 time cannot be guaranteed. The email addresses for submitting objects to 708 the existing registries are listed in Figure 13. 710 ANS auto-dbm@ans.net 711 CANET auto-dbm@canet.net 712 CW auto-rr@cw.net 713 RADB auto-dbm@radb.ra.net 714 RIPE auto-dbm@ripe.net 716 Figure 13: Email addresses to register policy objects in IRR. 718 Because it is required that a maintainer be specified in many of the 719 database objects, a mntner is usually the first to be created. To have it 720 properly authenticated, a mntner object is added manually by registry staff. 721 Thereafter, all database submissions, deletions and modifications should be 722 done through the registry robot. 724 Each of the registries should can provide additional information and support 725 for users. For the public registries this support is available from the 726 email addresses listed in Figure 14. 728 RADB db-admin@radb.ra.net 729 RIPE ripe-dbm@ripe.net 731 Figure 14: Support email addresses. 733 If you are using one of the private registries, your service provider should 734 be able to address your questions. 736 A.1 The Maintainer Object 738 The maintainer object is used to introduce some kind of authorization for 739 registrations. It lists various contact persons and describes security 740 mechanisms that will be applied when updating objects in the IRR. 741 Registering a mntner object is the first step in creating policies for an 742 AS. An example is shown in Figure 15. The maintainer is called 743 MAINT-AS3701. The contact person here is the same for administrative 744 (admin-c) and technical (tech-c) issues and is referenced by the NIC-handle 745 DMM65. NIC-handles are unique identifiers for persons in registries. Refer 746 to registry documentation for further details on person objects and usage of 747 NIC-handles. 749 The example shows two authentication mechanisms: CRYPT-PW and MAIL-FROM. 750 CRYPT-PW takes as its argument a password that is encrypted with Unix 751 crypt(3) routine. When sending updates, the maintainer adds the field 752 password: to the beginning of any requests that are to 753 be authenticated. MAIL-FROM takes an argument that is a regular expression 754 which covers a set of mail addresses. Only users with any of these mail 755 addresses are authorized to work with objects secured by the corresponding 756 maintainer(3). 758 The security mechanisms of the mntner object will only be applied on those 759 objects referencing a specific mntner object. The reference is done by 760 adding the attribute mnt-by to an object using the name of the mntner object 761 as its value. In Figure 15, the maintainer MAINT-AS3701 is maintained by 762 itself. 764 mntner: MAINT-AS3701 765 descr: Network for Research and Engineering in Oregon 766 remark: Internal Backbone 767 admin-c: DMM65 768 tech-c: DMM65 769 upd-to: noc@nero.net 770 auth: CRYPT-PW 949WK1mirBy6c 771 auth: MAIL-FROM .*@nero.net 772 notify: noc@nero.net 773 mnt-by: MAINT-AS3701 774 changed: meyer@antc.uoregon.edu 970318 775 source: RADB 777 Figure 15: Maintainer Object 779 A.2 The Autonomous System Object 781 The autonomous system object describes the import and export policies of an 782 AS. Each organization registers an autonomous system object (aut-num) in the 783 IRR for its AS. Figure 16 shows the aut-num for AS3582 (UONET). 785 The autonomous system object lists contacts (admin-c, tech-c) and is 786 maintained by (mnt-by) MAINT-AS3701 which is the maintainer displayed in 787 Figure 15. 789 ------------------------------ 790 3. Clearly, neither of these mechanisms is sufficient to provide 791 strong authentication or authorization. Other public key (e.g., PGP) 792 authentication mechanisms are available from some of the IRRs. 794 The most important attributes of the aut-num object are import and export. 795 The import clause of an aut-num specifies import policies, while the export 796 clause specifies export policies. The corresponding clauses allow a very 797 detailed description of the routing policy of the AS specified. The details 798 are given in section 2. 800 With these clauses, an aut-num object shows its relationship to other 801 autonomous systems by describing its peerings. In addition, it also defines 802 a routing entity comprising a group of IP networks which are handled 803 according to the rules defined in the aut-num object. Therefore, it is 804 closely linked to route objects. 806 In this example, AS3582 imports all routes from AS3701 by using the keyword 807 ANY. AS3582 imports only internal routes from AS4222, AS5650, and AS1798. 808 The import policy for for AS2914 is slightly more complex. Since AS2914 809 provides transit to various other ASes, AS3582 accepts routes with ASPATHs 810 that begin with AS2194 followed by members of AS-WNA, which is an as set 811 (see section A.4.1 below) describing those customers that transit AS2914. 813 Since AS3582 is a multi-homed stub AS (i.e., it does not provide transit), 814 its export policy consists simply of ``announce AS3582'' clauses; that is, 815 announce internal routes of AS3582. These routes are those in route objects 816 where the origin attribute is AS3582. 818 aut-num: AS3582 819 as-name: UONET 820 descr: University of Oregon, Eugene OR 821 import: from AS3701 accept ANY 822 import: from AS4222 accept <^AS4222$> 823 import: from AS5650 accept <^AS5650$> 824 import: from AS2914 accept <^AS2914+ (AS-WNA)*$> 825 import: from AS1798 accept <^AS1798$> 826 export: to AS3701 announce AS3582 827 export: to AS4222 announce AS3582 828 export: to AS5650 announce AS3582 829 export: to AS2914 announce AS3582 830 export: to AS1798 announce AS3582 831 admin-c: DMM65 832 tech-c: DMM65 833 notify: nethelp@ns.uoregon.edu 834 mnt-by: MAINT-AS3582 835 changed: meyer@antc.uoregon.edu 970316 836 source: RADB 838 Figure 16: Autonomous System Object 840 The aut-num object forms the basis of a scalable and maintainable router 841 route: 128.223.0.0/16 842 origin: AS3582 843 descr: UONet 844 descr: University of Oregon 845 descr: Computing Center 846 descr: Eugene, OR 97403-1212 847 descr: USA 848 mnt-by: MAINT-AS3582 849 changed: meyer@ns.uoregon.edu 960222 850 source: RADB 852 Figure 17: Example of a route object 854 configuration system. For example, if AS3582 originates a new route, it 855 need only create a route object for that route with origin AS3582. AS3582 856 can now build configuration using this route object without changing its 857 aut-num object. 859 Similarly, if for example, AS3701 originates a new route, it need only 860 create a route object for that route with origin AS3701. Both AS3701 and 861 AS3582 can now build configuration using this route object without modifying 862 its aut-num object. 864 A.3 The Route Object 866 In contrast to aut-num objects which describe propagation of routing 867 information for an autonomous system as a whole, route objects define single 868 routes from an AS. An example is given in Figure 17. 870 This route object is maintained by MAINT-AS3582 and references AS3582 by the 871 origin attribute. By this reference it is grouped together with other 872 routes of the same origin AS, becoming member of the routing entity denoted 873 by AS3582. The routing policies can then be defined in the aut-num objects 874 for this group of routes. 876 Consequently, the route objects give the routes from this AS which are 877 distributed to peer ASes according to the rules of the routing policy. 878 Therefore, for any route in the routing tables of the backbone routers a 879 route object must exist in one of the registries in IRR. route objects must 880 be registered in the IRR only for the routes seen outside your AS. Normally, 881 this set of external routes is different from the routes internally visible 882 within your AS. One of the major reasons is that external peers need no 883 information at all about your internal routing specifics. Therefore, 884 external routes are in general aggregated combinations of internal routes, 885 having shorter IP prefixes where applicable according to the CIDR rules. 886 Please see the CIDR FAQ [5] for a tutorial introduction to CIDR. It is 887 strongly recommended that you aggregate your routes as much as possible, 888 thereby minimizing the number of routes you inject into the global routing 889 table and at the same time reducing the corresponding number of route 890 objects in the IRR. 892 While you may easily query single route objects using the whois program, and 893 submit objects via mail to the registry robots, this becomes kind of awkward 894 for larger sets. The RAToolSet [6] offers several tools to make handling of 895 route objects easier. If you want to read policy data from the IRR and 896 process it by other programs, you might be interested in using peval which 897 is a low level policy evaluation tool. As an example, the command 899 peval -h radb.ra.net AS3582 901 will give you all route objects from AS3582 registered with RADB. 903 A much more sophisticated tool from the RAToolSet to handle route objects 904 interactively is the route object editor roe (please see Figure 18). It has 905 a graphical user interface to view and manipulate route objects registered 906 at any IRR. New route objects may be generated from templates and submitted 907 to the registries. Moreover, the route objects from the databases may be 908 compared to real life routes. Therefore, roe is highly recommended as an 909 interface to the IRR for route objects. Further information on peval and 910 roe is available together with the RAToolSet [6]. 912 file=roe.ps 914 Figure 18: route object editor (roe). 916 A.4 Set Objects 918 With routing policies it is often necessary to reference groups of 919 autonomous systems or routes which have identical properties regarding a 920 specific policy. To make working with such groups easier RPSL allows to 921 combine them in set objects. There are two basic types of predefined set 922 objects, as-set, and route-set. The RPSL set objects are described below. 924 A.4.1 AS-SET Object 926 Autonomous system set objects (as-set) are used to group autonomous system 927 objects into named sets. An as-set has an RPSL name that starts with 928 ``AS-''. In the example in Figure 19, an as-set called AS-NERO-PARTNERS and 929 containing AS3701, AS4201, AS3582, AS4222, AS1798 is defined. The as-set is 930 the RPSL replacement for the RIPE-181 as-macro. It has been extended to 931 include ASes in the set indirectly by referencing as set names in the 932 aut-num objects. 934 AS-SETs are particularly useful when specifying policies for groups such as 935 customers, providers, or for transit. You are encouraged to register sets 936 for these groups because it is most likely that you will treat them alike, 937 i.e. you will have a very similar routing policy for all your customers 938 which have an autonomous system of their own. You may as well discover that 939 this is also true for the providers you are peering with, and it is most 940 convenient to have the ASes combined in one as-set for which you offer 941 transit. For example, if a transit provider specifies its import policy 942 using its customer's as-set (i.e., its import clause for the customer 943 contains the customer's as-set), then that customer can modify the set of 944 ASes that its transit provider accepts from it. Again, this can be 945 accomplished without requiring the customer or the transit provider to 946 modify its aut-num object. 948 as-set: AS3582:AS-PARTNERS 949 members: AS3701, AS4201, AS3582, AS4222, AS1798 951 Figure 19: as-set Object 953 The ASes of the set are simply compiled in a comma delimited list following 954 the members attribute of the as-set. This list may also contain other 955 AS-SET names. 957 A.4.2 ROUTE-SET Object 959 A route-set is a way to name a group of routes. The syntax is similar to 960 the as-set. A route-set has an RPSL name that starts with ``RS-''. The 961 members attribute lists the members of the set. The value of a members 962 attribute is a list of address prefixes, or route-set names. The members of 963 the route-set are the address prefixes or the names of other route sets 964 specified. 966 Figure 20 presents some example route-set objects. The set rs-uo contains 967 two address prefixes, namely 128.223.0.0/16 and 198.32.162.0/24. The set 968 rs-bar contains the members of the set rs-uo and the address prefix 969 128.7.0.0/16. The set rs-martians illustrate the use of range operators. 970 0.0.0.0/0^32 are the length 32 more specifics of 0.0.0.0/0, i.e. the host 971 routes; 224.0.0.0/3^+ are the more specifics of 224.0.0.0/3, i.e. the routes 972 falling into the multicast address space. For more complete list of range 973 operators please refer to RFC-2280. 975 route-set: rs-uo 976 members: 128.223.0.0/16, 198.32.162.0/24 978 route-set: rs-bar 979 members: 128.7.0.0/16, rs-uo 981 route-set: rs-martians 982 remarks: routes not accepted from any peer 983 members: 0.0.0.0/0, # default route 984 0.0.0.0/0^32, # host routes 985 224.0.0.0/3^+, # multicast routes 986 127.0.0.0/8^9-32, . . . 988 Figure 20: route-set Objects 990 B Output of RtConfig: An Example 992 In Figure 21, you see the result of running RtConfig on the source file in 993 Figure 12. 995 References 997 [1] C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, M. 998 Terpstra, and C. Villamizer: Routing Policy Specification Language 999 (RPSL), RFC 2280. 1001 [2] T. Bates, J-M. Jouanigot, D. Karrenberg, P. Lothberg, and M. Terpstra. 1002 Representation of IP Routing Policies in the RIPE database, Technical 1003 Report ripe-81, RIPE, RIPE NCC, Amsterdam, Netherlands, February 1993. 1005 [3] T. Bates, E. Gerich, J. Joncharay, J-M. Jouanigot, D. Karrenberg, M. 1006 Terpstra, and J. Yu. Representation of IP Routing Policies in a 1007 Routing Registry, Technical Report ripe-181, RIPE, RIPE NCC, 1008 Amsterdam, Netherlands, October 1994. 1010 [4] A. M. R. Magee. RIPE NCC Database Documentation. Technical Report 1011 RIPE-157, RIPE NCC, Amsterdam, Netherlands, May 1997. 1013 [5] Hank Nussbacher. The CIDR FAQ. Tel Aviv University and IBM Israel. 1014 http://www.ibm.net.il/~hank/cidr.html 1016 [6] The RAToolSet. http://www.ra.net/ra/RAToolSet/ 1018 [7] Y. Rekhter adn T. Li. A Border Gateway Protocol 4 (BGP-4). Request for 1019 Comment RFC 1654. Network Information Center, July 1994. 1021 [8] RtConfig as part of the RAToolSet. 1022 http://www.ra.net/ra/RAToolSet/RtConfig.html 1024 [9] E. Chen, T. Bates. An Application of the BGP Community Attribute in 1025 Multi-Home Routing. RFC 1998. 1027 router bgp 3582 1028 network 128.223.0.0 1029 ! 1030 ! NERO 1031 neighbor 198.32.162.2 remote-as 3701 1033 no access-list 100 1034 access-list 100 permit ip 128.223.0.0 0.0.0.0 255.255.0.0 0.0.0.0 1035 access-list 100 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 1036 ! 1037 no route-map AS3701-EXPORT 1038 route-map AS3701-EXPORT permit 1 1039 match ip address 100 1040 ! 1041 router bgp 3582 1042 neighbor 198.32.162.2 route-map AS3701-EXPORT out 1043 ! 1044 no route-map AS3701-IMPORT 1045 route-map AS3701-IMPORT permit 1 1046 set local-preference 1000 1047 ! 1048 router bgp 3582 1049 neighbor 198.32.162.2 route-map AS3701-IMPORT in 1050 ! 1051 ! WNA/VERIO 1052 neighbor 198.32.162.6 remote-as 2914 1053 ! 1054 no route-map AS2914-EXPORT 1055 route-map AS2914-EXPORT permit 1 1056 match ip address 100 1057 ! 1058 router bgp 3582 1059 neighbor 198.32.162.6 route-map AS2914-EXPORT out 1060 no ip as-path access-list 100 1061 ip as-path access-list 100 permit ^_2914(((_[0-9]+))*_ \ 1062 (13|22|97|132|175|668|1914|2905|2914|3361|3381|3791|3937| \ 1063 4178|4354|4571|4674|4683|5091|5303|5798|5855|5856|5881|6083 \ 1064 |6188|6971|7790|7951|8028))?$ 1065 ! 1066 no route-map AS2914-IMPORT 1067 route-map AS2914-IMPORT permit 1 1068 match as-path 100 1069 set local-preference 998 1070 ! 1071 router bgp 3582 1072 neighbor 198.32.162.6 route-map AS2914-IMPORT in 1074 Figure 21: Output of RtConfig