Editor's Note: These minutes have not been edited. Here are the minutes from Monday's PPPEXT WG session. The next session will be Wednesday and those minutes will follow. My fingers are solely responsible for these minutes. Please comment if my fingers misrepresented or misinterpreted anything. PPP Extensions Working Group Agenda - 38th IETF - Memphis Monday, April 07, 1997 Karl Fox - Chair Matt Holdrege - Minutes PPP Vendor Extensions - Bill Simpson - draft-ietf-pppext-vendor-01.txt New draft. IESG suggested changes. They didn't want to mandate OUI's. Will now be forwarded back to the IESG. PPP CallBack draft-ietf-pppext-callback-ds-01.txt Will go forward, probably as Draft Standard. PPP LCP Extensions - draft-ietf-pppext-lcpext-ds.txt Will go forward on standards track Mobile Ipv4 Configuration - Jim Solomon - solomon@comm.mot.com - draft-ietf-pppext-ipcp-mip-00.txt Goal: Reach consensus that this option is useful and on the procedure for its advancement on the standards track Status: Consensus in Mobile IP working group that this option as specified, is useful and in fact necessary; Consensus among Area Directors that this protocol belongs in the PPPEXT WG. Proposal: New IPCP option. Add bit options to handle Mobile IP better and specifically, foreign agent care-of address. Q: What to do when IP address req is in the same packet as a mobile node request? Jim to check if the new option can be used in conjunction with IPCP IP-Address rather than instead of it. Q: Why does this use type=137? IANA assigned it, but Jim will check the sanity of this. Preferable to breaking this into an original IPCP request and a Mobile node request. PPP Stac LZS Compression (RFC 1974) Fix the conflict between Extended Mode and PFC Propose to remove mention of PFC if Microsoft won't accept PFC while accepting STAC option 4? Need to find out Microsoft behavior. Philip Rakity pmr@flowpoint.com - Resynchronizing when using extended mode. Philip proposed changing text which he will send to the list. Proposal for a PPP network Layer entity selection protocol - Avri Doria adoria@gdc.com - draft-ietf-pppext-nles-00.txt Mechanism for selecting target system when using a direct access network like xDSL. Suggested using LCP. Much discussion made it seem clear that this may not be necessary. If using HDLC switching, a special HDLC packet may handle this better. If using PPP authentication, something like RADIUS realms seems more appropriate. WG to drop this item. PPP DES Encryption - RFC 1969 - Plaintext padding. SDP is assumed to be pre-negotiated with M=8 and pad all protocols. PPP-style SDP technique is mandated, not PKCS style. If the packet length doesn't require padding, add pad bytes only if the last byte of data is 8 or less. In security section, say that checking all pad bytes is recommended but not mandatory. Semi Connected modem for PPP links - Mikael Latvala mikael.latvala@lmf.ericsson.se - draft-ietf-pppext-scm-00.txt. Motivation: Minimize reconnection latency. Allow end-users to pay for a bearer service on a need basis. It was also stated that this protocol will aid greatly in resource reservation. The Chair pointed out that the resource issue is handled by other protocols. Bill Simpson gave a discourse on the many reasons why latency issues should not be considered. It would be handy but not necessary to have an implementor's document describing how to do this with existing protocols. L2TP draft-ietf-pppext-l2tp-01.txt - Andy Valencia - vandys@cisco.com Much progress had been made since the last IETF meeting. Looking forward to the interoperability testing at the CIUG in May. Will be tunneled on top of UDP. Will work with some NAT techniques. UDP checksums will be supported. No PPP checksums because the LNS cannot be expected to handle that. Issues of callback in complex configurations has yet to be hashed out. Andy is looking for feedback from implementors. Matt Holdrege - http://www.ascend.com - matt@ascend.com ------- end ------- As before, please comment if anything below seems to misrepresent what actually occurred at the meeting. Day Two - April 9, 1997 Chair: Karl Fox Minutes: Matt Holdrege PPP over AAL5/FUNI - Manu Kaycee - mjk@nj.paradyne.com Manu gave an overview of the draft and proposed encapsulation Map PPP packet over AAL5 and FUNI datalink Leverage the rich PPP framework in these level-2 environments Provide a standard for ADSL forum and other bodies Uses RFC 1483 VC multiplexing for payload mappings Applies equally to AAL5 & FUNI FUNI 2.0 is being straw balloted in ATM forum. ACFC, No. PFC, yes. Clarifying text to follow. Propose separate ID's. Other signaling frameworks may follow. Discussion: LLC encapsulation? Yes or no? What about the Frame discard issue in section 4? Andy Malis said performance is better with VC encaps than LLC. Others said the LLC was needed for internetworking. The CF issue was discussed for internetworking's sake. Bill recommends we choose either AAL5 or FUNI to move forward to fit with IETF philosophy. Andy says that both interfaces will be popular and will need to interoperate. So, it was proposed that text would be included in the two documents that will make sure that interoperability will work between the two. It was stated that LLC adds overhead, but it may be needed to handle situations where switches lose information It was stated that major vendors are now implementing PPP over AAL5 and working on PPP over FUNI No consensus was reached. The issues surrounding this draft will move to the list. An updated draft will soon be sent to the list. Next step: Update ID's L2TP over AAL5 & FUNI Much the same justification and motivation as PPP over AAL5 & FUNI Multiple tunnels MAY exist over the same VC Same tunnel MAY be administered across multiple VC's L2TP codepoint: Tim Kwock to follow though Section 2.2 is incorrect and will be updated QoS AVP will be sent to the list Next step: Clean up and update ID Bill Simpson asked why we need this protocol? Manu said it is intended to support large number of VC's in core networks. This draft will cover how to multiplex several L2TP/PPP sessions over a single VC. BT & others will send some scenarios to the list, which would support the usefulness of this protocol. It was stated that it would be useful in building access networks, which want to use L2TP mapped to ATM VC's. Some are afraid that ATM or ATM CPE doesn't currently scale well enough to support enough VC's to handle individual VC's per L2TP/PPP sessions. Others said that this is a temporary issue and we shouldn't design a protocol to solve a temporary issue. It was pointed out that this draft doesn't adequately address security. It was mentioned that the QoS AVP's will be added to RADIUS as tunnel attributes. Other items: The chair repeated that SCM is now dropped as a work item. IPCP is out in draft; comments are requested When the chair requested on the L2TP mailing list that discussion be dropped concerning UDP checksums, several people refused, both publicly and privately. The chair pointed out that the Area Directors agree with his decision, and would ask that such rude behavior be kept off the PPP lists in the future. Matt Holdrege - http://www.ascend.com - matt@ascend.com ------- end ------- -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841