This is only a rough draft - Megan 04/20/92 18 March 1992 Point-to-Point Protocol Extensions (pppext) Chair: Brian Lloyd, brian@lloyd.com Mailing Lists: General Discussion: ietf-ppp@ucdavis.edu To Subscribe: ietf-ppp-request@ucdavis.edu Archive: ucdavis.edu:archive/ppp-archive IETF PPP *Appletalk *LQM *MIB *IPX *Decnet *CLNP *Physical Layer Brian Lloyd distributed a memo titled "The PPP Internetwork Packet Exchange (IPX) Control Protocol" submitted by Novell. Karl Fox distributed a PPP Pocket Reference card from Morningstar Technologies. There will be a delay in the issuance of an RFC for LCP, IPCP, and Authentication due to an oversite within the IAB. However, there are not going to be any changes to the drafts prior to becoming RFCs. So it is safe to implement, and still be in compliance. Questions re: IP Address Negotiation. The implementor needs to support old format until PPP becomes a full standard. First check to see if the peer is using the old format. If so, negotiate IP addressing using the old algorithm. This procedure applies until PPP is a full standard. After that, support will not be provided for old algorithm for IP address negotiation. If you do IP you need to go ahead and do the new IP address negotiation scheme. Each of LCP, IP Control, LQM, and Authentication have their own document. Brian asked, "how many here are actively working to implement PPP?" Approximately 12 hands went up. As for penetration in the market it was noted that BARRNet now runs PPP on links to member sites. APPLETALK Brad Parker of Cayman presented an updated draft of his Appletalk over PPP document. Feedback from Bill Simpson and Chris Ranch of Novell. The document was forwarded to the IETF drafts mailing list. Good review from Appletalk community, supports ARAP. Will support router to router half routing. Doc will be placed on Merit.edu and Angband.stanford.edu in addition to usual places. LINK QUALITY MONITORING (LQM) The previous version of LQM was not widely implemented so major changes were deemed acceptable (this choice was made at the Santa Fe IETF meeting). As a result the general mechanism was redefined. should be able to determine if a synchronous link is up. Flow control monitoring not recommend for async. LQM is useful for high speed point to point between router vendors. LQM will give continuous state of the link info. This is good for OSPF type link state relative protocols. PPP MIB Frank Kastenholz of Clearpoint (kasten@clearpoint.com) updated MIB for PPP. Discussion has been open on the mailing list. Frank presented an update. PPP is a complex protocol so the MIB grew to almost 200 variables. Frank says this MIB has to be trimmed down, but others are asking for more. This MIB doesn't even address Appletalk, Decnet, CLNP. Should this MIB cover NCPs? was asked. Frank drew on the overhead. There were four columns: Protocol, Mandatory, Conditional Mandatory (if you are trying to control PPP instead of just monitor), and Optional. This graph allowed the members of the WG to assign each variable to a category. One reason to have lots of MIB variables is the need to configure PPP in routers via SNMP (the router from NAT was used as an example since it is only manageable via SNMP). It was suggested that all configuration variables be in the optional column and get rid of the Conditional Mandatory column. Discussion continued as to how necessary it might be to trim down the variables. It was determined that MIB variables present for debugging purposes be discarded. Brian requested that Frank Kastenholz, Bill Simpson, and Glenn McGregor meet to pare down the MIB prior to the next day's WG meeting. IPX Christopher Ranch of Novell took the floor to lead the discussion of IPX over PPP. The Novell NCP has no options and this is in conflict with what Shiva has proposed. Brian recommended that Novell and Shiva hammer out the differences and produce a single unifying document. The working group indicated that they wanted to see an address negotiation and a compression option added to Novell's proposal. Brian also asked Chris to consider adding negotiation of a routing protocol IF he thinks it would be useful. DECNET There appeared to be no progress in the area of DECNet over PPP. Further work on this subject is awaiting an implementation and/or a new draft document. OSI/CLNP Bill opened discussion with the remark that there is a well-written document for which there are no implementations. This is a no-option document that differentiated between the three different kinds of CLNP. This will be re-addressed when there is an implementation. Christopher Ranch will forward requests on this to the correct person at Novell who is beginning an implementation. BRIDGING Fred Baker is looking for implementation experiences to document. 3-COM has done bridging over PPP. Currently the document needs to 1) clarify the concept of a virtual ring, and 2) tighten up the language. 19 March 1992 09:00 32-BIT FCS Bill Simpson stated the issues with 32-bit FCS. These being that DEC owns patents on a procedure of combining the 32bit and 16bit FCS into a 48bit FCS to be used while 32bit FCS is being negotiated. Noel Chiappa said that DEC will make a license to their process freely available. DEC will provide a general grant of right to use the technology and will provide a letter to the IETF stating so. Action item: Karl Fox of Morningstar Technologies, being a vendor of a company with an implementation, is going to take the task of getting the letter from DEC releasing the rights to the process to the world. PHYSICAL LAYER Where/how to handle the physical layer information. The PPP mailing list concluded that the LCP layer is not the place. Bill Simpson stated that PPP is supposed to run over anything; in other words if you have two wires you should be able to run PPP. Brian Lloyd suggested the need for an implementation reference. There was agreement to this. Someone said this should be an informational RFC. Items to be covered included: PPP SYNC interface with an eye towards RS232, V35, V36, RS422/RS449; async implementations; switched circuits, i.e. Hayes compatible, X21, V25bis dialing; and definition of physical layer up/down determination; etc. Questions presented: How are we going to deal with ISDN? This is a topic of future discussion and work with the IPLPDN WG. Chat scripts and dealing with a login sequence on an async link. What is the other end going to send? MIB REVISITED Frank took the floor to revisit the issue of MIB variables. Together with Bill Simpson, Glenn McGregor, and some input from Jeff Case they got the number of variables to just over a hundred. This is down from 196. They did not deal with every section, and some still need to be added for Appletalk, and IPX. It will be necessary to know if and what will be monitored in IPX over PPP. Changes: link extensions table is gone, FSM table(s) are gone, these were deemed to be debugging information. It was decided that it made more sense to return the link quality reports as a single aggregate MIB variable instead of permitting each field withing the LQR to be queried separately. Individual variables in the LQR are not very useful by themselves plus in order to make sense of the timely information it is necessary to see a complete "snapshot" in one operation. On the philosophy of configurable parameters: the choice seems to be, a rich set of "knobs" or allowing the vendor to completely control the initial and desired state of the implementation. There was no hard-and-fast decision so it was left up to Frank to clean up what was decided and to post all changes to the MIBs to the mailing list in a few weeks where discussion will begin anew.