home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / pppext / pppext-minutes-97apr.txt < prev    next >
Text File  |  1997-05-29  |  8KB  |  228 lines
  1. Editor's Note:  These minutes have not been edited.
  2.  
  3.  
  4. Here are the minutes from Monday's PPPEXT WG session. The next session will
  5. be Wednesday and those minutes will follow. 
  6.  
  7. My fingers are solely responsible for these minutes. Please comment if my
  8. fingers misrepresented or misinterpreted anything.
  9.  
  10.  
  11. PPP Extensions Working Group Agenda - 38th IETF - Memphis
  12.  
  13. Monday, April 07, 1997
  14.  
  15. Karl Fox - Chair
  16. Matt Holdrege - Minutes
  17.  
  18.  
  19. PPP Vendor Extensions - Bill Simpson - draft-ietf-pppext-vendor-01.txt
  20.  
  21. New draft. IESG suggested changes. They didn't want to mandate OUI's. Will
  22. now be forwarded back to the IESG.
  23.  
  24.  
  25. PPP CallBack draft-ietf-pppext-callback-ds-01.txt
  26.  
  27. Will go forward, probably as Draft Standard.
  28.  
  29.  
  30. PPP LCP Extensions - draft-ietf-pppext-lcpext-ds.txt
  31.  
  32. Will go forward on standards track
  33.  
  34.  
  35. Mobile Ipv4 Configuration - Jim Solomon - solomon@comm.mot.com -
  36. draft-ietf-pppext-ipcp-mip-00.txt
  37.  
  38. Goal: Reach consensus that this option is useful and on the procedure for
  39. its advancement on the standards track
  40.  
  41. Status: Consensus in Mobile IP working group that this option as specified,
  42. is useful and in fact necessary; Consensus among Area Directors that this
  43. protocol belongs in the PPPEXT WG.
  44.  
  45. Proposal: New IPCP option. Add bit options to handle Mobile IP better and
  46. specifically, foreign agent care-of address.
  47.  
  48. Q: What to do when IP address req is in the same packet as a mobile node
  49. request?  Jim to check if the new option can be used in conjunction with
  50. IPCP IP-Address rather than instead of it.
  51.  
  52. Q: Why does this use type=137? IANA assigned it, but Jim will check the
  53. sanity of this.
  54.  
  55. Preferable to breaking this into an original IPCP request and a Mobile node
  56. request.
  57.  
  58.  
  59.  
  60.  
  61. PPP Stac LZS Compression (RFC 1974)
  62.  
  63. Fix the conflict between Extended Mode and PFC
  64.  
  65. Propose to remove mention of PFC if Microsoft won't accept PFC while
  66. accepting STAC option 4?  Need to find out Microsoft behavior.
  67.  
  68. Philip Rakity pmr@flowpoint.com - Resynchronizing when using extended mode.
  69. Philip proposed changing text which he will send to the list.
  70.  
  71.  
  72.  
  73.  
  74. Proposal for a PPP network Layer entity selection protocol - Avri Doria
  75. adoria@gdc.com - draft-ietf-pppext-nles-00.txt
  76.  
  77. Mechanism for selecting target system when using a direct access network
  78. like xDSL. Suggested using LCP.  
  79.  
  80. Much discussion made it seem clear that this may not be necessary. 
  81.  
  82. If using HDLC switching, a special HDLC packet may handle this better. If
  83. using PPP authentication, something like RADIUS realms seems more
  84. appropriate. 
  85.  
  86. WG to drop this item.
  87.  
  88. PPP DES Encryption - RFC 1969 - Plaintext padding.
  89. SDP is assumed to be pre-negotiated with M=8 and pad all protocols.
  90. PPP-style SDP technique is mandated, not PKCS style. If the packet length
  91. doesn't require padding, add pad bytes only if the last byte of data is 8
  92. or less. In security section, say that checking all pad bytes is
  93. recommended but not mandatory.
  94.  
  95. Semi Connected modem for PPP links - Mikael Latvala
  96. mikael.latvala@lmf.ericsson.se - draft-ietf-pppext-scm-00.txt.
  97. Motivation: Minimize reconnection latency. Allow end-users to pay for a
  98. bearer service on a need basis.
  99.  
  100. It was also stated that this protocol will aid greatly in resource
  101. reservation. The Chair pointed out that the resource issue is handled by
  102. other protocols. 
  103.  
  104. Bill Simpson gave a discourse on the many reasons why latency issues should
  105. not be considered.  It would be handy but not necessary to have an
  106. implementor's document describing how to do this with existing protocols.
  107.  
  108. L2TP draft-ietf-pppext-l2tp-01.txt - Andy Valencia - vandys@cisco.com
  109. Much progress had been made since the last IETF meeting. Looking forward to
  110. the interoperability testing at the CIUG in May. 
  111.  
  112. Will be tunneled on top of UDP. Will work with some NAT techniques. UDP
  113. checksums will be supported. No PPP checksums because the LNS cannot be
  114. expected to handle that.  
  115.  
  116. Issues of callback in complex configurations has yet to be hashed out.
  117.  
  118. Andy is looking for feedback from implementors.
  119.  
  120. Matt Holdrege  -  http://www.ascend.com  -  matt@ascend.com
  121.  
  122. ------- end -------
  123.  
  124.  
  125. As before, please comment if anything below seems to misrepresent what
  126. actually occurred at the meeting.
  127.  
  128. Day Two - April 9, 1997
  129.  
  130. Chair: Karl Fox
  131. Minutes: Matt Holdrege
  132.  
  133. PPP over AAL5/FUNI - Manu Kaycee - mjk@nj.paradyne.com
  134. Manu gave an overview of the draft and proposed encapsulation
  135. Map PPP packet over AAL5 and FUNI datalink
  136. Leverage the rich PPP framework in these level-2 environments
  137. Provide a standard for ADSL forum and other bodies
  138. Uses RFC 1483 VC multiplexing for payload mappings
  139. Applies equally to AAL5 & FUNI
  140. FUNI 2.0 is being straw balloted in ATM forum.
  141. ACFC, No. PFC, yes. Clarifying text to follow.
  142. Propose separate ID's.
  143. Other signaling frameworks may follow.
  144.  
  145. Discussion:
  146. LLC encapsulation? Yes or no?
  147. What about the Frame discard issue in section 4?
  148. Andy Malis said performance is better with VC encaps than LLC.
  149. Others said the LLC was needed for internetworking.
  150. The CF issue was discussed for internetworking's sake.
  151. Bill recommends we choose either AAL5 or FUNI to move forward to fit with
  152. IETF philosophy.
  153. Andy says that both interfaces will be popular and will need to interoperate.
  154.  
  155. So, it was proposed that text would be included in the two documents that
  156. will make sure that interoperability will work between the two.
  157.  
  158. It was stated that LLC adds overhead, but it may be needed to handle
  159. situations where switches lose information
  160.  
  161. It was stated that major vendors are now implementing PPP over AAL5 and
  162. working on PPP over FUNI
  163.  
  164. No consensus was reached. The issues surrounding this draft will move to
  165. the list.
  166.  
  167. An updated draft will soon be sent to the list.
  168.  
  169. Next step:
  170. Update ID's
  171.  
  172.  
  173.  
  174. L2TP over AAL5 & FUNI
  175.  
  176. Much the same justification and motivation as PPP over AAL5 & FUNI
  177. Multiple tunnels MAY exist over the same VC
  178. Same tunnel MAY be administered across multiple VC's
  179. L2TP codepoint: Tim Kwock to follow though
  180. Section 2.2 is incorrect and will be updated
  181. QoS AVP will be sent to the list
  182.  
  183. Next step:
  184. Clean up and update ID
  185.  
  186. Bill Simpson asked why we need this protocol?
  187. Manu said it is intended to support large number of VC's in core networks.
  188. This draft will cover how to multiplex several L2TP/PPP sessions over a
  189. single VC.
  190.  
  191. BT & others will send some scenarios to the list, which would support the
  192. usefulness of this protocol.
  193.  
  194. It was stated that it would be useful in building access networks, which
  195. want to use L2TP mapped to ATM VC's. Some are afraid that ATM or ATM CPE
  196. doesn't currently scale well enough to support enough VC's to handle
  197. individual VC's per L2TP/PPP sessions. Others said that this is a temporary
  198. issue and we shouldn't design a protocol to solve a temporary issue.
  199.  
  200. It was pointed out that this draft doesn't adequately address security.
  201.  
  202. It was mentioned that the QoS AVP's will be added to RADIUS as tunnel
  203. attributes.
  204.  
  205. Other items:
  206.  
  207. The chair repeated that SCM is now dropped as a work item.
  208.  
  209. IPCP is out in draft; comments are requested
  210.  
  211. When the chair requested on the L2TP mailing list that discussion be
  212. dropped concerning UDP checksums, several people refused, both publicly and
  213. privately.  The chair pointed out that the Area Directors agree with his
  214. decision, and would ask that such rude behavior be kept off the PPP lists
  215. in the future.
  216.  
  217.  
  218.  
  219.  
  220. Matt Holdrege  -  http://www.ascend.com  -  matt@ascend.com
  221.  
  222. ------- end -------
  223.  
  224. -- 
  225. Karl Fox, servant of God, employee of Ascend Communications
  226. 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221   +1 614 326 6841
  227.  
  228.