2.5.2 IS-IS for IP Internets (isis)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98


Tony Li <tli@juniper.net>
Antoni Przygienda <prz@dnrc.bell-labs.com>

Routing Area Director(s):

Rob Coltun <rcoltun@fore.com>

Routing Area Advisor:

Rob Coltun <rcoltun@fore.com>

Mailing Lists:

General Discussion:isis-wg@juniper.net
To Subscribe: isis-wg-request@juniper.net
Archive: ftp://ftp.ietf.org/ietf-mail-archive/isis

Description of Working Group:

IS-IS is an IGP specified and standarized by ISO and incorporating extensions to support IP. It has been deployed successfully in the Internet for several years years. The IS-IS Working Group is chartered to document current protocol implementation practices and improvements, as well as to propose further extensions to be used within the scope of IS-IS and IP routing. Short term, the WG is expected to deliver a set of documents describing common implementation practices and extensions necessary to scale the protocol. These specifications will encourage multiple, inter-operable vendor implementations.

This working group will interact with other standards bodies that have responsibility for standardizing IS-IS.

Goals and Milestones:

Dec 98


Submit I-D on IETF recommendations for improvements to IS-IS

Dec 98


Submit I-D on IETF comments on the proposed second edition of IS-IS

Dec 98


Submit I-D on IS-IS Traffic Engineering Extensions

Dec 98


Submit I-D on IS-IS HMAC-MD5 Authentication

Dec 98


Submit I-D on IS-IS over IPv4

Dec 98


Submit I-D on Maintaining more than 255 adjacencies in IS-IS

Dec 98


Submit I-D on Optional Checksums on IIHs, CSNPs, and PSNPs in IS-IS

Mar 99


Submit I-D on IS-IS MIB

Mar 99


Submit IETF recommendations for improvements to IS-IS to IESG for publication as an Informational RFC.

Mar 99


Submit IS-IS Traffic Engineering Extensions to IESG for publication as an Informational RFC

Mar 99


Submit IS-IS over IPv4 to IESG for publication as an Informational RFC

Mar 99


Submit IS-IS HMAC-MD5 Authentication to IESG for publication as an Informational RFC

Mar 99


Submit Maintaining more than 255 adjacencies in IS-IS to IESG for publication as an Informational RFC

Mar 99


Submit Optional Checksums on IIHs, CSNPs, and PSNPs in IS-IS to IESG for publication as an Informational RFC

Mar 99


Review WG's priorities and future potential

Jul 99


Submit IS-IS MIB to IESG for consideration as a Proposed Standard.


Request For Comments:







Use of OSI IS-IS for Routing in TCP/IP and Dual Environments

Current Meeting Report

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.


None received.