home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rps / rps-minutes-95jul.txt < prev    next >
Text File  |  1995-10-18  |  8KB  |  226 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by Susan Hares/Merit
  6.  
  7. Minutes of the Routing Policy System Working Group (RPS)
  8.  
  9.  
  10.  
  11. Agenda
  12.  
  13.    o Logistics
  14.    o Status on IRR (Daniel Karrenberg)
  15.    o AS path expressions extensions to RIPE-181 (Cengiz Alaettinoglu)
  16.    o Database distribution (Daniel Karrenberg)
  17.    o RPSL policy term (Cengiz Alaettinoglu)
  18.    o Dictionary object (Craig Labovitz)
  19.    o RPSL syntax alternatives (Cengiz Alaettinoglu)
  20.    o Review of work plan until next meeting
  21.  
  22.  
  23. All agenda topics were covered on Tuesday, 18 July, except database
  24. distribution which was covered on Wednesday, 19 July.  Items are
  25. reported in order of the agenda instead of chronological order.
  26.  
  27.  
  28.  
  29. Status Reports
  30.  
  31.  
  32. The following reports were given:
  33.  
  34.  
  35.    o RA (Brian Renaud)
  36.      The RA continues to cleanup the RADB from the PRDB to RADB changes.
  37.      20,000 networks have network prefixes more specific than other
  38.      prefixes.  The RA wants to cleanup these prefixes or mark them as
  39.      withdrawn.
  40.      Interactions with CA*NET and InternetMCI RRDB are in progress.
  41.  
  42.    o RIPE NCC (Daniel Karrenberg)
  43.      Registry based in Europe.  Most AS or upstream providers have put
  44.      in AS maintainer objects.  Consistency checking with other
  45.      registries is part of the on-going work.
  46.  
  47.  
  48. Reports were not given for CA*NET and InternetMCI.
  49.  
  50. Randy Bush asked why register in two databases?  Brian Renaud stated
  51. that it is not needed at this time and MCI agrees.
  52.  
  53.  
  54.  
  55. AS Path Expressions
  56.  
  57. (See Cengiz's slides.  All slides are available at
  58. ftp://ftp.isi.edu/rps/stockholm-ietf.)
  59.  
  60. The focus of Cengiz's information is to allow an extended AS path syntax
  61. that allows extended AS path syntax and current syntax to work with
  62. existing tools and new tools.  If both the old and the new syntax are
  63. used, the policy should be roughly the same.  It was noted that the
  64. policy expressed might not be exactly the same.
  65.  
  66. Tony Bates suggested using AS macros in AS path expressions and the
  67. group agreed to this.  Tony and Andrew Partan noted that the AS macro
  68. expansion should expand to either the old syntax for AS path expansions
  69. or the new syntax.
  70.  
  71. This new syntax has been added to RA tools.  Other tool builders (e.g.,
  72. Tony Bates of MCI and Marten Terpstra of Bay Networks) indicated their
  73. interest in these extended as path expressions.
  74.  
  75. Any further expansion should be made with RPSL.
  76.  
  77.  
  78.  
  79. Database Distribution
  80.  
  81. Daniel Karrenberg presented the paper drafted by David Kessens and
  82. Cengiz Alaettinoglu.
  83.  
  84. The problem with database distribution is that the distribution has n**2
  85. problem with the number of registries that need to be updated.  The
  86. granularity of current updates is 1/24 hours as files are FTPed from
  87. site to site.  User interfaces may not be the same across registries.
  88.  
  89. Daniel Karrenberg proposed:
  90.  
  91.  
  92.    o Updating to authoritative registry
  93.      The receiving registry would forward the update request to the
  94.      authoritative registry for the object.  If the authoritative
  95.      registry is unknown, it would be bounced.
  96.  
  97.    o Updates will be split apart from a full database dump
  98.      Each update will contain (for adds/deletes) time stamp, sequence
  99.      number, and registry name.  Each update will be checksummed with
  100.      MD5.
  101.  
  102.    o Full database fetched (FTP)
  103.      Each full database has time stamp and sequence number of the last
  104.      update processed.  The full database pull will be checksummed
  105.      (MD5?)  to ensure the data is correct.
  106.  
  107.    o Journal files will contain updates
  108.      Each journal file will contain updates that can be applied after
  109.      the last full database pull.  Each journal updates will contain
  110.      time stamp, sequence number and registry.
  111.  
  112.    o Asynchronous updates should be possible to send to users
  113.      This service will be subscribed to.  Subscribers will receive (via
  114.      e-mail or other transport) the updates listed above as they occur.
  115.  
  116.  
  117. The group discussed how to get consistency working across databases.
  118. The focus was using maintainer objects which specified priority of
  119. registries.  Tony Bates and Marten Terpstra noted that multiple
  120. maintainer objects can exist for routing objects.  Since the frequence
  121. of new maintainer objects is low, time stamps and human interaction can
  122. be used in the 4 databases to resolve differences.
  123.  
  124. The group recommended that the history of the databases needed to be two
  125. full copies backward plus associated journal files.
  126.  
  127. Bill Manning and Paul Vixie discussed using the DNS as a Routing
  128. Registry.  Weakness in DNS was:  bootstrapping problem (Michael Patton),
  129. indexing and problems with the tools for consistency checking.
  130. Strengths of DNS are its hierarchical nature and the methods by which it
  131. delegates to others.
  132.  
  133. Those who wish to experiment may.  If databases grow, within two years
  134. we may need a hierarchical solution.  Bill will find an RA draftee to
  135. experiment with a DNS based routing registry idea.
  136.  
  137. Holing punches in CIDR blocks has been addressed by RIPE-127.  The
  138. current code does support this.  Daniel volunteered to publish this fact
  139. to the list.
  140.  
  141.  
  142.  
  143. RPSL Policy Term
  144.  
  145. (See Cengiz Alaettinoglu's slides for full a description.)
  146.  
  147. RPSL policy terms have an event name, a filter, event parameters, and
  148. actions.  The split of event name, filter and actions is for efficiency
  149. of processing.  Five options were discussed for the interaction of
  150. different policy terms.  Consensus was to go with one of the two
  151. options:  specification order or a combination with the overrides rule.
  152. The combination would use the overrides rule within a policy terms and
  153. specification order between policy terms in the database.
  154.  
  155. It was asked why this discussion is occurring and suggested that the
  156. group concentrate on getting the tools working with simple policy.
  157. Cengiz responded that for simple cases, policy is simple.  For more
  158. complicated cases, it will aid.  However, it appears that documents
  159. indicating the application will be needed for the working group.
  160.  
  161.  
  162.  
  163. Dictionary Object
  164.  
  165. (See Craig Labovitz's slides.)
  166.  
  167. The dictionary provides extensibility to the language.  The dictionary
  168. would contain current descriptions plus reference implementation.  The
  169. documents would contain syntax description plus a place to point to for
  170. reference implementations.
  171.  
  172. New changes to the RPSL would include shared libraries or perl code that
  173. could be loaded.
  174.  
  175. Andrew Partan and others wondered that the Dictionary seemed two steps
  176. ahead of the current technology.  He was more interested in seeing more
  177. tools with current things.
  178.  
  179.  
  180. RPSL Syntax Alternatives
  181.  
  182. Should the RIPE-181 syntax be extended or replaced by a new syntax?  In
  183. the extended RIPE-181 syntax, interas-in and interas-out syntax is
  184. replaced by an extended as-in and as-out syntax.
  185.  
  186. If a completely new syntax is used, programs would just read in the new
  187. syntax elegantly.  If the RIPE syntax is extended, tools using it will
  188. have to be compatible with the old syntax using hacks.
  189.  
  190. Tony Bates thought it would be good to have both new syntax for the
  191. as-in and as-out plus get rid of the interas-in.  At the time it was
  192. created it was thought that the separation of local and global policy
  193. was important.
  194.  
  195.  
  196. Review of Work Plan Until Next Meeting
  197.  
  198. Items to do for the next meeting:
  199.  
  200.  
  201.    o Daniel Karrenberg will write a registry object definition paper.
  202.  
  203.    o Daniel will write a document outlining his proposed approach on
  204.      coordinating databases.
  205.  
  206.    o Cengiz and David Kessens will write a document on the consistency
  207.      model that gets rid of the source attribute and uses the
  208.      authoritative registry idea based on the maintainer object.  There
  209.      was consensus to go with this approach rather than the multiple
  210.      sources approach.
  211.  
  212.    o Daniel will announce the non-hole punching option in CIDR block to
  213.      the list.  (The status field now has a PI/PA function.)
  214.  
  215.    o Daniel and Marten Terpstra will examine all RIPE documents and
  216.      publish what changes needed to be done to them.  The working group
  217.      will then begin to re-write the RIPE documents as RPS documents.
  218.      This change is subject to RIPE DB Working Group and the Area
  219.      Director's approval
  220.  
  221.    o RPSL Language
  222.      Cengiz, Craig Labovitz and Marten Terpstra and other Routing
  223.      Registry people will continue work on this and report back at the
  224.      next IETF.
  225.  
  226.