home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / idpr / idpr-minutes-92jul.txt < prev    next >
Text File  |  1993-02-17  |  6KB  |  158 lines

  1. Editor's Note: Minutes received 8/5
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by Martha Steenstrup/BBN
  7.  
  8. Minutes of the Inter-Domain Policy Routing Working Group (IDPR)
  9.  
  10. The IDPR Working Group met in two sessions during the July 1992 IETF
  11. meeting in Boston.  In the first session we talked about shorter-term as
  12. well as longer-term work on IDPR, and in the second session we offered a
  13. spur-of-the-moment demo and shared the remainder of the session with the
  14. NIMROD Group.
  15.  
  16. Shorter-term Topics
  17.  
  18.  
  19.    o Work on the Gated Version of IDPR. Currently, Woody Woodburn has a
  20.      version of IDPR that runs as part of gated.  Woody provided a
  21.      detailed description of the status of the gated implementation at
  22.      the first session and at the second session gave a demo of the
  23.      software.  To obtain a copy of the IDPR software, please contact
  24.      woody@sparta.com.  We plan a pilot demonstration of this software
  25.      in the Internet in late summer or early fall.  Moreover, we expect
  26.      that, as a result of this experimentation, we will want to make
  27.      changes to the software and perhaps to the protocols as well.  The
  28.      IDPR Working Group needs a set of people that are able and
  29.      interested in working on enhancing the IDPR gated software.
  30.  
  31.    o MIB Development.  We need to implement the MIB, and we need to
  32.      update the Internet Drafts describing both the IDPR MIB and the
  33.      IDPR configuration and usage guide.
  34.  
  35.    o Adding Facilities to the DNS. The DNS should be able to return
  36.      domain information in response to a query giving entity name or
  37.      address.
  38.  
  39.    o Adding the Capability for Hosts to Request Source Policies
  40.      Dynamically.  In the current version of IDPR, source policies are
  41.      specified as part of path agent configuration and remain active for
  42.      a given host until they are reconfigured.  Thus, hosts needn't do
  43.      anything special to communicate this information to the path
  44.      agents.  We made this choice so that no host changes were necessary
  45.      to reap the benefits of IDPR. However, we expect that in the
  46.      future, hosts may want to have different source policies, depending
  47.      upon the application active at the moment, and hence need a way to
  48.      communicate this information to the path agents.  SRI is working on
  49.      a subset of this problem, but we may require a more general
  50.      solution.
  51.  
  52.  
  53. At the Working Group sessions, several of you volunteered to work on the
  54. shorter-term topics, pending approval from employers.  Would those of
  55. you who have obtained such approval and who are still interested in
  56.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63. working on these topics, please send mail to me at msteenst@bbn.com so
  64. that we can move these efforts along.
  65.  
  66. Longer-term Topics
  67.  
  68.  
  69.    o Multicast Support.  IDPR should have the ability to construct
  70.      multicast trees and establish the appropriate paths associated with
  71.      these trees.  Moreover, IDPR should be able to take advantage of
  72.      intra-domain multicast where available, both for IDPR control
  73.      information distribution and for multicast user applications.  We
  74.      are pursuing solutions targeted for IDPR. However, those of you
  75.      interested in inter-domain multicasting in general may also wish to
  76.      join the mailing list set up by Jon Crowcroft and Tony Ballardie of
  77.      UCL. To subscribe to the list, send email to
  78.      idmr-request@cs.ucl.ac.uk.
  79.  
  80.    o Multipath Support.  IDPR should have the ability to maintain as a
  81.      unit multiple paths of the same service between the same source and
  82.      destination.  Multiple paths provide a vehicle for obtaining
  83.      sufficient bandwidth, for load-balancing, and for providing backups
  84.      when a primary path fails.
  85.  
  86.    o Resource Allocation.  IDPR should be able to interoperate with
  87.      resource reservation and flow control mechanisms to provide service
  88.      guarantees.
  89.  
  90.    o Super Domains.  As the Internet grows, one may wish to aggregate
  91.      domains into super domains in order to reduce the amount of
  92.      information and computation related to routing.  Aggregation
  93.      produces a hierarchy of domains.  IDPR should provide a domain
  94.      address format that permits addressing of domains at arbitrary
  95.      positions in a domain hierarchy.
  96.  
  97.  
  98. Any comments on any of these topics are most welcome on the IDPR mailing
  99. list, idpr-wg@bbn.com.
  100.  
  101. Attendees
  102.  
  103. Nagaraj Arunkumar        nak@3com.com
  104. Robert Austein           sra@epilogue.com
  105. William Babson           bill@penril.com
  106. Tony Ballardie           a.ballardie@cs.ucl.ac.uk
  107. Tony Bates               tony@ean-relay.ac.uk
  108. James Beers              beers@nr-tech.cit.cornell.edu
  109. Lou Berger               lberger@penril.com
  110. David Bridgham           dab@epilogue.com
  111. Alan Bryenton            bryenton@bnr.ca
  112. John Chang               jrc@uswest.com
  113. Robert Ching             natadm!rching@uunet.uu.net
  114. Bilal Chinoy             bac@sdsc.edu
  115.  
  116.                                    2
  117.  
  118.  
  119.  
  120.  
  121.  
  122. Michael Craren           mjc@proteon.com
  123. Osmund de Souza          osmund.desouza@att.com
  124. Irina Dobrina            irina@ftp.com
  125. Tom Farinelli            tcf@tyco.ncsc.mil
  126. Elise Gerich             epg@merit.edu
  127. William Haggerty         haggerty@ctron.com
  128. Dimitry Haskin           dhaskin@bbn.com
  129. Steven Hubert            hubert@cac.washington.edu
  130. Takashi Ikemoto          tikemoto@xerox.com
  131. Bob Jeckell              rrj@3com.com
  132. Matthew Jonson           jonson@server.af.mil
  133. Michael Khalandovsky     mlk@ftp.com
  134. John Krawczyk            jkrawczy@wellfleet.com
  135. Whay Lee                 whay@merlin.dev.cdx.mot.com
  136. Tony Li                  tli@cisco.com
  137. Anthony Lisotta          lisotta@nas.nasa.gov
  138. Ed Menze                 menze@cs.arizona.edu
  139. Shehzad Merchant         merchant@erg.sri.com
  140. Donald Merritt           don@brl.mil
  141. Kraig Owen               tko@merit.edu
  142. Lars Poulsen             lars@cmc.com
  143. Stephanie Price Marasciulloprice@cmc.com
  144. Manoel Rodrigues         manoel_rodrigues@att.com
  145. Karen Seo                kseo@bbn.com
  146. Frank Solensky           solensky@clearpoint.com
  147. Martha Steenstrup        msteenst@bbn.com
  148. Fumio Teraoka            tera@csl.sony.co.jp
  149. Huyen Vu                 vi@polaris.disa.mil
  150. David Wang               wang@xylogics.com
  151. Luanne Waul              luanne@wwtc.timeplex.com
  152. Steven Winnett           swinnett@bbn.com
  153. Robert Woodburn          woody@cseic.saic.com
  154.  
  155.  
  156.  
  157.                                    3
  158.