home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / sdr / sdr-minutes-94dec.txt < prev    next >
Text File  |  1995-02-28  |  4KB  |  83 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Tony Li/cisco Systems
  5.  
  6. Minutes of the Source Demand Routing Working Group (SDR)
  7.  
  8.  
  9.  
  10. SDR Status
  11.  
  12. SDR Status was presented by Deborah Estrin.  The document has been
  13. submitted as an Experimental RFC. The protocol remains tied solely to
  14. IPv4 and demand in quiescent.  Vendor support is needed to produce more
  15. implementations so that special services can be supported over SDR, but
  16. vendors are hesitant because it is still hard to present a clear
  17. business case.
  18.  
  19.  
  20. ERP Draft
  21.  
  22. The current ERP draft was presented by Peter Ford.  ERP is the follow on
  23. from GRE and SDR specifically targeted for IPv6.  There is an existing
  24. Internet-Draft on the protocol, as well as a related draft on the
  25. concept of ``packs.''  The primary change from SDR is that ERP is
  26. carried as an IPv6 option.  There are still several open issues related
  27. to the mechanisms for nested source routing.  One mechanism is to
  28. perform explicit recursive tunneling, invoking a new packet header and
  29. ERP option for each layer of tunneling.  Alternatively, the previous
  30. source route information can be nested within the ERP option.  This can
  31. be viewed as a space-time tradeoff, with explicit recursive tunneling
  32. being high space low time, while stacking information within ERP is low
  33. space and high time.  There is not yet consensus on how to proceed on
  34. this issue, but it is hoped that implementation experience will drive
  35. the decision.
  36.  
  37.  
  38. Work In Progress On Route Construction
  39.  
  40. Work in progress on route construction was presented by Kannan Varadhan
  41. and Deborah Estrin.  The primary thrust here is to develop additional
  42. hooks into IDRP for SDR/ERP and route server support.  In the longer
  43. term several people are working on path explorers with constraints
  44. (Hotz, Rekhter, Estrin, Brijesh).  Route servers maintain multiple views
  45. of the routing infrastructure, one view per desired perspective.  These
  46. systems are being deployed at the NAPs, and will hopefully help scale
  47. the number of external connections that a router will need.  Route
  48. servers can also assist route computation for explicit routes by
  49. providing remote data services to base the computation on.  There are
  50. already some mechanisms for obtaining information from a route server,
  51. such as performing a RIB query.  There is also interest in generating a
  52. path explorer, which would cause a particular special route to be
  53. introduced and propagated into the normal routing fabric, however, its
  54. scope would be constrained so that there would be no scaling issues.
  55.  
  56. Another mechanism for extracting data from the route server is a Routing
  57. Information Filter.  Each filter element consists of a tuple (action,
  58. NLRI, scope, Base).  Actions are ALLOW (add an NLRI to the reported
  59. ones), RESTRICT (ignore an NLRI), or REMOVE (remove a restriction).
  60. Scope can be EXACT (exact match), REFINE (longer matches), NORMAL (exact
  61. or longer) and REACHABILITY (longest match).  Base is the information
  62. base to select data from.  There was some concern that this mechanism
  63. needs to be more extensible so that more complex data filtering can be
  64. performed.
  65.  
  66.  
  67. Other Issues
  68.  
  69. Deborah Estrin closed the session by listing a number of other issues
  70. which need attention.  More work needs to be done on interactions
  71. between SDR and multicast.  Currently, PIM is being designed to support
  72. SDR routes to guide joins, thereby passing an explicit route to the
  73. multicast tree.  Installing this route and using it and preventing
  74. looping, however is an open issue.  There is significant work to be done
  75. on how RSVP would interact with SDR. For a note describing preliminary
  76. work in this area contact zappala@isi.edu.  There was also a discussion
  77. of what security and authentication needs to be present in SDR. The
  78. group came to the conclusion that it was a nontrivial problem, as simple
  79. end-to-end authentication is insufficient.
  80.  
  81. And, as always, we need to have someone work on the MIB.
  82.  
  83.