CURRENT_MEETING_REPORT_ Reported by Ross Callon/Wellfleet Communications Minutes of the IS-IS for IP Internets Working Group (ISIS) Ross Callon is resigning as working group co-chair. Tentatively (subject to management approval), Doug Montgomery will replace him. Chris Gunner will continue as co-chair. Document Status Doug presented the documents related to pushing ``Use of OSI IS-IS for Routing in TCP/IP and Multi-Protocol Environments'' (draft-ietf-isis-tcpip), referred to as ``I.IS-IS'' in these minutes, to Draft Standard. It is suggested that the MIB, ``Integrated IS-IS Management Information Base'' (draft-ietf-isis-mib), go to Proposed Standard, and I.IS-IS (``son of RFC 1195'') go to Draft Standard. The protocol experience document, ``Experience with the Integrated ISIS Protocol'' (draft-ietf-isis-opexp), and the protocol analysis document, ``Integrated ISIS Protocol Analysis'' (draft-ietf-isis-prot-anal), need to be issued as Informational RFCs. An applicability statement is also needed. The status of the IS-IS/IDRP-BGP interaction is unknown. This should be published as an Internet-Draft and/or RFC. Changes to I.IS-IS There have been some changes to I.IS-IS since last time, mostly clarifications resulting from testing. All changes will interoperate with implementations based on the existing specification. Some of these changes result in changes to the base ISO specification. These will be sent to ISO, and will also become a normative part of the I.IS-IS specification. Precedence of ES-IS Information Versus IS-IS Information There could be cases where there is an adjacency learned from ES-IS (corresponding to a subnet with a high metric), and also a lower metric path learned from IS-IS. In this case, you should go with the lowest cost path. Some implementations do this the other way currently, and/or provide a knob to allow folks to control this. The same issue occurs with IP routes. The same solution should be used. This is already described in the I.IS-IS specification (although there is the option of having a configuration option to override the metrics). Changes to the Configuration Options There are a couple of changes to the configuration options in the MIB: (1) reachable address prefixes to include the NET; (2) ES polling timers (ES-IS Configuration Timer option)---allow user to turn off the rapid polling option (ageing only). Padding in IS-IS Hellos can be turned off (this is particularly important for low bandwidth and high cost links). Also, you must not discard a Hello packet just because the neighbor uses a different pad size. Uses of Area Addresses The relationship between the configured area addresses and the computed area addresses is confusing to some implementors and users. The configured area addresses should be used in computing end system adjacencies. This should be a transient problem and/or gross configuration error, and therefore should not happen much. The group discussed whether to use the union of computed and configured, or just computed. It seems that using configured is broken. This will be resolved on the mailing list. Routing Through Overloaded ISs Implementations are not currently consistent, i.e., the existing text is in fact correct, but has been misinterpreted. The text therefore has been clarified to emphasize that the goal is to be able to reach the overloaded IS, but not other end systems ``after'' the overloaded IS. Designated IS TOS Reporting DISs currently only report the TOSs that they themselves support when generating pseudonode LSPs (reporting end nodes). They should report all TOSs. Clarifying text has been added (some existing implementations have already fixed this). Interfaces to Subnets Where You Are Not Running IS-IS Clearly you want to be able to reach such subnets (even if you don't run IS-IS on it). Clarifying text has been added. Conclusion Given fixes to the one minor issue discussed above, the overwhelming working group consensus is that I.IS-IS is ready to go to Draft Standard and the MIB to Proposed Standard. Any significant additional features would then be added to a future version of the standard.