home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-rps-appl-rpsl-01.txt < prev    next >
Text File  |  1997-07-31  |  42KB  |  1,121 lines
  1.  
  2.  
  3.  
  4. Internet Draft                                                   David Meyer
  5. Expires  January 29, 1998                               University of Oregon
  6. draft-ietf-rps-appl-rpsl-01.txt                              Joachim Schmitz
  7.                                                                      DFN-NOC
  8.                                                          Cengiz Alaettinoglu
  9.                                                                      USC/ISI
  10.                                                                July 29, 1997
  11.  
  12.  
  13.  
  14. Application of Routing Policy Specification Language (RPSL) on the Internet
  15.  
  16.  
  17.  
  18.  
  19. Status of this Memo
  20.  
  21.  
  22. This document is an Internet Draft, and can be found as draft-ietf-rps-appl-
  23. rpsl-01.txt in any standard internet drafts repository.  Internet Drafts are
  24. working documents of the Internet Engineering Task Force (IETF), its  Areas,
  25. and its Working Groups.  Note that other groups may also distribute  working
  26. documents as Internet Drafts.
  27.  
  28. Internet Drafts  are draft  documents valid  for a  maximum of  six  months.
  29. Internet Drafts may be  updated, replaced, or  obsoleted by other  documents
  30. at any time.   It  is not appropriate  to use Internet  Drafts as  reference
  31. material, or to cite  them other than  as a ``working  draft'' or ``work  in
  32. progress.''
  33.  
  34. Please check  the I-D  abstract  listing contained  in each  Internet  Draft
  35. directory to learn the current status of this or any other Internet Draft.
  36.  
  37.  
  38.  
  39. 1 Introduction
  40.  
  41.  
  42. This document  is  a tutorial  on  using the  Routing  Policy  Specification
  43. Language (RPSL) to specify routing policies.   It covers specifying  routing
  44. policies using  RPSL, registering  these policies  in the  Internet  Routing
  45. Registry (IRR), and analysing them using the routing policy analysis  tools,
  46. for example  to  generate  vendor  specific router  configurations.     This
  47. document is targeted towards an Internet/Network Service Provider  (ISP/NSP)
  48. engineer who is new  to RPSL and  to IRR. Readers are  referred to the  RPSL
  49. reference document [3] for completeness.  We recommend reading this document
  50. before reading the reference document.   We hope  that for many cases,  this
  51. document will be sufficient.
  52.  
  53. IRR is a  repository of routing  policies.   It currently  consists of  five
  54. Internet Draft               Application of RPSL               July 29, 1997
  55.  
  56. sites:  CA*Net  registry in  Canada,  ANS, MCI  and RADB  registries in  the
  57. United States  of America,  and RIPE  registry in  Europe.    Each of  these
  58. sites run independent  of each  other.   However,  each  site exchanges  its
  59. data with each other at some frequency (at  least once a day or as often  as
  60. every ten minutes).  MCI, Ca*Net and ANS are private registries and  contain
  61. routing policies  of MCI,  Ca*Net, ANS,  and their  customers  respectively.
  62. RADB and RIPE are public registries, and any ISP can publish their  policies
  63. in these registries.   Since registries exchange  their data regularly,  you
  64. need to  register  your policies  in  only one  of  them.    If you  are  an
  65. MCI, ANS or CA*Net  customer, we recommend you  register your policies  with
  66. them.  Otherwise, you may register your policies either at the RIPE or  RADB
  67. registry, whichever is closer to you.   We recommend against registering  in
  68. multiple registries since  it often  eventually leads  to inconsistent  data
  69. between the registries.
  70.  
  71. Routing policies registered in IRR are  specified using RPSL. RPSL is  based
  72. on an earlier language known as RIPE-181 [4, 5].  Through operational use of
  73. RIPE-181 it has become  apparent that certain  policies cannot be  specified
  74. and a  need for  an enhanced  and more  general language  is needed.    RPSL
  75. addresses RIPE-181's limitations.  RPSL obsoletes RIPE-181 [4, 5].
  76.  
  77. RPSL is  object oriented;  that is,  objects  contain pieces  of policy  and
  78. administrative information.  For example, each address prefix routed in  the
  79. inter-domain mesh is specified in a route object and policies of each AS are
  80. specified in an aut-num object.  Objects have relations between each  other.
  81. For example, all route objects of an ISP refer to the aut-num object of  the
  82. ISP. These relations form  sets of objects,  we can then  use these sets  to
  83. specify policies collectively to  all their members.   For  example, we  can
  84. specify policy against all routes of an ISP, by refering to the AS number of
  85. the ISP. In the following sections,  we will describe each of these  objects
  86. (rather object classes) in more detail and give numerous examples for you to
  87. create your own objects.  In most cases, you should be able to cut and paste
  88. our examples to create your own objects.
  89.  
  90. Once you register  your policies in  IRR, they are  available for others  to
  91. query using a  whois service.   Figure 1  illustrates the use  of the  whois
  92. command to obtain the route  object for 128.223.0.0/16.   The output of  the
  93. whois command is  the ASCII representation  of the  route object.   We  will
  94. describe the details of the route object in Section 2.3.
  95.  
  96. That is  not all,  once  you register  your  policies in  IRR, they  can  be
  97. analyzed for consistency or used to diagnose Internet's operational  routing
  98. problems.   RAToolSet  [1] is  a suite  of tools  for analyzing  this  data.
  99. It contains  tools  (RtConfig)  to  configure  routers,  tools  (prpath  and
  100. prtraceroute) to analyse paths on the Internet, tools (roe, aoe and prcheck)
  101. to compare, validate and register RPSL objects, and others.
  102.  
  103. The remainder  of  this  document  is  organized  as  follows:    Section  2
  104. introduces the fundamental RPSL objects.  Section 3 discusses implementation
  105. of various common policies using RPSL. Finally, Section 4 describes the  use
  106. of RtConfig to generate vendor specific router configurations.
  107.  
  108.  
  109. Meyer et.  al.              Expires  January 29, 1998               [Page 2]
  110. Internet Draft               Application of RPSL               July 29, 1997
  111.  
  112.  
  113.  
  114.        % whois -h radb.ra.net 128.223.0.0/16
  115.          route:       128.223.0.0/16
  116.          descr:       UONet
  117.          descr:       University of Oregon
  118.          descr:       Computing Center
  119.          descr:       Eugene, OR 97403-1212
  120.          descr:       USA
  121.          origin:      AS3582
  122.          mnt-by:      MAINT-AS3582
  123.          changed:     meyer@ns.uoregon.edu 19960222
  124.          source:      RADB
  125.  
  126.  
  127.                 Figure 1:  whois command and a route object.
  128.  
  129.  
  130.  
  131. 2 RPSL Objects
  132.  
  133.  
  134. This section introduces the fundamental  RPSL objects required to  implement
  135. many typical Internet routing policies.  The basic elements are:
  136.  
  137.  
  138.  o  maintainer objects (mntner)
  139.  
  140.  o  autonomous system number objects (aut-num)
  141.  
  142.  o  route objects (route)
  143.  
  144.  o  set objects (as-set, route-set)
  145.  
  146.  
  147. and they are described  in the following  sections.   These objects must  be
  148. registered in the IRR, in only one of the existing registries.  In  general,
  149. registration is done by sending  electronic mail to a  registry robot.   The
  150. email addresses  for  existing registries  are  listed in  Figure  2.    The
  151. contents of the mail  consists of the objects  you want to have  registered,
  152. separated by empty lines, and often some kind of authorization (see  below).
  153. The registry robot automatically processes  your mail, entering new  objects
  154. into the database, deleting old ones,  or activating changes.  Moreover,  it
  155. may send notifications and replies with an error or success report about its
  156. actions.   The first  object which  has to  be registered,  normally is  the
  157. mntner.  In general, to have it properly authenticated, a maintainer  object
  158. is added manually by registry staff.   Afterwards, all other actions  should
  159. be done through the registry robot.  Each registry provides documentation on
  160. how to use it.  If problems  arise your registry staff is willing to  assist
  161. you.
  162.  
  163.  
  164.  
  165. Meyer et.  al.              Expires  January 29, 1998               [Page 3]
  166. Internet Draft               Application of RPSL               July 29, 1997
  167.  
  168.  
  169.                         ANS    auto-dbm@ans.net
  170.                         CANET  auto-dbm@canet.net
  171.                         MCI    auto-rr@mci.net
  172.                         RADB   auto-dbm@radb.ra.net
  173.                         RIPE   auto-dbm@ripe.net
  174.  
  175.    Figure 2:  Registry email addresses to register policy objects in IRR.
  176.  
  177.  
  178. 2.1 The Maintainer Object
  179.  
  180.  
  181. The maintainer  object  is used  to  introduce some  kind  of  authorization
  182. for  registrations.     It  lists  various  contact  persons  and  describes
  183. security mechanisms  that  will be  applied  when updating  objects  in  the
  184. IRR. Registering a  mntner object  is the  first step  in creating  policies
  185. for an AS.  An example  is shown  in Figure  3.   The  maintainer is  called
  186. MAINT-AS3701.   The  contact  person here  is  the same  for  administrative
  187. (admin-c) and technical (tech-c) issues and is referenced by the  NIC-handle
  188. DMM65.  NIC-handles are unique identifiers for persons in registries.  Refer
  189. to registry documentation for further details on person objects and usage of
  190. NIC-handles.
  191.  
  192. The example shows  two authentication mechanisms:   CRYPT-PW and  MAIL-FROM.
  193. CRYPT-PW takes  as its  argument  a password  that  is encrypted  with  Unix
  194. crypt(3) routine.    When sending  updates, the  maintainer adds  the  field
  195. password:  <cleartext password> to the beginning of any requests that are to
  196. be authenticated.  MAIL-FROM takes an argument that is a regular  expression
  197. which covers a set  of mail addresses.   Only users with  any of these  mail
  198. addresses are authorized to work  with objects secured by the  corresponding
  199. maintainer(1).
  200.  
  201. The security mechanisms of the mntner  object will only be applied on  those
  202. objects referencing a  specific mntner  object.   The reference  is done  by
  203. adding the attribute mnt-by to an object using the name of the mntner object
  204. as its value.   In Figure  3, the maintainer  MAINT-AS3701 is maintained  by
  205. itself.
  206.  
  207.  
  208.  
  209. 2.2 The Autonomous System Object
  210.  
  211.  
  212. The autonomous system object describes the import and export policies of  an
  213. AS. Each organization registers an autonomous system object (aut-num) in the
  214. ------------------------------
  215.  1.   Clearly,   neither  of  these  mechanisms  is  sufficient  to  provide
  216. strong authentication  or  authorization.    Other public  key  (e.g.,  PGP)
  217. authentication mechanisms are available from some of the IRRs.
  218.  
  219.  
  220.  
  221. Meyer et.  al.              Expires  January 29, 1998               [Page 4]
  222. Internet Draft               Application of RPSL               July 29, 1997
  223.  
  224.  
  225.  
  226. mntner:      MAINT-AS3701
  227. descr:       Network for Research and Engineering in Oregon
  228. remark:      Internal Backbone
  229. admin-c:     DMM65
  230. tech-c:      DMM65
  231. upd-to:      noc@nero.net
  232. auth:        CRYPT-PW  949WK1mirBy6c
  233. auth:        MAIL-FROM .*@nero.net
  234. notify:      noc@nero.net
  235. mnt-by:      MAINT-AS3701
  236. changed:     meyer@antc.uoregon.edu 970318
  237. source:      RADB
  238.  
  239.  
  240.                         Figure 3:  Maintainer Object
  241.  
  242.  
  243.  
  244. IRR for its AS. Figure 4 shows the aut-num for AS3582 (UONET).
  245.  
  246. The autonomous  system  object  lists  contacts  (admin-c,  tech-c)  and  is
  247. maintained by (mnt-by)  MAINT-AS3701 which  is the  maintainer displayed  in
  248. Figure 3.
  249.  
  250. The most important attributes of the  aut-num object are import and  export.
  251. The import clause of an aut-num specifies import policies, while the  export
  252. clause specifies export policies.   The corresponding  clauses allow a  very
  253. detailed description of the routing policy of the AS specified.  The details
  254. are given in section 3.
  255.  
  256. With these  clauses,  an aut-num  object  shows  its relationship  to  other
  257. autonomous systems by describing its peerings.  In addition, it also defines
  258. a routing  entity  comprising a  group  of  IP networks  which  are  handled
  259. according to the  rules defined in  the aut-num  object.   Therefore, it  is
  260. closely linked to route objects.
  261.  
  262. In this example, AS3582 imports all routes from AS3701 by using the  keyword
  263. ANY. AS3582 imports only  internal routes from  AS4222, AS5650, and  AS1798.
  264. The import policy for  for AS2914 is  slightly more complex.   Since  AS2914
  265. provides transit to various other  ASes, AS3582 accepts routes with  ASPATHs
  266. that begin with AS2194  followed by members  of AS-WNA, which  is an as  set
  267. (see section 2.4.1 below) describing those customers that transit AS2914.
  268.  
  269. Since AS3582 is a multi-homed stub  AS (i.e., it does not provide  transit),
  270. its export policy consists simply of  ``announce AS3582'' clauses; that  is,
  271. announce internal routes of AS3582.  These routes are those in route objects
  272. where the origin attribute is AS3582.
  273.  
  274. The aut-num object  forms the basis  of a scalable  and maintainable  router
  275.  
  276.  
  277. Meyer et.  al.              Expires  January 29, 1998               [Page 5]
  278. Internet Draft               Application of RPSL               July 29, 1997
  279.  
  280.  
  281.  
  282. aut-num:     AS3582
  283. as-name:     UONET
  284. descr:       University of Oregon, Eugene OR
  285. import:      from AS3701 accept ANY
  286. import:      from AS4222 accept <^AS4222$>
  287. import:      from AS5650 accept <^AS5650$>
  288. import:      from AS2914 accept <^AS2914+ (AS-WNA)*$>
  289. import:      from AS1798 accept <^AS1798$>
  290. export:      to AS3701 announce AS3582
  291. export:      to AS4222 announce AS3582
  292. export:      to AS5650 announce AS3582
  293. export:      to AS2914 announce AS3582
  294. export:      to AS1798 announce AS3582
  295. admin-c:     DMM65
  296. tech-c:      DMM65
  297. notify:      nethelp@ns.uoregon.edu
  298. mnt-by:      MAINT-AS3582
  299. changed:     meyer@antc.uoregon.edu 970316
  300. source:      RADB
  301.  
  302.  
  303.                     Figure 4:  Autonomous System Object
  304.  
  305.  
  306.  
  307. configuration system.   For example,  if AS3582 originates  a new route,  it
  308. need only create a route object for  that route with origin AS3582.   AS3582
  309. can now build  configuration using  this route object  without changing  its
  310. aut-num object.
  311.  
  312. Similarly, if  for example,  AS3701 originates  a new  route,  it need  only
  313. create a route object for  that route with origin AS3701.   Both AS3701  and
  314. AS3582 can now build configuration using this route object without modifying
  315. its aut-num object.
  316.  
  317.  
  318. 2.3 The Route Object
  319.  
  320.  
  321. In contrast  to  aut-num  objects  which  describe  propagation  of  routing
  322. information for an autonomous system as a whole, route objects define single
  323. routes from an AS. An example is given in Figure 5.
  324.  
  325. This route object  is maintained  by MAINT-AS3582 and  references AS3582  by
  326. the origin attribute.  By this  reference it is grouped together with  other
  327. routes of the same origin AS, becoming member of the routing entity  denoted
  328. by AS3582.  The routing policies can then be defined in the aut-num  objects
  329. for this group of routes.
  330.  
  331.  
  332.  
  333. Meyer et.  al.              Expires  January 29, 1998               [Page 6]
  334. Internet Draft               Application of RPSL               July 29, 1997
  335.  
  336.  
  337.       route:       128.223.0.0/16
  338.       descr:       UONet
  339.       descr:       University of Oregon
  340.       descr:       Computing Center
  341.       descr:       Eugene, OR 97403-1212
  342.       descr:       USA
  343.       origin:      AS3582
  344.       mnt-by:      MAINT-AS3582
  345.       changed:     meyer@ns.uoregon.edu 960222
  346.       source:      RADB
  347.  
  348.                     Figure 5:  Example of a route object
  349.  
  350.  
  351. Consequently, the  route objects  give the  routes from  this AS  which  are
  352. distributed to  peer ASes  according to  the rules  of the  routing  policy.
  353. Therefore, for any  route in the  routing tables of  the backbone routers  a
  354. route object must exist in one of the registries in IRR. route objects  must
  355. be registered in the IRR only for the routes seen outside your AS. Normally,
  356. this set of external routes is different from the routes internally  visible
  357. within your AS.  One of the  major reasons  is that external  peers need  no
  358. information at  all  about your  internal  routing specifics.     Therefore,
  359. external routes are in general  aggregated combinations of internal  routes,
  360. having shorter IP  prefixes where  applicable according to  the CIDR  rules.
  361. Please see the  CIDR FAQ  [8] for  a tutorial  introduction to  CIDR. It  is
  362. strongly recommended that  you aggregate  your routes as  much as  possible,
  363. thereby minimizing the number of routes  you inject into the global  routing
  364. table and  at the  same  time reducing  the  corresponding number  of  route
  365. objects in the IRR.
  366.  
  367. While you may easily query single route objects using the whois program, and
  368. submit objects via mail to the registry robots, this becomes kind of awkward
  369. for larger sets.  The RAToolSet [1] offers several tools to make handling of
  370. route objects easier.   If  you want to  read policy data  from the IRR  and
  371. process it by other programs, you  might be interested in using peval  which
  372. is a low level policy evaluation tool.  As an example, the command
  373.  
  374.  
  375.     peval -h radb.ra.net -expand_all AS3582
  376.  
  377.  
  378. will give you all route objects from AS3582 registered with RADB.
  379.  
  380. A much more sophisticated  tool from the RAToolSet  to handle route  objects
  381. interactively is the route object editor roe (please see Figure 6).  It  has
  382. a graphical user interface to  view and manipulate route objects  registered
  383. at any IRR. New route objects may be generated from templates and  submitted
  384. to the registries.   Moreover, the route objects  from the databases may  be
  385. compared to real life routes.   Therefore, roe  is highly recommended as  an
  386.  
  387.  
  388.  
  389. Meyer et.  al.              Expires  January 29, 1998               [Page 7]
  390. Internet Draft               Application of RPSL               July 29, 1997
  391.  
  392. interface to the IRR for  route objects.   Further information on peval  and
  393. roe is available together with the RAToolSet [1].
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.                    Figure 6:  route object editor (roe).
  422.  
  423.  
  424.  
  425.  
  426. 2.4 Set Objects
  427.  
  428.  
  429. With  routing  policies  it  is  often  necessary  to  reference  groups  of
  430. autonomous systems or  routes which  have identical  properties regarding  a
  431. specific policy.   To make working  with such groups  easier RPSL allows  to
  432. combine them in set objects.   There are two  basic types of predefined  set
  433. objects, as-set, and route-set.  The RPSL set objects are described below.
  434.  
  435.  
  436. 2.4.1 AS-SET Object
  437.  
  438.  
  439. Autonomous system set objects (as-set)  are used to group autonomous  system
  440. objects into  named sets.    An as-set  has an  RPSL name  that starts  with
  441. ``AS-''.  In the example in Figure 7, an as-set called AS-NERO-PARTNERS  and
  442. containing AS3701, AS4201, AS3582,  AS4222, AS1798 is  defined.  The  as-set
  443.  
  444.  
  445. Meyer et.  al.              Expires  January 29, 1998               [Page 8]
  446. Internet Draft               Application of RPSL               July 29, 1997
  447.  
  448. is the RPSL replacement  for the RIPE-181  as-macro.   It has been  extended
  449. to include ASes in  the set indirectly  by referencing as  set names in  the
  450. aut-num objects.
  451.  
  452. AS-SETs are particularly  useful when  specifying policies  for groups  such
  453. as customers, providers,  or for transit.   You  are encouraged to  register
  454. sets for these groups  because it is  most likely that  you will treat  them
  455. alike, i.e.  you  will have  a  very similar  routing  policy for  all  your
  456. customers which have an  autonomous system of  their own.   You may as  well
  457. discover that this  is also  true for the  providers you  are peering  with,
  458. and it  is most  convenient to  have the  ASes combined  in one  as-set  for
  459. which you offer transit.  For  example, if a transit provider specifies  its
  460. import policy using its customer's as-set  (i.e., its import clause for  the
  461. customer contains the customer's as-set), then that customer can modify  the
  462. set of ASes  that its transit  provider accepts from  it.   Again, this  can
  463. be accomplished without requiring  the customer or  the transit provider  to
  464. modify its aut-num object.
  465.  
  466.  
  467.    as-set:    AS3582:AS-PARTNERS
  468.    members:   AS3701, AS4201, AS3582, AS4222, AS1798
  469.  
  470.  
  471.                           Figure 7:  as-set Object
  472.  
  473.  
  474. The ASes of the set are simply compiled in a comma delimited list  following
  475. the members attribute  of the  as-set.   This  list may  also contain  other
  476. AS-SETs.
  477.  
  478.  
  479. 2.4.2 ROUTE-SET Object
  480.  
  481.  
  482. A route-set is a way to  name a group of routes.   The syntax is similar  to
  483. the as-set.   A route-set has an  RPSL name that starts  with ``RS-''.   The
  484. members attribute lists  the members of  the set.   The value  of a  members
  485. attribute is a list of  address prefixes, or route-set  names.  The  members
  486. of the route-set are the address prefixes  or the names of other route  sets
  487. specified.
  488.  
  489. Figure 8 presents some  example route-set objects.   The set rs-uo  contains
  490. two address  prefixes,  namely  128.223.0.0/16  and 198.32.162.0/24.     The
  491. set rs-bar contains  the members  of the set  rs-uo and  the address  prefix
  492. 128.7.0.0/16.
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501. Meyer et.  al.              Expires  January 29, 1998               [Page 9]
  502. Internet Draft               Application of RPSL               July 29, 1997
  503.  
  504.  
  505.    route-set: rs-uo
  506.    members: 128.223.0.0/16, 198.32.162.0/24
  507.  
  508.    route-set: rs-bar
  509.    members: 128.7.0.0/16, rs-uo
  510.  
  511.    route-set: AS3582:RS-MARTIANS
  512.    remarks: routes not accepted from any peer
  513.    members: 0.0.0.0/0,              # default route
  514.             0.0.0.0/0^32,           # host routes
  515.             224.0.0.0/3^4-32,       # multicast routes
  516.             127.0.0.0/8^9-32, . . .
  517.  
  518.  
  519.                         Figure 8:  route-set Objects
  520.  
  521. 3 Specifying Policies using RPSL
  522.  
  523.  
  524. In this section we show how the various RPSL objects can be used to  specify
  525. typical Internet policies.
  526.  
  527.  
  528. 3.1 Provider-Customer Policies
  529.  
  530.  
  531. In typical customer-provider  relationships,  the customer  imports all  the
  532. routes that the provider has  and exports its routes to  the provider.   The
  533. provider's policies are symmetrical in the sense that it exports all  routes
  534. that it has  to the  customer,  and it  imports only  the customers  routes.
  535. Figure 9 illustrates one way of  expressing these policies using RPSL  where
  536. AS3701 is the provider and  AS3582 is the customer.   Refer to Figure 4  for
  537. AS3582's aut-num.
  538.  
  539. In this example,  ``announce ANY'' means  export any route  that AS3701  has
  540. in its routing table, and  ``accept <^AS3582$>'' means accept only  AS3582's
  541. routes (i.e., that have  AS-PATHs of length  one, where the  AS in the  path
  542. is AS3582)(2).  Note  that AS3582 is taking  full routing from AS3701;  this
  543. can be seen in  that AS3701 is announcing  ``ANY'', and AS3582 is  accepting
  544. ``ANY''. The  important point  in this  example is  that if  AS3582 adds  or
  545. deletes route objects, there is no need to update the aut-num objects.   The
  546. added (or  deleted) objects  will implicitly  update AS3582's  and  AS3701's
  547. policies, and thus affect their router configuration files.
  548.  
  549. As mentioned  above, if  the customer  is  itself a  provider, i.e.  it  has
  550.  
  551. ------------------------------
  552.  2.  AS-PATH  regular expressions are  POSIX compliant regular  expressions,
  553. see section 3.3.
  554.  
  555.  
  556.  
  557. Meyer et.  al.              Expires  January 29, 1998              [Page 10]
  558. Internet Draft               Application of RPSL               July 29, 1997
  559.  
  560.  
  561.   aut-num:     AS3701
  562.   as-name:     NERO-NET
  563.   descr:       Network for Engineering and Research in Oregon
  564.   ...
  565.   import:      from AS3582 accept <^AS3582$>
  566.   export:      to AS3582 announce ANY
  567.   ...
  568.   admin-c:     DMM65
  569.   tech-c:      DMM65
  570.   notify:      noc@nero.net
  571.   mnt-by:      MAINT-AS3701
  572.   changed:     meyer@antc.uoregon.edu 970316
  573.   source:      RADB
  574.  
  575.  
  576.                Figure 9:  Provider-Customer Policies in RPSL
  577.  
  578. its own customers,  the set of  routes passed to  the provider includes  its
  579. customers' routes as illustrated  in Figure 10.   In this example,  ``accept
  580. AS3582:AS-PARTNERS'' means  that  for  each  AS X  in  the  set  defined  by
  581. AS3582:AS-PARTNERS accept AS X's routes.
  582.  
  583.  
  584.   aut-num:     AS4600
  585.   as-name:     NERO-TRANSIT
  586.   descr:       Network for Engineering and Research in Oregon
  587.   ...
  588.   import:      from AS3701 accept <^A3701+ (AS3582:AS-PARTNERS)*$>
  589.   export:      to AS3701 announce ANY
  590.   ...
  591.   admin-c:     DMM65
  592.   tech-c:      DMM65
  593.   notify:      noc@nero.net
  594.   mnt-by:      MAINT-AS4600
  595.   changed:     meyer@antc.uoregon.edu 970316
  596.   source:      RADB
  597.  
  598.  
  599.                Figure 10:  Provider-Customer Policies in RPSL
  600.  
  601. In this case shown in Figure 10, if AS3701 gets a new customer, then  it can
  602. update the definition of the AS3582:AS-PARTNERS  set to include the new  AS.
  603. The policies specified in the aut-num  objects for AS4600 and AS3701 do  not
  604. change.
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613. Meyer et.  al.              Expires  January 29, 1998              [Page 11]
  614. Internet Draft               Application of RPSL               July 29, 1997
  615.  
  616. 3.2 Inter-Provider Policies
  617.  
  618.  
  619. In this  case, the  policies  of both  providers are  to export  only  their
  620. customer routes  to the  other provider,  and to  import only  the  customer
  621. routes of the  other provider.   This  is commonly referred  to as  peerage.
  622. Figure 11 illustrates  how this is  expressed using RPSL  where both  AS3701
  623. and AS2914 are providers.   In this example,  AS3701 advertises only the  AS
  624. paths described by  the AS-SET AS3582:AS-PARTNERS  (i.e., customer  routes).
  625. Likewise, we  filter routes  that  come from  AS2914, accepting  only  those
  626. defined by the filter ``<^AS2914+  (AS-WNA)*\$>'', i.e., those routes  whose
  627. AS-PATH attribute ends with an AS in the set defined by the AS-WNA AS-SET.
  628.  
  629.  
  630.   aut-num:     AS3701
  631.   as-name:     NERO-NET
  632.   descr:       Network for Engineering and Research in Oregon
  633.   ...
  634.   import:      from AS2914 accept <^AS2914+ (AS-WNA)*$>
  635.   export:      to AS2914 announce AS3582:AS-PARTNERS
  636.   ...
  637.   admin-c:     DMM65
  638.   tech-c:      DMM65
  639.   notify:      noc@nero.net
  640.   mnt-by:      MAINT-AS3701
  641.   changed:     meyer@antc.uoregon.edu 970316
  642.   source:      RADB
  643.  
  644.  
  645.                 Figure 11:  Inter-Provider Policies in RPSL
  646.  
  647.  
  648. 3.3 AS Path Based Policies
  649.  
  650.  
  651. Our routing  policy  examples have  used  AS  path expressions  in  them  to
  652. describe the routes accepted from or  announced to peering partners.   these
  653. expressions do not only cover the  ASes themselves but also the  interdomain
  654. topology between them.   This is  achieved by a  mechanism known as  regular
  655. expressions.    Those familiar  with  the  UNIX world  or  with  programming
  656. languages like C or perl will most likely already understood the details  of
  657. the AS-PATHS displayed in the examples.   RPSL uses POSIX compliant  regular
  658. expressions over AS numbers.   In  this section,  we briefly describe  their
  659. use.
  660.  
  661. Regular expressions follow certain rules.   Several characters have  special
  662. meanings, e.g.  ``^'' denotes  the beginning  of a  string,  ``$'' its  end.
  663. Then it becomes obvious that the AS-PATH <^AS3582$> accepted from AS3582  in
  664. figure 10 has length one and consists of AS3582 only.
  665.  
  666. Besides these  positional indicators  there  are also  operators,  e.g.  the
  667.  
  668.  
  669. Meyer et.  al.              Expires  January 29, 1998              [Page 12]
  670. Internet Draft               Application of RPSL               July 29, 1997
  671.  
  672.  
  673.     +--------------------+                +--------------------+
  674.     |            7.7.7.1 |-----+    +-----| 7.7.7.2            |
  675.     |                    |     |    |     |                    |
  676.     | AS1                |    ========    |                AS2 |
  677.     |                    |    IX    |     |                    |
  678.     |                    |          +-----| 7.7.7.3            |
  679.     +--------------------+                +--------------------+
  680.  
  681.  
  682.           Figure 12:  Including interfaces in peerings definitions
  683.  
  684. unary postfix operators ``+'' or ``*'' as  seen in figure 11 which ASes  are
  685. accepted by AS2914:   <^AS2914+ (AS-WNA)*$>.   These  operators work on  the
  686. directly preceding  regular expressions,  i.e. +  only affects  AS2914,  and
  687. * only works  on (AS-WNA).  Operator ``+''  means one  or more  occurrences,
  688. operator ``*'' means zero or more occurrences.  Now it becomes obvious  that
  689. the AS-PATHS accepted  start with at  least one  AS2914 but may  as well  be
  690. stuffed allowing several occurrences of AS2914.  Then the AS-PATH  continues
  691. with no or any number  of any ASes out of  the as-set AS-WNA. No other  ASes
  692. may then follow.
  693.  
  694. Apparently, quite  complicated AS-PATHS  can be  expressed in  a very  handy
  695. and short way.    For a  complete list of  operators and  rules for  regular
  696. expressions applicable  to  AS-PATHS  in  RPSL, please  refer  to  the  RPSL
  697. document [3].
  698.  
  699.  
  700. 3.4 Including Interfaces in Peering Definitions
  701.  
  702.  
  703. In the above examples  peerings were only  given among ASes.   However,  the
  704. peerings may be described  in much more detail  by RPSL. Actually,  peerings
  705. are introduced among physical routers using real IP addresses.  These can be
  706. specified in the import  and export attributes.   Figure  12 shows a  simple
  707. example of two ASes  AS1 and AS2  which are connected  to an exchange  point
  708. IX. While AS1 has  only one connection  to the exchange  point via a  router
  709. interface with IP address  7.7.7.1, AS2 has  two different connections  with
  710. IP address 7.7.7.2 and 7.7.7.3.   The first AS  may then define its  routing
  711. policy in more detail by specifying its boundary router.
  712.  
  713.  
  714.     aut-num:   AS1
  715.     import:    from AS2 at 7.7.7.1 accept <^AS2$>
  716.     ...
  717.  
  718.  
  719. This is very simple  and does not  make much of a  difference compared to  a
  720. policy where no boundary router is specified because AS1 in this example has
  721. only one connection  to the  exchange point.    However, AS1  might want  to
  722.  
  723.  
  724.  
  725. Meyer et.  al.              Expires  January 29, 1998              [Page 13]
  726. Internet Draft               Application of RPSL               July 29, 1997
  727.  
  728. choose to accept  only announcements  from AS2  which come  from the  router
  729. with IP address 7.7.7.2 and disregard router 7.7.7.3.  AS1 then defines  the
  730. following routing policy towards AS2:
  731.  
  732.  
  733.     aut-num:   AS1
  734.     import:    from AS2 7.7.7.2 at 7.7.7.1 accept <^AS2$>
  735.     ...
  736.  
  737.  
  738. So both routers  involved in  a peering may  be specified  and by  selecting
  739. certain pairs of routers other connections can be denied.  If no routers are
  740. included in a policy clause then it  is assumed that the policy is true  for
  741. all peerings among the ASes involved.
  742.  
  743.  
  744. 3.5 Describing Simple Backup Connections
  745.  
  746.  
  747. The specification of peerings  among ASes is not  limited to one router  for
  748. each AS. In  figure 12 one  of the two  connections of AS2  to the  exchange
  749. point IX might be used as backup in case the other connection fails.  Let us
  750. assume that AS1 wants to use the connection to router 7.7.7.2 of AS2  during
  751. regular operations, and router 7.7.7.3 as backup.  In a router configuration
  752. this may be done by setting a local  preference.  The equivalent in RPSL  is
  753. a corresponding action definition  in the peering description.   The  action
  754. definitions are inserted directly before the accept keyword.
  755.  
  756.  
  757.     aut-num:   AS1
  758.     import:    from AS2 7.7.7.2 at 7.7.7.1 action pref=10;
  759.                from AS2 7.7.7.3 at 7.7.7.1 action pref=20;
  760.                accept <^AS2$>
  761.     ...
  762.  
  763.  
  764. Actions may also be defined without specifying IP addresses of routers.   If
  765. no routers are included  in the policy  clause then it  is assumed that  the
  766. actions are carried out for all peerings among the ASes involved.
  767.  
  768. In the previous example  AS1 controls where it  sends its traffic and  which
  769. connection is  used as  backup.    However,  AS2 may  also define  a  backup
  770. connection in an export clause:
  771.  
  772.  
  773.     aut-num:   AS2
  774.     export:    to AS1 7.7.7.1 at 7.7.7.2 action med=10;
  775.                to AS1 7.7.7.1 at 7.7.7.3 action med=20;
  776.                announce <^AS2$>
  777.  
  778.  
  779.  
  780.  
  781. Meyer et.  al.              Expires  January 29, 1998              [Page 14]
  782. Internet Draft               Application of RPSL               July 29, 1997
  783.  
  784. The definition  given here  for  AS2 is  the  symmetric counterpart  to  the
  785. routing policy of  AS1.   The selection  of routing information  is done  by
  786. setting the multi exit discriminator metric med.  Actually, med metrics will
  787. not be used in practice like this; they are more suitable for load balancing
  788. including backups.   For  more details  on med  metrics refer  to the  BGP-4
  789. RFC [9].  To use the med to achieve load balancing, one often sets it to the
  790. ``IGP metric''.  This is specified in RPSL as:
  791.  
  792.  
  793.     aut-num:   AS2
  794.     export:    to AS1 action med=igp;
  795.                announce <^AS2$>
  796.  
  797.  
  798. Hence, both  routers will set  the med  to the  IGP metric  at that  router,
  799. causing some routes to be prefferred at one of the routers and other  routes
  800. at the other router.
  801.  
  802.  
  803. 3.6 Multi-Home Routing Policies using the community Attribute
  804.  
  805.  
  806. RFC 1998 [7] describes the use of the BGP community attribute [6] to  handle
  807. the load balancing and backup connection of multi-homed autonomous  systems.
  808. In this section, we simply illustrates  how those policies are specified  in
  809. RPSL.
  810.  
  811. AS3561 bases  its route  selection preference  on the  community  attribute.
  812. Other ASes may indirectly affect  AS3561's route selection by including  the
  813. appropriate communities in their route announcements.   In our example,  AS1
  814. is connected to AS2 and AS3 which are  both connected to AS3561.  AS1  wants
  815. AS3561 to prefer the AS2 connection over the AS3 connection.
  816.  
  817. AS3561 prefers the routes with no community attribute followed by the routes
  818. with community {3561,90}, followed  by the routes  with community {3561,80},
  819. and followed  by the  routes with  community {3561,70}.    AS1 achieves  its
  820. policy by adding the  community {3561,90} to  the routes it exports  to AS2,
  821. and the community {3561,80} to the routes it exports to  AS1.  Hence, AS3561
  822. will assign a  lower preference  value to the  routes it  receives from  AS2
  823. (note that, in RPSL smaller integers  represents higher preferences).   This
  824. is illustrated in Figure 13.
  825.  
  826.  
  827. 3.7 The aut-num Object Editor
  828.  
  829.  
  830. All the examples shown in the previous sections may well be edited by  hand.
  831. They may be  extracted one  by one  from the  IRR using  the whois  program,
  832. edited, and then handed  back to the  registry robots.   However, again  the
  833. RAToolSet [1] provides  a very nice  tool which makes  working with  aut-num
  834. objects much easier:  the aut-num object editor aoe (please see Figure 14).
  835.  
  836.  
  837. Meyer et.  al.              Expires  January 29, 1998              [Page 15]
  838. Internet Draft               Application of RPSL               July 29, 1997
  839.  
  840.  
  841.  as-set: AS3561:AS-PEERS
  842.  members: AS2, AS3, . . .
  843.  
  844.  aut-num: AS3561
  845.  import: from AS3561:AS-PEERS
  846.          action pref = 30;
  847.          accept community.contains({3561,70})
  848.  import: from AS3561:AS-PEERS
  849.          action pref = 20;
  850.          accept community.contains({3561,80})
  851.  import: from AS3561:AS-PEERS
  852.          action pref = 10;
  853.          accept community.contains({3561,90})
  854.  import: from AS3561:AS-PEERS
  855.          action pref = 0;
  856.          accept ANY
  857.  
  858.  aut-num: AS1
  859.  export: to AS2 action community.={3561,90};
  860.          to AS3 action community.={3561,80};
  861.          announce AS1
  862.  
  863.  
  864.         Figure 13:  Policy example using the community rp-attribute.
  865.  
  866. The aut-num  object  editor has  a  graphical  user interface  to  view  and
  867. manipulate aut-num objects registered at any IRR. New aut-num objects may be
  868. generated using templates and  submitted to the registries.   Moreover,  the
  869. routing policy from  the databases may  be compared to  real life  peerings.
  870. Therefore,  aoe is  highly  recommended  as  an interface  to  the  IRR  for
  871. aut-num objects.  Further information on aoe is available together with  the
  872. RAToolSet [1].
  873.  
  874.  
  875.  
  876. 4 Router Configuration Using RtConfig
  877.  
  878.  
  879. RtConfig is  a  tool  developed  by  the  Routing  Arbiter  project  [2]  to
  880. generate vendor specific  router configurations  from the  policy data  held
  881. in the various  IRRs.   RtConfig  currently supports  Cisco,  gated and  RSd
  882. configuration formats.   RtConfig  written in C++,  C, lex,  and yacc.    It
  883. has been publicly  available since late  1994, and is  currently being  used
  884. by several sites for  router configuration.   A few  of the sites  currently
  885. using RtConfig include the Routing Arbiter Project (USA), ANS (USA),  CA*Net
  886. (Canada),  IMNet (Japan),  VERIO  (USA),  Oregon-IX  (USA),  IAfrica  (South
  887. Africa), Connect (Australia).  The next section describes a methodology  for
  888.  
  889.  
  890.  
  891.  
  892.  
  893. Meyer et.  al.              Expires  January 29, 1998              [Page 16]
  894. Internet Draft               Application of RPSL               July 29, 1997
  895.  
  896.  
  897.  
  898.  
  899.  
  900.  
  901.  
  902.  
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.              Figure 14:  Autonomous System object editor (aoe).
  926.  
  927.  
  928.  
  929. generating vendor specific router configurations using RtConfig.(3)
  930.  
  931.  
  932. 4.1 Using RtConfig
  933.  
  934.  
  935. The general paradigm for  using RtConfig involves  registering policy in  an
  936. IRR, building a RtConfig source file, then running running RtConfig  against
  937. the source  file and  the  IRR database  to  create vendor  specific  router
  938. configuration for the specified policy.  The source file will contain vendor
  939. specific commands as well as RtConfig commands.  To make a source file, pick
  940. up one of your  router configuration files and  replace the vendor  specific
  941. policy configuration commands with the RtConfig commands.
  942.  
  943. Commands beginning  with  @RtConfig  instruct RtConfig  to  perform  special
  944. ------------------------------
  945.  3.  Discussion of RtConfig internals is beyond the scope of this document.
  946.  
  947.  
  948.  
  949. Meyer et.  al.              Expires  January 29, 1998              [Page 17]
  950. Internet Draft               Application of RPSL               July 29, 1997
  951.  
  952. operations.   An  example  source file  is shown  in  Figure 15.    In  this
  953. example, commands such as  ``@RtConfig import AS3582 198.32.162.1/32  AS3701
  954. 198.32.162.2/32'' instruct  RtConfig  to  generate  vendor  specific  import
  955. policies where the router  198.32.162.1 in AS3582  is importing routes  from
  956. router 198.32.162.2 in AS3701.   The other  @RtConfig commands instruct  the
  957. RtConfig to use certain  names and numbers in  the output that it  generates
  958. (please refer to RtConfig manual [2] for additional information).
  959.  
  960.  
  961.   router    bgp 3582
  962.   network   128.223.0.0
  963.   !
  964.   !       Start with access-list 100
  965.   !
  966.   @RtConfig set cisco_access_list_no = 100
  967.   !
  968.   !       NERO
  969.   !
  970.   neighbor 198.32.162.2 remote-as 3701
  971.   @RtConfig set cisco_map_name = "AS3701-EXPORT"
  972.   @RtConfig export AS3582 198.32.162.1/32 AS3701 198.32.162.2/32
  973.   @RtConfig set cisco_map_name = "AS3701-IMPORT"
  974.   @RtConfig import AS3582 198.32.162.1/32 AS3701 198.32.162.2/32
  975.   !
  976.   !       WNA/VERIO
  977.   !
  978.   neighbor 198.32.162.6 remote-as 2914
  979.   @RtConfig set cisco_map_name = "AS2914-EXPORT"
  980.   @RtConfig export AS3582 198.32.162.1/32 AS2914 198.32.162.6/32
  981.   @RtConfig set cisco_map_name = "AS2914-IMPORT"
  982.   @RtConfig import AS3582 198.32.162.1/32 AS2914 198.32.162.6/32
  983.   ...
  984.  
  985.  
  986.                      Figure 15:  RtConfig Template File
  987.  
  988. Once a  source file  is created,  the  file is  processed by  RtConfig  (the
  989. default IRR is the RADB, and the default vendor is Cisco; however,  RtConfig
  990. or command line options can be used  to override these values).  The  result
  991. of running RtConfig on the source file in Figure 15 is shown in Figure 16.
  992.  
  993.  
  994. References
  995.  
  996.  
  997. [1] C.   Alaettinouglu.   RAToolSet  Routing   Policy  Analysis   Tool   Set.
  998.     Marina   del    Rey,   CA    90292,   March    1996.   Available    from
  999.     http://www.isi.edu/ra/RAToolSet.
  1000.  
  1001. [2] C. Alaettinouglu. RtConfig Manual. Marina del Rey,  CA 90292, March 1996.
  1002.     Available from http://www.isi.edu/ra/RAToolSet.
  1003.  
  1004.  
  1005. Meyer et. al.              Expires  January 29, 1998               [Page 18]
  1006. Internet Draft               Application of RPSL               July 29, 1997
  1007.  
  1008. [3] C. Alaettinouglu,  T. Bates, E. Gerich,  D. Karrenberg, M. Terpstra,  and
  1009.     C. Villamizer.  Routing Policy Specification  Language (RPSL).  Internet
  1010.     Draft  draft-ietf-rps-rpsl-00.txt,  Network  Information  Center,  March
  1011.     1996. Revised, June 1996.
  1012.  
  1013. [4] T.  Bates,  E. Gerich,  L.  Joncheray, J-M.  Jouanigot,  D.  Karrenberg,
  1014.     M.  Terpstra, and  J. Yu.  Representation of  IP Routing  Policies in  a
  1015.     Routing Registry. Technical Report ripe-181, RIPE, RIPE  NCC, Amsterdam,
  1016.     Netherlands, October 1994.
  1017.  
  1018. [5] T.  Bates,  E. Gerich,  L.  Joncheray, J-M.  Jouanigot,  D.  Karrenberg,
  1019.     M.  Terpstra,  and J.  Yu.  Representation  of IP  Routing  Policies  in
  1020.     a  Routing  Registry.  Technical Report  RFC-1786,  Network  Information
  1021.     Center, March 1995.
  1022.  
  1023. [6] R. Chandra,  P. Traina, and  T. Li.  BGP Communities Attribute.  Request
  1024.     for Comment RFC-1997, Network Information Center, August 1996.
  1025.  
  1026. [7] E. Chen and T.  Bates. An Application of the BGP Community Attribute  in
  1027.     Multi-Home Routing.  Request for  Comment RFC-1998, Network  Information
  1028.     Center, August 1996.
  1029.  
  1030. [8] H.      Nussbacher.      The     CIDR      FAQ.      Available      from
  1031.     http://www.ibm.net.il/ hank/cidr.html.
  1032.  
  1033. [9] Y. Rekhter and T.  Li. A Border Gateway Protocol 4 (BGP-4). Request  for
  1034.     Comment RFC-1771, Network Information Center, March 1995.
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061. Meyer et.  al.              Expires  January 29, 1998              [Page 19]
  1062. Internet Draft               Application of RPSL               July 29, 1997
  1063.  
  1064.  
  1065.   router    bgp 3582
  1066.   network   128.223.0.0
  1067.   !
  1068.   !       NERO
  1069.   !
  1070.   neighbor 198.32.162.2 remote-as 3701
  1071.  
  1072.   no access-list 100
  1073.   access-list 100 permit ip 128.223.0.0   0.0.0.0   255.255.0.0   0.0.0.0
  1074.   access-list 100 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
  1075.   !
  1076.   !
  1077.   no route-map AS3701-EXPORT
  1078.   route-map AS3701-EXPORT permit 1
  1079.    match ip address 100
  1080.   !
  1081.   router bgp 3582
  1082.   neighbor 198.32.162.2 route-map AS3701-EXPORT out
  1083.   !
  1084.   !
  1085.   no route-map AS3701-IMPORT
  1086.   route-map AS3701-IMPORT permit 1
  1087.    set local-preference 1000
  1088.   !
  1089.   router bgp 3582
  1090.   neighbor 198.32.162.2 route-map AS3701-IMPORT in
  1091.   !
  1092.   !       WNA/VERIO
  1093.   !
  1094.   neighbor 198.32.162.6 remote-as 2914
  1095.   !
  1096.   no route-map AS2914-EXPORT
  1097.   route-map AS2914-EXPORT permit 1
  1098.    match ip address 100
  1099.   !
  1100.   router bgp 3582
  1101.   neighbor 198.32.162.6 route-map AS2914-EXPORT out
  1102.   no ip as-path access-list  100
  1103.   ip as-path access-list 100 permit ^_2914(((_[0-9]+))*_             \
  1104.         (13|22|97|132|175|668|1914|2905|2914|3361|3381|3791|3937|    \
  1105.          4178|4354|4571|4674|4683|5091|5303|5798|5855|5856|5881|6083 \
  1106.          |6188|6971|7790|7951|8028))?$
  1107.   !
  1108.   no route-map AS2914-IMPORT
  1109.   route-map AS2914-IMPORT permit 1
  1110.    match as-path 100
  1111.    set local-preference 998
  1112.   !
  1113.   router bgp 3582
  1114.   neighbor 198.32.162.6 route-map AS2914-IMPORT in
  1115.   !
  1116. Me!yothereciscorcommandset.  al.              Expires  January 29, 1998              [Page 20]
  1117.  
  1118.  
  1119.  
  1120.                        Figure 16:  Output of RtConfig
  1121.