CURRENT_MEETING_REPORT_


Reported by Ross Callon/DEC

IS-IS Minutes

The IS-IS Working Group met at the IETF meeting in Atlanta, Georgia.
There were two topics of discussion:  A brief overview of the status of
the IS-IS spec (led by Ross Callon), and a presentation and longer
discussion of the SNMP MIB for IS-IS (led by Chris Gunner).


 1. Status of IS-IS
    Ross reported that the OSI IS-IS Intra-Domain routing protocol (ISO
    DIS 10589) has completed the Draft International Standard (DIS)
    ballot, and all ballot comments were successfully resolved at a
    recent ISO meeting.  This implies that the ISO IS-IS will be
    progressing to final International Standard state relatively
    quickly.  This, in combination with the completion of a couple of
    Integrated IS-IS implementations means that it is a good time to
    start think about issuing an update to RFC 1195.

    Ross then gave a quck overview of some minor changes that would be
    involved:


      o Reference to ISO standard
        RFC 1195 reference the DP version of ISO IS-IS. This clearly
        needs to be updated to reference the final International
        Standard version, when available.  This would also imply that
        Annex B (Encoding of Sequence Number Packets) can be removed.
        It turns out that we were either lucky or good, and the
        sequence number format in the current ISO document is
        compatible with Annex B.

      o RIP (or other external routes) at level 1
        Currently the spec says that this is not allowed.  There are
        good technical reasons why we don't want fully general external
        connections at both level 1 and level 2.  However, there may be
        many cases where we have a small RIP ``island'' which is only
        reachable via a level 1 area.  For example, this is very likely
        to occur during transition from a RIP routing domain to an
        Integrated IS-IS routing domain.  No technical change is
        needed, but the document should be upgraded editorially to
        specify that this is permissible.

      o Default IP route at level 1.
        There will be some cases where level 1 routing is IP-capable
        (using Integrated IS-IS) but level 2 routing is not (such as
        using OSI-only IS-IS at level 2, or possibly during phase 4 to
        phase 5 DECnet(TM) transition).  In this case, there needs to
        be a way for level 1 routers to know where to send traffic

                                  1





      destined to outside of the area (for example, one single level
      2 router might be running RIP with external routers).  The
      solution to this is to allow IP Default Route (subnet mask of
      all 0's) at level 1, and to specify that for level 1 only
      routers which see the default route advertised in level 1 LSPs,
      this takes precedence over forwarding traffic to level 2
      routers.

    o Compatibility with earlier versions of IS-IS
      There should be a ``for information only'' annex which
      specifies the differences between RFC 1195, and the updated
      RFC. This will also specify how to ensure interoperability
      between old and new routers.

    o IS-IS / BGP interaction
      Yakov Rekhter brought up the issue of interaction between IS-IS
      and BGP. Ross and Yakov will work on this issue off-line, and
      report results back to the Working Group.

    o Encoding of Authentication Field
      Someone brought up the issue that RFC 1195 and DIS 10589 both
      have an authentication field, in which the encoding and use is
      identical but the code value is different.  The Working Group
      agreed that this was an unnecessary redundancy, and that we
      should use the value from 10589.

    o Ships in the Night Operation
      RFC 1195 currently has sufficient functionality to allow
      operating two instances of IS-IS in ``Ships in the Night'' mode
      -- one instance would be for IP-only routing, and one for
      OSI-only routing.  However, just how to do this is not written
      down anywhere.  It was agreed that this should be writted down,
      with the approach ``you don't have to be capable to run two
      instances of IS-IS, but if you do run two instances then this
      is how you do it''.  Generally, you demultiplex on the
      ``Protocols Supported'' field, and optionally may use
      authentication to protect against accidental merging of the two
      logical routing domains by a mis-configured router.


2. MIB for IS-IS
  Chris Gunner then gave a detailed presentation of the proposed MIB
  for IS-IS. This MIB allows management of Integrated IS-IS
  (including full management of both ISO 10589 and RFC 1195) using
  SNMP. This is based on the GDMO (i.e., ISO format network
  management information) contained in DIS 10589, with additional
  objects added for management of RFC 1195.

  The recent progression of 10589 in ISO will result in some changes
  to the GDMO in 10589.  Chris will need to produce an update of the
  MIB in order to maintain alignment with the ISO document.



                                2





    There was a discussion of the size of the MIB. In particular, there
    are situations where several similar things are in different tables
    For example, different sorts of circuits currently are managed
    using different tables.  There is substantial overlap between these
    different tables.  The alternative is to have one type of table for
    all circuits, with some fields not always used.  This implies
    slightly more bits will be transmitted on the wire, but allows a
    smaller MIB and less software code (e.g., data structures are
    simpler).  The Working Group agreed that the latter approach was
    preferable, at least in those cases where the overlap is relatively
    large.

    The group agreed that the MIB should permit multiple instances of
    Integrated IS-IS and/or IS-IS to be managed in a system.  This
    means turning single instance objects in groups into table objects.
    The group also agreed that all such table entries should be capable
    of creation and deletion to mirror the creation and deletion
    capabilities of the DIS 10589 managed objects to which they are
    equivalent.

 3. Other Issues
    Yakov Rekhter pointed out that the ISO GDMO of IS-IS does not allow
    measurement of routes coming from external protocols to IS-IS.
    Chris and Ross agreed to bring up this issue with the folks working
    on the ISO specification.

    Outside of the Working Group, a couple of folks brought up the
    issue of how to handle the ``3rd party router'' case (a single
    routing domain having several routers on a broadcase or
    general-topology network with only one router running BGP). Ross
    will write up a proposal on how to deal with this and discuss it
    within the Working Group.


Attendees

Nagaraj Arunkumar        [email protected]
William Barns            [email protected]
Scott Barvick            [email protected]
William Biagi            [email protected]
John Burruss             [email protected]
Ross Callon              [email protected]
Dino Farinacci           [email protected]
Dennis Ferguson          [email protected]
Robert Griffioen
Chris Gunner             [email protected]
Robert Hagens            [email protected]
Susan Hares              [email protected]
Manu Kaycee              [email protected]
Paulina Knibbe           [email protected]
Dale Land                [email protected]
Chao-Yu Liang
Shane MacPhillamy        [email protected]

                                  3





Bill Manning             [email protected]
Dennis Morris            [email protected]
Yakov Rekhter            [email protected]
Mike Truskowski          [email protected]
Rick Wilder              [email protected]
L. Michele Wright        [email protected]



                                  4

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.