idnits 2.17.1 draft-ietf-rps-appl-rpsl-01.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-23) 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. ** 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. ** 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 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 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 271 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 360 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 31 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance 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: ---------------------------------------------------------------------------- == Line 17 has weird spacing: '...tribute worki...' == Line 22 has weird spacing: '...e. It is no...' == Line 23 has weird spacing: '...to cite them ...' == Line 26 has weird spacing: '...e check the I...' == Line 31 has weird spacing: '...ocument is a...' == (266 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 (July 29, 1997) is 9765 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-03) exists of draft-ietf-rps-rpsl-00 -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 1786 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 1998 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 1771 (ref. '9') (Obsoleted by RFC 4271) Summary: 17 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft David Meyer 3 Expires January 29, 1998 University of Oregon 4 draft-ietf-rps-appl-rpsl-01.txt Joachim Schmitz 5 DFN-NOC 6 Cengiz Alaettinoglu 7 USC/ISI 8 July 29, 1997 10 Application of Routing Policy Specification Language (RPSL) on the Internet 12 Status of this Memo 14 This document is an Internet Draft, and can be found as draft-ietf-rps-appl- 15 rpsl-01.txt in any standard internet drafts repository. Internet Drafts are 16 working documents of the Internet Engineering Task Force (IETF), its Areas, 17 and its Working Groups. Note that other groups may also distribute working 18 documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six months. 21 Internet Drafts may be updated, replaced, or obsoleted by other documents 22 at any time. It is not appropriate to use Internet Drafts as reference 23 material, or to cite them other than as a ``working draft'' or ``work in 24 progress.'' 26 Please check the I-D abstract listing contained in each Internet Draft 27 directory to learn the current status of this or any other Internet Draft. 29 1 Introduction 31 This document is a tutorial on using the Routing Policy Specification 32 Language (RPSL) to specify routing policies. It covers specifying routing 33 policies using RPSL, registering these policies in the Internet Routing 34 Registry (IRR), and analysing them using the routing policy analysis tools, 35 for example to generate vendor specific router configurations. This 36 document is targeted towards an Internet/Network Service Provider (ISP/NSP) 37 engineer who is new to RPSL and to IRR. Readers are referred to the RPSL 38 reference document [3] for completeness. We recommend reading this document 39 before reading the reference document. We hope that for many cases, this 40 document will be sufficient. 42 IRR is a repository of routing policies. It currently consists of five 43 sites: CA*Net registry in Canada, ANS, MCI and RADB registries in the 44 United States of America, and RIPE registry in Europe. Each of these 45 sites run independent of each other. However, each site exchanges its 46 data with each other at some frequency (at least once a day or as often as 47 every ten minutes). MCI, Ca*Net and ANS are private registries and contain 48 routing policies of MCI, Ca*Net, ANS, and their customers respectively. 49 RADB and RIPE are public registries, and any ISP can publish their policies 50 in these registries. Since registries exchange their data regularly, you 51 need to register your policies in only one of them. If you are an 52 MCI, ANS or CA*Net customer, we recommend you register your policies with 53 them. Otherwise, you may register your policies either at the RIPE or RADB 54 registry, whichever is closer to you. We recommend against registering in 55 multiple registries since it often eventually leads to inconsistent data 56 between the registries. 58 Routing policies registered in IRR are specified using RPSL. RPSL is based 59 on an earlier language known as RIPE-181 [4, 5]. Through operational use of 60 RIPE-181 it has become apparent that certain policies cannot be specified 61 and a need for an enhanced and more general language is needed. RPSL 62 addresses RIPE-181's limitations. RPSL obsoletes RIPE-181 [4, 5]. 64 RPSL is object oriented; that is, objects contain pieces of policy and 65 administrative information. For example, each address prefix routed in the 66 inter-domain mesh is specified in a route object and policies of each AS are 67 specified in an aut-num object. Objects have relations between each other. 68 For example, all route objects of an ISP refer to the aut-num object of the 69 ISP. These relations form sets of objects, we can then use these sets to 70 specify policies collectively to all their members. For example, we can 71 specify policy against all routes of an ISP, by refering to the AS number of 72 the ISP. In the following sections, we will describe each of these objects 73 (rather object classes) in more detail and give numerous examples for you to 74 create your own objects. In most cases, you should be able to cut and paste 75 our examples to create your own objects. 77 Once you register your policies in IRR, they are available for others to 78 query using a whois service. Figure 1 illustrates the use of the whois 79 command to obtain the route object for 128.223.0.0/16. The output of the 80 whois command is the ASCII representation of the route object. We will 81 describe the details of the route object in Section 2.3. 83 That is not all, once you register your policies in IRR, they can be 84 analyzed for consistency or used to diagnose Internet's operational routing 85 problems. RAToolSet [1] is a suite of tools for analyzing this data. 86 It contains tools (RtConfig) to configure routers, tools (prpath and 87 prtraceroute) to analyse paths on the Internet, tools (roe, aoe and prcheck) 88 to compare, validate and register RPSL objects, and others. 90 The remainder of this document is organized as follows: Section 2 91 introduces the fundamental RPSL objects. Section 3 discusses implementation 92 of various common policies using RPSL. Finally, Section 4 describes the use 93 of RtConfig to generate vendor specific router configurations. 95 % whois -h radb.ra.net 128.223.0.0/16 96 route: 128.223.0.0/16 97 descr: UONet 98 descr: University of Oregon 99 descr: Computing Center 100 descr: Eugene, OR 97403-1212 101 descr: USA 102 origin: AS3582 103 mnt-by: MAINT-AS3582 104 changed: meyer@ns.uoregon.edu 19960222 105 source: RADB 107 Figure 1: whois command and a route object. 109 2 RPSL Objects 111 This section introduces the fundamental RPSL objects required to implement 112 many typical Internet routing policies. The basic elements are: 114 o maintainer objects (mntner) 116 o autonomous system number objects (aut-num) 118 o route objects (route) 120 o set objects (as-set, route-set) 122 and they are described in the following sections. These objects must be 123 registered in the IRR, in only one of the existing registries. In general, 124 registration is done by sending electronic mail to a registry robot. The 125 email addresses for existing registries are listed in Figure 2. The 126 contents of the mail consists of the objects you want to have registered, 127 separated by empty lines, and often some kind of authorization (see below). 128 The registry robot automatically processes your mail, entering new objects 129 into the database, deleting old ones, or activating changes. Moreover, it 130 may send notifications and replies with an error or success report about its 131 actions. The first object which has to be registered, normally is the 132 mntner. In general, to have it properly authenticated, a maintainer object 133 is added manually by registry staff. Afterwards, all other actions should 134 be done through the registry robot. Each registry provides documentation on 135 how to use it. If problems arise your registry staff is willing to assist 136 you. 138 ANS auto-dbm@ans.net 139 CANET auto-dbm@canet.net 140 MCI auto-rr@mci.net 141 RADB auto-dbm@radb.ra.net 142 RIPE auto-dbm@ripe.net 144 Figure 2: Registry email addresses to register policy objects in IRR. 146 2.1 The Maintainer Object 148 The maintainer object is used to introduce some kind of authorization 149 for registrations. It lists various contact persons and describes 150 security mechanisms that will be applied when updating objects in the 151 IRR. Registering a mntner object is the first step in creating policies 152 for an AS. An example is shown in Figure 3. The maintainer is called 153 MAINT-AS3701. The contact person here is the same for administrative 154 (admin-c) and technical (tech-c) issues and is referenced by the NIC-handle 155 DMM65. NIC-handles are unique identifiers for persons in registries. Refer 156 to registry documentation for further details on person objects and usage of 157 NIC-handles. 159 The example shows two authentication mechanisms: CRYPT-PW and MAIL-FROM. 160 CRYPT-PW takes as its argument a password that is encrypted with Unix 161 crypt(3) routine. When sending updates, the maintainer adds the field 162 password: to the beginning of any requests that are to 163 be authenticated. MAIL-FROM takes an argument that is a regular expression 164 which covers a set of mail addresses. Only users with any of these mail 165 addresses are authorized to work with objects secured by the corresponding 166 maintainer(1). 168 The security mechanisms of the mntner object will only be applied on those 169 objects referencing a specific mntner object. The reference is done by 170 adding the attribute mnt-by to an object using the name of the mntner object 171 as its value. In Figure 3, the maintainer MAINT-AS3701 is maintained by 172 itself. 174 2.2 The Autonomous System Object 176 The autonomous system object describes the import and export policies of an 177 AS. Each organization registers an autonomous system object (aut-num) in the 178 ------------------------------ 179 1. Clearly, neither of these mechanisms is sufficient to provide 180 strong authentication or authorization. Other public key (e.g., PGP) 181 authentication mechanisms are available from some of the IRRs. 183 mntner: MAINT-AS3701 184 descr: Network for Research and Engineering in Oregon 185 remark: Internal Backbone 186 admin-c: DMM65 187 tech-c: DMM65 188 upd-to: noc@nero.net 189 auth: CRYPT-PW 949WK1mirBy6c 190 auth: MAIL-FROM .*@nero.net 191 notify: noc@nero.net 192 mnt-by: MAINT-AS3701 193 changed: meyer@antc.uoregon.edu 970318 194 source: RADB 196 Figure 3: Maintainer Object 198 IRR for its AS. Figure 4 shows the aut-num for AS3582 (UONET). 200 The autonomous system object lists contacts (admin-c, tech-c) and is 201 maintained by (mnt-by) MAINT-AS3701 which is the maintainer displayed in 202 Figure 3. 204 The most important attributes of the aut-num object are import and export. 205 The import clause of an aut-num specifies import policies, while the export 206 clause specifies export policies. The corresponding clauses allow a very 207 detailed description of the routing policy of the AS specified. The details 208 are given in section 3. 210 With these clauses, an aut-num object shows its relationship to other 211 autonomous systems by describing its peerings. In addition, it also defines 212 a routing entity comprising a group of IP networks which are handled 213 according to the rules defined in the aut-num object. Therefore, it is 214 closely linked to route objects. 216 In this example, AS3582 imports all routes from AS3701 by using the keyword 217 ANY. AS3582 imports only internal routes from AS4222, AS5650, and AS1798. 218 The import policy for for AS2914 is slightly more complex. Since AS2914 219 provides transit to various other ASes, AS3582 accepts routes with ASPATHs 220 that begin with AS2194 followed by members of AS-WNA, which is an as set 221 (see section 2.4.1 below) describing those customers that transit AS2914. 223 Since AS3582 is a multi-homed stub AS (i.e., it does not provide transit), 224 its export policy consists simply of ``announce AS3582'' clauses; that is, 225 announce internal routes of AS3582. These routes are those in route objects 226 where the origin attribute is AS3582. 228 The aut-num object forms the basis of a scalable and maintainable router 229 aut-num: AS3582 230 as-name: UONET 231 descr: University of Oregon, Eugene OR 232 import: from AS3701 accept ANY 233 import: from AS4222 accept <^AS4222$> 234 import: from AS5650 accept <^AS5650$> 235 import: from AS2914 accept <^AS2914+ (AS-WNA)*$> 236 import: from AS1798 accept <^AS1798$> 237 export: to AS3701 announce AS3582 238 export: to AS4222 announce AS3582 239 export: to AS5650 announce AS3582 240 export: to AS2914 announce AS3582 241 export: to AS1798 announce AS3582 242 admin-c: DMM65 243 tech-c: DMM65 244 notify: nethelp@ns.uoregon.edu 245 mnt-by: MAINT-AS3582 246 changed: meyer@antc.uoregon.edu 970316 247 source: RADB 249 Figure 4: Autonomous System Object 251 configuration system. For example, if AS3582 originates a new route, it 252 need only create a route object for that route with origin AS3582. AS3582 253 can now build configuration using this route object without changing its 254 aut-num object. 256 Similarly, if for example, AS3701 originates a new route, it need only 257 create a route object for that route with origin AS3701. Both AS3701 and 258 AS3582 can now build configuration using this route object without modifying 259 its aut-num object. 261 2.3 The Route Object 263 In contrast to aut-num objects which describe propagation of routing 264 information for an autonomous system as a whole, route objects define single 265 routes from an AS. An example is given in Figure 5. 267 This route object is maintained by MAINT-AS3582 and references AS3582 by 268 the origin attribute. By this reference it is grouped together with other 269 routes of the same origin AS, becoming member of the routing entity denoted 270 by AS3582. The routing policies can then be defined in the aut-num objects 271 for this group of routes. 273 route: 128.223.0.0/16 274 descr: UONet 275 descr: University of Oregon 276 descr: Computing Center 277 descr: Eugene, OR 97403-1212 278 descr: USA 279 origin: AS3582 280 mnt-by: MAINT-AS3582 281 changed: meyer@ns.uoregon.edu 960222 282 source: RADB 284 Figure 5: Example of a route object 286 Consequently, the route objects give the routes from this AS which are 287 distributed to peer ASes according to the rules of the routing policy. 288 Therefore, for any route in the routing tables of the backbone routers a 289 route object must exist in one of the registries in IRR. route objects must 290 be registered in the IRR only for the routes seen outside your AS. Normally, 291 this set of external routes is different from the routes internally visible 292 within your AS. One of the major reasons is that external peers need no 293 information at all about your internal routing specifics. Therefore, 294 external routes are in general aggregated combinations of internal routes, 295 having shorter IP prefixes where applicable according to the CIDR rules. 296 Please see the CIDR FAQ [8] for a tutorial introduction to CIDR. It is 297 strongly recommended that you aggregate your routes as much as possible, 298 thereby minimizing the number of routes you inject into the global routing 299 table and at the same time reducing the corresponding number of route 300 objects in the IRR. 302 While you may easily query single route objects using the whois program, and 303 submit objects via mail to the registry robots, this becomes kind of awkward 304 for larger sets. The RAToolSet [1] offers several tools to make handling of 305 route objects easier. If you want to read policy data from the IRR and 306 process it by other programs, you might be interested in using peval which 307 is a low level policy evaluation tool. As an example, the command 309 peval -h radb.ra.net -expand_all AS3582 311 will give you all route objects from AS3582 registered with RADB. 313 A much more sophisticated tool from the RAToolSet to handle route objects 314 interactively is the route object editor roe (please see Figure 6). It has 315 a graphical user interface to view and manipulate route objects registered 316 at any IRR. New route objects may be generated from templates and submitted 317 to the registries. Moreover, the route objects from the databases may be 318 compared to real life routes. Therefore, roe is highly recommended as an 319 interface to the IRR for route objects. Further information on peval and 320 roe is available together with the RAToolSet [1]. 322 Figure 6: route object editor (roe). 324 2.4 Set Objects 326 With routing policies it is often necessary to reference groups of 327 autonomous systems or routes which have identical properties regarding a 328 specific policy. To make working with such groups easier RPSL allows to 329 combine them in set objects. There are two basic types of predefined set 330 objects, as-set, and route-set. The RPSL set objects are described below. 332 2.4.1 AS-SET Object 334 Autonomous system set objects (as-set) are used to group autonomous system 335 objects into named sets. An as-set has an RPSL name that starts with 336 ``AS-''. In the example in Figure 7, an as-set called AS-NERO-PARTNERS and 337 containing AS3701, AS4201, AS3582, AS4222, AS1798 is defined. The as-set 338 is the RPSL replacement for the RIPE-181 as-macro. It has been extended 339 to include ASes in the set indirectly by referencing as set names in the 340 aut-num objects. 342 AS-SETs are particularly useful when specifying policies for groups such 343 as customers, providers, or for transit. You are encouraged to register 344 sets for these groups because it is most likely that you will treat them 345 alike, i.e. you will have a very similar routing policy for all your 346 customers which have an autonomous system of their own. You may as well 347 discover that this is also true for the providers you are peering with, 348 and it is most convenient to have the ASes combined in one as-set for 349 which you offer transit. For example, if a transit provider specifies its 350 import policy using its customer's as-set (i.e., its import clause for the 351 customer contains the customer's as-set), then that customer can modify the 352 set of ASes that its transit provider accepts from it. Again, this can 353 be accomplished without requiring the customer or the transit provider to 354 modify its aut-num object. 356 as-set: AS3582:AS-PARTNERS 357 members: AS3701, AS4201, AS3582, AS4222, AS1798 359 Figure 7: as-set Object 361 The ASes of the set are simply compiled in a comma delimited list following 362 the members attribute of the as-set. This list may also contain other 363 AS-SETs. 365 2.4.2 ROUTE-SET Object 367 A route-set is a way to name a group of routes. The syntax is similar to 368 the as-set. A route-set has an RPSL name that starts with ``RS-''. The 369 members attribute lists the members of the set. The value of a members 370 attribute is a list of address prefixes, or route-set names. The members 371 of the route-set are the address prefixes or the names of other route sets 372 specified. 374 Figure 8 presents some example route-set objects. The set rs-uo contains 375 two address prefixes, namely 128.223.0.0/16 and 198.32.162.0/24. The 376 set rs-bar contains the members of the set rs-uo and the address prefix 377 128.7.0.0/16. 379 route-set: rs-uo 380 members: 128.223.0.0/16, 198.32.162.0/24 382 route-set: rs-bar 383 members: 128.7.0.0/16, rs-uo 385 route-set: AS3582:RS-MARTIANS 386 remarks: routes not accepted from any peer 387 members: 0.0.0.0/0, # default route 388 0.0.0.0/0^32, # host routes 389 224.0.0.0/3^4-32, # multicast routes 390 127.0.0.0/8^9-32, . . . 392 Figure 8: route-set Objects 394 3 Specifying Policies using RPSL 396 In this section we show how the various RPSL objects can be used to specify 397 typical Internet policies. 399 3.1 Provider-Customer Policies 401 In typical customer-provider relationships, the customer imports all the 402 routes that the provider has and exports its routes to the provider. The 403 provider's policies are symmetrical in the sense that it exports all routes 404 that it has to the customer, and it imports only the customers routes. 405 Figure 9 illustrates one way of expressing these policies using RPSL where 406 AS3701 is the provider and AS3582 is the customer. Refer to Figure 4 for 407 AS3582's aut-num. 409 In this example, ``announce ANY'' means export any route that AS3701 has 410 in its routing table, and ``accept <^AS3582$>'' means accept only AS3582's 411 routes (i.e., that have AS-PATHs of length one, where the AS in the path 412 is AS3582)(2). Note that AS3582 is taking full routing from AS3701; this 413 can be seen in that AS3701 is announcing ``ANY'', and AS3582 is accepting 414 ``ANY''. The important point in this example is that if AS3582 adds or 415 deletes route objects, there is no need to update the aut-num objects. The 416 added (or deleted) objects will implicitly update AS3582's and AS3701's 417 policies, and thus affect their router configuration files. 419 As mentioned above, if the customer is itself a provider, i.e. it has 421 ------------------------------ 422 2. AS-PATH regular expressions are POSIX compliant regular expressions, 423 see section 3.3. 425 aut-num: AS3701 426 as-name: NERO-NET 427 descr: Network for Engineering and Research in Oregon 428 ... 429 import: from AS3582 accept <^AS3582$> 430 export: to AS3582 announce ANY 431 ... 432 admin-c: DMM65 433 tech-c: DMM65 434 notify: noc@nero.net 435 mnt-by: MAINT-AS3701 436 changed: meyer@antc.uoregon.edu 970316 437 source: RADB 439 Figure 9: Provider-Customer Policies in RPSL 441 its own customers, the set of routes passed to the provider includes its 442 customers' routes as illustrated in Figure 10. In this example, ``accept 443 AS3582:AS-PARTNERS'' means that for each AS X in the set defined by 444 AS3582:AS-PARTNERS accept AS X's routes. 446 aut-num: AS4600 447 as-name: NERO-TRANSIT 448 descr: Network for Engineering and Research in Oregon 449 ... 450 import: from AS3701 accept <^A3701+ (AS3582:AS-PARTNERS)*$> 451 export: to AS3701 announce ANY 452 ... 453 admin-c: DMM65 454 tech-c: DMM65 455 notify: noc@nero.net 456 mnt-by: MAINT-AS4600 457 changed: meyer@antc.uoregon.edu 970316 458 source: RADB 460 Figure 10: Provider-Customer Policies in RPSL 462 In this case shown in Figure 10, if AS3701 gets a new customer, then it can 463 update the definition of the AS3582:AS-PARTNERS set to include the new AS. 464 The policies specified in the aut-num objects for AS4600 and AS3701 do not 465 change. 467 3.2 Inter-Provider Policies 469 In this case, the policies of both providers are to export only their 470 customer routes to the other provider, and to import only the customer 471 routes of the other provider. This is commonly referred to as peerage. 472 Figure 11 illustrates how this is expressed using RPSL where both AS3701 473 and AS2914 are providers. In this example, AS3701 advertises only the AS 474 paths described by the AS-SET AS3582:AS-PARTNERS (i.e., customer routes). 475 Likewise, we filter routes that come from AS2914, accepting only those 476 defined by the filter ``<^AS2914+ (AS-WNA)*\$>'', i.e., those routes whose 477 AS-PATH attribute ends with an AS in the set defined by the AS-WNA AS-SET. 479 aut-num: AS3701 480 as-name: NERO-NET 481 descr: Network for Engineering and Research in Oregon 482 ... 483 import: from AS2914 accept <^AS2914+ (AS-WNA)*$> 484 export: to AS2914 announce AS3582:AS-PARTNERS 485 ... 486 admin-c: DMM65 487 tech-c: DMM65 488 notify: noc@nero.net 489 mnt-by: MAINT-AS3701 490 changed: meyer@antc.uoregon.edu 970316 491 source: RADB 493 Figure 11: Inter-Provider Policies in RPSL 495 3.3 AS Path Based Policies 497 Our routing policy examples have used AS path expressions in them to 498 describe the routes accepted from or announced to peering partners. these 499 expressions do not only cover the ASes themselves but also the interdomain 500 topology between them. This is achieved by a mechanism known as regular 501 expressions. Those familiar with the UNIX world or with programming 502 languages like C or perl will most likely already understood the details of 503 the AS-PATHS displayed in the examples. RPSL uses POSIX compliant regular 504 expressions over AS numbers. In this section, we briefly describe their 505 use. 507 Regular expressions follow certain rules. Several characters have special 508 meanings, e.g. ``^'' denotes the beginning of a string, ``$'' its end. 509 Then it becomes obvious that the AS-PATH <^AS3582$> accepted from AS3582 in 510 figure 10 has length one and consists of AS3582 only. 512 Besides these positional indicators there are also operators, e.g. the 513 +--------------------+ +--------------------+ 514 | 7.7.7.1 |-----+ +-----| 7.7.7.2 | 515 | | | | | | 516 | AS1 | ======== | AS2 | 517 | | IX | | | 518 | | +-----| 7.7.7.3 | 519 +--------------------+ +--------------------+ 521 Figure 12: Including interfaces in peerings definitions 523 unary postfix operators ``+'' or ``*'' as seen in figure 11 which ASes are 524 accepted by AS2914: <^AS2914+ (AS-WNA)*$>. These operators work on the 525 directly preceding regular expressions, i.e. + only affects AS2914, and 526 * only works on (AS-WNA). Operator ``+'' means one or more occurrences, 527 operator ``*'' means zero or more occurrences. Now it becomes obvious that 528 the AS-PATHS accepted start with at least one AS2914 but may as well be 529 stuffed allowing several occurrences of AS2914. Then the AS-PATH continues 530 with no or any number of any ASes out of the as-set AS-WNA. No other ASes 531 may then follow. 533 Apparently, quite complicated AS-PATHS can be expressed in a very handy 534 and short way. For a complete list of operators and rules for regular 535 expressions applicable to AS-PATHS in RPSL, please refer to the RPSL 536 document [3]. 538 3.4 Including Interfaces in Peering Definitions 540 In the above examples peerings were only given among ASes. However, the 541 peerings may be described in much more detail by RPSL. Actually, peerings 542 are introduced among physical routers using real IP addresses. These can be 543 specified in the import and export attributes. Figure 12 shows a simple 544 example of two ASes AS1 and AS2 which are connected to an exchange point 545 IX. While AS1 has only one connection to the exchange point via a router 546 interface with IP address 7.7.7.1, AS2 has two different connections with 547 IP address 7.7.7.2 and 7.7.7.3. The first AS may then define its routing 548 policy in more detail by specifying its boundary router. 550 aut-num: AS1 551 import: from AS2 at 7.7.7.1 accept <^AS2$> 552 ... 554 This is very simple and does not make much of a difference compared to a 555 policy where no boundary router is specified because AS1 in this example has 556 only one connection to the exchange point. However, AS1 might want to 557 choose to accept only announcements from AS2 which come from the router 558 with IP address 7.7.7.2 and disregard router 7.7.7.3. AS1 then defines the 559 following routing policy towards AS2: 561 aut-num: AS1 562 import: from AS2 7.7.7.2 at 7.7.7.1 accept <^AS2$> 563 ... 565 So both routers involved in a peering may be specified and by selecting 566 certain pairs of routers other connections can be denied. If no routers are 567 included in a policy clause then it is assumed that the policy is true for 568 all peerings among the ASes involved. 570 3.5 Describing Simple Backup Connections 572 The specification of peerings among ASes is not limited to one router for 573 each AS. In figure 12 one of the two connections of AS2 to the exchange 574 point IX might be used as backup in case the other connection fails. Let us 575 assume that AS1 wants to use the connection to router 7.7.7.2 of AS2 during 576 regular operations, and router 7.7.7.3 as backup. In a router configuration 577 this may be done by setting a local preference. The equivalent in RPSL is 578 a corresponding action definition in the peering description. The action 579 definitions are inserted directly before the accept keyword. 581 aut-num: AS1 582 import: from AS2 7.7.7.2 at 7.7.7.1 action pref=10; 583 from AS2 7.7.7.3 at 7.7.7.1 action pref=20; 584 accept <^AS2$> 585 ... 587 Actions may also be defined without specifying IP addresses of routers. If 588 no routers are included in the policy clause then it is assumed that the 589 actions are carried out for all peerings among the ASes involved. 591 In the previous example AS1 controls where it sends its traffic and which 592 connection is used as backup. However, AS2 may also define a backup 593 connection in an export clause: 595 aut-num: AS2 596 export: to AS1 7.7.7.1 at 7.7.7.2 action med=10; 597 to AS1 7.7.7.1 at 7.7.7.3 action med=20; 598 announce <^AS2$> 600 The definition given here for AS2 is the symmetric counterpart to the 601 routing policy of AS1. The selection of routing information is done by 602 setting the multi exit discriminator metric med. Actually, med metrics will 603 not be used in practice like this; they are more suitable for load balancing 604 including backups. For more details on med metrics refer to the BGP-4 605 RFC [9]. To use the med to achieve load balancing, one often sets it to the 606 ``IGP metric''. This is specified in RPSL as: 608 aut-num: AS2 609 export: to AS1 action med=igp; 610 announce <^AS2$> 612 Hence, both routers will set the med to the IGP metric at that router, 613 causing some routes to be prefferred at one of the routers and other routes 614 at the other router. 616 3.6 Multi-Home Routing Policies using the community Attribute 618 RFC 1998 [7] describes the use of the BGP community attribute [6] to handle 619 the load balancing and backup connection of multi-homed autonomous systems. 620 In this section, we simply illustrates how those policies are specified in 621 RPSL. 623 AS3561 bases its route selection preference on the community attribute. 624 Other ASes may indirectly affect AS3561's route selection by including the 625 appropriate communities in their route announcements. In our example, AS1 626 is connected to AS2 and AS3 which are both connected to AS3561. AS1 wants 627 AS3561 to prefer the AS2 connection over the AS3 connection. 629 AS3561 prefers the routes with no community attribute followed by the routes 630 with community {3561,90}, followed by the routes with community {3561,80}, 631 and followed by the routes with community {3561,70}. AS1 achieves its 632 policy by adding the community {3561,90} to the routes it exports to AS2, 633 and the community {3561,80} to the routes it exports to AS1. Hence, AS3561 634 will assign a lower preference value to the routes it receives from AS2 635 (note that, in RPSL smaller integers represents higher preferences). This 636 is illustrated in Figure 13. 638 3.7 The aut-num Object Editor 640 All the examples shown in the previous sections may well be edited by hand. 641 They may be extracted one by one from the IRR using the whois program, 642 edited, and then handed back to the registry robots. However, again the 643 RAToolSet [1] provides a very nice tool which makes working with aut-num 644 objects much easier: the aut-num object editor aoe (please see Figure 14). 646 as-set: AS3561:AS-PEERS 647 members: AS2, AS3, . . . 649 aut-num: AS3561 650 import: from AS3561:AS-PEERS 651 action pref = 30; 652 accept community.contains({3561,70}) 653 import: from AS3561:AS-PEERS 654 action pref = 20; 655 accept community.contains({3561,80}) 656 import: from AS3561:AS-PEERS 657 action pref = 10; 658 accept community.contains({3561,90}) 659 import: from AS3561:AS-PEERS 660 action pref = 0; 661 accept ANY 663 aut-num: AS1 664 export: to AS2 action community.={3561,90}; 665 to AS3 action community.={3561,80}; 666 announce AS1 668 Figure 13: Policy example using the community rp-attribute. 670 The aut-num object editor has a graphical user interface to view and 671 manipulate aut-num objects registered at any IRR. New aut-num objects may be 672 generated using templates and submitted to the registries. Moreover, the 673 routing policy from the databases may be compared to real life peerings. 674 Therefore, aoe is highly recommended as an interface to the IRR for 675 aut-num objects. Further information on aoe is available together with the 676 RAToolSet [1]. 678 4 Router Configuration Using RtConfig 680 RtConfig is a tool developed by the Routing Arbiter project [2] to 681 generate vendor specific router configurations from the policy data held 682 in the various IRRs. RtConfig currently supports Cisco, gated and RSd 683 configuration formats. RtConfig written in C++, C, lex, and yacc. It 684 has been publicly available since late 1994, and is currently being used 685 by several sites for router configuration. A few of the sites currently 686 using RtConfig include the Routing Arbiter Project (USA), ANS (USA), CA*Net 687 (Canada), IMNet (Japan), VERIO (USA), Oregon-IX (USA), IAfrica (South 688 Africa), Connect (Australia). The next section describes a methodology for 689 Figure 14: Autonomous System object editor (aoe). 691 generating vendor specific router configurations using RtConfig.(3) 693 4.1 Using RtConfig 695 The general paradigm for using RtConfig involves registering policy in an 696 IRR, building a RtConfig source file, then running running RtConfig against 697 the source file and the IRR database to create vendor specific router 698 configuration for the specified policy. The source file will contain vendor 699 specific commands as well as RtConfig commands. To make a source file, pick 700 up one of your router configuration files and replace the vendor specific 701 policy configuration commands with the RtConfig commands. 703 Commands beginning with @RtConfig instruct RtConfig to perform special 704 ------------------------------ 705 3. Discussion of RtConfig internals is beyond the scope of this document. 707 operations. An example source file is shown in Figure 15. In this 708 example, commands such as ``@RtConfig import AS3582 198.32.162.1/32 AS3701 709 198.32.162.2/32'' instruct RtConfig to generate vendor specific import 710 policies where the router 198.32.162.1 in AS3582 is importing routes from 711 router 198.32.162.2 in AS3701. The other @RtConfig commands instruct the 712 RtConfig to use certain names and numbers in the output that it generates 713 (please refer to RtConfig manual [2] for additional information). 715 router bgp 3582 716 network 128.223.0.0 717 ! 718 ! Start with access-list 100 719 ! 720 @RtConfig set cisco_access_list_no = 100 721 ! 722 ! NERO 723 ! 724 neighbor 198.32.162.2 remote-as 3701 725 @RtConfig set cisco_map_name = "AS3701-EXPORT" 726 @RtConfig export AS3582 198.32.162.1/32 AS3701 198.32.162.2/32 727 @RtConfig set cisco_map_name = "AS3701-IMPORT" 728 @RtConfig import AS3582 198.32.162.1/32 AS3701 198.32.162.2/32 729 ! 730 ! WNA/VERIO 731 ! 732 neighbor 198.32.162.6 remote-as 2914 733 @RtConfig set cisco_map_name = "AS2914-EXPORT" 734 @RtConfig export AS3582 198.32.162.1/32 AS2914 198.32.162.6/32 735 @RtConfig set cisco_map_name = "AS2914-IMPORT" 736 @RtConfig import AS3582 198.32.162.1/32 AS2914 198.32.162.6/32 737 ... 739 Figure 15: RtConfig Template File 741 Once a source file is created, the file is processed by RtConfig (the 742 default IRR is the RADB, and the default vendor is Cisco; however, RtConfig 743 or command line options can be used to override these values). The result 744 of running RtConfig on the source file in Figure 15 is shown in Figure 16. 746 References 748 [1] C. Alaettinouglu. RAToolSet Routing Policy Analysis Tool Set. 749 Marina del Rey, CA 90292, March 1996. Available from 750 http://www.isi.edu/ra/RAToolSet. 752 [2] C. Alaettinouglu. RtConfig Manual. Marina del Rey, CA 90292, March 1996. 753 Available from http://www.isi.edu/ra/RAToolSet. 755 [3] C. Alaettinouglu, T. Bates, E. Gerich, D. Karrenberg, M. Terpstra, and 756 C. Villamizer. Routing Policy Specification Language (RPSL). Internet 757 Draft draft-ietf-rps-rpsl-00.txt, Network Information Center, March 758 1996. Revised, June 1996. 760 [4] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, 761 M. Terpstra, and J. Yu. Representation of IP Routing Policies in a 762 Routing Registry. Technical Report ripe-181, RIPE, RIPE NCC, Amsterdam, 763 Netherlands, October 1994. 765 [5] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, 766 M. Terpstra, and J. Yu. Representation of IP Routing Policies in 767 a Routing Registry. Technical Report RFC-1786, Network Information 768 Center, March 1995. 770 [6] R. Chandra, P. Traina, and T. Li. BGP Communities Attribute. Request 771 for Comment RFC-1997, Network Information Center, August 1996. 773 [7] E. Chen and T. Bates. An Application of the BGP Community Attribute in 774 Multi-Home Routing. Request for Comment RFC-1998, Network Information 775 Center, August 1996. 777 [8] H. Nussbacher. The CIDR FAQ. Available from 778 http://www.ibm.net.il/ hank/cidr.html. 780 [9] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4). Request for 781 Comment RFC-1771, Network Information Center, March 1995. 783 router bgp 3582 784 network 128.223.0.0 785 ! 786 ! NERO 787 ! 788 neighbor 198.32.162.2 remote-as 3701 790 no access-list 100 791 access-list 100 permit ip 128.223.0.0 0.0.0.0 255.255.0.0 0.0.0.0 792 access-list 100 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 793 ! 794 ! 795 no route-map AS3701-EXPORT 796 route-map AS3701-EXPORT permit 1 797 match ip address 100 798 ! 799 router bgp 3582 800 neighbor 198.32.162.2 route-map AS3701-EXPORT out 801 ! 802 ! 803 no route-map AS3701-IMPORT 804 route-map AS3701-IMPORT permit 1 805 set local-preference 1000 806 ! 807 router bgp 3582 808 neighbor 198.32.162.2 route-map AS3701-IMPORT in 809 ! 810 ! WNA/VERIO 811 ! 812 neighbor 198.32.162.6 remote-as 2914 813 ! 814 no route-map AS2914-EXPORT 815 route-map AS2914-EXPORT permit 1 816 match ip address 100 817 ! 818 router bgp 3582 819 neighbor 198.32.162.6 route-map AS2914-EXPORT out 820 no ip as-path access-list 100 821 ip as-path access-list 100 permit ^_2914(((_[0-9]+))*_ \ 822 (13|22|97|132|175|668|1914|2905|2914|3361|3381|3791|3937| \ 823 4178|4354|4571|4674|4683|5091|5303|5798|5855|5856|5881|6083 \ 824 |6188|6971|7790|7951|8028))?$ 825 ! 826 no route-map AS2914-IMPORT 827 route-map AS2914-IMPORT permit 1 828 match as-path 100 829 set local-preference 998 830 ! 831 router bgp 3582 832 neighbor 198.32.162.6 route-map AS2914-IMPORT in 833 ! 835 Figure 16: Output of RtConfig