Subject: minutes ...

From: Antoni Przygienda <[email-masked]>
Date: Mon, 14 Dec 1998 20:31:09 -0500

first version of working group minutes. Please comment ...

		thank you

		--- tony

Monday Session:
===============

ISIS-MIB presented by Jim Halpin, author Jeff Parker, Nexabit
-------------------------------------------------------------

Long-term target of the work is a standard MIB for IS-IS. Presentation
given was aiming at providing the overview of a first attempt and
highlight several issues that came up on the mailing list. The draft
has been based on the 1992 version of C. Gunner's draft, whereas it
has been revised to MIB-II style, multiple groups have been removed
and values corrected and added. The draft will be moved to the name
draft-ietf-isis-wg-mib-xx.txt. Several comments have been provided on
the mailing list that has been since incorporated, more specifically
some dropped groups and objects have been reintroduced, one other
group dropped. Beside that, indices have been marked inaccessible and
several defaults and limits adjusted. A discussion has taken place on
the mailing list on the correct interpretation of the timer values in
the context of p2p links. Ascend has offered to contribute their
enterprise MIB capabilities to the general MIB to support ISIS
extensions used in deployment today if necessary.  Outstanding issues
on the mailing list encompass support for more than 255 circuits that
have been presented later, interpretation of system values as default
values for circuit instances and proper support for non-disruptive
modification of timer values.

Optional Checksums presented by Tony Przygienda, Bell Labs
----------------------------------------------------------

The draft describing optional checksums (OC) in IS-IS has been
introduced with the justification that corruption of hellos and
especially SNPs cannot be detected today in IS-IS. Such a corruption
can lead to the generation of spurious LSPs in the network. Generation
and processing rules have been presented with a special emphasis on
co-existence with other signature-generating TLVs.  Several comments
have been made. First, the inefficiency of hello checksumming has been
raised with proposed modifications such as introduction of the checksum
before padding TLVs and not taking the padding into account during
its computation. The question has been answered by several people
pointing
out that the checksums are optional, can be computed in a distributed
fashion or cached. It has been emphasized as well that CSNPs and PSNPs
have to cope with the change of the lifetimes of described LSPs and
therefore a caching scheme is not feasible there.

Dynamic Resolution of System IDs by N. Sheng, Cisco
---------------------------------------------------

The draft has been introduced to allow for support of possibly
human-readable names in place of numeric system IDs. Although an
inverse DNS lookup solution should be preffered, it has several
disadvantages, such as the necessity for CLNP suport in DNS and high
likelihood to fail in times of network instability. Other
possibilities involve static mapping or the
proposed dynamic mapping by using IS-IS TLVs and the flooding
mechanism. Several questions have been raised after the presentation.
Generally, the necessity of a dynamic mapping has been
questioned. Moreover, since sytem IDs do not have to be necessarily
unique across an IS-IS domain, the viability of the scheme has been
questioned, however, since no proposal has been made to leak the TLVs
between L1 and L2 or vice-versa, this did not seem to be a relevant
issue.  As a consequence of the missing leaking, it has been pointed
out that a global resolution is impossible. The discussion diverged
into reverse DNS lookup problems and the conclusion has been reached
that
either area ID would have to be included as part of the System ID or
the complete NSAP used for reverse lookups. After that, a request for
a reserved TLV ID has been issued and lead to a short repetition of
the discussion on the mailing list that encompassed the proposal to
introduce subTLVs of a IP reserved TLV ID and/or a reserved OUI TLV
ID. As conclusion, the group agreed to use TLV IDs over 128 in a
temporary fashion without a synchronization with OSI on the issue. The
comment has been made that it may be easier to incorporate the
mechanism into a OUI TLV since that would leave only a single ID to be
synchronized with OSI.

More than 255 Circuit by Tony Przygienda, Bell Labs
---------------------------------------------------

The presentation introduced submitted draft that documents a mechanism
to support more than 255 circuits in IS-IS without the violation of
existing protocol.  Several comments have been made after the
presentation, one of them considering the issue of CircID being only 8
bits wide and used as primary index in MIB today.  Discussion has been
postponed to the mailing list and the issue acknowledged as
solvable. H. Smit from Cisco made the comment that the draft points
out that some of the solutions may have been deployed before and at
the same time includes a section asserting potential IPR issues. The
author stated that the point-to-point solution is assumed to be
mentioned in the forthcoming draft describing deployed modifications,
the broadcast media solutions is believed to be novel.

HMAC MD5 Authentication by Tony Li, Juniper
-------------------------------------------

Tony Li introduced the draft proposing a new TLV with the ID 54,
including 16 bytes of MD5 authentication data. Rules for the
processing and computation of the signature has been presented. As a
special case, the purging of LSPs has been considered in more detail
since unathorized purges could be easily used as an attack given the
lack of
protection of LSP lifetime. Other types of attacks have been
acknowledged
as not being addressed and furthermore, deployment issues of MD5
mentioned. 
As solution for the roll-over
of keys, simultaneous verification over multiple keys has been 
proposed since otherwise
non-disruptive deployment of new keys would not be possible. A short
discussion confirmed the necessity of optional checksums even if MD5
will be used due to backwards comptability issues and costs involved in
MD5
signatures.

ISIS in IPv4 by Tony Przygienda, Bell Labs
------------------------------------------

The proposal encompassed the encapsulation of IS-IS PDUs within
IPv4. This encapsulation is based on OSPF, is however different
significantly enough to justify an independent document. Within the
presentation, it has been pointed out by the author that the section
on interoperability with OSI will be removed and replaced by an
observation that such an interoperability is not required from the
operational point of view and will cause more trouble than possible
gain. The issue of the introduced ethernet encapsulation has been also
raised and the conclusion reached that it is probably too convoluted for 
its advantages. H. Smit pointed out in a private discussion
that it makes probably more sense to substitute the MAC address used
in OSI encapsulation for adjacency forming by a padded source IP
address that can be normally obtained from the IP header.  The issue
of IPv6 has been raised but dismissed as not being within of the scope
of this document at the moment. A lengthy discussion on the issue of
IP fragmentation of LSPs brought the conclusion that LSPs should never
be IP fragmented to ensure functional networks with mix
of OSI and IP encapsulated links. The discussion has been moved to the
mailing list for further evolution.

Thursday Session
================

An introductory question has been asked as of whether a draft
documenting modification to the formats and procedures defined by the
OSI specification and used in deployment today will be issued. Tony Li
answered that the person supposed to issue this draft is well-known.

ISIS-OMP by Curtis Villamizar, UUnet
------------------------------------

A short presentation has been given that mainly outlined the differences 
between OSPF and ISIS versions of OMP. Issues concerning load
adjustement and 
path setup with MPLS-OMP have been touched as well. The question has
been asked whether 
ISIS-OMP should be accepted as workgroup item and it passed without
objections.