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

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by Ross Callon/DEC
  6.  
  7. IS-IS Minutes
  8.  
  9. The IS-IS Working Group met at the IETF meeting in Atlanta, Georgia.
  10. There were two topics of discussion:  A brief overview of the status of
  11. the IS-IS spec (led by Ross Callon), and a presentation and longer
  12. discussion of the SNMP MIB for IS-IS (led by Chris Gunner).
  13.  
  14.  
  15.   1. Status of IS-IS
  16.      Ross reported that the OSI IS-IS Intra-Domain routing protocol (ISO
  17.      DIS 10589) has completed the Draft International Standard (DIS)
  18.      ballot, and all ballot comments were successfully resolved at a
  19.      recent ISO meeting.  This implies that the ISO IS-IS will be
  20.      progressing to final International Standard state relatively
  21.      quickly.  This, in combination with the completion of a couple of
  22.      Integrated IS-IS implementations means that it is a good time to
  23.      start think about issuing an update to RFC 1195.
  24.  
  25.      Ross then gave a quck overview of some minor changes that would be
  26.      involved:
  27.  
  28.  
  29.        o Reference to ISO standard
  30.          RFC 1195 reference the DP version of ISO IS-IS. This clearly
  31.          needs to be updated to reference the final International
  32.          Standard version, when available.  This would also imply that
  33.          Annex B (Encoding of Sequence Number Packets) can be removed.
  34.          It turns out that we were either lucky or good, and the
  35.          sequence number format in the current ISO document is
  36.          compatible with Annex B.
  37.  
  38.        o RIP (or other external routes) at level 1
  39.          Currently the spec says that this is not allowed.  There are
  40.          good technical reasons why we don't want fully general external
  41.          connections at both level 1 and level 2.  However, there may be
  42.          many cases where we have a small RIP ``island'' which is only
  43.          reachable via a level 1 area.  For example, this is very likely
  44.          to occur during transition from a RIP routing domain to an
  45.          Integrated IS-IS routing domain.  No technical change is
  46.          needed, but the document should be upgraded editorially to
  47.          specify that this is permissible.
  48.  
  49.        o Default IP route at level 1.
  50.          There will be some cases where level 1 routing is IP-capable
  51.          (using Integrated IS-IS) but level 2 routing is not (such as
  52.          using OSI-only IS-IS at level 2, or possibly during phase 4 to
  53.          phase 5 DECnet(TM) transition).  In this case, there needs to
  54.          be a way for level 1 routers to know where to send traffic
  55.  
  56.                                    1
  57.  
  58.  
  59.  
  60.  
  61.  
  62.        destined to outside of the area (for example, one single level
  63.        2 router might be running RIP with external routers).  The
  64.        solution to this is to allow IP Default Route (subnet mask of
  65.        all 0's) at level 1, and to specify that for level 1 only
  66.        routers which see the default route advertised in level 1 LSPs,
  67.        this takes precedence over forwarding traffic to level 2
  68.        routers.
  69.  
  70.      o Compatibility with earlier versions of IS-IS
  71.        There should be a ``for information only'' annex which
  72.        specifies the differences between RFC 1195, and the updated
  73.        RFC. This will also specify how to ensure interoperability
  74.        between old and new routers.
  75.  
  76.      o IS-IS / BGP interaction
  77.        Yakov Rekhter brought up the issue of interaction between IS-IS
  78.        and BGP. Ross and Yakov will work on this issue off-line, and
  79.        report results back to the Working Group.
  80.  
  81.      o Encoding of Authentication Field
  82.        Someone brought up the issue that RFC 1195 and DIS 10589 both
  83.        have an authentication field, in which the encoding and use is
  84.        identical but the code value is different.  The Working Group
  85.        agreed that this was an unnecessary redundancy, and that we
  86.        should use the value from 10589.
  87.  
  88.      o Ships in the Night Operation
  89.        RFC 1195 currently has sufficient functionality to allow
  90.        operating two instances of IS-IS in ``Ships in the Night'' mode
  91.        -- one instance would be for IP-only routing, and one for
  92.        OSI-only routing.  However, just how to do this is not written
  93.        down anywhere.  It was agreed that this should be writted down,
  94.        with the approach ``you don't have to be capable to run two
  95.        instances of IS-IS, but if you do run two instances then this
  96.        is how you do it''.  Generally, you demultiplex on the
  97.        ``Protocols Supported'' field, and optionally may use
  98.        authentication to protect against accidental merging of the two
  99.        logical routing domains by a mis-configured router.
  100.  
  101.  
  102. 2. MIB for IS-IS
  103.    Chris Gunner then gave a detailed presentation of the proposed MIB
  104.    for IS-IS. This MIB allows management of Integrated IS-IS
  105.    (including full management of both ISO 10589 and RFC 1195) using
  106.    SNMP. This is based on the GDMO (i.e., ISO format network
  107.    management information) contained in DIS 10589, with additional
  108.    objects added for management of RFC 1195.
  109.  
  110.    The recent progression of 10589 in ISO will result in some changes
  111.    to the GDMO in 10589.  Chris will need to produce an update of the
  112.    MIB in order to maintain alignment with the ISO document.
  113.  
  114.  
  115.  
  116.                                  2
  117.  
  118.  
  119.  
  120.  
  121.  
  122.      There was a discussion of the size of the MIB. In particular, there
  123.      are situations where several similar things are in different tables
  124.      For example, different sorts of circuits currently are managed
  125.      using different tables.  There is substantial overlap between these
  126.      different tables.  The alternative is to have one type of table for
  127.      all circuits, with some fields not always used.  This implies
  128.      slightly more bits will be transmitted on the wire, but allows a
  129.      smaller MIB and less software code (e.g., data structures are
  130.      simpler).  The Working Group agreed that the latter approach was
  131.      preferable, at least in those cases where the overlap is relatively
  132.      large.
  133.  
  134.      The group agreed that the MIB should permit multiple instances of
  135.      Integrated IS-IS and/or IS-IS to be managed in a system.  This
  136.      means turning single instance objects in groups into table objects.
  137.      The group also agreed that all such table entries should be capable
  138.      of creation and deletion to mirror the creation and deletion
  139.      capabilities of the DIS 10589 managed objects to which they are
  140.      equivalent.
  141.  
  142.   3. Other Issues
  143.      Yakov Rekhter pointed out that the ISO GDMO of IS-IS does not allow
  144.      measurement of routes coming from external protocols to IS-IS.
  145.      Chris and Ross agreed to bring up this issue with the folks working
  146.      on the ISO specification.
  147.  
  148.      Outside of the Working Group, a couple of folks brought up the
  149.      issue of how to handle the ``3rd party router'' case (a single
  150.      routing domain having several routers on a broadcase or
  151.      general-topology network with only one router running BGP). Ross
  152.      will write up a proposal on how to deal with this and discuss it
  153.      within the Working Group.
  154.  
  155.  
  156. Attendees
  157.  
  158. Nagaraj Arunkumar        nak@3com.com
  159. William Barns            barns@gateway.mitre.org
  160. Scott Barvick            sbarvick@wellfleet.com
  161. William Biagi            bbiagi@cos.com
  162. John Burruss             jburruss@wellfleet.com
  163. Ross Callon              callon@bigfut.enet.dec.com
  164. Dino Farinacci           dino@cisco.com
  165. Dennis Ferguson          dennis@canet.ca
  166. Robert Griffioen
  167. Chris Gunner             gunner@osicwg.enet.dec.com
  168. Robert Hagens            hagens@cs.wisc.edu
  169. Susan Hares              skh@merit.edu
  170. Manu Kaycee              kaycee@trlian.enet.dec.com
  171. Paulina Knibbe           knibbe@cisco.com
  172. Dale Land                land@lanl.gov
  173. Chao-Yu Liang
  174. Shane MacPhillamy        slm@netrix.com
  175.  
  176.                                    3
  177.  
  178.  
  179.  
  180.  
  181.  
  182. Bill Manning             bmanning@rice.edu
  183. Dennis Morris            morrisd@imo-uvax.dca.mil
  184. Yakov Rekhter            yakov@watson.ibm.com
  185. Mike Truskowski          truskowski@cisco.com
  186. Rick Wilder              rick@gateway.mitre.org
  187. L. Michele Wright        uncng!michele@uunet.uu.net
  188.  
  189.  
  190.  
  191.                                    4
  192.