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 >
Wrap
Text File
|
1993-02-17
|
8KB
|
192 lines
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 nak@3com.com
William Barns barns@gateway.mitre.org
Scott Barvick sbarvick@wellfleet.com
William Biagi bbiagi@cos.com
John Burruss jburruss@wellfleet.com
Ross Callon callon@bigfut.enet.dec.com
Dino Farinacci dino@cisco.com
Dennis Ferguson dennis@canet.ca
Robert Griffioen
Chris Gunner gunner@osicwg.enet.dec.com
Robert Hagens hagens@cs.wisc.edu
Susan Hares skh@merit.edu
Manu Kaycee kaycee@trlian.enet.dec.com
Paulina Knibbe knibbe@cisco.com
Dale Land land@lanl.gov
Chao-Yu Liang
Shane MacPhillamy slm@netrix.com
3
Bill Manning bmanning@rice.edu
Dennis Morris morrisd@imo-uvax.dca.mil
Yakov Rekhter yakov@watson.ibm.com
Mike Truskowski truskowski@cisco.com
Rick Wilder rick@gateway.mitre.org
L. Michele Wright uncng!michele@uunet.uu.net
4