CURRENT_MEETING_REPORT_ Reported by Ross Callon/DEC Minutes of the ISIS for IP Internets Working Group (ISIS) Agenda 1. Update to ISIS MIB (Chris Gunner) 2. Update to RFC 1195 (Ross Callon) 3. ISIS-BGP Interactions (Yakov Rekhter) Update to ISIS MIB draft Chris Gunner presented an updated draft of ISIS MIB. The major changes from the previous draft were: o The number of table were reduced from the previous version - now there are half as many tables roughly as previously. o No restriction on Set PDU's contents in the MIB specification. An agent, however, can impose one on the Set PDU's contents. There was a suggestion to link the IP destination object and the IP Forwarding Table. Additional detail-level reviewers of the ISIS MIB would be appreciated. It is expected that this will occur at the MIB is implemented. The IS-IS MIB is currently an Internet Draft. Update to RFC 1195 Ross Callon presented an updated version of RFC 1195. The changes to RFC 1195 are listed in Section 6 of the new draft (which has been distributed to the Working Group). Following changes and topics were discussed: o Reference to final International Standard of ISO 10589. This is the biggest change to the draft. This allows several sections of RFC 1195 to be removed as they are redundant with corrections and improvements that have been made to ISO 10589. For example, Annexes on encoding of sequence number packets and on authentication are now redundant with ISO 10589. o The spec now allows announcement of the IP Router ID over unnumbered links. This is needed for Strict Source Routing, network management, and for locally originated IP packets over unnumbered links. The spec will be updated to specify that for routers which have only unnumbered links, the router ID must be 1 announced in the LSP's as a Host Route. The spec should probably also include a brief description of what a router ID is. o What should be done when a router is a L1 and L2 router, doing RIP, but L2 is not IP capable? The spec now describes this in some detail, but some editorial clarification is needed (see the "mixed operation" section of the update to RFC 1195). o NSAP address for IP-only routers was discussed. There are several ways in which these can be obtained. This is currently being pursued in several other places for uses which include, but which go well beyond use in IS-IS. Therefore this should be removed from the update to RFC 1195. o There was a discussion of how to transition two instances of IS-IS which are operating in "Ships in the Night" mode to a single instance of Integrated IS-IS. Ross proposed two possible transition methods, one of which was well received and the other of which was quickly rejected. Implementations will not be required to be able to run two instances of IS-IS in this manner. However, if an implementation does implement the capability of running two versions of IS-IS in SIN mode, then the implementation must also implement the controls needed to be able to transition from SIN mode to integrated mode and vice versa. o An optimization of when to leak routes from L1 to L2 was discussed and approved. This would optionally allow selective leaking of routes from level 1 to level 2 LSPs, in a manner which not effect routes (except for an improvement in routes in one obscure case) but which would reduce the amount of information in level 2 LSPs, at the cost of slightly more work for the routers doing the route leaking. This feature would work well even when implemented by only some routers, and therefore can be optionally implemented and deployed. o There was a discussion of redundant manually configured summary routes. It was agreed that this issue was not particularly important, but that the spec should be complete and unambiguous. The decision was that when redundant summary addresses are manually configured, both are announced. o Dino Farinacci suggested that we can use the LSP protocols supported field to avoid creating a black hole when all routers within an area are not the same type (all OSI, all IP, or all Dual). Again this was a feature which will work well even when implemented by only some routers in an area (routers which do not implement this will interwork with those that do). This proposal was accepted. Ross agreed to update the spec based on this discussion, and to have this issued as an Internet Draft when available. 2 BGP - ISIS Interaction Yakov Rekhter presented the issues of interaction between BGP and IS-IS. After the discussion, Sharad Sanghi of ASN (sharad@ans.net) and Atul Bansal (bansal@wile.enet.dec.com) volunteered to write BGP-IS-IS draft. Leakage of routes between BGP and IS-IS was discussed, and it was agreed that this should be the same as in the OSPF-BGP case. The relationship between BGP router IDs and IS-IS router IDs was discussed. Piggybacking of BGP information in IS-IS packets was discussed. In those cases where all or most level 2 routers are border routers running BGP, this makes sense (IS-IS solves the n-square BGP link problem, and provides reliable multicast mechanism). However, in those cases where very few level 2 routers are border routers, the n-square link problem is not significant, and piggybacking requires non-border routers to store BGP information. It was therefore agreed that whether to piggyback BGP information on IS-IS packets or to run internal BGP will depend upon the network environment, and therefore both possibilities should be allowed. If a network has very few BGP speakers then I-BGP is a good solution. If a network has lots of BGP speakers and very few non-BGP speaking L2 routers then Piggybacking is most efficient. Auto-configuration of I-BGP neighbors was also discussed. Auto I-BGP configuration optimization was suggested as an efficient mechanism for discovering I-BGP neighbors. This feature eliminates the nightmare - manual configuration of I-BGP neighbors. This autoconfiguration can be piggybacked on IS-IS. Tagging is currently defined by RFC 1195. This should continue to be available. We also discussed how to pass BGP information between two I-BGP neighbors when one is doing OSPF and the other is doing ISIS? This required close cooperation with the folks working on BGP-OSPF interactions. Attendees Atul Bansal bansal@wile.nac.dec.com Robert Blokzijl K13@nikhef.nl Daniel Blum 4108980@mcimail.com David Bolen db3l@nis.ans.net Ross Callon callon@bigfut.enet.dec.com Ken Carlberg carlberg@cseic.saic.com Dean Cheng dean@sunz.retix.com Chi Chu chi@sparta.com Kurt Dobbins dobbins@ctron.com Dino Farinacci dino@cisco.com Chris Gunner gunner@osicwg.enet.dec.com Christine Hemrick hemrick@cisco.com Tony Li tli@cisco.com 3 April Merrill abmerri@tycho.ncsc.mil Dave Monachello dave@pluto.dss.com Dennis Morris morrisd@imo-uvax.dca.mil Yakov Rekhter yakov@watson.ibm.com Manoel Rodrigues manoel.rodrigues@att.com Sharad Sanghi sharad@ans.net Harvey Shapiro shapiro@wnyose.nctsw.navy.mil Ravi Srinivasan ravi@eng.vitalink.com Andrew Veitch aveitch@bbn.com Cathy Wittbrodt cjw@nersc.gov Osmund de Souza osmund.desouza@att.com 4