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