home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / sdr / sdr-minutes-93jul.txt < prev    next >
Text File  |  1993-09-10  |  7KB  |  165 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5.  
  6. Reported by Peter Ford/Los Alamos National Laboratory
  7.  
  8. Minutes of the Source Demand Routing Working Group (SDR)
  9.  
  10. Tony Li opened the meeting and bashed the agenda into shape.  It was
  11. subsequently dynamically reordered.
  12.  
  13. Deborah Estrin gave an overview of SDRP, noting the specification for
  14. SDRP has not changed since the last meeting.  She requested that people
  15. read the specification and provide more comments.
  16.  
  17. Deborah reported on a prototype implementation by Daniel Zapalla at USC
  18. based on the SunOS DARTnet kernel.  Tests were conducted on a small
  19. 4-node testbed at USC, and on DARTnet.  There is a kernel interface
  20. establishing source routes, filtering and encapsulation.  There is a
  21. routing socket interface for the D-FIB.
  22.  
  23. USC is interested in seeing more people pick up the code and build
  24. experimental testbed islands, and then interconnecting them for later
  25. interdomain experimentation.
  26.  
  27. Christian Huitema asked about anycast, and Yakov noted that the AS
  28. number is a group address.  Further work remains to be done in defining
  29. the requirements for anycasting, but there appears to be nothing in the
  30. SDRP specification that would be a substantial limitation.
  31.  
  32. Tony Li reported on his work on BGP/IDRP interaction with SDRP. The
  33. original idea was to route SDRP control messages to AS representatives
  34. (e.g.  to query AS for policy).  This functionality is possible by
  35. changing routing of control messages, with the last address being an AS
  36. address.  Thus the BGP attribute is no longer needed for this
  37. functionality.  Tony will fix the specification to reflect this change.
  38. The IDRP attribute is still useful for tunneling.  Yakov has a draft of
  39. this attribute and will post it as an Internet-Draft shortly.
  40.  
  41. Tony reported on the policy language he has been working on.  It is
  42. C-like.  Tony would like to get more comments on the specification.  The
  43. evaluation of policy is boolean.  The functionality will be familiar to
  44. people who are familiar with cisco access lists.  The OR operator
  45. (distinct from ||) can be used to ignore a term which cannot be
  46. evaluated (bottom).  Christian Huitema suggested that the access control
  47. aspects of this language should be checked against the work on IP
  48. security.  Future work will include policy based on source and
  49. destination AS number (using the DNS?), source and destination
  50. communities, and there may be some work on richer pattern matching on
  51. the entire SDRP route if there is a need.  There could be some work on
  52. time varying characteristics, such as load or delay.  Steve Hotz sent
  53. mail suggesting that Tony think about evaluating policy terms to
  54. preference continuous values instead of boolean values.
  55.  
  56. Tony reported on his work on Information Distribution.  The plan is to
  57. get the current AS topology from some static source.  It was suggested
  58. to see RIPE-81 for an expression of this information.  Christian noted
  59. that we probably need to consider higher levels of aggregation of this
  60. information above ASs.
  61.  
  62. Deborah stated that she needs to do a rework of the futures document
  63. which deals with scaling issues.  She will update the document.
  64.  
  65. Deborah reported on SDRP setup work.  Setup is done via an explicitly
  66. source routed packet with the probe bit set.  The motivation for these
  67. setups is to reduce the header size.  It is not a requirement for a
  68. router to participate.  It can strip the probe bit, send it ahead, and
  69. send a setup rejected message back to the originator.
  70.  
  71. There was a question if the routers have to maintain information on
  72. source routes that it is currently setup for:  the answer was yes.  It
  73. was again noted that this is soft state.
  74.  
  75. There is a draft specification of SDRP Setup that will be distributed
  76. later in the summer.
  77.  
  78. Christian stated that setup needs to be investigated to see what its
  79. interactions are with regard to load splitting.
  80.  
  81. Deborah noted additional work that will be considered, including
  82. multicast (and its relationship to ESL). This would be used to establish
  83. branches on multicast trees.  There also needs to be better tools for
  84. building SDRP routes.
  85.  
  86.  
  87. Task List:
  88.  
  89. 1)  Review of Specification.  Tony will lead a section by section read 
  90.     of the document at the next IETF.  Christian Huitema, Keith Mitchell, 
  91.     Shezahd Merchant agreed to read the entire specification and comment 
  92.     as soon as possible.
  93.  
  94. 2)  MIB -- Yakov will find someone to do this.
  95.  
  96. 3)  Usage Internet-Draft -- Peter Ford
  97.  
  98. 4)  Gated hack needed to populate D-FIB.  Sue Hares/John Scudder
  99.  
  100. 5)  Experiments with SDRP
  101.  
  102.     Merit -- Hares and Scudder
  103.     Lothberg
  104.     Scott Brim - maybe
  105.  
  106. 6)  Mapping packets/ packet classification
  107.  
  108. 7)  DNS support for IP to AS number mapping
  109.         Peter Ford will talk with RIPE-81 people
  110.  
  111. 8)  Policy Language -- Tony Li and Steve hotz 
  112.  
  113. 9)  Request/Response protocol -- Tony Li
  114.  
  115. 10) Futures Update -- Deborah
  116.  
  117. 11) Tony will do two specification changes for:
  118.  
  119.     passing control messages to ASs
  120.     setup -- translate request to explicit route
  121.  
  122.  
  123. Attendees
  124.  
  125. Michael Anello           mike@xlnt.com
  126. Toshiya Asaba            asaba@iij.ad.jp
  127. Cynthia Bagwell          cbagwell@gateway.mitre.org
  128. Dennis Baker             dbaker@wellfleet.com
  129. John Ballard             jballard@microsoft.com
  130. John Burnett             jlb@adaptive.com
  131. Ross Callon              rcallon@wellfleet.com
  132. Henry Clark              henryc@oar.net
  133. Francis Dupont           francis.dupont@inria.fr
  134. Deborah Estrin           estrin@usc.edu
  135. Dino Farinacci           dino@cisco.com
  136. Peter Ford               peter@goshawk.lanl.gov
  137. Vince Fuller             vaf@stanford.edu
  138. Susan Hares              skh@merit.edu
  139. Denise Heagerty          denise@dxcoms.cern.ch
  140. Frank Hoffmann           hoffmann@dhdibm1.bitnet
  141. Nandor Horvath           horvath@sztaki.hu
  142. David Jacobson           dnjake@vnet.ibm.com
  143. John Krawczyk            jkrawczy@wellfleet.com
  144. Tony Li                  tli@cisco.com
  145. Robin Littlefield        robin@wellfleet.com
  146. Jun Matsukata            jm@eng.isas.ac.jp
  147. Keith Mitchell           keith@pipex.net
  148. Ramin Najmabadi          najmabadi@helios.iihe.rtt.be
  149. Peder Chr.  Noergaard    pcn@tbit.dk
  150. Erik Nordmark            nordmark@eng.sun.com
  151. Petri Ojala              ojala@eunet.fi
  152. Juergen Rauschenbach     jrau@dfn.de
  153. James Reeves             jreeves@synoptics.com
  154. Yakov Rekhter            yakov@watson.ibm.com
  155. Duncan Rogerson          d.rogerson@nosc.ja.net
  156. Shawn Routhier           sar@epilogue.com
  157. John Scudder             jgs@merit.edu
  158. John Stewart             jstewart@cnri.reston.va.us
  159. Fumio Teraoka            tera@csl.sony.co.jp
  160. Paul Traina              pst@cisco.com
  161. Rene van der Hauw        rene@geveke.nl
  162. Willem van der Scheun    scheun@sara.nl
  163. Jost Weinmiller          jost@prz.tu-berlin.d400.de
  164. Jessica Yu               jyy@merit.edu
  165.