CURRENT_MEETING_REPORT_ Reported by John Moy/Cascade Communications Minutes of the Open Shortest Path First IGP Working Group (OSPF) ``Extending OSPF to Support Demand Circuits'' The Internet-Draft, draft-ietf-ospf-demand-00.txt, was reviewed. John Moy gave an overview of the features provided and the mechanisms employed. The intent is to enhance OSPF so that it runs efficiently over dial-up networks. The mechanisms get rid of all periodic OSPF protocol traffic (i.e., Hellos and flooding refreshes). Comments on the draft included: o John warned that the last paragraph in Section 2.3 of the Internet-Draft is incorrect, and that implementors should skip this for now. o People wanted to document the assumption that either side of the circuit can dial. Apparently this is not true for all modems. o There was a great deal of discussion about the support for oversubscribed interfaces (e.g., a single basic rate ISDN channel that supports more than two endpoints over time). The draft mentions increasing the cost of a connection that cannot be opened due to being blocked (i.e., oversubscribed), in hope of getting the established links to form a spanning tree. Some people were opposed to changing costs in this fashion. Others were in favor. The draft will be expanded to describe the functionality in more detail. o Also on the subject of oversubscription, some network designs are incapable of forming a spanning tree, thereby preventing simultaneous access of all destinations. The draft should explain this. o It was proposed that, instead of LSAs that do not age, the endpoint of a demand circuit should refresh LSAs (originating from the other side of the circuit) by proxy. It was John's contention that this is actually more complicated. o Fred Baker offered to add an object to the OSPF MIB that indicates whether a particular OSPF interface is a ``demand interface.'' Technical Changes to the Base OSPF Specification The representation of point-to-point links will be enhanced to allow the point-to-point link to be advertised as a subnet (a la RIP). This change had been previously discussed on the OSPF mailing list. The specification already requires a router to reject LSA updates that arrive more frequently than interval X (step 5a of Section 13). This is to rate-limit neighbors that are not obeying the 5 second limit on LSA originations. The current value of X is 5 seconds. It is proposed to change X to 1 second. This makes it less likely that a router will reject an update that it should not (because of differing clock speeds and granularities). Also in flooding (Section 13, Step 8), if a router receives a less recent LSA, instead of the current behavior of silently ignoring the LSA, it will now flood back its database copy. This helps in two cases involving MaxAge LSAs: 1) where they are stuck in a retransmission queue on a slow link and 2) where a router is not properly flushing them from its database. In both of these cases, if the router responds back with the MaxAge LSA, the originator will then pick the next highest sequence number and the LSA will be overwritten. (In addition, this change is needed for the demand circuit additions). John also proposed to get rid of the PostScript in the next update of the OSPF specification, but this was soundly defeated. A New Authentication Mechanism for OSPF Based on MD5 Fred Baker presented a new authentication mechanism for OSPF based on MD5. This has since been published as an Internet-Draft, draft-ietf-ospf-md5-00.txt. Comments on the proposal included: o There was some confusion over the amount of padding required for MD5 as specified in RFC 1321. o It was felt that specifying a non-decreasing sequence number was good, both for replay detection and to avoid delaying for RouterDeadInterval seconds upon restart. It was suggested that a router have some way to ensure a non-decreasing send sequence number across restarts (e.g., a time of day clock). o Ran Atkinson said that secure SNMP is probably not the best way to do key distribution. He suggested that we simply specify manual key distribution and leave key management to the Security Area (contact person Steve Bellovin). o It was noted that since there is a secret per-LAN, you cannot really verify who the sender is, just that it is one of your trusted neighbors. o It was requested that, for efficiency reasons, the OSPF packet checksum be avoided when MD5 authentication is being used. The MD5 algorithm already performs a checksum of packet contents. o Dennis Ferguson was interested in having an inexpensive way to indicate that two OSPF routers are in different Autonomous Systems, and therefore should not communicate via OSPF. This is generally done by giving them different secrets, but it was feared that the additional overhead of MD5 might get onerous. A suggestion was to allocate space in the ``authentication'' part of the OSPF header (not all of which is used when doing MD5) for this purpose. ``Point-to-MultiPoint Interface'' Fred then revisited his ``OSPF Point-to-MultiPoint Interface'' Internet-Draft (draft-ietf-ospf-pmp-if-00.txt). The purpose of this new interface type is to simplify configuration on non-mesh-connected Frame Relay networks. The draft specifies use in a star topology, but will be updated to address a general topology of PVC connections. Dennis suggested that the right way to look at the point-to-multipoint interface is as a way of profiling the representation of a Frame Relay network as multiple point-to-point connections that (1) are always numbered, (2) have an associated mask and (3) whose own addresses are advertised in LSAs (instead of the neighbors'), with a cost of 0. John mentioned that the point-to-multipoint interface does not obsolete NBMAs -- NBMAs are still more efficient in full mesh connected networks (e.g., X.25 or Frame Relay with SVCs). The following comparison was made between the three ways of representing a Frame Relay network: a) as one or more NBMAs, b) as multiple point-to-point networks and c) using the point-to-multipoint interface. This is from the point of view of a router connecting to a Frame Relay network through n PVCs. The point-to-point networks can be either numbered or unnumbered. The point-to-multipoint interface provides a ``non-standard'' subnet model since two routers on the same subnet do not have to be directly connected by a PVC. Feature 1-n NBMAs n P-Ps P-MP ______________________________________________________________ router links (router LSA) 0 n n stub links 0 0-n 1 transit net links 1-n 0 0 ______________________________________________________________ # OSPF ifcs 1-n n 1 # ifc addresses 1-n 0-n 1 # OSPF adjacencies 1-n n n ______________________________________________________________ subnet model 1-n subnets none 1 non-standard Document Disposition The OSPF Working Group has twelve documents currently in RFC or Internet-Draft form. The group decided on the disposition of each. In general, it was decided that rather than wait for implementation experience on several of the new proposals, they would be published as Experimental RFCs. o RFC 1583: OSPF specification - Will submit for Full Standard status, after folding in the Point-to-point interface, MD5 authentication and some small technical changes (see above). Responsible: John Moy. o RFC 1245: OSPF Analysis - Does not need to be updated. Informational RFC. o RFC 1246: OSPF Experience - Does not need to be updated. Informational RFC. o RFC 1587: OSPF NSSAs - Currently at Proposed Standard. We desire to advance, but need more experience. Network Systems indicated that they have an implementation. We need another independent implementation, and some deployments. Right now the text does not need to be updated. o RFC 1586: Frame Relay Guidelines - Informational RFC. Desire reissue since affected by the new Point-to-Multipoint interface. Responsible: need volunteer. o RFC 1253: OSPF MIB - Want to advance to Draft Standard. Being updated by Fred Baker. o Point-to-multipoint Internet-Draft - Merge with base OSPF specification. Responsible: John Moy. o External attributes LSA Internet-Draft - Update and publish as Experimental RFC. Responsible: Dennis Ferguson. o Demand circuit support Internet-Draft - Update and publish as Experimental RFC. Responsible: John Moy. o MD5 Authentication - Update and merge into base OSPF specification. Responsible: Fred Baker and John Moy. o OSPF Database Overflow - Still unwritten. John Moy to write and publish as Experimental RFC. o OSPF for IPng - See below. OSPF for IPng Finally, the IPng Working Group requested that we update Paul Francis' OSPF for SIPP document, and turn it into an OSPF for IPng specification. Fred Baker and Dennis Ferguson volunteered to spearhead this effort.