home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / INET / IETF / SDR / 94JUL.MIN < prev    next >
Encoding:
Text File  |  1994-08-08  |  2.7 KB  |  52 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3. Date: Tue, 2 Aug 1994 23:50:42 -0700
  4. From: Tony Li <tli@cisco.com>
  5. Subject: SDR WG minutes
  6.  
  7.  
  8.    The SDRP forwarding protocol and prototype has been stable for some
  9.    time. There are two issues now facing the working group: 1. mechanisms
  10.    for constructing source routes to make the forwarding code useful, 2.
  11.    working with IPng folks to support SDR functionality. Looking a bit
  12.    farther ahead, we should be addressing  the SDR routing requirements
  13.    raised by integrated-services/RSVP traffic. This meeting was composed
  14.    of  two parts: a discussion of RIB query support in IDRP to support
  15.    SDR route construction, and a joint meeting  with the IPng working
  16.    group to present a strawman proposal on SDR support in IPng. 
  17.  
  18.    As introduction to the IDRP support discussion, Deborah Estrin
  19.    reviewed the two basic route construction approaches under
  20.    development: RIB query and Path explorer.  Activity has been
  21.    focused mainly at USC/ISI and Merit. 
  22.  
  23.    Sue Hares presented some new functionality to enable route computation
  24.    by obtaining information through IDRP.  The mechanisms permit a node
  25.    to query an IDRP speaker via a IDRP Rib Refresh message, with the
  26.    response being a series of Update messages.  The facility allows the
  27.    requestor to get a single snapshot of the IDRP speaker's database, or
  28.    to get a continuous series updates, effectively forming a one-way IDRP
  29.    peering.  The requestor can specify particular attributes in the
  30.    information request, including QOS and NLRI criteria.  
  31.  
  32.    The response can contain information from the IDRP speaker's Loc_rib
  33.    or Adj_Rib, so that the requestor also learns some information about
  34.    all of the IDRP speaker's neighbors.  The end of the initial response
  35.    is also clearly delimited by a message so that the requestor can begin
  36.    computation.
  37.  
  38.    Estrin briefly addressed two related issues: one was the role of the
  39.    Route Server/Routing Arbiter in route construction and aquisition, and
  40.    the second was the proposed use of SDR routes to guide multicast
  41.    (e.g., PIM) join messages along alternate routes to join the
  42.    distribution tree, when the generic unicast route is inadequate. 
  43.  
  44.    The working group then went to a joint session with the IPv6
  45.    working group, where SDR for IPv6 was discussed.  Peter Ford
  46.    presented a basic proposal in which SDR would become an optional
  47.    header in an IPv6 packet.  There was some inconclusive discussion
  48.    about the utility of strict source routing and for the requirement
  49.    of policy routing in general.  After this discussion, it was
  50.    decided that SDR for IPv6 is indeed of interest and that this work
  51.    should continue in the SDR working group.
  52.