From owner-ietf-ppp@merit.edu Tue Feb 3 14:14:02 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA17658; Tue, 3 Feb 1998 14:10:43 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 3 Feb 1998 14:02:26 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA17370 for ietf-ppp-outgoing; Tue, 3 Feb 1998 14:02:25 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA17365 for ; Tue, 3 Feb 1998 14:02:20 -0500 (EST) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id LAA20313; Tue, 3 Feb 1998 11:02:03 -0800 Received: from ascend.com by ascend.com with ESMTP id LAA26118; Tue, 3 Feb 1998 11:02:02 -0800 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id LAA01071; Tue, 3 Feb 1998 11:02:01 -0800 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id LAA17703; Tue, 3 Feb 1998 11:01:58 -0800 Date: Tue, 3 Feb 1998 11:01:58 -0800 Message-Id: <199802031901.LAA17703@gump.eng.ascend.com> From: Karl Fox To: Jeffrey Burgan , Thomas Narten Cc: ietf-ppp@merit.edu, Steve Coya Subject: IP Header Compression over PPP to Proposed Standard Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Jeff and Thomas, The PPPEXT Working Group recommends that IP Header Compression over PPP, draft-engan-ip-compress-02.txt, be advanced to Proposed Standard. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Feb 4 09:22:27 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA04159; Wed, 4 Feb 1998 09:21:37 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 4 Feb 1998 09:17:15 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA04055 for ietf-ppp-outgoing; Wed, 4 Feb 1998 09:17:14 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA04049 for ; Wed, 4 Feb 1998 09:17:09 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA10069; Wed, 4 Feb 1998 09:17:05 -0500 (EST) Message-Id: <199802041417.JAA10069@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ietf-ppp@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-pppext-l2tp-ds-00.txt Date: Wed, 04 Feb 1998 09:17:04 -0500 Sender: owner-ietf-ppp@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Layer Two Tunneling Protocol ''L2TP'' IP Differential Services Extension Author(s) : K. Peirce, P. Calhoun Filename : draft-ietf-pppext-l2tp-ds-00.txt Pages : 4 Date : 03-Feb-98 The L2TP document [1] defines the base protocol which describes the method of tunneling PPP [2] data. The L2TP base protocol does not address any Differential Services extensions. Since the market is reluctant to outsource dial access without any Quality of Service assurances, this draft addresses this problem by allowing each L2TP Data Session to be assigned an appropriate differential services indicator. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-l2tp-ds-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tp-ds-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-l2tp-ds-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980203152936.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tp-ds-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tp-ds-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980203152936.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Feb 4 11:20:59 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA07111; Wed, 4 Feb 1998 11:20:31 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 4 Feb 1998 11:16:19 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA06825 for ietf-ppp-outgoing; Wed, 4 Feb 1998 11:16:16 -0500 (EST) Received: from atlas.xylogics.com (atlas.xylogics.com [132.245.33.7]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA06810 for ; Wed, 4 Feb 1998 11:16:03 -0500 (EST) Received: from bighorn.xylogics.com (bighorn.xylogics.com [132.245.32.188]) by atlas.xylogics.com (8.7.3/8.7.3) with SMTP id LAA12220 for ; Wed, 4 Feb 1998 11:15:02 -0500 (EST) Received: by bighorn.xylogics.com id AA21365 (5.x/UK-doug-sol2-951219); Wed, 4 Feb 1998 11:15:00 -0500 From: Gary Scott Malkin Date: Wed, 4 Feb 1998 11:15:00 -0500 Message-Id: <21365.9802041615@bighorn.xylogics.com> To: ietf-ppp@merit.edu Subject: MMP Bundle Discovery Protocol Sender: owner-ietf-ppp@merit.edu The latest I-D has been out for a couple of weeks now. Does anyone have any comments? If anyone is interested in doing interoperability testing, please let me know. -- Gary Malkin Cheap, Fast, Good (978) 916-4237 Pick two! - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Feb 4 16:11:53 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA20193; Wed, 4 Feb 1998 16:11:46 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 4 Feb 1998 16:09:45 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA20089 for ietf-ppp-outgoing; Wed, 4 Feb 1998 16:09:43 -0500 (EST) Received: from alpha.shiva.com (eagle-ext.shiva.com [192.80.57.28]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA20078 for ; Wed, 4 Feb 1998 16:09:35 -0500 (EST) From: sreeve@shiva.com Received: from zule.shiva.com (zule.shiva.com [140.248.128.52]) by alpha.shiva.com (8.8.8/8.8.8) with SMTP id QAA14456 for ; Wed, 4 Feb 1998 16:07:30 -0500 (EST) Received: by zule.shiva.com(Lotus SMTP MTA SMTP MTA v1.1.04 (495.1 10-24-1997)) id 852565A1.00745E00 ; Wed, 4 Feb 1998 16:11:02 -0500 X-Lotus-FromDomain: SHIVA CORPORATION To: ietf-ppp@merit.edu Message-ID: <852565A1.00723231.00@zule.shiva.com> Date: Wed, 4 Feb 1998 16:06:03 -0500 Subject: Re: MMP Bundle Discovery Protocol Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ppp@merit.edu gmalkin@xylogics.com on 02/04/98 11:15:00 AM To: ietf-ppp@merit.edu cc: (bcc: Scott Reeve/Shiva Corporation) Subject: MMP Bundle Discovery Protocol >The latest I-D has been out for a couple of weeks now. Does >anyone have any comments? > >-- > >Gary Malkin Cheap, Fast, Good >(978) 916-4237 Pick two! 1) Is it necessary to define/limit a particular tunneling protocol to use? Perhaps the tunneling protocol itself is beyond the scope of MMP. 2) For the purposes of clarity, I want to make sure that I understand Random IDs. Let me know if I have anything wrong: - A Random ID is unique to a bundle. I.e. when the decision is made to start MMP on a call, a random number is calculated. - Subsequent/different bundles require a new random number calculation. - When a bundle re-trasmits a Query it must stick to the same Random ID that went out in the first Query. 3) If a node has sent out its ROBUSTNESS Queries, and realizes that it doesn't have the lowest Random ID, then it must wait until it hears a Response. How long should it wait for a Response? E.g: two nodes could be sending with quite different ROBUSTNESS and/or QUERY_INTERVAL values, so one node could give up trying to be the bundle head, but has no idea how long the other node may still be trying. What if it never gets a Response? This probably means that the NAS that had the lowest Random ID just went down. Should the node then determine the next lowest Random ID? 4) Is it necessary to limit MMP activity to broadcast or a defined multicast address? If it were left fully configurable, any implementation could send to any address that they wanted, even unicast, conceivably. (many 'multicast applications' fold down to unicast if that's what the user wants) Scott Reeve sreeve@shiva.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Feb 4 16:39:29 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA21211; Wed, 4 Feb 1998 16:39:26 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 4 Feb 1998 16:38:56 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA21165 for ietf-ppp-outgoing; Wed, 4 Feb 1998 16:38:55 -0500 (EST) Received: from alpha.shiva.com (eagle-ext.shiva.com [192.80.57.28]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA21149 for ; Wed, 4 Feb 1998 16:38:45 -0500 (EST) From: sreeve@shiva.com Received: from zule.shiva.com (zule.shiva.com [140.248.128.52]) by alpha.shiva.com (8.8.8/8.8.8) with SMTP id QAA15651 for ; Wed, 4 Feb 1998 16:36:45 -0500 (EST) Received: by zule.shiva.com(Lotus SMTP MTA SMTP MTA v1.1.04 (495.1 10-24-1997)) id 852565A1.00770DAE ; Wed, 4 Feb 1998 16:40:22 -0500 X-Lotus-FromDomain: SHIVA CORPORATION To: ietf-ppp@merit.edu Message-ID: <852565A1.007641C2.00@zule.shiva.com> Date: Wed, 4 Feb 1998 16:35:22 -0500 Subject: Re: MMP Bundle Discovery Protocol Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ppp@merit.edu Let's try that again. gmalkin@xylogics.com on 02/04/98 11:15:00 AM To: ietf-ppp@merit.edu cc: (bcc: Scott Reeve/Shiva Corporation) Subject: MMP Bundle Discovery Protocol >The latest I-D has been out for a couple of weeks now. Does >anyone have any comments? If anyone is interested in doing >interoperability testing, please let me know. >Gary Malkin Cheap, Fast, Good >(978) 916-4237 Pick two! 1) Is it necessary to define/limit a particular tunneling protocol to use? Perhaps the tunneling protocol itself is beyond the scope of MMP. 2) For the purposes of clarity, I want to make sure that I understand Random IDs. Let me know if I have anything wrong: - A Random ID is unique to a bundle. I.e. when the decision is made to start MMP on a call, a random number is calculated. - Subsequent/different bundles require a new random number calculation. - When a bundle re-trasmits a Query it must stick to the same Random ID that went out in the first Query. 3) If a node has sent out its ROBUSTNESS Queries, and realizes that it doesn't have the lowest Random ID, then it must wait until it hears a Response. How long should it wait for a Response? E.g: two nodes could be sending with quite different ROBUSTNESS and/or QUERY_INTERVAL values, so one node could give up trying to be the bundle head, but has no idea how long the other node may still be trying. What if it never gets a Response? This probably means that the NAS that had the lowest Random ID just went down. Should the node then determine the next lowest Random ID? 4) Is it necessary to limit MMP activity to broadcast or a defined multicast address? If it were left fully configurable, any implementation could send to any address that they wanted, even unicast, conceivably. (many 'multicast applications' fold down to unicast if that's what the user wants) Scott Reeve sreeve@shiva.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 5 16:30:25 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA16196; Thu, 5 Feb 1998 16:28:53 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 5 Feb 1998 16:20:41 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA16003 for ietf-ppp-outgoing; Thu, 5 Feb 1998 16:20:41 -0500 (EST) Received: from zyxel.com (ss7.zyxel.com [204.217.0.7]) by merit.edu (8.8.7/8.8.5) with SMTP id QAA15998 for ; Thu, 5 Feb 1998 16:20:32 -0500 (EST) Received: from is.zyxel.com by zyxel.com (SMI-8.6/SMI-SVR4) id NAA05323; Thu, 5 Feb 1998 13:26:40 -0800 Received: by is.zyxel.com with Microsoft Exchange (IMC 4.12.736) id <01BD323B.33CA30F0@is.zyxel.com>; Thu, 5 Feb 1998 13:37:28 -0800 Message-ID: From: Nasser Tarazi To: "'IETF-Announce@ns.ietf.org'" , "'ietf-ppp@merit.edu'" Subject: Remove for list Date: Thu, 5 Feb 1998 13:37:27 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.12.736 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD323B.33CA30F0" Sender: owner-ietf-ppp@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. Contact your mail administrator for information about upgrading your reader to a version that supports MIME. ------ =_NextPart_000_01BD323B.33CA30F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, Can you remove me for the list Nasser Tarazi ********************************************************** ZyXEL Communications Inc. - Product Engineering Dept. Phone: 714-693-0808 Ext. 206 Fax : 714-693-8811 E-Mail: nasser@zyxel.com FTP: ftp://ftp.zyxel.com WWW: http://www.zyxel.com ********************************************************** ------ =_NextPart_000_01BD323B.33CA30F0-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 6 12:07:34 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA01405; Fri, 6 Feb 1998 12:05:54 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 6 Feb 1998 11:59:17 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA01271 for ietf-ppp-outgoing; Fri, 6 Feb 1998 11:59:17 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.7/8.8.5) with SMTP id LAA01264 for ; Fri, 6 Feb 1998 11:59:11 -0500 (EST) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id IAA08327 for ; Fri, 6 Feb 1998 08:59:10 -0800 Received: from ascend.com by ascend.com with ESMTP id IAA11052 for ; Fri, 6 Feb 1998 08:59:06 -0800 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id IAA28069 for ; Fri, 6 Feb 1998 08:59:05 -0800 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id IAA13320 for ; Fri, 6 Feb 1998 08:58:59 -0800 Date: Fri, 6 Feb 1998 08:58:59 -0800 Message-Id: <199802061658.IAA13320@gump.eng.ascend.com> From: Karl Fox To: ietf-ppp@merit.edu Subject: PPPEXT schedule for 41st IETF-Los Angeles Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu We have been assigned two slots adding up to 3 hours of meeting time: Monday, March 30 at 1530-1730 (opposite ssh, manet, mboned) Tuesday, March 31 at 0900-1000 (opposite issll) -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sun Feb 8 11:14:17 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA21600; Sun, 8 Feb 1998 11:13:45 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Sun, 8 Feb 1998 11:08:24 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA21558 for ietf-ppp-outgoing; Sun, 8 Feb 1998 11:08:23 -0500 (EST) Received: from smtp-gw.BayNetworks.COM (ext-ns3.baynetworks.com [192.32.253.3] (may be forged)) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA21554 for ; Sun, 8 Feb 1998 11:08:19 -0500 (EST) Received: from mailhost.BayNetworks.COM ([132.245.135.84] (may be forged)) by smtp-gw.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id KAA09548; Sun, 8 Feb 1998 10:57:53 -0500 (EST) Received: from lobster1.corpeast.Baynetworks.com (ns2.corpeast.baynetworks.com [192.32.72.17]) by mailhost.BayNetworks.COM (8.8.6/8.8.6) with SMTP id KAA00882; Sun, 8 Feb 1998 10:57:25 -0500 (EST) Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-nf0) by lobster1.corpeast.Baynetworks.com (4.1/BNET-97/04/29-S) id AA17157; Sun, 8 Feb 98 10:57:03 EST for int-serv@isi.edu Received: from ndoraswa.corpeast.baynetworks.com ([132.245.112.95]) by bl-mail1.corpeast.BayNetworks.com (post.office MTA v2.0 0529 ID# 0-13458) with SMTP id AAA13444; Sun, 8 Feb 1998 10:55:55 -0500 Message-Id: <3.0.32.19980208105656.00b7bb68@bl-mail1.corpeast.baynetworks.com> X-Sender: ndoraswa_pop@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 08 Feb 1998 10:56:58 -0500 To: ipsec@tis.com, mpls@external.cisco.com, ietf-ppp@merit.edu, int-serv@ISI.EDU From: Naganand Doraswamy Subject: VPN mailing list Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_886971418==_" Sender: owner-ietf-ppp@merit.edu --=====================_886971418==_ Content-Type: text/plain; charset="us-ascii" I have created VPN mailing list and attached a proposed charter. I would like to start discussion on what the charter of working group should be and what problems we should be working on. We intend to have another BOF at IETF but this time we need to nail down the charter. --=====================_886971418==_ Content-Type: text/plain; charset="us-ascii" VPN BOF ------- Proposed Chairs --------------- Naganand Doraswamy (naganand@baynetworks.com) Robert Moskowitz (rgm3@icsa.net) Area Directors -------------- Thomas Narten (narten@raleigh.ibm.com) Jeffrey Burgan (burgan@home.net) Area Advisor ------------ TBD Mailing Lists ------------- Discussions: vpn@baynetworks.com subscription: majordomo@baynetworks.com. In the body of the message say: subscribe vpn Description of VPN BOF ---------------------- Virtual Priavate Networking (VPN) is a way of extending a private network seamlessly over a public network. However, this raises various issues such as security, Addressing, Quality of Service to name a few as the traffic belonging to the private network traverses a public network. VPN model can be one of many. An organization can build its VPN. An ISP can build and maintain a VPN of an organization. VPN can exist between organizations (extranets). There is a need to define mechanisms to achieve these capabilies. Some of the issues that needs to be addressed are: 1. Security: Security can be achived by restricting the packet flowing in an out of a VPN. In addition the packets can also be encrypted and authenticated. 2. How to provide Quality of Service/Class of service for packets flowing between the edges. In this case, we may not be worried about providing end to end QoS but only between edges. 3. How to handle Network Address Translation issues. Even though NAT's are a kludge, it has been deployed widely and there is a need to address this issue properly. Should we consider extending the concept of private addressing over the Internet? 4. Ease of configuration. 5. Reliability. 6. Management The goals of the VPN BOF are: 1. Decide if there is a need to form a working group to solve some or all of the problems above. 2. Which of the problems above should be addressed by the working group. 3. What will the working group produce. In our opinion, we need to interact with other working groups such as IPsec working group, NAT working group, int-serv working group, and probably routing working group to solve some or all of the problems above. 4. What other problems need to be solved for succesful deployment of VPN's. --=====================_886971418==_ Content-Type: text/plain; charset="us-ascii" --Naganand ----------------------------------------------------------------- Naganand Doraswamy (978)916-1323 (O) Bay Architecture Lab (978)670-0620 (Fax) 3 Federal St, Mail Stop BL3-03 Billerica, MA 01821 --=====================_886971418==_-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Feb 9 09:52:29 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA06542; Mon, 9 Feb 1998 09:52:18 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 9 Feb 1998 09:46:31 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA06462 for ietf-ppp-outgoing; Mon, 9 Feb 1998 09:46:30 -0500 (EST) Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA06458 for ; Mon, 9 Feb 1998 09:46:21 -0500 (EST) Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.0.1458.49) id <12SHYCKB>; Mon, 9 Feb 1998 15:47:37 +0100 Message-ID: <0DEBEE4818DCD011B70200A024D43F4D5661B6@c-mhs.caen.cnet.fr> From: JACQUENET Christian CNET/DSE/CAE To: "'ietf-ppp@merit.edu'" Subject: PPP over Ethernet networks Date: Mon, 9 Feb 1998 15:50:39 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Dear PPP gurus, If I remember correctly, there was somme discussion last year about the opportunity to establish PPP sessions over Ethernet segments. Two questions : 1. Am I wrong ? 2. If the answer is "no" to the previous question, can anyone provide some useful pointers, since I did not find anything about this subject yet (including a possible I-D) ? Thanks in advance and best regards, Christian. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Feb 9 10:02:51 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA06774; Mon, 9 Feb 1998 10:02:42 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 9 Feb 1998 10:02:00 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA06737 for ietf-ppp-outgoing; Mon, 9 Feb 1998 10:01:59 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA06732 for ; Mon, 9 Feb 1998 10:01:52 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA19287; Mon, 9 Feb 1998 10:01:47 -0500 (EST) Message-Id: <199802091501.KAA19287@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ietf-ppp@merit.edu, mobile-ip@smallworks.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-pppext-ipcp-mip-03.txt Date: Mon, 09 Feb 1998 10:01:47 -0500 Sender: owner-ietf-ppp@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Mobile-IPv4 Configuration Option for PPP IPCP Author(s) : J. Solomon, S. Glass Filename : draft-ietf-pppext-ipcp-mip-03.txt Pages : 18 Date : 06-Feb-98 Mobile IP [RFC 2002] defines media-independent procedures by which a Mobile Node can maintain existing transport and application-layer connections despite changing its point-of-attachment to the Internet and without changing its IP address. PPP [RFC 1661] provides a standard method for transporting multi-protocol packets over point- to-point links. As currently specified, Mobile IP Foreign Agents which support Mobile Node connections via PPP can do so only by first assigning unique addresses to those Mobile Nodes, defeating one of the primary advantages of Foreign Agents. This documents corrects this problem by defining the Mobile-IPv4 Configuration Option to the Internet Protocol Control Protocol (IPCP) [RFC 1332]. Using this option, two peers can communicate their support for Mobile IP during the IPCP phase of PPP. Familiarity with Mobile IP [RFC 2002], IPCP [RFC 1332], and PPP [RFC 1661] is assumed. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-ipcp-mip-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-ipcp-mip-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-ipcp-mip-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980206145604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-ipcp-mip-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-ipcp-mip-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980206145604.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Feb 9 10:47:08 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA08216; Mon, 9 Feb 1998 10:47:06 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 9 Feb 1998 10:45:37 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA08107 for ietf-ppp-outgoing; Mon, 9 Feb 1998 10:45:36 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA08099 for ; Mon, 9 Feb 1998 10:45:26 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA21866; Mon, 9 Feb 1998 10:45:07 -0500 (EST) Message-Id: <199802091545.KAA21866@ns.ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@merit.edu From: The IESG Subject: Protocol Action: PPP Extensible Authentication Protocol (EAP) to Proposed Standard Date: Mon, 09 Feb 1998 10:45:07 -0500 Sender: owner-ietf-ppp@merit.edu The IESG has approved the Internet-Draft "PPP Extensible Authentication Protocol (EAP)" as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Thomas Narten and Jeffrey Burgan. Technical Summary The PPP Extensible Authentication Protocol (EAP) is a general protocol for PPP authentication which supports multiple authentication mechanisms. After the link has been established, PPP provides this optional Authentication Phase before proceeding to the Network-Layer Protocol phase. EAP does not select a specific authentication mechanism at Link Control Phase, but rather postpones this until the Authentication Phase. This allows the authenticator to request more information before determining the specific authentication mechanism. This also permits the use of a "back-end" server which actually implements the various mechanisms while the PPP authenticator merely passes through the authentication exchange. Working Group Summary The Working Group last call produced no issues with this document. Protocol Quality This document has been reviewed by Jeffrey Burgan and Thomas Narten of the IESG. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Feb 9 20:29:23 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA23984; Mon, 9 Feb 1998 20:28:59 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 9 Feb 1998 20:27:53 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA23945 for ietf-ppp-outgoing; Mon, 9 Feb 1998 20:27:53 -0500 (EST) Received: from netman.iscs.nus.sg (root@netman.iscs.nus.sg [137.132.87.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA23940 for ; Mon, 9 Feb 1998 20:27:47 -0500 (EST) Received: from sun450.iscs.nus.edu.sg (limlipye@sun450-m.iscs.nus.edu.sg [137.132.21.116]) by netman.iscs.nus.sg (8.8.5/8.8.5) with ESMTP id JAA25910; Tue, 10 Feb 1998 09:27:43 +0800 (GMT+0800) Received: from localhost (limlipye@localhost) by sun450.iscs.nus.edu.sg (8.8.5/8.8.5) with SMTP id JAA28912; Tue, 10 Feb 1998 09:27:42 +0800 (GMT-8) X-Authentication-Warning: sun450.iscs.nus.edu.sg: limlipye owned process doing -bs Date: Tue, 10 Feb 1998 09:27:42 +0800 (GMT-8) From: Lim Lip Yeow To: JACQUENET Christian CNET/DSE/CAE cc: "'ietf-ppp@merit.edu'" Subject: Re: PPP over Ethernet networks In-Reply-To: <0DEBEE4818DCD011B70200A024D43F4D5661B6@c-mhs.caen.cnet.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Mon, 9 Feb 1998, JACQUENET Christian CNET/DSE/CAE wrote: > Dear PPP gurus, sorry, i'm no guru... :) > If I remember correctly, there was somme discussion last year about the > opportunity to establish PPP sessions over Ethernet segments. Two > questions : are you referring to Piont-to-Point Tunneling protocol -- PPTP or L2TP? if true try: draft-ietf-pppext-pptp-02.txt draft-ietf-l2tp-09.txt hope it helps ... lip yeow - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Feb 10 03:00:35 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id DAA28557; Tue, 10 Feb 1998 03:00:07 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 10 Feb 1998 02:58:57 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id CAA28528 for ietf-ppp-outgoing; Tue, 10 Feb 1998 02:58:56 -0500 (EST) Received: from fsnt.future.futsoft.com ([38.242.192.5]) by merit.edu (8.8.7/8.8.5) with ESMTP id CAA28524 for ; Tue, 10 Feb 1998 02:58:49 -0500 (EST) Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Tue, 10 Feb 1998 13:24:27 +0530 Received: from essen.future.futsoft.com (essen.future.futsoft.com [10.0.4.130]) by kailash.future.futsoft.com (8.7.1/8.7.1) with ESMTP id NAA25257; Tue, 10 Feb 1998 13:01:39 +0530 Received: (from suryam@localhost) by essen.future.futsoft.com (8.6.11/8.6.9) id NAA00209; Tue, 10 Feb 1998 13:21:01 -0500 Date: Tue, 10 Feb 1998 13:21:00 -0500 (EST) From: "M.N.V.Suryanarayana" To: ietf-ppp@merit.edu Subject: A doubt in RFC 1974 Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Hi, I'm a bit confused about the following statement in RFC 1974(PPP Stac LZS Compression Protocol, Page 12). "Receiver Process: If a CCP Reset-Request packet is received, the local compression engine MUST be signaled that a Reset-Request has been received for the history number specified in the data field" But RFC 1962(CCP) states that a Reset-Request is sent by the Receiver(i.e the decompressor) to indicate a decompression failure. The transmitter sends a Reset-Ack after processing the Reset-Request. I couldn't find in the RFC as to when a transmitter can send a Reset-Request. When does a transmitter sends a Reset-Request packet to Receiver? When a Receiver process receives a Reset-Request packet, its stated that local compression engine MUST be signalled. What kind of action needs to be taken by local compression engine? Can someone please help me to understand this point better. Thanks, Ramachandran - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Feb 10 07:05:08 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id HAA00296; Tue, 10 Feb 1998 07:04:32 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 10 Feb 1998 06:58:28 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id GAA00216 for ietf-ppp-outgoing; Tue, 10 Feb 1998 06:58:27 -0500 (EST) Received: from ironbridgenetworks.com ([146.115.140.2]) by merit.edu (8.8.7/8.8.5) with SMTP id GAA00212 for ; Tue, 10 Feb 1998 06:58:21 -0500 (EST) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id GAA22711; Tue, 10 Feb 1998 06:58:02 -0500 Date: Tue, 10 Feb 1998 06:58:02 -0500 Message-Id: <199802101158.GAA22711@ironbridgenetworks.com> From: James Carlson To: suryam@future.futsoft.com CC: ietf-ppp@merit.edu In-reply-to: (suryam@future.futsoft.com) Subject: Re: A doubt in RFC 1974 References: Sender: owner-ietf-ppp@merit.edu > I'm a bit confused about the following statement in RFC 1974(PPP Stac LZS > Compression Protocol, Page 12). > > "Receiver Process: > If a CCP Reset-Request packet is received, the local compression engine > MUST be signaled that a Reset-Request has been received for the history > number specified in the data field" > > But RFC 1962(CCP) states that a Reset-Request is sent by the > Receiver(i.e the decompressor) to indicate a decompression failure. > The transmitter sends a Reset-Ack after processing the > Reset-Request. Those are saying the same thing. RFC 1974 just confusingly describes it in passive voice from the view of the receiver of the message. The reset request always comes from the decompressor. In other words, when you get a reset-request on input, you have to reset your compressor and send reset-ack. (Note also that if you're doing 1974 in order to support Win95, that it uses "mode 4," which is very different from the general 1974 text.) > I couldn't find in the RFC as to when a transmitter can send a Reset-Request. The decompressor transmits a reset-request to the compressor when it detects an error (LCS, CRC, sequence, or algorithmic error). "Transmitter" here isn't the same thing as "compressor." "Transmitter" means the entity that transmits a packet. Both the compressor and the decompressor transmit packets in this sense. > When does a transmitter sends a Reset-Request packet to Receiver? > When a Receiver process receives a Reset-Request packet, its stated > that local compression engine MUST be signalled. What kind of action > needs to be taken by local compression engine? It resets itself. -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 402 8032 Lexington MA 02173-7999 / USA 42.423N Fax: +1 781 402 8092 "PPP Design and Debugging" ------- http://id.wing.net/People/carlson/ppp - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Feb 10 08:59:42 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA01327; Tue, 10 Feb 1998 08:59:30 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 10 Feb 1998 08:58:42 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA01299 for ietf-ppp-outgoing; Tue, 10 Feb 1998 08:58:41 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA01295 for ; Tue, 10 Feb 1998 08:58:37 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA16663; Tue, 10 Feb 1998 08:58:34 -0500 (EST) Message-Id: <199802101358.IAA16663@ns.ietf.org> To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: The IESG SUBJECT: Last Call: PPP over AAL5 to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Tue, 10 Feb 1998 08:58:34 -0500 Sender: owner-ietf-ppp@merit.edu The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider PPP over AAL5 as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 24, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-aal5-04.txt - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Feb 10 09:16:29 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA01729; Tue, 10 Feb 1998 09:16:29 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 10 Feb 1998 09:16:12 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA01702 for ietf-ppp-outgoing; Tue, 10 Feb 1998 09:16:12 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA01698 for ; Tue, 10 Feb 1998 09:16:07 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA17081; Tue, 10 Feb 1998 09:16:04 -0500 (EST) Message-Id: <199802101416.JAA17081@ns.ietf.org> To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: The IESG SUBJECT: Last Call: PPP Over FUNI to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Tue, 10 Feb 1998 09:16:03 -0500 Sender: owner-ietf-ppp@merit.edu The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider PPP Over FUNI as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 24, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-funi-04.txt - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Feb 10 11:37:20 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA04878; Tue, 10 Feb 1998 11:36:35 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 10 Feb 1998 11:34:38 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA04799 for ietf-ppp-outgoing; Tue, 10 Feb 1998 11:34:38 -0500 (EST) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA04795 for ; Tue, 10 Feb 1998 11:34:29 -0500 (EST) Received: from scesie03.sie.siemens.at (root@firix [10.1.143.100]) by zwei.siemens.at with ESMTP id RAA28424 for ; Tue, 10 Feb 1998 17:33:31 +0100 (MET) Received: from pc7990 (pc7990.hai.siemens.co.at) by scesie03.sie.siemens.at with SMTP (1.40.112.8/16.2) id AA164488412; Tue, 10 Feb 1998 17:33:32 +0100 From: "Walter Klausberger" To: Subject: PPP Payload in L2TP Date: Tue, 10 Feb 1998 17:37:14 +0100 Message-Id: <01bd3642$24c8c200$bb4802c3@pc7990.ERD01> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ietf-ppp@merit.edu Hi I have a question about PPP over L2TP. In L2TP Draft, Page 8 (end of page) is written: Frames from the remote user are received at the POP, stripped of CRC, link framing, and transparency bytes,... Question: If the PPP connection works over ISDN (synch. HDLC Framing) does the address and control field belong to the link framing, or are they also encapsulated into L2TP. This question arises, because we plan to transport PPP over AAL5 and Frame Relay. This PPP packets will be forwarded into a L2TP tunnel. The framing of AAl5 or Frame Relay is different to the framing of ISDN/HDLC with best regards Walter Klausberger Siemens Austria - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Feb 10 12:21:39 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA05725; Tue, 10 Feb 1998 12:21:34 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 10 Feb 1998 12:20:54 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA05687 for ietf-ppp-outgoing; Tue, 10 Feb 1998 12:20:54 -0500 (EST) Received: from ntserver.newoak.com ([146.115.61.251]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA05683 for ; Tue, 10 Feb 1998 12:20:50 -0500 (EST) Received: from rshea ([10.0.1.243]) by ntserver.newoak.com (Netscape Mail Server v2.02) with ESMTP id AAA184; Tue, 10 Feb 1998 12:21:25 -0500 Message-ID: <34E08C3C.B52CA2DA@BayNetworks.com> Date: Tue, 10 Feb 1998 12:19:56 -0500 From: Richard Shea Reply-To: rshea@BayNetworks.com Organization: Bay Networks X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: Walter Klausberger CC: ietf-ppp@merit.edu Subject: Re: PPP Payload in L2TP X-Priority: 3 (Normal) References: <01bd3642$24c8c200$bb4802c3@pc7990.ERD01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Walter Klausberger wrote: > > Hi > I have a question about PPP over L2TP. > > In L2TP Draft, Page 8 (end of page) is written: > Frames from the remote user are received at the POP, stripped of CRC, > link > framing, and transparency bytes,... > > Question: If the PPP connection works over ISDN (synch. HDLC Framing) > does the address and control field belong to the link framing, or are > they > also encapsulated into L2TP. > Address and control field are encapsulated into L2TP as necessary (i.e. when present). In the case of HDLC I believe "link framing" would consist of the "flag sequence" which would of course not be encapsulated in L2TP. Richard. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Richard Shea rshea@BayNetworks.com Bay Networks, Extranet Access 978-266-1011 x210 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Feb 10 14:08:59 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA07704; Tue, 10 Feb 1998 14:08:46 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 10 Feb 1998 14:06:36 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA07649 for ietf-ppp-outgoing; Tue, 10 Feb 1998 14:06:36 -0500 (EST) Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA07642 for ; Tue, 10 Feb 1998 14:06:31 -0500 (EST) Received: (rtio@localhost) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id LAA15689; Tue, 10 Feb 1998 11:05:10 -0800 (PST) From: Rene Tio Message-Id: <199802101905.LAA15689@flipper.cisco.com> Subject: Re: PPP Payload in L2TP To: rshea@BayNetworks.COM Date: Tue, 10 Feb 1998 11:05:10 -0800 (PST) Cc: walter.klausberger@siemens.at, ietf-ppp@merit.edu In-Reply-To: <34E08C3C.B52CA2DA@BayNetworks.com> from "Richard Shea" at Feb 10, 98 12:19:56 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Rich, Perhaps I am misunderstanding your remark, but PPP in Frame Relay says the frame format is: +-+-+-+-+-+-+-+-+ | Flag (0x7e) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Q.922 Address | Control | NLPID(0xcf) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PPP Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If link framing is only the flag sequence, and the LAC only strips this portion, the LNS would see the Q.922 header in full. Is this the intent of the L2TP text? Thanks -- Rene Tio > From owner-ietf-ppp@merit.edu Tue Feb 10 09:25:40 1998 > > Walter Klausberger wrote: > > > > Hi > > I have a question about PPP over L2TP. > > > > In L2TP Draft, Page 8 (end of page) is written: > > Frames from the remote user are received at the POP, stripped of CRC, > > link > > framing, and transparency bytes,... > > > > Question: If the PPP connection works over ISDN (synch. HDLC Framing) > > does the address and control field belong to the link framing, or are > > they > > also encapsulated into L2TP. > > > > Address and control field are encapsulated into L2TP as necessary (i.e. > when present). In the case of HDLC I believe "link framing" would > consist of the "flag sequence" which would of course not be encapsulated > in L2TP. > > Richard. > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > Richard Shea rshea@BayNetworks.com > Bay Networks, Extranet Access 978-266-1011 x210 > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Feb 10 14:17:57 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA07894; Tue, 10 Feb 1998 14:17:56 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 10 Feb 1998 14:16:24 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA07810 for ietf-ppp-outgoing; Tue, 10 Feb 1998 14:16:24 -0500 (EST) Received: from ntserver.newoak.com ([146.115.61.251]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA07790 for ; Tue, 10 Feb 1998 14:16:01 -0500 (EST) Received: from rshea ([10.0.1.243]) by ntserver.newoak.com (Netscape Mail Server v2.02) with ESMTP id AAA109; Tue, 10 Feb 1998 14:16:34 -0500 Message-ID: <34E0A73A.9045AE5B@BayNetworks.com> Date: Tue, 10 Feb 1998 14:15:06 -0500 From: Richard Shea Reply-To: rshea@BayNetworks.com Organization: Bay Networks X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: Rene Tio CC: walter.klausberger@siemens.at, ietf-ppp@merit.edu Subject: Re: PPP Payload in L2TP X-Priority: 3 (Normal) References: <199802101905.LAA15689@flipper.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Rene Tio wrote: > > Rich, > > Perhaps I am misunderstanding your remark, but PPP in Frame Relay says > the > frame format is: > > +-+-+-+-+-+-+-+-+ > | Flag (0x7e) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Q.922 Address | Control | NLPID(0xcf) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PPP Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > If link framing is only the flag sequence, and the LAC only strips > this > portion, the LNS would see the Q.922 header in full. Is this the > intent of > the L2TP text? > For HDLC (ala rfc 1662) the flag sequence is the link framing which is removed. I honestly don't know what the intent is for FR or AAL5 encapsulated PPP over L2TP. IF (big if) I had to guess, I would guess that everything above except "PPP Protocol" would be removed. I know for a fact that my LNS implementation wouldn't know what to do with the rest of it! > Thanks > -- > Rene Tio > > > From owner-ietf-ppp@merit.edu Tue Feb 10 09:25:40 1998 > > > > Walter Klausberger wrote: > > > > > > Hi > > > I have a question about PPP over L2TP. > > > > > > In L2TP Draft, Page 8 (end of page) is written: > > > Frames from the remote user are received at the POP, stripped of > CRC, > > > link > > > framing, and transparency bytes,... > > > > > > Question: If the PPP connection works over ISDN (synch. HDLC > Framing) > > > does the address and control field belong to the link framing, or > are > > > they > > > also encapsulated into L2TP. > > > > > > > Address and control field are encapsulated into L2TP as necessary > (i.e. > > when present). In the case of HDLC I believe "link framing" would > > consist of the "flag sequence" which would of course not be > encapsulated > > in L2TP. > > > > Richard. > > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > Richard Shea rshea@BayNetworks.com > > Bay Networks, Extranet Access 978-266-1011 x210 > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Richard Shea rshea@BayNetworks.com Bay Networks, Extranet Access 978-266-1011 x210 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Feb 11 03:44:11 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id DAA19189; Wed, 11 Feb 1998 03:44:03 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 11 Feb 1998 03:43:05 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id DAA19166 for ietf-ppp-outgoing; Wed, 11 Feb 1998 03:43:04 -0500 (EST) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by merit.edu (8.8.7/8.8.5) with ESMTP id DAA19162 for ; Wed, 11 Feb 1998 03:42:57 -0500 (EST) Received: from scesie03.sie.siemens.at (root@firix [10.1.143.100]) by zwei.siemens.at with ESMTP id JAA03826; Wed, 11 Feb 1998 09:42:21 +0100 (MET) Received: from pc7990 (pc7990.hai.siemens.co.at) by scesie03.sie.siemens.at with SMTP (1.40.112.8/16.2) id AA243416543; Wed, 11 Feb 1998 09:42:23 +0100 From: "Walter Klausberger" To: Cc: , Subject: Re: PPP Payload in L2TP Date: Wed, 11 Feb 1998 09:46:09 +0100 Message-Id: <01bd36c9$7fbf93f0$bb4802c3@pc7990.ERD01> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ietf-ppp@merit.edu Well that is the main problem. How should the LNS know, what header is used for PPP at the LAC? During establishment of the tunnel-session (Incoming-Call-Request) the LNS is only informed if the PPP is transported over analog or digital channel (Bearer Type). With the message Incoming-Call-Connected the AVP "Framing Type" must be sent. But the LNS is only informed if asynch. or synch. framing is used, not which type of synch. framing (e.g. HDLC, PPP in Frame Relay, PPP over AAL5/ATM). I think this is a problem. Thanks, Walter -----Ursprüngliche Nachricht----- Von: rtio@cisco.com An: rshea@BayNetworks.COM Cc: walter.klausberger@siemens.at ; ietf-ppp@merit.edu Datum: Dienstag, 10. Februar 1998 20:05 Betreff: Re: PPP Payload in L2TP >Rich, > >Perhaps I am misunderstanding your remark, but PPP in Frame Relay says the >frame format is: > > +-+-+-+-+-+-+-+-+ > | Flag (0x7e) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Q.922 Address | Control | NLPID(0xcf) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PPP Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >If link framing is only the flag sequence, and the LAC only strips this >portion, the LNS would see the Q.922 header in full. Is this the intent of >the L2TP text? > >Thanks >-- >Rene Tio > > >> From owner-ietf-ppp@merit.edu Tue Feb 10 09:25:40 1998 >> >> Walter Klausberger wrote: >> > >> > Hi >> > I have a question about PPP over L2TP. >> > >> > In L2TP Draft, Page 8 (end of page) is written: >> > Frames from the remote user are received at the POP, stripped of CRC, >> > link >> > framing, and transparency bytes,... >> > >> > Question: If the PPP connection works over ISDN (synch. HDLC Framing) >> > does the address and control field belong to the link framing, or are >> > they >> > also encapsulated into L2TP. >> > >> >> Address and control field are encapsulated into L2TP as necessary (i.e. >> when present). In the case of HDLC I believe "link framing" would >> consist of the "flag sequence" which would of course not be encapsulated >> in L2TP. >> >> Richard. >> >> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >> Richard Shea rshea@BayNetworks.com >> Bay Networks, Extranet Access 978-266-1011 x210 >> > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Feb 11 05:33:15 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id FAA19725; Wed, 11 Feb 1998 05:32:41 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 11 Feb 1998 05:25:48 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id FAA19643 for ietf-ppp-outgoing; Wed, 11 Feb 1998 05:25:48 -0500 (EST) Received: from extmx.itri.org.tw (ntx.itri.org.tw [140.96.158.1]) by merit.edu (8.8.7/8.8.5) with SMTP id FAA19639 for ; Wed, 11 Feb 1998 05:25:36 -0500 (EST) Received: by extmx.itri.org.tw; (5.65v3.2/1.3/10May95) id AA29430; Wed, 11 Feb 1998 18:27:13 +0800 Received: from oax2.ccl.itri.org.tw by ntx.itri.org.tw (smtpxd); id XA31083 Received: from cclk400.ccl.itri.org.tw (cclk400.ccl.itri.org.tw [140.96.104.5]) by oax2.CCL.ITRI.Org.tw (8.8.5/8.8.5) with ESMTP id SAA22112 for ; Wed, 11 Feb 1998 18:25:12 +0800 (CST) Received: from CCLK400/MAILQ_K400 by cclk400.ccl.itri.org.tw (Mercury 1.21); 11 Feb 98 18:28:24 GMT+800 Received: from MAILQ_K400 by CCLK400 (Mercury 1.21); 11 Feb 98 18:28:10 GMT+800 Received: from cclk400.ccl.itri.org.tw by cclk400.ccl.itri.org.tw (Mercury 1.21) with ESMTP; 11 Feb 98 18:28:01 GMT+800 Message-Id: <34E17DAA.6DEFC056@cclk400.ccl.itri.org.tw> Date: Wed, 11 Feb 1998 18:30:03 +0800 From: Jen-Chi Liu X-Mailer: Mozilla 4.04 [en] (Win95; I) Mime-Version: 1.0 To: ietf-ppp@merit.edu Subject: I want L2TP source codes Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-ppp@merit.edu Somebody can tell me where I can find out L2TP source codes or buy them?? Thanks a lot!! -- ¼B«Ø§Ó/Jen-Chi, Liu Ph.D. Engineer, Multimedia System Dept. Computer & Communications Research Laboratories, Industrial Technology Research Institute, Taiwan (tel) 886-3-5914663 (fax) 886-3-5820310 e-mail: ccliu@cclk400.ccl.itri.org.tw - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Feb 11 07:49:12 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id HAA20478; Wed, 11 Feb 1998 07:49:10 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 11 Feb 1998 07:45:54 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id HAA20448 for ietf-ppp-outgoing; Wed, 11 Feb 1998 07:45:54 -0500 (EST) Received: from btmplq.god.bel.alcatel.be (gatekeeper.alcatel.be [138.203.244.2]) by merit.edu (8.8.7/8.8.5) with SMTP id HAA20444 for ; Wed, 11 Feb 1998 07:45:49 -0500 (EST) Received: from localhost (uucp@localhost) by btmplq.god.bel.alcatel.be (8.6.5/8.6.5) id NAA28623 for ; Wed, 11 Feb 1998 13:44:34 +0100 Received: from btmp80.sebb.bel.alcatel.be(138.203.168.88) by btmplq via smap (V1.3) id smac28601; Wed Feb 11 13:44:26 1998 Received: from btk0dy.Broadband (btk0dy [138.203.224.11]) by btmp80 (8.6.5/8.6.5) with SMTP id NAA08434; Wed, 11 Feb 1998 13:45:35 +0100 Date: Wed, 11 Feb 1998 13:45:35 +0100 From: christian hublet we21 7848 Message-Id: <199802111245.NAA08434@btmp80> To: rtio@cisco.com, walter.klausberger@siemens.at Subject: Re: PPP Payload in L2TP Cc: rshea@BayNetworks.com, ietf-ppp@merit.edu Sender: owner-ietf-ppp@merit.edu Hi, I completely agree with Walter. I also see this as an issue and it is related to the framing used for PPP. We are also implementing PPP over AAL5 in combination with L2TP. If we play the role of the LAC, what can we expect from the LNS in the case of outgoing calls ? Will the LNS assume to send PPP in an ISDN or ATM or ... framing ? In short what is the use of the control and address byte in the L2TP packet ? Why not transport the PDU's compliant to RFC 1661 (PPP) over an L2TP tunnel ? Currently it looks like transporting PDU's compliant to RFC 1662 (PPP in HDLC-like framing) over an L2TP tunnel. In other words, why send medium dependent PPP if we can send medium independent PPP. Thanks, Chris ----- Begin Included Message ----- From owner-ietf-ppp@merit.edu Wed Feb 11 09:44:13 1998 From: "Walter Klausberger" To: Cc: , Subject: Re: PPP Payload in L2TP Date: Wed, 11 Feb 1998 09:46:09 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ietf-ppp@merit.edu Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by merit.edu id DAA19172 Content-Length: 2516 Well that is the main problem. How should the LNS know, what header is us= ed for PPP at the LAC? During establishment of the tunnel-session (Incoming-Call-Request) the LN= S is only informed if the PPP is transported over analog or digital channel (Bearer Type). With the message Incoming-Call-Connected the AVP "Framing Type" must be sent. But the LNS is only informed if asynch. or synch. framing is used, not which type of synch. framing (e.g. HDLC, PPP in Fram= e Relay, PPP over AAL5/ATM). I think this is a problem. Thanks, Walter -----Urspr=FCngliche Nachricht----- Von: rtio@cisco.com An: rshea@BayNetworks.COM Cc: walter.klausberger@siemens.at ; ietf-ppp@merit.edu Datum: Dienstag, 10. Februar 1998 20:05 Betreff: Re: PPP Payload in L2TP >Rich, > >Perhaps I am misunderstanding your remark, but PPP in Frame Relay says t= he >frame format is: > > +-+-+-+-+-+-+-+-+ > | Flag (0x7e) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Q.922 Address | Control | NLPID(0xcf) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PPP Protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >If link framing is only the flag sequence, and the LAC only strips this >portion, the LNS would see the Q.922 header in full. Is this the intent= of >the L2TP text? > >Thanks >-- >Rene Tio > > >> From owner-ietf-ppp@merit.edu Tue Feb 10 09:25:40 1998 >> >> Walter Klausberger wrote: >> > >> > Hi >> > I have a question about PPP over L2TP. >> > >> > In L2TP Draft, Page 8 (end of page) is written: >> > Frames from the remote user are received at the POP, stripped of CRC= , >> > link >> > framing, and transparency bytes,... >> > >> > Question: If the PPP connection works over ISDN (synch. HDLC Framing= ) >> > does the address and control field belong to the link framing, or ar= e >> > they >> > also encapsulated into L2TP. >> > >> >> Address and control field are encapsulated into L2TP as necessary (i.e. >> when present). In the case of HDLC I believe "link framing" would >> consist of the "flag sequence" which would of course not be encapsulat= ed >> in L2TP. >> >> Richard. >> >> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >> Richard Shea rshea@BayNetworks.com >> Bay Networks, Extranet Access 978-266-1011 x210 >> > ----- End Included Message ----- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Feb 11 08:41:59 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA21070; Wed, 11 Feb 1998 08:41:57 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 11 Feb 1998 08:36:27 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA20988 for ietf-ppp-outgoing; Wed, 11 Feb 1998 08:36:26 -0500 (EST) Received: from ntserver.newoak.com ([146.115.61.251]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA20983 for ; Wed, 11 Feb 1998 08:36:21 -0500 (EST) Received: from rshea ([10.0.1.243]) by ntserver.newoak.com (Netscape Mail Server v2.02) with ESMTP id AAA215; Wed, 11 Feb 1998 08:36:48 -0500 Message-ID: <34E1A91B.4943AC19@BayNetworks.com> Date: Wed, 11 Feb 1998 08:35:23 -0500 From: Richard Shea Reply-To: rshea@BayNetworks.com Organization: Bay Networks X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: christian hublet we21 7848 CC: rtio@cisco.com, walter.klausberger@siemens.at, ietf-ppp@merit.edu, l2tp@zendo.com Subject: Re: PPP Payload in L2TP X-Priority: 3 (Normal) References: <199802111245.NAA08434@btmp80> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu christian hublet we21 7848 wrote: > > Hi, > > I completely agree with Walter. I also see this as an issue and it is > related to the framing used for PPP. > > We are also implementing PPP over AAL5 in combination with L2TP. If we > play the > role of the LAC, what can we expect from the LNS in the case of > outgoing calls ? > Will the LNS assume to send PPP in an ISDN or ATM or ... framing ? > > In short what is the use of the control and address byte in the L2TP > packet ? > > Why not transport the PDU's compliant to RFC 1661 (PPP) over an L2TP > tunnel ? > Currently it looks like transporting PDU's compliant to RFC 1662 > (PPP in HDLC-like framing) over an L2TP tunnel. In other words, why > send medium > dependent PPP if we can send medium independent PPP. > > Thanks, Chris > I think the two sticky issues with RFC 1662 is that there are LCP options related to the framing (ACFC) and also ACFC can be used on any packet except LCP packets. So, when tunneling HDLC ppp traffic, the LNS could tell the LAC that ACFC was negotiated, but the LAC would have to know if the traffic was LCP or not in order to do the right things with the AC fields. So there are three ways I can think of for dealing with this: (1) The way it is today. (2) Have the LACs "snoop" to recognize LCP traffic. (3) Having a bit in the L2TP encapsulation payload indicating to the LAC when the encapsulated payload is LCP. Of these, I think (3) might be the best option. I'm not confident that I understand the architecture of all of the LACs out there enough to know if this is really viable. It is a question which should definitely be taken-up on the L2TP mailing list (l2tp@zendo.com, l2tp-request@zendo.com). The problem with (1) is that it sets a precedent for the LNS to have to know the framing information (and incur the byte overhead of having to send the framing information between the LNS and LAC). The problems with (2) are actually being discussed right now on the L2TP mailing list, and I don't think it sounds like a viable option. Richard. > ----- Begin Included Message ----- > > >From owner-ietf-ppp@merit.edu Wed Feb 11 09:44:13 1998 > From: "Walter Klausberger" > To: > Cc: , > Subject: Re: PPP Payload in L2TP > Date: Wed, 11 Feb 1998 09:46:09 +0100 > Mime-Version: 1.0 > Content-Type: text/plain; charset="iso-8859-1" > X-Priority: 3 > X-Msmail-Priority: Normal > X-Mailer: Microsoft Outlook Express 4.71.1712.3 > X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 > Sender: owner-ietf-ppp@merit.edu > Content-Transfer-Encoding: quoted-printable > X-MIME-Autoconverted: from 8bit to quoted-printable by merit.edu id > DAA19172 > Content-Length: 2516 > > Well that is the main problem. How should the LNS know, what header is > us= > ed > for PPP at the LAC? > > During establishment of the tunnel-session (Incoming-Call-Request) the > LN= > S > is only informed if the PPP is transported over analog or digital > channel > (Bearer Type). With the message Incoming-Call-Connected the AVP > "Framing > Type" must be sent. But the LNS is only informed if asynch. or synch. > framing is used, not which type of synch. framing (e.g. HDLC, PPP in > Fram= > e > Relay, PPP over AAL5/ATM). > > I think this is a problem. > > Thanks, Walter > -----Urspr=FCngliche Nachricht----- > Von: rtio@cisco.com > An: rshea@BayNetworks.COM > Cc: walter.klausberger@siemens.at ; > ietf-ppp@merit.edu > Datum: Dienstag, 10. Februar 1998 20:05 > Betreff: Re: PPP Payload in L2TP > > >Rich, > > > >Perhaps I am misunderstanding your remark, but PPP in Frame Relay > says t= > he > >frame format is: > > > > +-+-+-+-+-+-+-+-+ > > | Flag (0x7e) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Q.922 Address | Control | NLPID(0xcf) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | PPP Protocol | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >If link framing is only the flag sequence, and the LAC only strips > this > >portion, the LNS would see the Q.922 header in full. Is this the > intent= > of > >the L2TP text? > > > >Thanks > >-- > >Rene Tio > > > > > >> From owner-ietf-ppp@merit.edu Tue Feb 10 09:25:40 1998 > >> > >> Walter Klausberger wrote: > >> > > >> > Hi > >> > I have a question about PPP over L2TP. > >> > > >> > In L2TP Draft, Page 8 (end of page) is written: > >> > Frames from the remote user are received at the POP, stripped of > CRC= > , > >> > link > >> > framing, and transparency bytes,... > >> > > >> > Question: If the PPP connection works over ISDN (synch. HDLC > Framing= > ) > >> > does the address and control field belong to the link framing, or > ar= > e > >> > they > >> > also encapsulated into L2TP. > >> > > >> > >> Address and control field are encapsulated into L2TP as necessary > (i.e. > >> when present). In the case of HDLC I believe "link framing" would > >> consist of the "flag sequence" which would of course not be > encapsulat= > ed > >> in L2TP. > >> > >> Richard. > >> > >> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > -- > >> Richard Shea rshea@BayNetworks.com > >> Bay Networks, Extranet Access 978-266-1011 x210 > >> > > > > ----- End Included Message ----- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Richard Shea rshea@BayNetworks.com Bay Networks, Extranet Access 978-266-1011 x210 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Feb 11 09:16:12 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA21586; Wed, 11 Feb 1998 09:15:48 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 11 Feb 1998 09:12:27 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA21521 for ietf-ppp-outgoing; Wed, 11 Feb 1998 09:12:26 -0500 (EST) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA21514 for ; Wed, 11 Feb 1998 09:12:15 -0500 (EST) Received: from scesie03.sie.siemens.at (root@firix [10.1.143.100]) by zwei.siemens.at with ESMTP id PAA27649; Wed, 11 Feb 1998 15:09:57 +0100 (MET) Received: from pc7990 (pc7990.hai.siemens.co.at) by scesie03.sie.siemens.at with SMTP (1.40.112.8/16.2) id AA270996198; Wed, 11 Feb 1998 15:09:58 +0100 From: "Walter Klausberger" To: Cc: , , Subject: Re: PPP Payload in L2TP Date: Wed, 11 Feb 1998 15:13:45 +0100 Message-Id: <01bd36f7$43d69400$bb4802c3@pc7990.ERD01> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ietf-ppp@merit.edu Hi, Why send PPP in HDLC-like framing? That's what I was asking myself the first time when I read the L2TP Draft. I think that most PPP implementations have an synch. HDLC or asynch. Interface (eg. V.24). So you have to provide an HDLC (or serial) compatible interface for these implementations. The existing hardware drivers normally strip the flags and the CRC from the framed PPP packet. So the inventors of L2TP proposed this remaining PDU as "payload" for L2TP. This explains the sentence "The virtual interface behaves very much like a hardware interface with the exception that the hardware in this case is physically located at the ISP POP" (L2TP Draft Page 9, beginning of page). If this was intended then there should have been more variations for the AVP Framing Type (like AAL5 or PPP over Frame Relay) or otherwise the ISP will always assume HDLC framing in case of digital framing type. We plan to build a LAC based on a 2-part embedded platform. The Interface part provides several interfaces (ISDN, ATM, High Speed Bitrate Line Cards,...) towards the users. On the other hand there is an ATM connection to the second part (LAC functionality). So PPP connections over ISDN will be forwarded by the first part over an ATM VCI/VPI connection (framed with AAL5) to the second part. So you see there is a need for other interfaces than PPP/HDLC to be handled in conjunction with L2TP. Any comments are appriciated! with best regards Walter -----Ursprüngliche Nachricht----- Von: chub@sebb.bel.alcatel.be An: rtio@cisco.com ; walter.klausberger@siemens.at Cc: rshea@BayNetworks.com ; ietf-ppp@merit.edu Datum: Mittwoch, 11. Februar 1998 13:45 Betreff: Re: PPP Payload in L2TP > Hi, > >I completely agree with Walter. I also see this as an issue and it is related to the framing used for PPP. > >We are also implementing PPP over AAL5 in combination with L2TP. If we play the >role of the LAC, what can we expect from the LNS in the case of outgoing calls ? >Will the LNS assume to send PPP in an ISDN or ATM or ... framing ? > >In short what is the use of the control and address byte in the L2TP packet ? > >Why not transport the PDU's compliant to RFC 1661 (PPP) over an L2TP tunnel ? >Currently it looks like transporting PDU's compliant to RFC 1662 >(PPP in HDLC-like framing) over an L2TP tunnel. In other words, why send medium >dependent PPP if we can send medium independent PPP. > >Thanks, Chris > > >----- Begin Included Message ----- > >From owner-ietf-ppp@merit.edu Wed Feb 11 09:44:13 1998 >From: "Walter Klausberger" >To: >Cc: , >Subject: Re: PPP Payload in L2TP >Date: Wed, 11 Feb 1998 09:46:09 +0100 >Mime-Version: 1.0 >Content-Type: text/plain; charset="iso-8859-1" >X-Priority: 3 >X-Msmail-Priority: Normal >X-Mailer: Microsoft Outlook Express 4.71.1712.3 >X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 >Sender: owner-ietf-ppp@merit.edu >Content-Transfer-Encoding: quoted-printable >X-MIME-Autoconverted: from 8bit to quoted-printable by merit.edu id DAA19172 >Content-Length: 2516 > >Well that is the main problem. How should the LNS know, what header is us= >ed >for PPP at the LAC? > >During establishment of the tunnel-session (Incoming-Call-Request) the LN= >S >is only informed if the PPP is transported over analog or digital channel >(Bearer Type). With the message Incoming-Call-Connected the AVP "Framing >Type" must be sent. But the LNS is only informed if asynch. or synch. >framing is used, not which type of synch. framing (e.g. HDLC, PPP in Fram= >e >Relay, PPP over AAL5/ATM). > >I think this is a problem. > >Thanks, Walter >-----Urspr=FCngliche Nachricht----- >Von: rtio@cisco.com >An: rshea@BayNetworks.COM >Cc: walter.klausberger@siemens.at ; >ietf-ppp@merit.edu >Datum: Dienstag, 10. Februar 1998 20:05 >Betreff: Re: PPP Payload in L2TP > > >>Rich, >> >>Perhaps I am misunderstanding your remark, but PPP in Frame Relay says t= >he >>frame format is: >> >> +-+-+-+-+-+-+-+-+ >> | Flag (0x7e) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Q.922 Address | Control | NLPID(0xcf) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | PPP Protocol | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>If link framing is only the flag sequence, and the LAC only strips this >>portion, the LNS would see the Q.922 header in full. Is this the intent= > of >>the L2TP text? >> >>Thanks >>-- >>Rene Tio >> >> >>> From owner-ietf-ppp@merit.edu Tue Feb 10 09:25:40 1998 >>> >>> Walter Klausberger wrote: >>> > >>> > Hi >>> > I have a question about PPP over L2TP. >>> > >>> > In L2TP Draft, Page 8 (end of page) is written: >>> > Frames from the remote user are received at the POP, stripped of CRC= >, >>> > link >>> > framing, and transparency bytes,... >>> > >>> > Question: If the PPP connection works over ISDN (synch. HDLC Framing= >) >>> > does the address and control field belong to the link framing, or ar= >e >>> > they >>> > also encapsulated into L2TP. >>> > >>> >>> Address and control field are encapsulated into L2TP as necessary (i.e. >>> when present). In the case of HDLC I believe "link framing" would >>> consist of the "flag sequence" which would of course not be encapsulat= >ed >>> in L2TP. >>> >>> Richard. >>> >>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >>> Richard Shea rshea@BayNetworks.com >>> Bay Networks, Extranet Access 978-266-1011 x210 >>> >> > > > >----- End Included Message ----- > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Feb 11 09:36:16 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA22466; Wed, 11 Feb 1998 09:36:15 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 11 Feb 1998 09:33:16 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA22314 for ietf-ppp-outgoing; Wed, 11 Feb 1998 09:33:15 -0500 (EST) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA22277 for ; Wed, 11 Feb 1998 09:32:46 -0500 (EST) Received: from scesie03.sie.siemens.at (root@firix [10.1.143.100]) by zwei.siemens.at with ESMTP id PAA29178; Wed, 11 Feb 1998 15:31:07 +0100 (MET) Received: from pc7990 (pc7990.hai.siemens.co.at) by scesie03.sie.siemens.at with SMTP (1.40.112.8/16.2) id AA149947468; Wed, 11 Feb 1998 15:31:08 +0100 From: "Walter Klausberger" To: , Cc: , , Subject: Re: PPP Payload in L2TP Date: Wed, 11 Feb 1998 15:34:56 +0100 Message-Id: <01bd36fa$393a2e00$bb4802c3@pc7990.ERD01> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ietf-ppp@merit.edu Hi, Well, I think the only secure way to handle this is, to say that interface specific options (like ACFC) are forbidden to be negotiated by a LAC or LNS. If the LAC strips the AAL5 framing and puts 0xff 0x03 in front, the LNS could try to negotiate ACFC with the client, which will work in our case. We plan to build a LAC based on a 2-part embedded platform. The Interface part provides several interfaces (ISDN, ATM, High Speed Bitrate Line Cards,...) towards the users. On the other hand there is an ATM connection to the second part (LAC functionality). So PPP connections over ISDN will be forwarded by the first part over an ATM VCI/VPI connection (framed with AAL5) to the second part. The LAC can not listen to options that are re-negotiated between LNS and client. The LAC will only change headers based on his connection table. So how will this work? Another question: How can I take part in the discussions of this mailing list? with best regards Walter Klausberger Siemens AG Austria -----Ursprüngliche Nachricht----- Von: rshea@BayNetworks.com An: chub@sebb.bel.alcatel.be Cc: rtio@cisco.com ; walter.klausberger@siemens.at ; ietf-ppp@merit.edu ; l2tp@zendo.com Datum: Mittwoch, 11. Februar 1998 14:35 Betreff: Re: PPP Payload in L2TP >christian hublet we21 7848 wrote: >> >> Hi, >> >> I completely agree with Walter. I also see this as an issue and it is >> related to the framing used for PPP. >> >> We are also implementing PPP over AAL5 in combination with L2TP. If we >> play the >> role of the LAC, what can we expect from the LNS in the case of >> outgoing calls ? >> Will the LNS assume to send PPP in an ISDN or ATM or ... framing ? >> >> In short what is the use of the control and address byte in the L2TP >> packet ? >> >> Why not transport the PDU's compliant to RFC 1661 (PPP) over an L2TP >> tunnel ? >> Currently it looks like transporting PDU's compliant to RFC 1662 >> (PPP in HDLC-like framing) over an L2TP tunnel. In other words, why >> send medium >> dependent PPP if we can send medium independent PPP. >> >> Thanks, Chris >> > >I think the two sticky issues with RFC 1662 is that there are LCP >options related to the framing (ACFC) and also ACFC can be used on any >packet except LCP packets. > >So, when tunneling HDLC ppp traffic, the LNS could tell the LAC that >ACFC was negotiated, but the LAC would have to know if the traffic was >LCP or not in order to do the right things with the AC fields. > >So there are three ways I can think of for dealing with this: > >(1) The way it is today. >(2) Have the LACs "snoop" to recognize LCP traffic. >(3) Having a bit in the L2TP encapsulation payload indicating to the LAC >when the encapsulated payload is LCP. > >Of these, I think (3) might be the best option. I'm not confident that >I understand the architecture of all of the LACs out there enough to >know if this is really viable. It is a question which should definitely >be taken-up on the L2TP mailing list (l2tp@zendo.com, >l2tp-request@zendo.com). > >The problem with (1) is that it sets a precedent for the LNS to have to >know the framing information (and incur the byte overhead of having to >send the framing information between the LNS and LAC). > >The problems with (2) are actually being discussed right now on the L2TP >mailing list, and I don't think it sounds like a viable option. > >Richard. > >> ----- Begin Included Message ----- >> >> >From owner-ietf-ppp@merit.edu Wed Feb 11 09:44:13 1998 >> From: "Walter Klausberger" >> To: >> Cc: , >> Subject: Re: PPP Payload in L2TP >> Date: Wed, 11 Feb 1998 09:46:09 +0100 >> Mime-Version: 1.0 >> Content-Type: text/plain; charset="iso-8859-1" >> X-Priority: 3 >> X-Msmail-Priority: Normal >> X-Mailer: Microsoft Outlook Express 4.71.1712.3 >> X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 >> Sender: owner-ietf-ppp@merit.edu >> Content-Transfer-Encoding: quoted-printable >> X-MIME-Autoconverted: from 8bit to quoted-printable by merit.edu id >> DAA19172 >> Content-Length: 2516 >> >> Well that is the main problem. How should the LNS know, what header is >> us= >> ed >> for PPP at the LAC? >> >> During establishment of the tunnel-session (Incoming-Call-Request) the >> LN= >> S >> is only informed if the PPP is transported over analog or digital >> channel >> (Bearer Type). With the message Incoming-Call-Connected the AVP >> "Framing >> Type" must be sent. But the LNS is only informed if asynch. or synch. >> framing is used, not which type of synch. framing (e.g. HDLC, PPP in >> Fram= >> e >> Relay, PPP over AAL5/ATM). >> >> I think this is a problem. >> >> Thanks, Walter >> -----Urspr=FCngliche Nachricht----- >> Von: rtio@cisco.com >> An: rshea@BayNetworks.COM >> Cc: walter.klausberger@siemens.at ; >> ietf-ppp@merit.edu >> Datum: Dienstag, 10. Februar 1998 20:05 >> Betreff: Re: PPP Payload in L2TP >> >> >Rich, >> > >> >Perhaps I am misunderstanding your remark, but PPP in Frame Relay >> says t= >> he >> >frame format is: >> > >> > +-+-+-+-+-+-+-+-+ >> > | Flag (0x7e) | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | Q.922 Address | Control | NLPID(0xcf) | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | PPP Protocol | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > >> >If link framing is only the flag sequence, and the LAC only strips >> this >> >portion, the LNS would see the Q.922 header in full. Is this the >> intent= >> of >> >the L2TP text? >> > >> >Thanks >> >-- >> >Rene Tio >> > >> > >> >> From owner-ietf-ppp@merit.edu Tue Feb 10 09:25:40 1998 >> >> >> >> Walter Klausberger wrote: >> >> > >> >> > Hi >> >> > I have a question about PPP over L2TP. >> >> > >> >> > In L2TP Draft, Page 8 (end of page) is written: >> >> > Frames from the remote user are received at the POP, stripped of >> CRC= >> , >> >> > link >> >> > framing, and transparency bytes,... >> >> > >> >> > Question: If the PPP connection works over ISDN (synch. HDLC >> Framing= >> ) >> >> > does the address and control field belong to the link framing, or >> ar= >> e >> >> > they >> >> > also encapsulated into L2TP. >> >> > >> >> >> >> Address and control field are encapsulated into L2TP as necessary >> (i.e. >> >> when present). In the case of HDLC I believe "link framing" would >> >> consist of the "flag sequence" which would of course not be >> encapsulat= >> ed >> >> in L2TP. >> >> >> >> Richard. >> >> >> >> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >> -- >> >> Richard Shea rshea@BayNetworks.com >> >> Bay Networks, Extranet Access 978-266-1011 x210 >> >> >> > >> >> ----- End Included Message ----- > > >-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >Richard Shea rshea@BayNetworks.com >Bay Networks, Extranet Access 978-266-1011 x210 > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Feb 11 10:03:38 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA23872; Wed, 11 Feb 1998 10:03:37 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 11 Feb 1998 10:00:20 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA23707 for ietf-ppp-outgoing; Wed, 11 Feb 1998 10:00:19 -0500 (EST) Received: from algw1.lucent.com (algw1.lucent.com [205.147.213.1]) by merit.edu (8.8.7/8.8.5) with SMTP id KAA23696 for ; Wed, 11 Feb 1998 10:00:13 -0500 (EST) To: "Walter Klausberger" , , Cc: , , , gmgross@lucent.com Received: from luna3.lc.lucent.com by alig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id KAA28125; Wed, 11 Feb 1998 10:11:28 -0500 Received: by luna3.lc.lucent.com (SMI-8.6/EMS-1.3.1 sol2) id JAA09884; Wed, 11 Feb 1998 09:57:19 -0500 Date: Wed, 11 Feb 1998 09:57:19 -0500 Message-Id: <199802111457.JAA09884@luna3.lc.lucent.com> From: gmg@luna3.lc.lucent.com (luna3!gmg) Original-To: "Walter Klausberger" , , Original-Cc: , , , gmgross@lucent.com Subject: Re: PPP Payload in L2TP Content-Type: text Sender: owner-ietf-ppp@merit.edu Hi, This mail thread on PPP over L2TP has a striking resemblance to the thread on bridging convertors that occurred back in October/September on the PPP list. This new thread simply is talking about an L2TP/IP/UDP tunnel media instead of "foo". The upshot of those bridging convertor discussions was a BCP produced by Bill Simpson. In it, "passive" bridging conversion like is being done by L2TP is deprecated in favor of "active" bridging. In active bridging, the PPP framing is negotiated pair-wise between adjacent bridging convertor boxs using LCP. If you apply the BCP's philosophy to L2TP tunnels, it suggests to me that the LCP framing options should be negotiated between the LAC and LNS independent of the LAC's access link. In that case, you would not have any framing overhead on the tunnel, just the PPP payload. The LAC's access link could be async, ISDN, AAL5, Frame Relay, or "foo" and the LNS should not care... George - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Feb 11 12:06:23 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA00316; Wed, 11 Feb 1998 12:06:17 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 11 Feb 1998 12:05:31 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA00272 for ietf-ppp-outgoing; Wed, 11 Feb 1998 12:05:31 -0500 (EST) Received: from btmplq.god.bel.alcatel.be (gatekeeper.alcatel.be [138.203.244.2]) by merit.edu (8.8.7/8.8.5) with SMTP id MAA00266 for ; Wed, 11 Feb 1998 12:05:25 -0500 (EST) Received: from localhost (uucp@localhost) by btmplq.god.bel.alcatel.be (8.6.5/8.6.5) id SAA00424 for ; Wed, 11 Feb 1998 18:04:10 +0100 Received: from btmp80.sebb.bel.alcatel.be(138.203.168.88) by btmplq via smap (V1.3) id smac00389; Wed Feb 11 18:03:59 1998 Received: from btk0dy.Broadband (btk0dy [138.203.224.11]) by btmp80 (8.6.5/8.6.5) with SMTP id SAA12401; Wed, 11 Feb 1998 18:05:04 +0100 Date: Wed, 11 Feb 1998 18:05:04 +0100 From: christian hublet we21 7848 Message-Id: <199802111705.SAA12401@btmp80> To: rshea@BayNetworks.com, chub@sebb.bel.alcatel.be, walter.klausberger@siemens.at Subject: Re: PPP Payload in L2TP Cc: rtio@cisco.com, ietf-ppp@merit.edu, l2tp@zendo.com Sender: owner-ietf-ppp@merit.edu Thanks for the feedback on my question. Taken into account the reactions on this question, and assuming that the ACFC option is the only reason to include the address and the control field, I believe the discussion can be combined with the discussion called "MRU and Set_Link_Info". Here are discussed the fact that due to end to end negotiations (LNS/user), a MRU can be negotiated which the LAc is not able to handle. My impression is that the only thing we have to know are the capabilities of the LAC related to handling ACFC, MRU, Protocol field compression in other words LCP configuration options. Reading the Draft 4 on PPP over ATM it is clearly indicated that some options must not be requested and must be rejected e.g. ACFC, FCS, ACCM... So it seems to me that capabilities should be reported on call level and not on tunnel level (e.g. mixed ATM/ ISDN LAC). So in short, I believe the capabilities of the LAC should be negotiated on tunnel level and on call level between LAC and LNS another strategy could be to forbid some options on LCP level if tunnels are involved. For MRU, an AVP solution is desirable. Regards and thanks, Chris Hublet ----- Begin Included Message ----- From owner-ietf-ppp@merit.edu Wed Feb 11 15:41:07 1998 From: "Walter Klausberger" To: , Cc: , , Subject: Re: PPP Payload in L2TP Date: Wed, 11 Feb 1998 15:34:56 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ietf-ppp@merit.edu Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by merit.edu id JAA22320 Content-Length: 7326 Hi, Well, I think the only secure way to handle this is, to say that interfac= e specific options (like ACFC) are forbidden to be negotiated by a LAC or L= NS. If the LAC strips the AAL5 framing and puts 0xff 0x03 in front, the LNS could try to negotiate ACFC with the client, which will work in our case. We plan to build a LAC based on a 2-part embedded platform. The Interface part provides several interfaces (ISDN, ATM, High Speed Bitrate Line Cards,...) towards the users. On the other hand there is an ATM connectio= n to the second part (LAC functionality). So PPP connections over ISDN will= be forwarded by the first part over an ATM VCI/VPI connection (framed with AAL5) to the second part. The LAC can not listen to options that are re-negotiated between LNS and client. The LAC will only change headers based on his connection table. S= o how will this work? Another question: How can I take part in the discussions of this mailing list? with best regards Walter Klausberger Siemens AG Austria -----Urspr=FCngliche Nachricht----- Von: rshea@BayNetworks.com An: chub@sebb.bel.alcatel.be Cc: rtio@cisco.com ; walter.klausberger@siemens.at ; ietf-ppp@merit.edu ; l2tp@zendo.com Datum: Mittwoch, 11. Februar 1998 14:35 Betreff: Re: PPP Payload in L2TP >christian hublet we21 7848 wrote: >> >> Hi, >> >> I completely agree with Walter. I also see this as an issue and it is >> related to the framing used for PPP. >> >> We are also implementing PPP over AAL5 in combination with L2TP. If we >> play the >> role of the LAC, what can we expect from the LNS in the case of >> outgoing calls ? >> Will the LNS assume to send PPP in an ISDN or ATM or ... framing ? >> >> In short what is the use of the control and address byte in the L2TP >> packet ? >> >> Why not transport the PDU's compliant to RFC 1661 (PPP) over an L2TP >> tunnel ? >> Currently it looks like transporting PDU's compliant to RFC 1662 >> (PPP in HDLC-like framing) over an L2TP tunnel. In other words, why >> send medium >> dependent PPP if we can send medium independent PPP. >> >> Thanks, Chris >> > >I think the two sticky issues with RFC 1662 is that there are LCP >options related to the framing (ACFC) and also ACFC can be used on any >packet except LCP packets. > >So, when tunneling HDLC ppp traffic, the LNS could tell the LAC that >ACFC was negotiated, but the LAC would have to know if the traffic was >LCP or not in order to do the right things with the AC fields. > >So there are three ways I can think of for dealing with this: > >(1) The way it is today. >(2) Have the LACs "snoop" to recognize LCP traffic. >(3) Having a bit in the L2TP encapsulation payload indicating to the LAC >when the encapsulated payload is LCP. > >Of these, I think (3) might be the best option. I'm not confident that >I understand the architecture of all of the LACs out there enough to >know if this is really viable. It is a question which should definitely >be taken-up on the L2TP mailing list (l2tp@zendo.com, >l2tp-request@zendo.com). > >The problem with (1) is that it sets a precedent for the LNS to have to >know the framing information (and incur the byte overhead of having to >send the framing information between the LNS and LAC). > >The problems with (2) are actually being discussed right now on the L2TP >mailing list, and I don't think it sounds like a viable option. > >Richard. > >> ----- Begin Included Message ----- >> >> >From owner-ietf-ppp@merit.edu Wed Feb 11 09:44:13 1998 >> From: "Walter Klausberger" >> To: >> Cc: , >> Subject: Re: PPP Payload in L2TP >> Date: Wed, 11 Feb 1998 09:46:09 +0100 >> Mime-Version: 1.0 >> Content-Type: text/plain; charset=3D"iso-8859-1" >> X-Priority: 3 >> X-Msmail-Priority: Normal >> X-Mailer: Microsoft Outlook Express 4.71.1712.3 >> X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 >> Sender: owner-ietf-ppp@merit.edu >> Content-Transfer-Encoding: quoted-printable >> X-MIME-Autoconverted: from 8bit to quoted-printable by merit.edu id >> DAA19172 >> Content-Length: 2516 >> >> Well that is the main problem. How should the LNS know, what header is >> us=3D >> ed >> for PPP at the LAC? >> >> During establishment of the tunnel-session (Incoming-Call-Request) the >> LN=3D >> S >> is only informed if the PPP is transported over analog or digital >> channel >> (Bearer Type). With the message Incoming-Call-Connected the AVP >> "Framing >> Type" must be sent. But the LNS is only informed if asynch. or synch. >> framing is used, not which type of synch. framing (e.g. HDLC, PPP in >> Fram=3D >> e >> Relay, PPP over AAL5/ATM). >> >> I think this is a problem. >> >> Thanks, Walter >> -----Urspr=3DFCngliche Nachricht----- >> Von: rtio@cisco.com >> An: rshea@BayNetworks.COM >> Cc: walter.klausberger@siemens.at ; >> ietf-ppp@merit.edu >> Datum: Dienstag, 10. Februar 1998 20:05 >> Betreff: Re: PPP Payload in L2TP >> >> >Rich, >> > >> >Perhaps I am misunderstanding your remark, but PPP in Frame Relay >> says t=3D >> he >> >frame format is: >> > >> > +-+-+-+-+-+-+-+-+ >> > | Flag (0x7e) | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | Q.922 Address | Control | NLPID(0xcf) | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | PPP Protocol | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > >> >If link framing is only the flag sequence, and the LAC only strips >> this >> >portion, the LNS would see the Q.922 header in full. Is this the >> intent=3D >> of >> >the L2TP text? >> > >> >Thanks >> >-- >> >Rene Tio >> > >> > >> >> From owner-ietf-ppp@merit.edu Tue Feb 10 09:25:40 1998 >> >> >> >> Walter Klausberger wrote: >> >> > >> >> > Hi >> >> > I have a question about PPP over L2TP. >> >> > >> >> > In L2TP Draft, Page 8 (end of page) is written: >> >> > Frames from the remote user are received at the POP, stripped of >> CRC=3D >> , >> >> > link >> >> > framing, and transparency bytes,... >> >> > >> >> > Question: If the PPP connection works over ISDN (synch. HDLC >> Framing=3D >> ) >> >> > does the address and control field belong to the link framing, or >> ar=3D >> e >> >> > they >> >> > also encapsulated into L2TP. >> >> > >> >> >> >> Address and control field are encapsulated into L2TP as necessary >> (i.e. >> >> when present). In the case of HDLC I believe "link framing" would >> >> consist of the "flag sequence" which would of course not be >> encapsulat=3D >> ed >> >> in L2TP. >> >> >> >> Richard. >> >> >> >> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >> -- >> >> Richard Shea rshea@BayNetworks.com >> >> Bay Networks, Extranet Access 978-266-1011 x210 >> >> >> > >> >> ----- End Included Message ----- > > >-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >Richard Shea rshea@BayNetworks.com >Bay Networks, Extranet Access 978-266-1011 x210 > > ----- End Included Message ----- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 12 15:52:50 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA00984; Thu, 12 Feb 1998 15:52:36 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 15:41:16 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA00658 for ietf-ppp-outgoing; Thu, 12 Feb 1998 15:41:15 -0500 (EST) Received: from santaclara01.pop.internex.net (santaclara01.pop.internex.net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA00654 for ; Thu, 12 Feb 1998 15:41:10 -0500 (EST) Received: from flowpoint.com ([192.84.210.69]) by santaclara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA13022; Thu, 12 Feb 1998 12:41:06 -0800 Received: from localhost (pmr@localhost) by flowpoint.com (8.8.7/8.8.4) with SMTP id MAA23102; Thu, 12 Feb 1998 12:41:29 -0800 Date: Thu, 12 Feb 1998 12:41:29 -0800 (PST) From: Philip Rakity X-Sender: pmr@flowpnt Reply-To: Philip Rakity To: Andy Valencia cc: l2tp@zendo.com, ietf working group Subject: Re: LCP renegotiation In-Reply-To: <199802121817.KAA16252@vandys-pc.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Andy, If ADSL technology takes off, there will be many millions of lines running AAL5/PPP. The problem should be fixed. Concerning MRU size, The 1500 byte default MRU fails when bridging is negotiated, since the bridge frame is larger than 1500 bytes. It is true that IP works, but that is only true if other Pseudo NCPs such as compression and encryption are not negotiated. A value of 1600 bytes (if not negotiated) solves this problem and will work since there are no L2TP systems in the field today. My collegues would prefer 2000 bytes !! Philip Rakity FlowPoint On Thu, 12 Feb 1998, Andy Valencia wrote: > There appear to be three issues which are most immediately in front of the > WG. > > 1. non-HDLC PPP and L2TP > > I strongly recommend that non-HDCL-like media approach the question of > operating within L2TP by considering L2TP as it stands today, and adapting. > I believe this will require aping some HDLC characteristics as the PPP frame > enters the tunnel. This will at a minimum include address/control/proto, > and probably blithely ignoring any place ACCM rears its head. > > The question must not be whether L2TP could be better adapted to accomodate > AAL5, but whether devices doing PPP over AAL5 can be made to fit into L2TP as > described. Otherwise we will stop L2TP, laboriously construct more > protocol, stop L2TP until an interoperability workshop, refine the > description, create more protocol, and finally interoperate. We'll be back > to request advancement in, say, another year. > > Of course, by this time, PPP-over-FOO will have appeared, and off we go > again. > > 2. Outbound dial > > I was remiss in omitting outbound dial as a special case of LCP treatment. > In many ways it resembles the "PPTP scenario", as the LNS takes primary > responsibility for LCP, but it has the additional wrinkle that the LAC did > not initiate the action. > > If I were to solve this with an operational note, I would recommend that the > default ACCM quotes ^S and ^Q, and that the LNS will always negotiate > towards this mask unless a different one has been administratively set. I > know that you could shoot for all-0's and work with 99%+ of all modern > LAC's, but masking ^S/^Q also covers 99% of the legacy equipment which > exists, too. > > For MRU, I would recommend sticking to the PPP mandated value unless > otherwise set by administrative control. Again, this covers the 99% case, > and even in cases where some other value was desired, it is usually possible > for the special case to jump through a known hoop, rather than operate > against a vague haze of generality. This was our experience interoperating > with Shiva in this area. > > 3. Snooping LCP > > You do NOT want to create a protocol which has the LAC snooping LCP. In my > opinion, it's the wrong place to solve the wrong problem. If the LNS owns > LCP negotiation, the immediate goal of the WG is "simply" to document the > parameters which should be coordinated to guarantee operation. If the > incremental benefit of automation of this is found compelling, only then > would new AVP's be called for. Whoever's doing LCP negotiation has a set of > information which guides their actions. Some of this information may be > determined dynamically (to wit, renegotiation on an LNS after the LAC has > already done it and then forwarded--he can look at the previous negotiation > parameters), others known a priori (operational notes). Over time we may > add mechanism whch moves items from the latter set to the former. Again, I > do not think it prudent to hold any L2TP advancement until the latter set > has become the null set. > > Regards, > Andy Valencia > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 12 16:13:13 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA01638; Thu, 12 Feb 1998 16:13:12 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 16:07:00 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA01403 for ietf-ppp-outgoing; Thu, 12 Feb 1998 16:06:59 -0500 (EST) Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.51.26]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA01397 for ; Thu, 12 Feb 1998 16:06:54 -0500 (EST) Received: from vandys-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by vandys-pc.cisco.com (8.8.5/8.8.5) with ESMTP id NAA16795; Thu, 12 Feb 1998 13:05:18 -0800 (PST) Message-Id: <199802122105.NAA16795@vandys-pc.cisco.com> To: Philip Rakity cc: l2tp@zendo.com, ietf working group Subject: Re: LCP renegotiation In-reply-to: Your message of "Thu, 12 Feb 1998 12:41:29 PST." Date: Thu, 12 Feb 1998 13:05:18 -0800 From: Andy Valencia Sender: owner-ietf-ppp@merit.edu [Philip Rakity writes:] >If ADSL technology takes off, there will be many millions of lines running >AAL5/PPP. The problem should be fixed. That's fine. As a new technology emerges and gains operational experience, we do more protocol work to support it. If our protocols don't advance because we're always defending against each possible future, our protocols don't advance at all. We already DO have millions of lines running HDLC-ish PPP. L2TP tells how to enable a new class of service. There's nothing in any of these discussions which says (1) L2TP can't do what it needs to now (through a mixture of explicit protocol options, plus operational notes), and (2) can't be enhanced within its framework to handle futures. This protocol needs to move forward. It has rough consensus, it has running code, and we have proof by existence in L2F and PPTP that it works in the Real World. Andy Valencia - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 12 17:03:04 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA03001; Thu, 12 Feb 1998 17:03:01 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 16:58:08 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA02893 for ietf-ppp-outgoing; Thu, 12 Feb 1998 16:58:08 -0500 (EST) Received: from ntserver.newoak.com ([146.115.61.251]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA02886 for ; Thu, 12 Feb 1998 16:58:00 -0500 (EST) Received: from rshea ([10.0.1.243]) by ntserver.newoak.com (Netscape Mail Server v2.02) with ESMTP id AAA44; Thu, 12 Feb 1998 16:58:17 -0500 Message-ID: <34E3702D.9FAC4604@BayNetworks.com> Date: Thu, 12 Feb 1998 16:57:01 -0500 From: Richard Shea Reply-To: rshea@BayNetworks.com Organization: Bay Networks X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: Andy Valencia CC: Philip Rakity , l2tp@zendo.com, ietf working group Subject: Re: LCP renegotiation X-Priority: 3 (Normal) References: <199802122105.NAA16795@vandys-pc.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Andy Valencia wrote: > > [Philip Rakity writes:] > > >If ADSL technology takes off, there will be many millions of lines > running > >AAL5/PPP. The problem should be fixed. > > That's fine. As a new technology emerges and gains operational > experience, > we do more protocol work to support it. Ideally, as new access technologies are introduced the L2TP protocol should not have to change at all. L2TP is supposed to tunnel PPP, a datalink protocol. It shouldn't be specific to PPP-over-HDLC, PPP-over-ADSL, PPP-over-whatever. I know that having LCP options present for HDLC framing screws this up. And any future technology which adds physical-layer-dependent options to LCP will cause the same problems. And we can't even foresee that at this point. Why can't we simply have L2TP have the option of tunneling HDLC or not tunneling HDLC? Then any non-HDLC protocol that doesn't add LCP options to the picture can fit into L2TP "today". And we don't have to have the LAC stripping or not stripping the HDLC address and control fields if it doesn't need them? And more importantly, the LNS won't ask for ACFC options when they are not appropriate. Afterall, the ppp client dialing into the LAC isn't even supposed to "know" that its traffic is being tunneled. In the future, if access technologies add LCP options to PPP then we will deal with that when it comes. It seems to me we have a non-negligible problem with a simple solution. Isn't this a change that could be made even to a Proposed Standard? I don't understand the resistance. I also don't want to hold up the spec, but I don't see that this necessarily DOES hold up the spec from advancing. > If our protocols don't advance because we're always defending > against each possible future, our protocols don't advance at all. > I think protocols advance and don't hung up on possible futures when they are defined in such a way that they don't have dependencies on layers below or above them. Why is TCP/IP ubiquitous? In large part probably because all you need is a TCP port number and things start working. TCP doesn't worry about futures of what it will carry because it was defined not to have dependencies on what it carries. I honestly see it as a weakness of the protocol as currently defined (or at least as currently explained!) that we are even having this discussion. > We already DO have millions of lines running HDLC-ish PPP. L2TP tells > how > to enable a new class of service. There's nothing in any of these > discussions which says (1) L2TP can't do what it needs to now (through > a > mixture of explicit protocol options, plus operational notes), and (2) > can't > be enhanced within its framework to handle futures. This protocol > needs to > move forward. It has rough consensus, it has running code, and we > have > proof by existence in L2F and PPTP that it works in the Real World. > Again, I don't think we have to stall the protocol, it shouldn't be a huge change. And may save us countless future changes and amendments down the road. Richard. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Richard Shea rshea@BayNetworks.com Bay Networks, Extranet Access 978-266-1011 x210 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 12 17:44:44 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA04018; Thu, 12 Feb 1998 17:44:37 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 17:42:45 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA03914 for ietf-ppp-outgoing; Thu, 12 Feb 1998 17:42:44 -0500 (EST) Received: from hal.lcp.livingston.com (hal.lcp.livingston.com [158.222.8.12]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA03882 for ; Thu, 12 Feb 1998 17:42:24 -0500 (EST) Received: from [158.222.8.17] (alan.lcp.livingston.com [158.222.8.17]) by hal.lcp.livingston.com (8.8.7/8.8.4) with ESMTP id OAA21701; Thu, 12 Feb 1998 14:41:29 -0800 (PST) X-Sender: brian@hal.lcp.livingston.com Message-Id: In-Reply-To: References: <199802121817.KAA16252@vandys-pc.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Feb 1998 14:11:03 -0800 To: Philip Rakity From: Brian Lloyd Subject: Re: LCP renegotiation Cc: Andy Valencia , l2tp@zendo.com, ietf working group Sender: owner-ietf-ppp@merit.edu First, a disclaimer: I haven't been paying a lot of attention to L2TP so far so please forgive me in advance for saying something obviously wrong and/or stupid about L2TP. But that has never stopped me in the past so ... ;^) At 12:41 -0800 2/12/98, Philip Rakity wrote: >Andy, > >If ADSL technology takes off, there will be many millions of lines running >AAL5/PPP. The problem should be fixed. > >Concerning MRU size, The 1500 byte default MRU fails when bridging is >negotiated, since the bridge frame is larger than 1500 bytes. We thought of that back in the dim, dark, recesses of time long passed. That is why multilink can run over a single line. Go ahead and negotiate any MMRU you want and the MP will do intra-network fragmentation for you. That was the only way to bridge 8K FDDI frames over PPP links that had an MTU of 1500 octets. >It is true >that IP works, but that is only true if other Pseudo NCPs such as >compression and encryption are not negotiated. A value of 1600 bytes (if >not negotiated) solves this problem and will work since there are no L2TP >systems in the field today. My collegues would prefer 2000 bytes !! Several years back the folks trying to create multilink made the presumption that PPP is a link protocol. It wasn't and it isn't. PPP is a datagram-based networking protocol for degenerate networks of two nodes. OK, so it also just happens to have its own link protocol too. In any case, if you view it as both the link *AND* the network layers (no, IP/IPX/whatever is the *internetwork* layer) you will find that it becomes relatively easy to cleanly separate the functionallity. Treat your link differently from your network. Multilink provides a means to "hide" the link-layer related "problems" from the internetwork layer. So, has anyone considered using multilink over a single logical link as a way to hide the problems at the LCP layer for L2TP? Do so and your concern about what is negotiated at the LCP layer becomes moot. Who cares whether the framing is sync or async; who cares what the ACCM map looks like; who cares if you are doing link-layer compression or encryption. That is between the LAC and its client. Let MP serve to manage the L2TP tunnel as it would any other 2-node point-to-point network. OK, I'm sorry. I should have kept my mouth shut. Throw a few rocks at me and I will go (more or less) quietly. Brian Lloyd Lucent Technologies brian@lcp.livingston.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6399 - voice +1.530.676.3442 - fax O- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 12 17:44:39 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA04014; Thu, 12 Feb 1998 17:44:36 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 17:42:40 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA03906 for ietf-ppp-outgoing; Thu, 12 Feb 1998 17:42:40 -0500 (EST) Received: from hal.lcp.livingston.com (hal.lcp.livingston.com [158.222.8.12]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA03891 for ; Thu, 12 Feb 1998 17:42:28 -0500 (EST) Received: from [158.222.8.17] (alan.lcp.livingston.com [158.222.8.17]) by hal.lcp.livingston.com (8.8.7/8.8.4) with ESMTP id OAA21723; Thu, 12 Feb 1998 14:41:32 -0800 (PST) X-Sender: brian@hal.lcp.livingston.com Message-Id: In-Reply-To: <34E3702D.9FAC4604@BayNetworks.com> References: <199802122105.NAA16795@vandys-pc.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Feb 1998 14:37:53 -0800 To: rshea@BayNetworks.com From: Brian Lloyd Subject: Re: LCP renegotiation Cc: Andy Valencia , Philip Rakity , l2tp@zendo.com, ietf working group Sender: owner-ietf-ppp@merit.edu At 13:57 -0800 2/12/98, Richard Shea wrote: >Ideally, as new access technologies are introduced the L2TP protocol >should not have to change at all. L2TP is supposed to tunnel PPP, a >datalink protocol. Network protocol. >It shouldn't be specific to PPP-over-HDLC, >PPP-over-ADSL, PPP-over-whatever. 100% correct. >I know that having LCP options >present for HDLC framing screws this up. It does no such thing. You ack the options then ignore them. For instance, PPP allows one to offer the ACCM option over sync links where they have no meaning. ACK the option then ignore it. >And any future technology >which adds physical-layer-dependent options to LCP will cause the same >problems. And we can't even foresee that at this point. So treat PPP as it really is, i.e. both a link and a network layer protocol. Negotiate LCP locally and don't worry about it beyond that. >Why can't we simply have L2TP have the option of tunneling HDLC or not >tunneling HDLC? Then any non-HDLC protocol that doesn't add LCP options >to the picture can fit into L2TP "today". And we don't have to have the >LAC stripping or not stripping the HDLC address and control fields if it >doesn't need them? And more importantly, the LNS won't ask for ACFC >options when they are not appropriate. Afterall, the ppp client dialing >into the LAC isn't even supposed to "know" that its traffic is being >tunneled. And for that matter, the LNS probably doesn't need to know the details of the link. >In the future, if access technologies add LCP options to PPP then we >will deal with that when it comes. > >It seems to me we have a non-negligible problem with a simple solution. >Isn't this a change that could be made even to a Proposed Standard? I >don't understand the resistance. I also don't want to hold up the spec, >but I don't see that this necessarily DOES hold up the spec from >advancing. >... >I honestly see it as a weakness of the protocol as currently defined (or >at least as currently explained!) that we are even having this >discussion. Aha! You and I seem to be in agreement. Maybe I am not so crazy after all. Brian Lloyd Lucent Technologies brian@lcp.livingston.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6399 - voice +1.530.676.3442 - fax O- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 12 17:58:00 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA04393; Thu, 12 Feb 1998 17:57:59 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 17:56:16 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA04352 for ietf-ppp-outgoing; Thu, 12 Feb 1998 17:56:15 -0500 (EST) Received: from santaclara01.pop.internex.net (santaclara01.pop.internex.net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA04348 for ; Thu, 12 Feb 1998 17:56:09 -0500 (EST) Received: from flowpoint.com ([192.84.210.69]) by santaclara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA19131; Thu, 12 Feb 1998 14:56:08 -0800 Received: from localhost (pmr@localhost) by flowpoint.com (8.8.7/8.8.4) with SMTP id OAA09134; Thu, 12 Feb 1998 14:56:30 -0800 Date: Thu, 12 Feb 1998 14:56:30 -0800 (PST) From: Philip Rakity X-Sender: pmr@flowpnt To: Brian Lloyd cc: Andy Valencia , l2tp@zendo.com, ietf working group Subject: Re: LCP renegotiation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Brian, There is no support for MLP in PPP over AAL5, that is why I suggested making the default MRU large. regards, Philip Rakity FlowPoint On Thu, 12 Feb 1998, Brian Lloyd wrote: > First, a disclaimer: I haven't been paying a lot of attention to L2TP so > far so please forgive me in advance for saying something obviously wrong > and/or stupid about L2TP. But that has never stopped me in the past so ... > ;^) > > At 12:41 -0800 2/12/98, Philip Rakity wrote: > >Andy, > > > >If ADSL technology takes off, there will be many millions of lines running > >AAL5/PPP. The problem should be fixed. > > > >Concerning MRU size, The 1500 byte default MRU fails when bridging is > >negotiated, since the bridge frame is larger than 1500 bytes. > > We thought of that back in the dim, dark, recesses of time long passed. > That is why multilink can run over a single line. Go ahead and negotiate > any MMRU you want and the MP will do intra-network fragmentation for you. > That was the only way to bridge 8K FDDI frames over PPP links that had an > MTU of 1500 octets. > > >It is true > >that IP works, but that is only true if other Pseudo NCPs such as > >compression and encryption are not negotiated. A value of 1600 bytes (if > >not negotiated) solves this problem and will work since there are no L2TP > >systems in the field today. My collegues would prefer 2000 bytes !! > > Several years back the folks trying to create multilink made the > presumption that PPP is a link protocol. It wasn't and it isn't. PPP is a > datagram-based networking protocol for degenerate networks of two nodes. > OK, so it also just happens to have its own link protocol too. In any > case, if you view it as both the link *AND* the network layers (no, > IP/IPX/whatever is the *internetwork* layer) you will find that it becomes > relatively easy to cleanly separate the functionallity. > > Treat your link differently from your network. Multilink provides a means > to "hide" the link-layer related "problems" from the internetwork layer. > So, has anyone considered using multilink over a single logical link as a > way to hide the problems at the LCP layer for L2TP? Do so and your concern > about what is negotiated at the LCP layer becomes moot. Who cares whether > the framing is sync or async; who cares what the ACCM map looks like; who > cares if you are doing link-layer compression or encryption. That is > between the LAC and its client. Let MP serve to manage the L2TP tunnel as > it would any other 2-node point-to-point network. > > OK, I'm sorry. I should have kept my mouth shut. Throw a few rocks at me > and I will go (more or less) quietly. > > > Brian Lloyd Lucent Technologies > brian@lcp.livingston.com 3461 Robin Lane, Suite 1 > http://www.livingston.com Cameron Park, CA 95682 > +1.530.676.6399 - voice +1.530.676.3442 - fax O- > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 12 18:21:39 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA04874; Thu, 12 Feb 1998 18:21:37 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 18:19:37 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA04803 for ietf-ppp-outgoing; Thu, 12 Feb 1998 18:19:36 -0500 (EST) Received: from chaos.enteka.com (chaos.enteka.com [204.179.107.70]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA04791 for ; Thu, 12 Feb 1998 18:19:20 -0500 (EST) Received: (from philipp@localhost) by chaos.enteka.com (8.8.8/8.8.8) id PAA18009; Thu, 12 Feb 1998 15:19:19 -0800 (PST) Date: Thu, 12 Feb 1998 15:19:19 -0800 (PST) From: "Philip A. Prindeville" Message-Id: <199802122319.PAA18009@chaos.enteka.com> To: pmr@flowpoint.com, vandys@cisco.com Cc: ietf-ppp@merit.edu, l2tp@zendo.com Subject: Re: LCP renegotiation Sender: owner-ietf-ppp@merit.edu > Date: Thu, 12 Feb 1998 12:41:29 -0800 (PST) > From: Philip Rakity > To: Andy Valencia > cc: l2tp@zendo.com, ietf working group > Subject: Re: LCP renegotiation > > > Andy, > > If ADSL technology takes off, there will be many millions of lines running > AAL5/PPP. The problem should be fixed. I was just telling myself not to jump back in when this arrived... > Concerning MRU size, The 1500 byte default MRU fails when bridging is > negotiated, since the bridge frame is larger than 1500 bytes. It is true > that IP works, but that is only true if other Pseudo NCPs such as > compression and encryption are not negotiated. A value of 1600 bytes (if > not negotiated) solves this problem and will work since there are no L2TP > systems in the field today. My collegues would prefer 2000 bytes !! I think you are pushing back the problem. We implemented L2F as an exercise here and learned a lot in the process. First, L2F adds its own overhead, so by the time you've added 10 bytes (or more, if you are aligning your L2F header) of L2F overhead and 8 bytes of UDP header, plus 20 bytes of IP header, you've blown the 1500 byte Ethernet MTU (plus 4 bytes of PPP header). And two bytes of L2F trailer if you are generating checksums as well. We didn't want to fragment our L2F packets, so we forced the NAS (or LAC, in L2TP parlance) to negotiate down the MRU (which worked better for us anyway, because our modems actually perform best with an ~1100 byte packet). I *thought* this would solve our problem. Well, it would have, if Microsoft had read RFC 1122 carefully (the Requirements for Internet Hosts). Sections 3.3.3 (on the relationship of the MTU_S and IP fragmentation and the transport-layer MSS) and 4.2.2.6 (same, but from the TCP viewpoint) were completely violated. Winsock/DUN CONFACK the MRU, and then ignore it, sending 1460 byte MSSes even if the LAC (NAS) says don't send me more than 1400 (or 1100) byte packets. I've spent a week on the phone and sending email with Microsoft techies, and had to lead them to this document... If I had a working ThinkPad powersupply, I could tell you if 98 was afflicted by this non-conformance too. I note with some optimism that the NT 4.0 Resource Guide actually references RFC 1122.... I think counting on users' systems to handle MRU correctly is problably naive (as was I). Why not just have the LAC signal to the LNS what MRU it supports when the connection is opened but before any traffic is sent (not unlike the TCP MSS)? -Philip > Philip Rakity > FlowPoint - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 12 18:30:51 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA05084; Thu, 12 Feb 1998 18:30:50 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 18:29:10 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA05029 for ietf-ppp-outgoing; Thu, 12 Feb 1998 18:29:09 -0500 (EST) Received: from chaos.enteka.com (chaos.enteka.com [204.179.107.70]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA05021 for ; Thu, 12 Feb 1998 18:29:04 -0500 (EST) Received: (from philipp@localhost) by chaos.enteka.com (8.8.8/8.8.8) id PAA18080; Thu, 12 Feb 1998 15:29:03 -0800 (PST) Date: Thu, 12 Feb 1998 15:29:03 -0800 (PST) From: "Philip A. Prindeville" Message-Id: <199802122329.PAA18080@chaos.enteka.com> To: rshea@baynetworks.com, vandys@cisco.com Cc: ietf-ppp@merit.edu, l2tp@zendo.com, pmr@flowpoint.com Subject: Re: LCP renegotiation Sender: owner-ietf-ppp@merit.edu > Date: Thu, 12 Feb 1998 16:57:01 -0500 > From: Richard Shea > To: Andy Valencia > CC: Philip Rakity , l2tp@zendo.com, > ietf working group > Subject: Re: LCP renegotiation > I think protocols advance and don't hung up on possible futures when > they are defined in such a way that they don't have dependencies on > layers below or above them. Why is TCP/IP ubiquitous? In large part > probably because all you need is a TCP port number and things start > working. TCP doesn't worry about futures of what it will carry because > it was defined not to have dependencies on what it carries. I think you are being naive. As you go up the ISO reference model it gets easier to abstract things away because the lower layers are designed to deal with such details. The news is: *we* are at the lower layer. These are the issues that we have to concern ourselves with so that no one else will have to. > I honestly see it as a weakness of the protocol as currently defined (or > at least as currently explained!) that we are even having this > discussion. > [ ... ] > Again, I don't think we have to stall the protocol, it shouldn't be a > huge change. And may save us countless future changes and amendments > down the road. And I don't want to leave a possibly broken protocol as a legacy of my hurriedness. -Philip > Richard. > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > Richard Shea rshea@BayNetworks.com > Bay Networks, Extranet Access 978-266-1011 x210 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 12 18:30:32 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA05073; Thu, 12 Feb 1998 18:30:31 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 18:28:49 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA05005 for ietf-ppp-outgoing; Thu, 12 Feb 1998 18:28:49 -0500 (EST) Received: from ntserver.newoak.com ([146.115.61.251]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA05000 for ; Thu, 12 Feb 1998 18:28:44 -0500 (EST) Received: from rshea ([10.0.1.243]) by ntserver.newoak.com (Netscape Mail Server v2.02) with ESMTP id AAA51; Thu, 12 Feb 1998 18:29:02 -0500 Message-ID: <34E38571.171EB68@BayNetworks.com> Date: Thu, 12 Feb 1998 18:27:45 -0500 From: Richard Shea Reply-To: rshea@BayNetworks.com Organization: Bay Networks X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: Brian Lloyd CC: Philip Rakity , Andy Valencia , l2tp@zendo.com, ietf working group Subject: Re: LCP renegotiation X-Priority: 3 (Normal) References: <199802121817.KAA16252@vandys-pc.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Brian Lloyd wrote: > > First, a disclaimer: I haven't been paying a lot of attention to L2TP > so > far so please forgive me in advance for saying something obviously > wrong > and/or stupid about L2TP. But that has never stopped me in the past > so ... > ;^) > You're forgiven... ;) [..] > > Treat your link differently from your network. Multilink provides a > means > to "hide" the link-layer related "problems" from the internetwork > layer. > So, has anyone considered using multilink over a single logical link > as a > way to hide the problems at the LCP layer for L2TP? Do so and your > concern > about what is negotiated at the LCP layer becomes moot. Who cares > whether > the framing is sync or async; who cares what the ACCM map looks like; > who > cares if you are doing link-layer compression or encryption. That is > between the LAC and its client. Let MP serve to manage the L2TP > tunnel as > it would any other 2-node point-to-point network. > Link-layer compression and enryption isn't between the LAC and its client, it's between the LNS and it's client. ACCM escaping happens between the LAC and its client, but the ACCM value is in some cases negotiated between the LNS and the client. Whether the framing is sync or async is really unimportant from the LNS's point of view from a packet handling standpoint anyway. I'll have to think about the MP suggestions for handling MTU some more, but my initial feeling is that it won't be too helpful. I think the MP suggestions (if I understand them correctly) are too divergent from the current state of L2TP for consideration. If what you are saying is that single link would be negotiated between the LAC and client with the bundle terminated at the LNS, this is too far afield from the operational model of L2F/PPTP/L2TP for consideration (IMO). I have a feeling Andy will agree with me on this one... :) Richard. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Richard Shea rshea@BayNetworks.com Bay Networks, Extranet Access 978-266-1011 x210 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 12 18:33:50 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA05179; Thu, 12 Feb 1998 18:33:48 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 18:32:06 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA05107 for ietf-ppp-outgoing; Thu, 12 Feb 1998 18:32:05 -0500 (EST) Received: from hal.lcp.livingston.com (hal.lcp.livingston.com [158.222.8.12]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA05098 for ; Thu, 12 Feb 1998 18:31:58 -0500 (EST) Received: from [158.222.8.17] (alan.lcp.livingston.com [158.222.8.17]) by hal.lcp.livingston.com (8.8.7/8.8.4) with ESMTP id PAA10772; Thu, 12 Feb 1998 15:31:18 -0800 (PST) X-Sender: brian@hal.lcp.livingston.com Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Feb 1998 15:30:58 -0800 To: Philip Rakity From: Brian Lloyd Subject: Re: LCP renegotiation Cc: Andy Valencia , l2tp@zendo.com, ietf working group Sender: owner-ietf-ppp@merit.edu At 14:56 -0800 2/12/98, Philip Rakity wrote: >Brian, > >There is no support for MLP in PPP over AAL5, that is why I suggested >making the default MRU large. "... those who ignore the lessons of history ..." Then negotiate a larger MRU. What's the big deal? Brian Lloyd Lucent Technologies brian@lcp.livingston.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6399 - voice +1.530.676.3442 - fax O- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 12 18:47:41 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA05526; Thu, 12 Feb 1998 18:47:35 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 18:45:49 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA05480 for ietf-ppp-outgoing; Thu, 12 Feb 1998 18:45:49 -0500 (EST) Received: from ntserver.newoak.com ([146.115.61.251]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA05473 for ; Thu, 12 Feb 1998 18:45:44 -0500 (EST) Received: from rshea ([10.0.1.243]) by ntserver.newoak.com (Netscape Mail Server v2.02) with ESMTP id AAA140; Thu, 12 Feb 1998 18:46:03 -0500 Message-ID: <34E3896E.319B8B9F@BayNetworks.com> Date: Thu, 12 Feb 1998 18:44:46 -0500 From: Richard Shea Reply-To: rshea@BayNetworks.com Organization: Bay Networks X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: "Philip A. Prindeville" CC: vandys@cisco.com, ietf-ppp@merit.edu, l2tp@zendo.com, pmr@flowpoint.com Subject: Re: LCP renegotiation X-Priority: 3 (Normal) References: <199802122329.PAA18080@chaos.enteka.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Philip A. Prindeville wrote: > [..] > > I think you are being naive. As you go up the ISO reference > model it gets easier to abstract things away because the lower > layers are designed to deal with such details. > > The news is: *we* are at the lower layer. These are the issues > that we have to concern ourselves with so that no one else will > have to. > Well, the TCP-like abstraction is certainly an ideal which we can't achieve at this level, as you point out. My point was that L2TP could be defined to attempt to contain the more physical-level characteristics of the link to the end with the actual physical connection (i.e. the LAC). If we changed L2TP to differentiate HDLC and non-HDLC sessions at the LNS, then the LNS would be able to satisfy the ACF handling for HDLC links; And for non-HDLC links the LNS would just not include ACCM or ACFC options, and not prepend the ACF on any packets it sent out (nor expect to receive them!). Then, as long as all of the PPP-over-X protocols can take care of framing at the LAC and simply forward rfc1661-style PPP frames between the LAC and LNS we are all set. I don't yet understand (which may be entirely my fault!) why this wouldn't be effective. If in the future some portion of PPP framing has to be known at the LNS then we can add in that functionality to the L2TP protocol at that time (fairly simply). Richard. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Richard Shea rshea@BayNetworks.com Bay Networks, Extranet Access 978-266-1011 x210 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 12 18:49:46 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA05577; Thu, 12 Feb 1998 18:49:45 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 18:48:04 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA05535 for ietf-ppp-outgoing; Thu, 12 Feb 1998 18:48:04 -0500 (EST) Received: from santaclara01.pop.internex.net (santaclara01.pop.internex.net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA05531 for ; Thu, 12 Feb 1998 18:47:52 -0500 (EST) Received: from flowpoint.com ([192.84.210.69]) by santaclara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA21669; Thu, 12 Feb 1998 15:47:29 -0800 Received: from localhost (pmr@localhost) by flowpoint.com (8.8.7/8.8.4) with SMTP id PAA13111; Thu, 12 Feb 1998 15:47:52 -0800 Date: Thu, 12 Feb 1998 15:47:52 -0800 (PST) From: Philip Rakity X-Sender: pmr@flowpnt To: Brian Lloyd cc: Andy Valencia , l2tp@zendo.com, ietf working group Subject: Re: LCP renegotiation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Brian, The forgive me for not fully explaining the context of the 1500 byte MRU discussion. In L2TP, the client computer sends data to a LAC which forwards the data to an LNS. The LAC acts like a bit pump. The LAC needs to allocate space for the PPP frames that it receives/sends to the client computer/LNS. The question is how big must those buffers be for the LAC to work. There are two proposals to solve this problem. a) By definition they must be size X (where X will be defined in L2TP spec) b) Have the LAC tell the LNS its buffer sizes, so that the PPP negotiation preformed by the LNS can be properly done. regards, Philip Rakity FlowPoint On Thu, 12 Feb 1998, Brian Lloyd wrote: > At 14:56 -0800 2/12/98, Philip Rakity wrote: > >Brian, > > > >There is no support for MLP in PPP over AAL5, that is why I suggested > >making the default MRU large. > > "... those who ignore the lessons of history ..." > > Then negotiate a larger MRU. What's the big deal? > > > Brian Lloyd Lucent Technologies > brian@lcp.livingston.com 3461 Robin Lane, Suite 1 > http://www.livingston.com Cameron Park, CA 95682 > +1.530.676.6399 - voice +1.530.676.3442 - fax O- > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 12 19:01:14 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id TAA05796; Thu, 12 Feb 1998 19:01:13 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 18:59:29 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA05739 for ietf-ppp-outgoing; Thu, 12 Feb 1998 18:59:28 -0500 (EST) Received: from chaos.enteka.com (chaos.enteka.com [204.179.107.70]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA05732 for ; Thu, 12 Feb 1998 18:59:23 -0500 (EST) Received: (from philipp@localhost) by chaos.enteka.com (8.8.8/8.8.8) id PAA18285; Thu, 12 Feb 1998 15:59:22 -0800 (PST) Date: Thu, 12 Feb 1998 15:59:22 -0800 (PST) From: "Philip A. Prindeville" Message-Id: <199802122359.PAA18285@chaos.enteka.com> To: rshea@BayNetworks.com Cc: ietf-ppp@merit.edu, l2tp@zendo.com, pmr@flowpoint.com, vandys@cisco.com Subject: Re: LCP renegotiation Sender: owner-ietf-ppp@merit.edu > Date: Thu, 12 Feb 1998 18:44:46 -0500 > From: Richard Shea > To: "Philip A. Prindeville" > CC: vandys@cisco.com, ietf-ppp@merit.edu, l2tp@zendo.com, pmr@flowpoint.com > Subject: Re: LCP renegotiation > Philip A. Prindeville wrote: > > > [..] > > > > I think you are being naive. As you go up the ISO reference > > model it gets easier to abstract things away because the lower > > layers are designed to deal with such details. > > > > The news is: *we* are at the lower layer. These are the issues > > that we have to concern ourselves with so that no one else will > > have to. > > > Well, the TCP-like abstraction is certainly an ideal which we can't > achieve at this level, as you point out. My point was that L2TP could > be defined to attempt to contain the more physical-level characteristics > of the link to the end with the actual physical connection (i.e. the > LAC). No argument there. I think that the LAC should deal with the details to the greatest degree possible. But it should inform the LNS of any particularities it might have to deal with (like MRU). The case of out-going calls is particularly sticky. If the LAC told the MRU what value it should negotiate when the LNS/LAC handshake, then the LNS could enforce that value during the negotiation. Similarly for the ACCM. If the above works, then why not tell the LNS "hey, this is an HDLC link"... or not, as the case may be. > If we changed L2TP to differentiate HDLC and non-HDLC sessions at the > LNS, then the LNS would be able to satisfy the ACF handling for HDLC > links; And for non-HDLC links the LNS would just not include ACCM or > ACFC options, and not prepend the ACF on any packets it sent out (nor > expect to receive them!). Then, as long as all of the PPP-over-X > protocols can take care of framing at the LAC and simply forward > rfc1661-style PPP frames between the LAC and LNS we are all set. > I don't yet understand (which may be entirely my fault!) why this > wouldn't be effective. Idem. > If in the future some portion of PPP framing has to be known at the LNS > then we can add in that functionality to the L2TP protocol at that time > (fairly simply). Mmmmmmmm..... stuff gets entrenched awfully quickly. -Philip > Richard. > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > Richard Shea rshea@BayNetworks.com > Bay Networks, Extranet Access 978-266-1011 x210 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 12 19:07:47 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id TAA05965; Thu, 12 Feb 1998 19:07:43 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 19:06:01 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA05916 for ietf-ppp-outgoing; Thu, 12 Feb 1998 19:06:00 -0500 (EST) Received: from hal.lcp.livingston.com (hal.lcp.livingston.com [158.222.8.12]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA05911 for ; Thu, 12 Feb 1998 19:05:55 -0500 (EST) Received: from [158.222.8.17] (alan.lcp.livingston.com [158.222.8.17]) by hal.lcp.livingston.com (8.8.7/8.8.4) with ESMTP id QAA24745; Thu, 12 Feb 1998 16:04:48 -0800 (PST) X-Sender: brian@hal.lcp.livingston.com Message-Id: In-Reply-To: <34E38571.171EB68@BayNetworks.com> References: <199802121817.KAA16252@vandys-pc.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Feb 1998 16:00:14 -0800 To: rshea@BayNetworks.com From: Brian Lloyd Subject: Re: LCP renegotiation Cc: Brian Lloyd , Philip Rakity , Andy Valencia , l2tp@zendo.com, ietf working group Sender: owner-ietf-ppp@merit.edu At 15:27 -0800 2/12/98, Richard Shea wrote: >Brian Lloyd wrote: >> So, has anyone considered using multilink over a single logical link >> as a > >Link-layer compression and enryption isn't between the LAC and its >client, it's between the LNS and it's client. ACCM escaping happens >between the LAC and its client, but the ACCM value is in some cases >negotiated between the LNS and the client. Whether the framing is sync >or async is really unimportant from the LNS's point of view from a >packet handling standpoint anyway. > >I'll have to think about the MP suggestions for handling MTU some more, >but my initial feeling is that it won't be too helpful. > >I think the MP suggestions (if I understand them correctly) are too >divergent from the current state of L2TP for consideration. I'm sorry. I didn't realize that the protocol had reached standard state. I thought it was going to proposed standard. That is what I get for tuning in late. >If what you >are saying is that single link would be negotiated between the LAC and >client with the bundle terminated at the LNS, this is too far afield >from the operational model of L2F/PPTP/L2TP for consideration (IMO). I >have a feeling Andy will agree with me on this one... :) Oh, I understand and that is why I don't think anyone will take my comments too seriously. It strikes me that there is a possibility that the current L2TP draft protocol may be as flawed as the originally proposed Multilink protocols. My point was to suggest a different way of looking at the problem. I used Multilink because it has been down this road before. *Maybe* multilink is appropriate and maybe it isn't. I *suspect* that L2TP might benefit from using the network layer model for PPP instead of the link layer model. The partitioning of functionallity simplifies some things. Think about it. History: PPPEXT fragmented into two camps over how to do Multilink. The two groups came to me for adjudication. I looked at both proposals, pronounced both as being flawed, and then proposed a new architecture based on them model wherein PPP is really two layers, i.e. link and network, instead of just one. The problems then disappeared with the new model. I suspect that we have a similar sort of problem here. On the other hand, maybe I am completely off base and my comments are invalid in which case I beg the group's pardon. Brian Lloyd Lucent Technologies brian@lcp.livingston.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6399 - voice +1.530.676.3442 - fax O- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 12 19:15:50 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id TAA06140; Thu, 12 Feb 1998 19:15:48 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 19:14:09 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA06100 for ietf-ppp-outgoing; Thu, 12 Feb 1998 19:14:08 -0500 (EST) Received: from ntserver.newoak.com ([146.115.61.251]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA06093 for ; Thu, 12 Feb 1998 19:14:03 -0500 (EST) Received: from rshea ([10.0.1.243]) by ntserver.newoak.com (Netscape Mail Server v2.02) with ESMTP id AAA118; Thu, 12 Feb 1998 19:14:18 -0500 Message-ID: <34E3900C.F52B5C7D@BayNetworks.com> Date: Thu, 12 Feb 1998 19:13:00 -0500 From: Richard Shea Reply-To: rshea@BayNetworks.com Organization: Bay Networks X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: Brian Lloyd CC: Philip Rakity , Andy Valencia , l2tp@zendo.com, ietf working group Subject: Re: LCP renegotiation X-Priority: 3 (Normal) References: <199802121817.KAA16252@vandys-pc.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Brian Lloyd wrote: > > At 15:27 -0800 2/12/98, Richard Shea wrote: > >Brian Lloyd wrote: > >> So, has anyone considered using multilink over a single logical > link > >> as a > > > >Link-layer compression and enryption isn't between the LAC and its > >client, it's between the LNS and it's client. ACCM escaping happens > >between the LAC and its client, but the ACCM value is in some cases > >negotiated between the LNS and the client. Whether the framing is > sync > >or async is really unimportant from the LNS's point of view from a > >packet handling standpoint anyway. > > > >I'll have to think about the MP suggestions for handling MTU some > more, > >but my initial feeling is that it won't be too helpful. > > > >I think the MP suggestions (if I understand them correctly) are too > >divergent from the current state of L2TP for consideration. > > I'm sorry. I didn't realize that the protocol had reached standard > state. > I thought it was going to proposed standard. That is what I get for > tuning > in late. > Nope, you were correct -- it will be going to Proposed Standard. I was coming more from the angle of where the inertia is and the fact that people are chomping at the bit to ship, etc., etc.. From a practical standpoint, not from a technical one, I don't think it will be considered. Sorry for the confusion. [..] > > My point was to suggest a different way of looking at the problem. I > used > Multilink because it has been down this road before. *Maybe* > multilink is > appropriate and maybe it isn't. I *suspect* that L2TP might benefit > from > using the network layer model for PPP instead of the link layer model. > The > partitioning of functionallity simplifies some things. Think about > it. > I will. Unfortunately, something coming from an angle as different as this won't be called L2TP (IMHO). It would be a competing protocol called something else. Richard. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Richard Shea rshea@BayNetworks.com Bay Networks, Extranet Access 978-266-1011 x210 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 12 20:29:14 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA07085; Thu, 12 Feb 1998 20:28:57 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 20:26:56 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA07054 for ietf-ppp-outgoing; Thu, 12 Feb 1998 20:26:55 -0500 (EST) Received: from santaclara01.pop.internex.net (santaclara01.pop.internex.net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA07050 for ; Thu, 12 Feb 1998 20:26:51 -0500 (EST) Received: from flowpoint.com ([192.84.210.69]) by santaclara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA26290; Thu, 12 Feb 1998 17:26:49 -0800 Received: from localhost (rcs@localhost) by flowpoint.com (8.8.7/8.8.4) with SMTP id RAA23567; Thu, 12 Feb 1998 17:27:11 -0800 Date: Thu, 12 Feb 1998 17:27:11 -0800 (PST) From: Rick Sewill X-Sender: rcs@flowpnt To: Richard Shea cc: "Philip A. Prindeville" , vandys@cisco.com, ietf-ppp@merit.edu, l2tp@zendo.com, pmr@flowpoint.com Subject: Re: LCP renegotiation In-Reply-To: <34E3896E.319B8B9F@BayNetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Richard, I think we should combine what you have been saying with what Brian Lloyd has been saying. I believe the LAC should be in charge of Link Layer functions, i.e., the LAC should tack on the ff03 on output to the client if HDLC, and remove the ff03 on input from the client if HDLC. Similarly, a LAC supporting PPP over ATM should pass the data between the client and LNS transparently if VC-Multiplexing is used; and should tack on/remove the fefe03cf if LLC-Multiplexing is used. The LAC should tell the LNS in an AVP what the LAC can do (if the LAC offers the LNS more than one choice) or will do (if the LAC offers the LNS only one choice). The LNS will negotiate with the client, and when it comes to link layer items, use the values recommended/required by the LAC. The LNS will tell the LAC in an AVP the link layer items that were agreed to and leave the dealing of link layer items to the LAC. This seems, IMHO, a reasonable way to resolve the questions of MRU size, ACCM, ACF, HDLC v.s. ADSL v.s. the next ppp protocol over whatever media, and resolve a substantial technical concern with L2TP. I will now run for cover in a bomb shelter while the tunneling begins. -Rick On Thu, 12 Feb 1998, Richard Shea wrote: > Philip A. Prindeville wrote: > > > [..] > > > > I think you are being naive. As you go up the ISO reference > > model it gets easier to abstract things away because the lower > > layers are designed to deal with such details. > > > > The news is: *we* are at the lower layer. These are the issues > > that we have to concern ourselves with so that no one else will > > have to. > > > > Well, the TCP-like abstraction is certainly an ideal which we can't > achieve at this level, as you point out. My point was that L2TP could > be defined to attempt to contain the more physical-level characteristics > of the link to the end with the actual physical connection (i.e. the > LAC). > > If we changed L2TP to differentiate HDLC and non-HDLC sessions at the > LNS, then the LNS would be able to satisfy the ACF handling for HDLC > links; And for non-HDLC links the LNS would just not include ACCM or > ACFC options, and not prepend the ACF on any packets it sent out (nor > expect to receive them!). Then, as long as all of the PPP-over-X > protocols can take care of framing at the LAC and simply forward > rfc1661-style PPP frames between the LAC and LNS we are all set. > > I don't yet understand (which may be entirely my fault!) why this > wouldn't be effective. > > If in the future some portion of PPP framing has to be known at the LNS > then we can add in that functionality to the L2TP protocol at that time > (fairly simply). > > Richard. > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > Richard Shea rshea@BayNetworks.com > Bay Networks, Extranet Access 978-266-1011 x210 > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 12 20:44:23 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA07267; Thu, 12 Feb 1998 20:44:22 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 20:42:40 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA07225 for ietf-ppp-outgoing; Thu, 12 Feb 1998 20:42:40 -0500 (EST) Received: from hal.lcp.livingston.com (hal.lcp.livingston.com [158.222.8.12]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA07221 for ; Thu, 12 Feb 1998 20:42:35 -0500 (EST) Received: from [158.222.8.17] (alan.lcp.livingston.com [158.222.8.17]) by hal.lcp.livingston.com (8.8.7/8.8.4) with ESMTP id RAA01908; Thu, 12 Feb 1998 17:41:48 -0800 (PST) X-Sender: brian@hal.lcp.livingston.com Message-Id: In-Reply-To: <34E3900C.F52B5C7D@BayNetworks.com> References: <199802121817.KAA16252@vandys-pc.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Feb 1998 17:34:16 -0800 To: rshea@BayNetworks.com From: Brian Lloyd Subject: Re: LCP renegotiation Cc: Philip Rakity , Andy Valencia , l2tp@zendo.com, ietf working group Sender: owner-ietf-ppp@merit.edu At 16:13 -0800 2/12/98, Richard Shea wrote: >Nope, you were correct -- it will be going to Proposed Standard. Oh good. I can remove my tongue from my cheek then. >I was >coming more from the angle of where the inertia is and the fact that >people are chomping at the bit to ship, etc., etc.. From a practical >standpoint, not from a technical one, I don't think it will be >considered. Sorry for the confusion. Well, we certainly wouldn't want good protocol engineering to stand in the way of shipping product now, would we. >> partitioning of functionallity simplifies some things. Think about >> it. > >I will. Unfortunately, something coming from an angle as different as >this won't be called L2TP (IMHO). It would be a competing protocol >called something else. A rose by any other name ... The purpose of L2TP, as I understand it, is to allow the PPP session to be managed remotely from the LNS essentially tunneling the "link" session from the LAC to the LNS. No internet (small 'i') layer routing involved. Call it what you will but it does the same thing. Other than the initial negotiation for Multilink, there is really no need for the LNS to bother with LCP negotiation. Clearly I need to look at L2TP a lot more closely than I have. More from me on this later. (No, that is not a threat.) Brian Lloyd Lucent Technologies brian@lcp.livingston.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6399 - voice +1.530.676.3442 - fax O- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 12 21:43:42 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id VAA07982; Thu, 12 Feb 1998 21:43:39 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Feb 1998 21:41:39 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA07947 for ietf-ppp-outgoing; Thu, 12 Feb 1998 21:41:39 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.7/8.8.5) with SMTP id VAA07943 for ; Thu, 12 Feb 1998 21:41:33 -0500 (EST) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id SAA19951; Thu, 12 Feb 1998 18:41:31 -0800 Received: from ascend.com by ascend.com with ESMTP id SAA01022; Thu, 12 Feb 1998 18:41:40 -0800 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id SAA15985; Thu, 12 Feb 1998 18:41:40 -0800 Received: from igoyret-pc.ascend.com (igoyret-pc.eng.ascend.com [172.20.16.32]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id SAA18175; Thu, 12 Feb 1998 18:41:39 -0800 Message-Id: <3.0.1.32.19980212183702.00b081e4@gump.eng.ascend.com> X-Sender: igoyret@gump.eng.ascend.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 12 Feb 1998 18:37:02 -0800 To: Rick Sewill From: Ignacio Goyret Subject: Re: LCP renegotiation Cc: ietf-ppp@merit.edu, l2tp@zendo.com In-Reply-To: References: <34E3896E.319B8B9F@BayNetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Rick, In four words: I like your proposal. -Ignacio PS: see comments below At 05:27 PM 2/12/98 -0800, Rick Sewill wrote: > >Richard, > >I think we should combine what you have been saying with what Brian Lloyd >has been saying. > >I believe the LAC should be in charge of Link Layer functions, i.e., the >LAC should tack on the ff03 on output to the client if HDLC, and remove >the ff03 on input from the client if HDLC. Similarly, a LAC supporting >PPP over ATM should pass the data between the client and LNS transparently >if VC-Multiplexing is used; and should tack on/remove the fefe03cf if >LLC-Multiplexing is used. > >The LAC should tell the LNS in an AVP what the LAC can do (if the LAC >offers the LNS more than one choice) or will do (if the LAC offers the LNS >only one choice). > >The LNS will negotiate with the client, and when it comes to link layer >items, use the values recommended/required by the LAC. > >The LNS will tell the LAC in an AVP the link layer items that were agreed >to and leave the dealing of link layer items to the LAC. We already have AVPs defined that can be used for this purpose perfectly well: see AVP #27 and #28. ----------------------------------------------------------------------- Ignacio Goyret, Sr. Software Engineer Voice: (510) 747-2823 Ascend Communications, Inc. FAX: (510) 747-2859 1701 Harbor Bay Parkway, Alameda, CA 94502 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 13 01:05:02 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id BAA11562; Fri, 13 Feb 1998 01:04:51 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Feb 1998 01:01:09 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id BAA11494 for ietf-ppp-outgoing; Fri, 13 Feb 1998 01:01:08 -0500 (EST) Received: from zevpc-isdn.network-alchemy.com (zevpc-isdn.Network-Alchemy.COM [199.46.17.90]) by merit.edu (8.8.7/8.8.5) with ESMTP id BAA11490 for ; Fri, 13 Feb 1998 01:01:03 -0500 (EST) Received: from zevpc-isdn.network-alchemy.com (localhost.Network-Alchemy.COM [127.0.0.1]) by zevpc-isdn.network-alchemy.com (8.8.8/8.8.5) with ESMTP id VAA01342; Thu, 12 Feb 1998 21:58:49 -0800 (PST) Message-Id: <199802130558.VAA01342@zevpc-isdn.network-alchemy.com> To: l2tp@zendo.com, ietf-ppp@merit.edu Subject: L2TP - PPP encapsulations and LCP renegotiation Date: Thu, 12 Feb 1998 21:58:47 -0800 From: William Palter Sender: owner-ietf-ppp@merit.edu I think we are losing a little perspective on what we set out to do and what we have already achieved. We set out to try and merge L2F and PPTP incorporating the best features of both, and to get the specification done quickly so that we would not end up with three standards and need to support all of them in every implementation (in order to be competitive). We have also had two successful backoffs in between which we have done some tweaking to the protocol, the next backoff is scheduled in less than two weeks. LCP renegotiation really falls into 4 cases, these cases are 1) Client and LAC in the same box, an example of this is voluntary tunneling in windows NT, in this case the PPP client should have enough knowledge about the fact that it is being tunneled thru L2TP that it should negotiate appropriate options with the LNS (since it knows that there really is not physical layer PPP session). 2) LAC negotiates LCP and then forwards the session. In this case the LNS should be able to get enough info from the proxy LCP info that if it renegotiates LCP it can use options that are compatible with the LAC. 3) HDLC/AHDLC client dialing into a LAC and being forwarded to an LNS without LCP being negotiated by the LAC. When this occurs the LNS needs to be conservative in what it negotiates with the client, but we have shown inter operability with the in the past two backoffs. 4) non-HDLC type clients connecting to a LAC being forwarded to an LNS. This is the real sticky case, since the LNS really has no idea what LCP options to negotiate with the client, but I think that if the LNS is conservative in what it does and takes some hints from the client, we should be able to inter-operate. We really haven't had any experience in the previous backoffs with this case. As for framing in the data packets, we choose basicly the HDLC type framing that most PPP clients support with the assumption that LACs could do some simple framing conversion if it were needed, if we had to do it again I believe that we probably would have chosen to strip the 0xff 0x03, move the protocol field into the L2TP header, and just send the data part of the PPP packet, if we knew then what we know now. But changing this now would break a lot of the interop that we have already done. If we decide at this point to go back and try to build a protocol that can tunnel and support every possible combination of LCP options (such as different FCSes or COBS or anything else that maybe dreamt up) we will end up needing a few more backoffs and probably will end up publishing this draft after its usefulness has passed. Bill Palter - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 13 01:57:02 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id BAA12066; Fri, 13 Feb 1998 01:57:00 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Feb 1998 01:53:53 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id BAA12006 for ietf-ppp-outgoing; Fri, 13 Feb 1998 01:53:53 -0500 (EST) Received: from santaclara01.pop.internex.net (santaclara01.pop.internex.net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id BAA12002 for ; Fri, 13 Feb 1998 01:53:48 -0500 (EST) Received: from flowpoint.com ([192.84.210.69]) by santaclara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA6350; Thu, 12 Feb 1998 22:53:47 -0800 Received: from localhost (pmr@localhost) by flowpoint.com (8.8.7/8.8.4) with SMTP id WAA08557; Thu, 12 Feb 1998 22:54:06 -0800 Date: Thu, 12 Feb 1998 22:54:06 -0800 (PST) From: Philip Rakity X-Sender: pmr@flowpnt To: William Palter cc: l2tp@zendo.com, ietf-ppp@merit.edu Subject: Re: L2TP - PPP encapsulations and LCP renegotiation In-Reply-To: <199802130558.VAA01342@zevpc-isdn.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Bill, On Thu, 12 Feb 1998, William Palter wrote: > > > I think we are losing a little perspective on what we set out to > do and what we have already achieved. We set out to try and merge L2F and > PPTP incorporating the best features of both, and to get the specification > done quickly so that we would not end up with three standards and need to > support all of them in every implementation (in order to be competitive). > We have also had two successful backoffs in between which we have done > some tweaking to the protocol, the next backoff is scheduled in less than > two weeks. > > > LCP renegotiation really falls into 4 cases, these cases are > > > 1) Client and LAC in the same box, an example of this is > voluntary tunneling in windows NT, in this case the > PPP client should have enough knowledge about the fact that > it is being tunneled thru L2TP that it should negotiate > appropriate options with the LNS (since it knows that there > really is not physical layer PPP session). > > > 2) LAC negotiates LCP and then forwards the session. In this case > the LNS should be able to get enough info from the proxy LCP > info that if it renegotiates LCP it can use options that are > compatible with the LAC. > > > 3) HDLC/AHDLC client dialing into a LAC and being forwarded to > an LNS without LCP being negotiated by the LAC. When this > occurs the LNS needs to be conservative in what it negotiates > with the client, but we have shown inter operability with the > in the past two backoffs. This can be fixed by either passing the MRU information etc to the LNS or specifing options in the specification that make this work. The question is what is the correct approach to resolve the problem; eg DEFINE conservative. > > > 4) non-HDLC type clients connecting to a LAC being forwarded to > an LNS. This is the real sticky case, since the LNS really > has no idea what LCP options to negotiate with the client, > but I think that if the LNS is conservative in what it does > and takes some hints from the client, we should be able to > inter-operate. We really haven't had any experience in the > previous backoffs with this case. > > > > As for framing in the data packets, we choose basicly the HDLC > type framing that most PPP clients support with the assumption that > LACs could do some simple framing conversion if it were needed, if > we had to do it again I believe that we probably would have chosen > to strip the 0xff 0x03, move the protocol field into the L2TP header, > and just send the data part of the PPP packet, if we knew then what > we know now. But changing this now would break a lot of the interop > that we have already done. This the problem that the interoperability testing is supposed to show up. Why not define the message flow between the LAC and LNS that are needed to fix this problem, then define the default action, that occurs when NO messages are passed. The default action maps the current implementations and the messages define the action that a full function LAC/LNS will implement. The interoperability test session can validate the draft without the message exchange. If we add text to the draft NOW to handle the message exchange, then some of us might be able to test this at the interoperability test session. (We are prepared to put code into our system to deal with this), and if we can interoperate with other folks, then we can move the draft towards an RFC number. > > > If we decide at this point to go back and try to build a protocol > that can tunnel and support every possible combination of LCP options > (such as different FCSes or COBS or anything else that maybe dreamt > up) we will end up needing a few more backoffs and probably will end > up publishing this draft after its usefulness has passed. > > > Bill Palter > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 13 08:40:46 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA15509; Fri, 13 Feb 1998 08:40:05 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Feb 1998 08:33:22 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA15396 for ietf-ppp-outgoing; Fri, 13 Feb 1998 08:33:21 -0500 (EST) Received: from ntserver.newoak.com ([146.115.61.251]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA15392 for ; Fri, 13 Feb 1998 08:33:14 -0500 (EST) Received: from rshea ([10.0.1.243]) by ntserver.newoak.com (Netscape Mail Server v2.02) with ESMTP id AAA118; Fri, 13 Feb 1998 08:33:31 -0500 Message-ID: <34E44B62.6AA636D2@BayNetworks.com> Date: Fri, 13 Feb 1998 08:32:18 -0500 From: Richard Shea Reply-To: rshea@BayNetworks.com Organization: Bay Networks X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: Brian Lloyd CC: Philip Rakity , Andy Valencia , l2tp@zendo.com, ietf working group Subject: Re: LCP renegotiation X-Priority: 3 (Normal) References: <199802121817.KAA16252@vandys-pc.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Brian Lloyd wrote: > > At 16:13 -0800 2/12/98, Richard Shea wrote: > >Nope, you were correct -- it will be going to Proposed Standard. > > Oh good. I can remove my tongue from my cheek then. > Aha. > >I was > >coming more from the angle of where the inertia is and the fact that > >people are chomping at the bit to ship, etc., etc.. From a practical > >standpoint, not from a technical one, I don't think it will be > >considered. Sorry for the confusion. > > Well, we certainly wouldn't want good protocol engineering to stand in > the > way of shipping product now, would we. > IMHO, I don't think the real goal of L2TP was ever good protocol engineering. To quote Bill Palter's email from last night: "We set out to try and merge L2F and PPTP incorporating the best features of both, and to get the specification done quickly so that we would not end up with three standards and need to support all of them in every implementation (in order to be competitive)." So, basically whatever faults (and features!) L2F and PPTP had were inherited by L2TP and some new features and tweaks were added. I think tunneling PPP has its applications, but I'm not sure it is a good fit in many other applications. Here are a few problems I see with it as it is or will be deployed: (1) This discussion. (2) L2TP-over-IP fragmentation. It is not necessarily easy to avoid fragmentation of encapsulated L2TP packets. On the Internet at least there is a wide range of packet loss characteristics. Each time you fragment a packet you increase the probability that the datagram being fragmented will be dropped. Each time you drop a packet you introduce timing complexity and throw a wrench in the stateful compression/encryption protocols. (3) Current popularity of stateful compression and encryption protocols in PPP. Tunneling stateful protocols across a network which drops packets much more routinely (say 3% to 5% of the time, NOT atypical of Internet) than a real point-to-point connection leads to serious performance degredation. (4) Termination of multilink on the LNS. Just like IP fragmentation, multilink terminated at the LNS increases probability of datagram loss. Also, the timing of link-packet reception due to the network traversal is sure to affect performance. (5) Acknowledgement by packet, not by byte. Unlike TCP which has a byte window size, L2TP has a packet window size. Which means it cannot adjust well with (perhaps intermittent) high-latency conditions between the LAC and LNS (especially if it tries to avoid fragmentation). Part of the reason this is necessary is because the packet window size is needed so that the stateful compression/encryption protocols can adjust better to packet loss conditions. I was going to address these problems one at a time over time, but it seems the can was open so the worms had to come out. ;) Of these, (1) is being currently addressed, I wrote an I-D to try and fix (2) (to which I've received NO feedback), (3) has been discussed but you can't do much with the installed base that is already out there, and (4) and (5) haven't been discussed at all to my knowledge. The company I work for (which was New Oak which was acquired by Bay) did just what Bill Palter mentioned. I implemented PPTP, L2F, and now L2TP not because they are necessarily great protocols, but because they are all out there and people are asking for them (and the reason for the company is to make money!). Our product also has an IPSEC client which uses IPSEC tunnel-mode to tunnel traffic to our box from a PC. We basically covered it all because there is no clear winner, not from a marketing point of view and not from a technical point of view. Now, having said all this I have to go show my face at the CIUG in a little more than a week and test my L2TP LNS implementation with all the people I've probably pissed off now! I believe, however, that my criticisms have technical merit and unless someone can address (1)-(5) and convince me that they are satisfactorily addressed by the L2TP spec I stand by them. BTW, (1)-(5) exist for PPTP, L2F, and L2TP, with the exception of L2F which didn't do any flow control and so (5) wasn't a problem (but not having flow control probably makes (3) worse in that case). [..] > > Clearly I need to look at L2TP a lot more closely than I have. More > from > me on this later. (No, that is not a threat.) > I welcome it. Richard. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Richard Shea rshea@BayNetworks.com Bay Networks, Extranet Access 978-266-1011 x210 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 13 13:41:44 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA21915; Fri, 13 Feb 1998 13:41:33 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Feb 1998 13:33:41 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA21773 for ietf-ppp-outgoing; Fri, 13 Feb 1998 13:33:40 -0500 (EST) Received: from hal.lcp.livingston.com (hal.lcp.livingston.com [158.222.8.12]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA21765 for ; Fri, 13 Feb 1998 13:33:35 -0500 (EST) Received: from [158.222.8.17] (alan.lcp.livingston.com [158.222.8.17]) by hal.lcp.livingston.com (8.8.7/8.8.4) with ESMTP id KAA19383; Fri, 13 Feb 1998 10:33:28 -0800 (PST) X-Sender: brian@hal.lcp.livingston.com Message-Id: In-Reply-To: <199802130558.VAA01342@zevpc-isdn.network-alchemy.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Feb 1998 10:20:00 -0800 To: l2tp@zendo.com, ietf-ppp@merit.edu From: Brian Lloyd Subject: Re: L2TP - PPP encapsulations and LCP renegotiation Sender: owner-ietf-ppp@merit.edu At 21:58 -0800 2/12/98, William Palter wrote: Everything you have written up to here makes sense to me. > As for framing in the data packets, we choose basicly the HDLC > type framing that most PPP clients support with the assumption that > LACs could do some simple framing conversion if it were needed, if > we had to do it again I believe that we probably would have chosen > to strip the 0xff 0x03, move the protocol field into the L2TP header, > and just send the data part of the PPP packet, if we knew then what > we know now. But changing this now would break a lot of the interop > that we have already done. You just stated the key factor, "if we knew then what we know now." OK, you know it now. You know that the assumptions originally made were flawed. You know where the flaw is. FIX IT! Don't screw around moaning about interoperability testing that has already been done. FIX IT! DO IT RIGHT! Then go back and do new interoperability testing. That is how you end up with good protocols with logical, straight-forward implementations instead of hacked up kludges that don't always converge, aren't likely to interoperate without case-by-case tweaking, and won't adapt to new technologies when the appear. Failure to "do the right thing" is a support nightmare. > If we decide at this point to go back and try to build a protocol > that can tunnel and support every possible combination of LCP options > (such as different FCSes or COBS or anything else that maybe dreamt > up) we will end up needing a few more backoffs and probably will end > up publishing this draft after its usefulness has passed. What is going on here? Do we have marketing people running the IETF instead of engineers who write code? (Gawd, I am starting to sound like Bill Simpson. Someone please shoot me now.) Is the new attitude, "it is more important to get it out than to get it right?" Yeah, I guess it then becomes the customer's problem. Well, I believe that it should be possible to define the protocol generally correctly in a week or two. We will need a couple of implementations to do preliminary testing which may result in tweaking the protocol. We get a few more people to implement the tweaked protocol and we do another bake-off. So you are worried about the different kinds of point-to-point framing you may run into out there and and in the future. If that is your concern, then isolate the framing to the link layer and don't propagate that back up the stack to the network layer. Now if someone comes up with a new way of framing data over the link, the network layer doesn't need to worry about it. Problem solved. OK, how about it stated in more detail. The problem is that the LNS really shouldn't have to know about what is going on down at the LCP layer. The LAC and the remote host negotiate the framing options because they know what the hardware looks like and know the requirements for the local link. Once that happens the LCP layer in the LAC communicates with the authentication/MP/NCP layers (phases?) in the LNS via L2TP and says, "you have a good pipe over which you may exchange packets with the remote client." Now your PPP "network layer" packets consist of a PPP payload preceeded by a protocol ID field. There is no framing cruft that needs to go back and forth because the envelope you are using; e.g. UDP, FR, or X.25; provides complete delineation of the payload boundaries. So if you don't need to send extra cruft, don't send it. The fly in this ointment is the fact that the LCP layer also offers the MP MMRU option to indicate that the virtual NAS (I want some different name here to denote the system that is the logical fusion of LNS and LAC) offers and supports MP. That means that the LAC needs to know ahead of time that the LNS is prepared to support MP. I had this ugly little feeling in the pit of my stomach several years ago that piggybacking the MP option as part of the LCP negotiation (read "gross violation of layering") would come back and bite me some day. And let me reiterate one thing: just because you have code ready to ship doesn't mean that you should ship it if it is wrong or that you won't ship updates becuase you have learned something new or better. Think about it, solve the problems, roll new code, and then test it. Repeat until it is right. Where the heck is our WG chaircritter? Karl, you should be doing this yelling about the meta issues, not me. You've been there. Please tell them; how many times did you change your PPP code at Morningstar while we were working out the problems with the base PPP spec? How many times did you ship updates to your customers because we discovered that we needed to change something based on experiential data? Folks, just because you have code out there doesn't mean you can't change your code for the better. Do you best to support backward compatibility but don't be slavish about it. If you have to abandon an older version of a protocol because it is completely incompatible with the correct version of a protocol, sobeit. I apologize for jumping back and forth between the technical issue(s) and the meta issue. This message was stream of consiousness. Hopefully this makes sense to people. Brian Lloyd Lucent Technologies brian@lcp.livingston.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6399 - voice +1.530.676.3442 - fax O- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 13 14:07:19 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA22636; Fri, 13 Feb 1998 14:07:17 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Feb 1998 14:02:49 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA22512 for ietf-ppp-outgoing; Fri, 13 Feb 1998 14:02:49 -0500 (EST) Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA22505 for ; Fri, 13 Feb 1998 14:02:43 -0500 (EST) Received: (tkolar@localhost) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id LAA23157; Fri, 13 Feb 1998 11:01:09 -0800 (PST) From: Tim Kolar Message-Id: <199802131901.LAA23157@flipper.cisco.com> Subject: Re: L2TP - PPP encapsulations and LCP renegotiation To: brian@lcp.livingston.com (Brian Lloyd) Date: Fri, 13 Feb 1998 11:01:09 -0800 (PST) Cc: l2tp@zendo.com, ietf-ppp@merit.edu In-Reply-To: from "Brian Lloyd" at Feb 13, 98 10:20:00 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Brian Lloyd writes... > > > If we decide at this point to go back and try to build a protocol > > that can tunnel and support every possible combination of LCP options > > (such as different FCSes or COBS or anything else that maybe dreamt > > up) we will end up needing a few more backoffs and probably will end > > up publishing this draft after its usefulness has passed. > > What is going on here? Do we have marketing people running the IETF > instead of engineers who write code? (Gawd, I am starting to sound like > Bill Simpson. Someone please shoot me now.) Is the new attitude, "it is > more important to get it out than to get it right?" Yeah, I guess it then > becomes the customer's problem. > The IETF risks finding itself sidelined if it can not operate in a timely fashion. I don't believe anyone on this list wants to see that, which is why you're starting to see some urgency around getting the spec out. The L2TP draft has long since satisfied its original goal of blending L2F and PPTP into something workable. In my opinion, we hit the point of diminishing returns sometime last March. Part of being a good engineer is knowing when to stop fiddling with something and ship it. You build in extensibility (we have), you think through possible problems (we have), then you bite the bullet and expose your work to the world. -Tim - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 13 14:20:02 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA22927; Fri, 13 Feb 1998 14:20:01 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Feb 1998 14:15:50 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA22821 for ietf-ppp-outgoing; Fri, 13 Feb 1998 14:15:49 -0500 (EST) Received: from santaclara01.pop.internex.net (santaclara01.pop.internex.net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA22814 for ; Fri, 13 Feb 1998 14:15:43 -0500 (EST) Received: from flowpoint.com ([192.84.210.69]) by santaclara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA27549; Fri, 13 Feb 1998 11:15:41 -0800 Received: from localhost (pmr@localhost) by flowpoint.com (8.8.7/8.8.4) with SMTP id LAA12533; Fri, 13 Feb 1998 11:16:02 -0800 Date: Fri, 13 Feb 1998 11:16:02 -0800 (PST) From: Philip Rakity X-Sender: pmr@flowpnt To: Tim Kolar cc: Brian Lloyd , l2tp@zendo.com, ietf-ppp@merit.edu Subject: Re: L2TP - PPP encapsulations and LCP renegotiation In-Reply-To: <199802131901.LAA23157@flipper.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Fri, 13 Feb 1998, Tim Kolar wrote: > Brian Lloyd writes... > > > > > If we decide at this point to go back and try to build a protocol > > > that can tunnel and support every possible combination of LCP options > > > (such as different FCSes or COBS or anything else that maybe dreamt > > > up) we will end up needing a few more backoffs and probably will end > > > up publishing this draft after its usefulness has passed. > > > > What is going on here? Do we have marketing people running the IETF > > instead of engineers who write code? (Gawd, I am starting to sound like > > Bill Simpson. Someone please shoot me now.) Is the new attitude, "it is > > more important to get it out than to get it right?" Yeah, I guess it then > > becomes the customer's problem. > > > > The IETF risks finding itself sidelined if it can not operate in a timely > fashion. I don't believe anyone on this list wants to see that, which is > why you're starting to see some urgency around getting the spec out. > > The L2TP draft has long since satisfied its original goal of blending L2F > and PPTP into something workable. In my opinion, we hit the point of > diminishing returns sometime last March. > > Part of being a good engineer is knowing when to stop fiddling with something > and ship it. You build in extensibility (we have), you think through > possible problems (we have), then you bite the bullet and expose your work > to the world. Part of good engineering is knowing when to fix problems that show up rather than pretend that they do not exist. If the spec was so good last March, why hasn't yet obtained an RFC number. BTW, when was the 1st/2nd interoperability kitchens for L2TP ?` On another note, we have put a proposal on the table to help fix the draft so that it can go forward. I am still waiting for an e-mail to take up the offer. Philip Rakity FlowPoint > > -Tim > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 13 14:35:52 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA23440; Fri, 13 Feb 1998 14:35:49 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Feb 1998 14:31:34 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA23282 for ietf-ppp-outgoing; Fri, 13 Feb 1998 14:31:33 -0500 (EST) Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA23261 for ; Fri, 13 Feb 1998 14:31:24 -0500 (EST) Received: (tkolar@localhost) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id LAA25731; Fri, 13 Feb 1998 11:29:13 -0800 (PST) From: Tim Kolar Message-Id: <199802131929.LAA25731@flipper.cisco.com> Subject: Re: L2TP - PPP encapsulations and LCP renegotiation To: pmr@flowpoint.com (Philip Rakity) Date: Fri, 13 Feb 1998 11:29:13 -0800 (PST) Cc: tkolar@cisco.com, brian@lcp.livingston.com, l2tp@zendo.com, ietf-ppp@merit.edu In-Reply-To: from "Philip Rakity" at Feb 13, 98 11:16:02 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Philip Rakity writes... > > Part of good engineering is knowing when to fix problems that show up > rather than pretend that they do not exist. If the spec was so good last > March, why hasn't yet obtained an RFC number. BTW, when was the > 1st/2nd interoperability kitchens for L2TP ?` It has not obtained an RFC number due to bickering over the details of an endless stream of "vital" additions to the basic protocol. Bottom line: L2F works for what it was intended to do, and is functioning fine in the field. PPTP works for what it was intended to do, and is also functioning in the field. L2TP in the meantime has gone way off into the weeds. As a developer, I know where to devote my time. -T - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 13 14:57:18 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA24173; Fri, 13 Feb 1998 14:57:11 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Feb 1998 14:52:23 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA24005 for ietf-ppp-outgoing; Fri, 13 Feb 1998 14:52:22 -0500 (EST) Received: from hal.lcp.livingston.com (hal.lcp.livingston.com [158.222.8.12]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA23996 for ; Fri, 13 Feb 1998 14:52:15 -0500 (EST) Received: from [158.222.8.17] (alan.lcp.livingston.com [158.222.8.17]) by hal.lcp.livingston.com (8.8.7/8.8.4) with ESMTP id LAA19051; Fri, 13 Feb 1998 11:51:24 -0800 (PST) X-Sender: brian@hal.lcp.livingston.com Message-Id: In-Reply-To: <34E44B62.6AA636D2@BayNetworks.com> References: <199802121817.KAA16252@vandys-pc.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Feb 1998 11:40:15 -0800 To: rshea@BayNetworks.com From: Brian Lloyd Subject: Re: LCP renegotiation Cc: Brian Lloyd , Philip Rakity , Andy Valencia , l2tp@zendo.com, ietf working group Sender: owner-ietf-ppp@merit.edu At 5:32 -0800 2/13/98, Richard Shea wrote:>IMHO, I don't think the real goal of L2TP was ever good protocol >engineering. ... I got that feeling. Still, we should try to make it as good as possible. >So, basically whatever faults (and features!) L2F and PPTP had were >inherited by L2TP and some new features and tweaks were added. Do you really believe that we would not be better served by looking at the problem and seeing if we can remove the warts? >I think tunneling PPP has its applications, but I'm not sure it is a >good fit in many other applications. I agree whole-heartedly. >Here are a few problems I see with >it as it is or will be deployed: >(1) This discussion. :^) >(2) L2TP-over-IP fragmentation. It is not necessarily easy to avoid >fragmentation of encapsulated L2TP packets. On the Internet at least >there is a wide range of packet loss characteristics. Each time you >fragment a packet you increase the probability that the datagram being >fragmented will be dropped. Each time you drop a packet you introduce >timing complexity and throw a wrench in the stateful >compression/encryption protocols. Mmmm, maybe. I have heard this argument before, way back in the connection vs. connectionless, IP vs. OSI wars of the 80's. One of the interesting things we learned is that the network is so much more reliable than anyone anticipated and that your error recovery routines don't need to be all that efficient, they just have to work. If losing the occasional packet breaks things all to pieces or packet loss reaches the magnitude that error recovery become a significant problem then you need a reliable transport medium like TCP to carry your tunnel data. But TCP doesn't preserve packet boundaries, does it. But let's turn this problem around. You have a problem because you want to use stateful encryption and/or compression algorithms that depend on previous data over a transport that is unreliable. Either you accept the performance hit that comes from losing data and having to resynch your compression/encryption engines or you switch to using block cyphers and per-packet stateless compression. >(3) Current popularity of stateful compression and encryption protocols >in PPP. Tunneling stateful protocols across a network which drops >packets much more routinely (say 3% to 5% of the time, NOT atypical of >Internet) than a real point-to-point connection leads to serious >performance degredation. So switch from CBC to ECB cyphers and per-packet stateless compression when the packet loss rate is high enough or just decide that you are going to use these stateless modes from the beginning with L2TP and be done with it. >(4) Termination of multilink on the LNS. Just like IP fragmentation, >multilink terminated at the LNS increases probability of datagram loss. >Also, the timing of link-packet reception due to the network traversal >is sure to affect performance. Sure it is. But that is what you get when you want to do something like L2TP. >(5) Acknowledgement by packet, not by byte. Unlike TCP which has a byte >window size, L2TP has a packet window size. You don't really have a choice if you consider the packet to be atomic. So far, this is packet oriented not stream oriented. IF you want to switch you have to take a new look at what you are trying to do. >Which means it cannot >adjust well with (perhaps intermittent) high-latency conditions between >the LAC and LNS (especially if it tries to avoid fragmentation). Part >of the reason this is necessary is because the packet window size is >needed so that the stateful compression/encryption protocols can adjust >better to packet loss conditions. I think it is difficult to punt this one unless you are going to switch to a stream-oriented transport and that engenders a whole new can of worms. On the other hand, if you put out two packets very close together (probably adjacent in the network) they are likely to form a packet train in the network and arrive very close together. I suspect that you aren't likely to experience latency spreading in the case of a pair of multilink payload packets. We need experiential data to determine whether or not this is a problem. >I was going to address these problems one at a time over time, but it >seems the can was open so the worms had to come out. ;) Seems we like worms. >Of these, (1) is being currently addressed, I wrote an I-D to try and >fix (2) (to which I've received NO feedback), (3) has been discussed but >you can't do much with the installed base that is already out there, and >(4) and (5) haven't been discussed at all to my knowledge. > >The company I work for (which was New Oak which was acquired by Bay) did >just what Bill Palter mentioned. I implemented PPTP, L2F, and now L2TP >not because they are necessarily great protocols, but because they are >all out there and people are asking for them (and the reason for the >company is to make money!). Our product also has an IPSEC client which >uses IPSEC tunnel-mode to tunnel traffic to our box from a PC. We >basically covered it all because there is no clear winner, not from a >marketing point of view and not from a technical point of view. You seem to be talking sense to me. I agree that the PPTP/L2F/L2TP mechanism is probably a poor technique in general. I can think of much better ways to accomplish these things but the Telcos want to get into this market and they like switched circuits. They understand them and PPTP/L2F/L2TP make the internet look like remotely-switched circuit sessions back to the remote ISP. >Now, having said all this I have to go show my face at the CIUG in a >little more than a week and test my L2TP LNS implementation with all the >people I've probably pissed off now! Well, if people can't stand the heat, they should probably stay out of the kitchen. >I believe, however, that my criticisms have technical merit and unless >someone can address (1)-(5) and convince me that they are satisfactorily >addressed by the L2TP spec I stand by them. Your criticisms seem very valid to me. I haven't finished reading the L2TP draft but so far it strikes me as being a whole lot more complex than it needs to be. I think we need to apply Ockham's razor and rethink how this thing gets done. >BTW, (1)-(5) exist for PPTP, L2F, and L2TP, with the exception of L2F >which didn't do any flow control and so (5) wasn't a problem (but not >having flow control probably makes (3) worse in that case). > >[..] >> >> Clearly I need to look at L2TP a lot more closely than I have. More >> from >> me on this later. (No, that is not a threat.) >> > >I welcome it. I am not sure everyone will welcome me quite as much as you do. Brian Lloyd Lucent Technologies brian@lcp.livingston.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6399 - voice +1.530.676.3442 - fax O- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 13 17:19:18 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA28549; Fri, 13 Feb 1998 17:19:05 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Feb 1998 17:13:48 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA28376 for ietf-ppp-outgoing; Fri, 13 Feb 1998 17:13:47 -0500 (EST) Received: from hal.lcp.livingston.com (hal.lcp.livingston.com [158.222.8.12]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA28363 for ; Fri, 13 Feb 1998 17:13:32 -0500 (EST) Received: from [158.222.8.17] (alan.lcp.livingston.com [158.222.8.17]) by hal.lcp.livingston.com (8.8.7/8.8.4) with ESMTP id OAA12749; Fri, 13 Feb 1998 14:13:21 -0800 (PST) X-Sender: brian@hal.lcp.livingston.com Message-Id: In-Reply-To: <199802131901.LAA23157@flipper.cisco.com> References: from "Brian Lloyd" at Feb 13, 98 10:20:00 am Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Feb 1998 14:10:32 -0800 To: Tim Kolar From: Brian Lloyd Subject: Re: L2TP - PPP encapsulations and LCP renegotiation Cc: l2tp@zendo.com, ietf-ppp@merit.edu Sender: owner-ietf-ppp@merit.edu At 11:01 -0800 2/13/98, Tim Kolar wrote: >The IETF risks finding itself sidelined if it can not operate in a timely >fashion. I don't believe anyone on this list wants to see that, which is >why you're starting to see some urgency around getting the spec out. The IETF is recognized as an international standards body because it gets work done and the work has, in the past, been of high quality, i.e. the protocols actually worked and did what they are supposed to do. I do not believe that the IETF will collapse because we feel that there is a problem in the L2TP draft and need to put in a couple more weeks to try to fix the problem. >The L2TP draft has long since satisfied its original goal of blending L2F >and PPTP into something workable. In my opinion, we hit the point of >diminishing returns sometime last March. I remain unconvinced that it is workable but then I haven't finished the draft doc. So far, what I see does not raise my expectations. >Part of being a good engineer is knowing when to stop fiddling with something >and ship it. You build in extensibility (we have), you think through >possible problems (we have), then you bite the bullet and expose your work >to the world. Good. I am part of the world. I have been here before a couple of times so I can put myself in your shoes. If it appears right, or perhaps I should say "best compromise," to me, I will say so. The yardstick is, "rough consensus and working code." I can tell you right now you don't have "rough consensus." If the protocol were indeed "best compromise" you would probably have rough consensus. There will be a bake-off in about 10 days. Maybe you will have universal "working code" then. Until then, I would certainly petition our Fearless Leader to hold off on advancing this draft to Proposed Standard. Brian Lloyd Lucent Technologies brian@lcp.livingston.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6399 - voice +1.530.676.3442 - fax O- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 13 17:27:44 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA28752; Fri, 13 Feb 1998 17:27:42 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Feb 1998 17:23:24 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA28630 for ietf-ppp-outgoing; Fri, 13 Feb 1998 17:23:23 -0500 (EST) Received: from ntserver.newoak.com ([146.115.61.251]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA28620 for ; Fri, 13 Feb 1998 17:23:13 -0500 (EST) Received: from rshea ([10.0.1.243]) by ntserver.newoak.com (Netscape Mail Server v2.02) with ESMTP id AAA213; Fri, 13 Feb 1998 17:23:32 -0500 Message-ID: <34E4C79D.316ED722@BayNetworks.com> Date: Fri, 13 Feb 1998 17:22:21 -0500 From: Richard Shea Reply-To: rshea@BayNetworks.com Organization: Bay Networks X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: l2tp@zendo.com, ietf working group Subject: Re: LCP renegotiation X-Priority: 3 (Normal) References: <199802121817.KAA16252@vandys-pc.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Brian Lloyd wrote: > [..] > > >(2) L2TP-over-IP fragmentation. It is not necessarily easy to avoid > >fragmentation of encapsulated L2TP packets. On the Internet at least > >there is a wide range of packet loss characteristics. Each time you > >fragment a packet you increase the probability that the datagram > being > >fragmented will be dropped. Each time you drop a packet you > introduce > >timing complexity and throw a wrench in the stateful > >compression/encryption protocols. > > Mmmm, maybe. I have heard this argument before, way back in the > connection > vs. connectionless, IP vs. OSI wars of the 80's. One of the > interesting > things we learned is that the network is so much more reliable than > anyone > anticipated and that your error recovery routines don't need to be all > that > efficient, they just have to work. > > If losing the occasional packet breaks things all to pieces or packet > loss > reaches the magnitude that error recovery become a significant problem > then > you need a reliable transport medium like TCP to carry your tunnel > data. > But TCP doesn't preserve packet boundaries, does it. > Performance measurements I took in a simulated environment based on packet loss and latency I measured on the real Internet suggest this is a problem. Tunneled TCP performance fell off very quickly with increase in latency between the tunnel endpoints, and I measured packet loss rates anywhere from barely any to 10% or so on a regular basis. So with fragmentation causing a packet loss jump from 5% to 10% or 10% to 20% you see noticable performance degredation. I should note I took these measurements between a WinNT 4.0 Workstation PC with PPTP and our implementation of PPTP, so there could have been implementation-dependent effects here. I would love to have time to do a simulation, or hopefully with L2TP do cross-vendor tests making the same measurements, probably across the real live Internet. Of course, if the network is better behaved than the typical Internet path then this isn't as big of a deal. > But let's turn this problem around. You have a problem because you > want to > use stateful encryption and/or compression algorithms that depend on > previous data over a transport that is unreliable. Either you accept > the > performance hit that comes from losing data and having to resynch your > compression/encryption engines or you switch to using block cyphers > and > per-packet stateless compression. > That would be great, but you are tunneling traffic at the LAC unknown to the client dialing in, and that client can be doing anything. There is a huge installed base of stateful compression/encryption implementations which won't migrate very quickly to stateless until everyone (i.e. users) upgrades their software to stateless implementations. I also remember reading on one of these lists that PPP DES-CBC does cross-packet chaining which I would consider semi-stateful. Again, this creates a "double your packet loss" phenomenon. VJ -- same sort of thing (I know.. "So don't negotiate it"). It seems the CCP compression algorithms can be done stateless today fairly easily so that is probably easier to change. [..] > > >(4) Termination of multilink on the LNS. Just like IP fragmentation, > >multilink terminated at the LNS increases probability of datagram > loss. > >Also, the timing of link-packet reception due to the network > traversal > >is sure to affect performance. > > Sure it is. But that is what you get when you want to do something > like L2TP. > I hear ya. I've been floating around a concept in my head of suggesting an extension to the protocol so that when you discover a new link being tunneled to you you "push" the processing of the link back to the NAS that tunneled the primary link to you, so that the NAS can reassemble the original mulilink datagram and tunnel that over to you as one unit. Jeez that sounds worse written out than it did in my head! ;) I'll give you one guess what that starts to sound like... > >(5) Acknowledgement by packet, not by byte. Unlike TCP which has a > byte > >window size, L2TP has a packet window size. > [..] I know we can't really do anything about this one, but it does effect performance I think. I don't think L2TP (or PPTP) is too efficient at utilizing the bandwidth between the LNS and LAC. In part this is because its hands are tied by the need to keep the window sizes small because of the stateful stuff we talked about above. So unlike TCP which can increase performance over high bandwidth/high delay connections, L2TP can't respond as well by increasing the window size -- otherwise it exposes itself to packet loss (which is non-negligible as I've measured before) and the performance problems associated with that. Performance is also affected when their is a mix of small packet and large packet data being tunneled, and the presence of the small packets brings down the overall throughtput of the connection (since small packets eat up as much of the window as large packets). Not much you can do about it, but worth recognizing anyway. Richard. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Richard Shea rshea@BayNetworks.com Bay Networks, Extranet Access 978-266-1011 x210 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 13 17:39:45 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA29072; Fri, 13 Feb 1998 17:39:44 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Feb 1998 17:35:31 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA28944 for ietf-ppp-outgoing; Fri, 13 Feb 1998 17:35:30 -0500 (EST) Received: from chaos.enteka.com (chaos.enteka.com [204.179.107.70]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA28934 for ; Fri, 13 Feb 1998 17:35:22 -0500 (EST) Received: (from philipp@localhost) by chaos.enteka.com (8.8.8/8.8.8) id OAA21896; Fri, 13 Feb 1998 14:35:13 -0800 (PST) Date: Fri, 13 Feb 1998 14:35:13 -0800 (PST) From: "Philip A. Prindeville" Message-Id: <199802132235.OAA21896@chaos.enteka.com> To: brian@lcp.livingston.com, rshea@baynetworks.com Cc: ietf-ppp@merit.edu, l2tp@zendo.com, pmr@flowpoint.com, vandys@cisco.com Subject: Re: LCP renegotiation Sender: owner-ietf-ppp@merit.edu For what it's worth, I also would like to see a "clean" protocol go out the door a couple of weeks later than one that will come back to haunt us. -Philip - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 13 21:02:44 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id VAA02604; Fri, 13 Feb 1998 21:02:19 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Feb 1998 21:00:18 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA02563 for ietf-ppp-outgoing; Fri, 13 Feb 1998 21:00:17 -0500 (EST) Received: from hal.lcp.livingston.com (hal.lcp.livingston.com [158.222.8.12]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA02558 for ; Fri, 13 Feb 1998 21:00:12 -0500 (EST) Received: from [158.222.8.17] (alan.lcp.livingston.com [158.222.8.17]) by hal.lcp.livingston.com (8.8.7/8.8.4) with ESMTP id RAA09080; Fri, 13 Feb 1998 17:56:38 -0800 (PST) X-Sender: brian@hal.lcp.livingston.com Message-Id: In-Reply-To: <34E4C79D.316ED722@BayNetworks.com> References: <199802121817.KAA16252@vandys-pc.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Feb 1998 17:47:49 -0800 To: rshea@BayNetworks.com From: Brian Lloyd Subject: Re: LCP renegotiation Cc: l2tp@zendo.com, ietf working group Sender: owner-ietf-ppp@merit.edu At 14:22 -0800 2/13/98, Richard Shea wrote: >Performance measurements I took in a simulated environment based on >packet loss and latency I measured on the real Internet suggest this is >a problem. Tunneled TCP performance fell off very quickly with increase >in latency between the tunnel endpoints, and I measured packet loss >rates anywhere from barely any to 10% or so on a regular basis. So with >fragmentation causing a packet loss jump from 5% to 10% or 10% to 20% >you see noticable performance degredation. Gee, I didn't know that things had gotten that bad. If I saw 1% packet loss across my network I would be tearing things apart to find the problem. I haven't seen packet loss rates on the order of 10% since my packet radio days. In fact, it was high packet loss rates on the packet radio networks we were building that led Phil Karn to roll his "new" round-trip timing algorithm for TCP. >I should note I took these measurements between a WinNT 4.0 Workstation >PC with PPTP and our implementation of PPTP, so there could have been >implementation-dependent effects here. I would love to have time to do >a simulation, or hopefully with L2TP do cross-vendor tests making the >same measurements, probably across the real live Internet. This is a good point. Here we have some experiential data that implies that packet loss rates are higher than I supposed (maybe this is not news to others). That negates my assumption that the network is sufficiently reliable that the packet loss correction algorithms don't have to be all that efficient because they don't get exercised all that often. A lot of the asumptions we put into PPP originally were that the links over which they would run would be high-reliability digital links with very low bit error rates, e.g. ISDN, T1, etc., or they would be running over modem connections and most modems do error correction (MNP or V.42) thus making them essentially error free also. They either worked well or they didn't work at all. Now we are talking about running PPP over poor reliability virtual links with high packet loss rates and we are going to expect to have to reset the compression dictionaries and lose lots of cypher blocks on a regular basis. If indeed this is the >Of course, if the network is better behaved than the typical Internet >path then this isn't as big of a deal. Yeah, right. I believe that one of the main driving forces behind PPTP, L2F, and L2TP is to allow a company to "wholesale" ports to ISPs and "the Enterprise". The transit network is going to be the Internet in general. (Just what we need when the network is already suffering from congestive collapse is to add a ton more traffic by tunneling all these PPP sessions across the network. Hello! Is anyone thinking about this?) But that is OK. The ISP will just tell its customers that the problems are in the network and they shouldn't be concerned by that fact that they are only getting 20%-30% of their channel capacity. I am sure that the customers will be pleased, accept that information, and go away happy! >> But let's turn this problem around. You have a problem because you >> want to >> use stateful encryption and/or compression algorithms that depend on >> previous data over a transport that is unreliable. Either you accept >> the >> performance hit that comes from losing data and having to resynch your >> compression/encryption engines or you switch to using block cyphers >> and >> per-packet stateless compression. >> > >That would be great, but you are tunneling traffic at the LAC unknown to >the client dialing in, and that client can be doing anything. There is >a huge installed base of stateful compression/encryption implementations >which won't migrate very quickly to stateless until everyone (i.e. >users) upgrades their software to stateless implementations. > >I also remember reading on one of these lists that PPP DES-CBC does >cross-packet chaining which I would consider semi-stateful. Again, this >creates a "double your packet loss" phenomenon. VJ -- same sort of >thing (I know.. "So don't negotiate it"). It seems the CCP compression >algorithms can be done stateless today fairly easily so that is probably >easier to change. I doubt that, with the current crop of modems, anyone would really notice VJ was on or off so I agree, negotiate away. Van wrote his header compression so that TELNET wouldn't be painful over slow modems or over Telebit modems. VJ header compression gets the IP datagrams for TELNET sessions short enough that the Telebit Trailblazer modem isn't triggered into its long packet mode so latency was greatly reduced. >[..] >> >> >(4) Termination of multilink on the LNS. Just like IP fragmentation, >> >multilink terminated at the LNS increases probability of datagram loss. >> >Also, the timing of link-packet reception due to the network traversal >> >is sure to affect performance. >> >> Sure it is. But that is what you get when you want to do something >> like L2TP. > >I hear ya. I've been floating around a concept in my head of suggesting >an extension to the protocol so that when you discover a new link being >tunneled to you you "push" the processing of the link back to the NAS >that tunneled the primary link to you, so that the NAS can reassemble >the original mulilink datagram and tunnel that over to you as one unit. >Jeez that sounds worse written out than it did in my head! ;) I'll give >you one guess what that starts to sound like... It sounds like the way that Livingston does multi-chassis MP. Gee, it also sounds like pushing the link processing back to the LAC. Next you are going to suggest that we just push all the PPP processing back to the LAC and just tunnel the IP datagrams. Well, that *would* be a solution to L2TP but I don't think that is what we are shooting for here. ;^) > >> >(5) Acknowledgement by packet, not by byte. Unlike TCP which has a byte >> >window size, L2TP has a packet window size. >> >[..] > >I know we can't really do anything about this one, but it does effect >performance I think. I don't think L2TP (or PPTP) is too efficient at >utilizing the bandwidth between the LNS and LAC. In part this is >because its hands are tied by the need to keep the window sizes small >because of the stateful stuff we talked about above. So unlike TCP >which can increase performance over high bandwidth/high delay >connections, L2TP can't respond as well by increasing the window size -- >otherwise it exposes itself to packet loss (which is non-negligible as >I've measured before) and the performance problems associated with that. > >Performance is also affected when their is a mix of small packet and >large packet data being tunneled, and the presence of the small packets >brings down the overall throughtput of the connection (since small >packets eat up as much of the window as large packets). Not much you >can do about it, but worth recognizing anyway. OK, L2TP is a bad idea and we should do something else. Case closed. Uh, I don't think you are going to sell that one around here. :^) Let's get back on track and see what we can do to make L2TP work as well as it possibly can. Brian Lloyd Lucent Technologies brian@lcp.livingston.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6399 - voice +1.530.676.3442 - fax O- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 13 21:52:36 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id VAA03187; Fri, 13 Feb 1998 21:52:34 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Feb 1998 21:52:18 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA03162 for ietf-ppp-outgoing; Fri, 13 Feb 1998 21:52:17 -0500 (EST) Received: from chaos.enteka.com (chaos.enteka.com [204.179.107.70]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA03158 for ; Fri, 13 Feb 1998 21:52:12 -0500 (EST) Received: (from philipp@localhost) by chaos.enteka.com (8.8.8/8.8.8) id SAA00427; Fri, 13 Feb 1998 18:52:03 -0800 (PST) Date: Fri, 13 Feb 1998 18:52:03 -0800 (PST) From: "Philip A. Prindeville" Message-Id: <199802140252.SAA00427@chaos.enteka.com> To: brian@lcp.livingston.com, rshea@baynetworks.com Cc: ietf-ppp@merit.edu, l2tp@zendo.com, pmr@flowpoint.com, vandys@cisco.com Subject: Re: LCP renegotiation Sender: owner-ietf-ppp@merit.edu I think it is also worh noting that the IETF could be sidelined if they stop being relevant. As long as people believe that what the collective wisdom of the IETF is greater than that of any single vendor, people will be biased (in a positive way) to standards put forth by the IETF. The moment we start cranking out sloppy work just to get something out in a timely fashion, we lose any advantage we might have had over vendors and their proprietary solutions. I know from my own experience purchasing equipment at France Telecom that I was always hesitant to go with a vendor-specific protocol unless it was *really* clearly head-and-shoulders above the rest (i.e. EIGRP). Or am I just being pompous? -Philip - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 13 21:59:00 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id VAA03267; Fri, 13 Feb 1998 21:58:59 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Feb 1998 21:58:48 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA03245 for ietf-ppp-outgoing; Fri, 13 Feb 1998 21:58:48 -0500 (EST) Received: from ntserver.newoak.com ([146.115.61.251]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA03241 for ; Fri, 13 Feb 1998 21:58:44 -0500 (EST) Received: from rshea ([10.0.1.243]) by ntserver.newoak.com (Netscape Mail Server v2.02) with ESMTP id AAA189; Fri, 13 Feb 1998 21:59:02 -0500 Message-ID: <34E50830.4158406A@BayNetworks.com> Date: Fri, 13 Feb 1998 21:57:52 -0500 From: Richard Shea Reply-To: rshea@BayNetworks.com Organization: Bay Networks X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: l2tp@zendo.com, ietf working group Subject: Re: LCP renegotiation X-Priority: 3 (Normal) References: <199802121817.KAA16252@vandys-pc.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Brian Lloyd wrote: > > At 14:22 -0800 2/13/98, Richard Shea wrote: > [..] > > Gee, I didn't know that things had gotten that bad. If I saw 1% > packet > loss across my network I would be tearing things apart to find the > problem. > I haven't seen packet loss rates on the order of 10% since my packet > radio > days. In fact, it was high packet loss rates on the packet radio > networks > we were building that led Phil Karn to roll his "new" round-trip > timing > algorithm for TCP. > The current internet packet loss rates are all over the map and can be horrendous (especially intermittently). Especially if the traffic has to go from one providers network to the other and they don't have a partner agreement. Then the traffic goes to the MAE's where I think the problems (latency and packet loss) are the worst. [..] > > A lot of the asumptions we put into PPP originally were that > the links over which they would run would be high-reliability digital > links with very low bit error rates, e.g. ISDN, T1, etc., or they > would > be running over modem connections and most modems do error correction > (MNP or V.42) thus making them essentially error free also. They > either > worked well or they didn't work at all. Now we are talking about > running > PPP over poor reliability virtual links with high packet loss rates > and we > are going to expect to have to reset the compression dictionaries and > lose > lots of cypher blocks on a regular basis. If indeed this is the > You trailed off here, but I can imagine what was coming.. ;) [..] > Let's get back on track and see what we can do to make L2TP work as > well > as it possibly can. > Let's. Knowing the limitations and problems we can go after the solutions. I think intractable problems are worth knowing about, hence me diversion into the ack of byte vs. packet business. Perhaps everyone was already aware of the issues I was bringing up, and if so I apologize to both mailing lists for wasting their collective time the latter half of this week. I think the lack of a difinitive answer to the problems posed is justification for the discussion however. I also suggest this be the last email sent to BOTH ietf-ppp and to l2tp, and we move this to l2tp-only. Anyone interested in the continuation of the l2tp protocol can move onto that list. l2tp-request@zendo.com, message body: subscribe. Richard. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Richard Shea rshea@BayNetworks.com Bay Networks, Extranet Access 978-266-1011 x210 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 13 22:20:13 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id WAA03597; Fri, 13 Feb 1998 22:20:10 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Feb 1998 22:19:25 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id WAA03558 for ietf-ppp-outgoing; Fri, 13 Feb 1998 22:19:23 -0500 (EST) Received: from chaos.enteka.com (chaos.enteka.com [204.179.107.70]) by merit.edu (8.8.7/8.8.5) with ESMTP id WAA03554 for ; Fri, 13 Feb 1998 22:19:17 -0500 (EST) Received: (from philipp@localhost) by chaos.enteka.com (8.8.8/8.8.8) id TAA00552; Fri, 13 Feb 1998 19:19:15 -0800 (PST) Date: Fri, 13 Feb 1998 19:19:15 -0800 (PST) From: "Philip A. Prindeville" Message-Id: <199802140319.TAA00552@chaos.enteka.com> To: brian@lcp.livingston.com, rshea@baynetworks.com Cc: ietf-ppp@merit.edu, l2tp@zendo.com Subject: Re: LCP renegotiation Sender: owner-ietf-ppp@merit.edu > Date: Fri, 13 Feb 1998 17:47:49 -0800 > To: rshea@baynetworks.com > From: Brian Lloyd > Subject: Re: LCP renegotiation > Cc: l2tp@zendo.com, ietf working group > At 14:22 -0800 2/13/98, Richard Shea wrote: > >Performance measurements I took in a simulated environment based on > >packet loss and latency I measured on the real Internet suggest this is > >a problem. Tunneled TCP performance fell off very quickly with increase > >in latency between the tunnel endpoints, and I measured packet loss > >rates anywhere from barely any to 10% or so on a regular basis. So with > >fragmentation causing a packet loss jump from 5% to 10% or 10% to 20% > >you see noticable performance degredation. > Gee, I didn't know that things had gotten that bad. If I saw 1% packet > loss across my network I would be tearing things apart to find the problem. > I haven't seen packet loss rates on the order of 10% since my packet radio > days. In fact, it was high packet loss rates on the packet radio networks > we were building that led Phil Karn to roll his "new" round-trip timing > algorithm for TCP. I have seen similar data. Especially going through MAE-West or on to Europe through Renater in Paris from San Francisco. But I don't think the LNS and the LAC will be that far apart typically. > >I should note I took these measurements between a WinNT 4.0 Workstation > >PC with PPTP and our implementation of PPTP, so there could have been > >implementation-dependent effects here. I would love to have time to do > >a simulation, or hopefully with L2TP do cross-vendor tests making the > >same measurements, probably across the real live Internet. > This is a good point. Here we have some experiential data that implies > that packet loss rates are higher than I supposed (maybe this is not > news to others). That negates my assumption that the network is > sufficiently reliable that the packet loss correction algorithms don't > have to be all that efficient because they don't get exercised all that > often. > A lot of the asumptions we put into PPP originally were that > the links over which they would run would be high-reliability digital > links with very low bit error rates, e.g. ISDN, T1, etc., or they would > be running over modem connections and most modems do error correction > (MNP or V.42) thus making them essentially error free also. They either > worked well or they didn't work at all. Now we are talking about running > PPP over poor reliability virtual links with high packet loss rates and we > are going to expect to have to reset the compression dictionaries and lose > lots of cypher blocks on a regular basis. If indeed this is the We are working with radio modems in the IMS band (fairly standard) that currently work as reliable links, but this in turn has negative side-effects on TCP running atop these links (if you've ever done IP over X.25, you'll know what I mean): the RTT variance is a bitch. We want to be able to do it in unreliable (datagram) mode when doing PPP over these radios, but then we will see the real loss rates. Around 6pm when people start getting home and powerup their laptops, the traffic on the radio net becomes significant. > >Of course, if the network is better behaved than the typical Internet > >path then this isn't as big of a deal. > Yeah, right. I believe that one of the main driving forces behind PPTP, > L2F, and L2TP is to allow a company to "wholesale" ports to ISPs and > "the Enterprise". The transit network is going to be the Internet in > general. (Just what we need when the network is already suffering from > congestive collapse is to add a ton more traffic by tunneling all these > PPP sessions across the network. Hello! Is anyone thinking about this?) I second that. Corporate customers will probably end up out-sourcing RF coverage from my client. (And yes, we are thinking about it. In most cases, the corporate customer is less than 6 hops away, and these are short hops.) > > But that is OK. The ISP will just tell its customers that the problems > are in the network and they shouldn't be concerned by that fact that > they are only getting 20%-30% of their channel capacity. I am sure that > the customers will be pleased, accept that information, and go away > happy! My only problem with this is that when the customer does a traceroute, the first "hop" is almost the entire network path.... Hmmmm... if we knew how far apart the LNS and LAC were (easy enough to find out), we could simply decrement the TTL of the IP datagram by that value at each end (well, once only for each direction). Do s nest? > >> But let's turn this problem around. You have a problem because you > >> want to > >> use stateful encryption and/or compression algorithms that depend on > >> previous data over a transport that is unreliable. Either you accept > >> the > >> performance hit that comes from losing data and having to resynch your > >> compression/encryption engines or you switch to using block cyphers > >> and > >> per-packet stateless compression. > >> > > > >That would be great, but you are tunneling traffic at the LAC unknown to > >the client dialing in, and that client can be doing anything. There is > >a huge installed base of stateful compression/encryption implementations > >which won't migrate very quickly to stateless until everyone (i.e. > >users) upgrades their software to stateless implementations. > > > >I also remember reading on one of these lists that PPP DES-CBC does > >cross-packet chaining which I would consider semi-stateful. Again, this > >creates a "double your packet loss" phenomenon. VJ -- same sort of > >thing (I know.. "So don't negotiate it"). It seems the CCP compression > >algorithms can be done stateless today fairly easily so that is probably > >easier to change. > I doubt that, with the current crop of modems, anyone would really notice > VJ was on or off so I agree, negotiate away. We've certainly noticed when STAC or MPPC was on! A note: MPPC hasn't been released yet on Ciscos which is what we use predominantly in-house and STAC has an issue between Ciscos and 95 (the Ciscos want EXTENDED and uSoft wants to do SEQUENCED history -- this bug has been around a *long* time and I'm surprised Cisco hasn't fixed it yet). Getting compression to work at all took a lot of tweaking (tweaking that most sites wouldn't be able to do). -Philip > Brian Lloyd Lucent Technologies > brian@lcp.livingston.com 3461 Robin Lane, Suite 1 > http://www.livingston.com Cameron Park, CA 95682 > +1.530.676.6399 - voice +1.530.676.3442 - fax O- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Feb 16 10:24:54 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA05465; Mon, 16 Feb 1998 10:22:49 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 16 Feb 1998 10:17:51 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA05267 for ietf-ppp-outgoing; Mon, 16 Feb 1998 10:17:51 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA05263 for ; Mon, 16 Feb 1998 10:17:47 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA24934; Mon, 16 Feb 1998 10:17:42 -0500 (EST) Message-Id: <199802161517.KAA24934@ns.ietf.org> To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: The IESG SUBJECT: Last Call: The PPP DES Encryption Protocol, Version 2 (DESE-bis) to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Mon, 16 Feb 1998 10:17:42 -0500 Sender: owner-ietf-ppp@merit.edu The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider The PPP DES Encryption Protocol, Version 2 (DESE-bis) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 2, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-des-encrypt-v2-01.txt - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Feb 16 10:50:44 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA06320; Mon, 16 Feb 1998 10:49:22 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 16 Feb 1998 10:49:09 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA06289 for ietf-ppp-outgoing; Mon, 16 Feb 1998 10:49:08 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA06283 for ; Mon, 16 Feb 1998 10:49:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA26491; Mon, 16 Feb 1998 10:48:58 -0500 (EST) Message-Id: <199802161548.KAA26491@ns.ietf.org> To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: The IESG SUBJECT: Last Call: The PPP Triple-DES Encryption Protocol (3DESE) to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Mon, 16 Feb 1998 10:48:57 -0500 Sender: owner-ietf-ppp@merit.edu The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider The PPP Triple-DES Encryption Protocol (3DESE) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 2, 1998. Files can be obtained via ftp://dftp.ietf.org/internet-drafts/draft-ietf-pppext-3des-encrypt-00.txt - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Feb 16 12:41:54 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA10588; Mon, 16 Feb 1998 12:41:46 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 16 Feb 1998 12:41:01 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA10528 for ietf-ppp-outgoing; Mon, 16 Feb 1998 12:41:00 -0500 (EST) Received: from mail.sprint.com (mail.sprint.com [208.4.29.129]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA10514 for ; Mon, 16 Feb 1998 12:40:37 -0500 (EST) Received: from sii01.mail.sprint.com ([192.251.141.141]) by bastion.mail.sprint.com with ESMTP id <16284>; Mon, 16 Feb 1998 11:37:24 -0600 Received: from x400-gw.mail.sprint.com by sii01.mail.sprint.com (X.400 to RFC822 Gateway); Mon, 16 Feb 1998 10:51:08 -0600 X400-Received: by mta MTASprint in /c=US/admd=TELEMAIL/prmd=Sprint/; Relayed; 16 Feb 1998 10:50:54 -0600 X400-Received: by /c=US/admd=TELEMAIL/prmd=Sprint/; Relayed; 16 Feb 1998 10:50:54 -0600 X400-MTS-Identifier: [/c=US/admd=TELEMAIL/prmd=Sprint/; 0068D34E86E6E0EC-MTASprint] Content-Identifier: 0068D34E86E6E0EC Content-Return: Allowed X400-Content-Type: P2-1988 ( 22 ) Conversion: Allowed Original-Encoded-Information-Types: IA5-Text Disclose-Recipients: Prohibited Alternate-Recipient: Allowed X400-Originator: Linn.Johnson@mail.sprint.com X400-Recipients: non-disclosure; Message-Id: <"0068D34E86E6E0EC*/c=us/admd=Telemail/prmd=Sprint/o=QM/ou=QM(u)1850(u)1/s=Johnson/g=Linn/"@MHS> Date: Mon, 16 Feb 1998 10:50:54 -0600 From: Linn Johnson To: Naganand Doraswamy (IPM Return requested Receipt notification requested), ietf-ppp (IPM Return requested Receipt notification requested), int-serv (IPM Return requested Receipt notification requested), ipsec (IPM Return requested Receipt notification requested), mpls (IPM Return requested Receipt notification requested) Subject: RE>VPN mailing list Sender: owner-ietf-ppp@merit.edu Reply to: RE>VPN mailing list How do I get off the ietf-ppp mailing list? linn.johnson@mail.sprint.com -------------------------------------- Date: 2/8/98 10:17 To: Linn Johnson From: Naganand Doraswamy I have created VPN mailing list and attached a proposed charter. I would like to start discussion on what the charter of working group should be and what problems we should be working on. We intend to have another BOF at IETF but this time we need to nail down the charter. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Feb 17 14:50:53 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA17120; Tue, 17 Feb 1998 14:49:48 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 17 Feb 1998 14:43:46 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA16993 for ietf-ppp-outgoing; Tue, 17 Feb 1998 14:43:46 -0500 (EST) Received: from santaclara01.pop.internex.net (santaclara01.pop.internex.net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA16985 for ; Tue, 17 Feb 1998 14:43:38 -0500 (EST) Received: from flowpoint.com ([192.84.210.69]) by santaclara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA21086; Tue, 17 Feb 1998 11:41:25 -0800 Received: from localhost (pmr@localhost) by flowpoint.com (8.8.7/8.8.4) with SMTP id LAA20696; Tue, 17 Feb 1998 11:41:31 -0800 Date: Tue, 17 Feb 1998 11:41:30 -0800 (PST) From: Philip Rakity X-Sender: pmr@flowpnt Reply-To: Philip Rakity To: townsley@cisco.com cc: brian@lcp.livingston.com, l2tp@zendo.com, ietf working group Subject: LAC -> LNS Interaction Problem (LCP) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Mark, A number of folks have raised significant issues with L2TP concerning the interaction between the LAC/LNS. I was wondering is you have some suggestions on how we should proceed. I have copied to e-mails below for your information. kind regards, Philip Rakity ============================================================ From pmr@flowpoint.com Tue Feb 17 11:36:26 1998 Date: Thu, 12 Feb 1998 22:54:06 -0800 (PST) From: Philip Rakity To: William Palter Cc: l2tp@zendo.com, ietf-ppp@merit.edu Subject: Re: L2TP - PPP encapsulations and LCP renegotiation Bill, On Thu, 12 Feb 1998, William Palter wrote: > > > I think we are losing a little perspective on what we set out to > do and what we have already achieved. We set out to try and merge L2F and > PPTP incorporating the best features of both, and to get the specification > done quickly so that we would not end up with three standards and need to > support all of them in every implementation (in order to be competitive). > We have also had two successful backoffs in between which we have done > some tweaking to the protocol, the next backoff is scheduled in less than > two weeks. > > > LCP renegotiation really falls into 4 cases, these cases are > > > 1) Client and LAC in the same box, an example of this is > voluntary tunneling in windows NT, in this case the > PPP client should have enough knowledge about the fact that > it is being tunneled thru L2TP that it should negotiate > appropriate options with the LNS (since it knows that there > really is not physical layer PPP session). > > > 2) LAC negotiates LCP and then forwards the session. In this case > the LNS should be able to get enough info from the proxy LCP > info that if it renegotiates LCP it can use options that are > compatible with the LAC. > > > 3) HDLC/AHDLC client dialing into a LAC and being forwarded to > an LNS without LCP being negotiated by the LAC. When this > occurs the LNS needs to be conservative in what it negotiates > with the client, but we have shown inter operability with the > in the past two backoffs. This can be fixed by either passing the MRU information etc to the LNS or specifing options in the specification that make this work. The question is what is the correct approach to resolve the problem; eg DEFINE conservative. > > > 4) non-HDLC type clients connecting to a LAC being forwarded to > an LNS. This is the real sticky case, since the LNS really > has no idea what LCP options to negotiate with the client, > but I think that if the LNS is conservative in what it does > and takes some hints from the client, we should be able to > inter-operate. We really haven't had any experience in the > previous backoffs with this case. > > > > As for framing in the data packets, we choose basicly the HDLC > type framing that most PPP clients support with the assumption that > LACs could do some simple framing conversion if it were needed, if > we had to do it again I believe that we probably would have chosen > to strip the 0xff 0x03, move the protocol field into the L2TP header, > and just send the data part of the PPP packet, if we knew then what > we know now. But changing this now would break a lot of the interop > that we have already done. This the problem that the interoperability testing is supposed to show up. Why not define the message flow between the LAC and LNS that are needed to fix this problem, then define the default action, that occurs when NO messages are passed. The default action maps the current implementations and the messages define the action that a full function LAC/LNS will implement. The interoperability test session can validate the draft without the message exchange. If we add text to the draft NOW to handle the message exchange, then some of us might be able to test this at the interoperability test session. (We are prepared to put code into our system to deal with this), and if we can interoperate with other folks, then we can move the draft towards an RFC number. > > > If we decide at this point to go back and try to build a protocol > that can tunnel and support every possible combination of LCP options > (such as different FCSes or COBS or anything else that maybe dreamt > up) we will end up needing a few more backoffs and probably will end > up publishing this draft after its usefulness has passed. > > > Bill Palter From brian@lcp.livingston.com Tue Feb 17 11:36:54 1998 Date: Fri, 13 Feb 1998 10:20:00 -0800 From: Brian Lloyd To: l2tp@zendo.com, ietf-ppp@merit.edu Subject: Re: L2TP - PPP encapsulations and LCP renegotiation At 21:58 -0800 2/12/98, William Palter wrote: Everything you have written up to here makes sense to me. > As for framing in the data packets, we choose basicly the HDLC > type framing that most PPP clients support with the assumption that > LACs could do some simple framing conversion if it were needed, if > we had to do it again I believe that we probably would have chosen > to strip the 0xff 0x03, move the protocol field into the L2TP header, > and just send the data part of the PPP packet, if we knew then what > we know now. But changing this now would break a lot of the interop > that we have already done. You just stated the key factor, "if we knew then what we know now." OK, you know it now. You know that the assumptions originally made were flawed. You know where the flaw is. FIX IT! Don't screw around moaning about interoperability testing that has already been done. FIX IT! DO IT RIGHT! Then go back and do new interoperability testing. That is how you end up with good protocols with logical, straight-forward implementations instead of hacked up kludges that don't always converge, aren't likely to interoperate without case-by-case tweaking, and won't adapt to new technologies when the appear. Failure to "do the right thing" is a support nightmare. > If we decide at this point to go back and try to build a protocol > that can tunnel and support every possible combination of LCP options > (such as different FCSes or COBS or anything else that maybe dreamt > up) we will end up needing a few more backoffs and probably will end > up publishing this draft after its usefulness has passed. What is going on here? Do we have marketing people running the IETF instead of engineers who write code? (Gawd, I am starting to sound like Bill Simpson. Someone please shoot me now.) Is the new attitude, "it is more important to get it out than to get it right?" Yeah, I guess it then becomes the customer's problem. Well, I believe that it should be possible to define the protocol generally correctly in a week or two. We will need a couple of implementations to do preliminary testing which may result in tweaking the protocol. We get a few more people to implement the tweaked protocol and we do another bake-off. So you are worried about the different kinds of point-to-point framing you may run into out there and and in the future. If that is your concern, then isolate the framing to the link layer and don't propagate that back up the stack to the network layer. Now if someone comes up with a new way of framing data over the link, the network layer doesn't need to worry about it. Problem solved. OK, how about it stated in more detail. The problem is that the LNS really shouldn't have to know about what is going on down at the LCP layer. The LAC and the remote host negotiate the framing options because they know what the hardware looks like and know the requirements for the local link. Once that happens the LCP layer in the LAC communicates with the authentication/MP/NCP layers (phases?) in the LNS via L2TP and says, "you have a good pipe over which you may exchange packets with the remote client." Now your PPP "network layer" packets consist of a PPP payload preceeded by a protocol ID field. There is no framing cruft that needs to go back and forth because the envelope you are using; e.g. UDP, FR, or X.25; provides complete delineation of the payload boundaries. So if you don't need to send extra cruft, don't send it. The fly in this ointment is the fact that the LCP layer also offers the MP MMRU option to indicate that the virtual NAS (I want some different name here to denote the system that is the logical fusion of LNS and LAC) offers and supports MP. That means that the LAC needs to know ahead of time that the LNS is prepared to support MP. I had this ugly little feeling in the pit of my stomach several years ago that piggybacking the MP option as part of the LCP negotiation (read "gross violation of layering") would come back and bite me some day. And let me reiterate one thing: just because you have code ready to ship doesn't mean that you should ship it if it is wrong or that you won't ship updates becuase you have learned something new or better. Think about it, solve the problems, roll new code, and then test it. Repeat until it is right. Where the heck is our WG chaircritter? Karl, you should be doing this yelling about the meta issues, not me. You've been there. Please tell them; how many times did you change your PPP code at Morningstar while we were working out the problems with the base PPP spec? How many times did you ship updates to your customers because we discovered that we needed to change something based on experiential data? Folks, just because you have code out there doesn't mean you can't change your code for the better. Do you best to support backward compatibility but don't be slavish about it. If you have to abandon an older version of a protocol because it is completely incompatible with the correct version of a protocol, sobeit. I apologize for jumping back and forth between the technical issue(s) and the meta issue. This message was stream of consiousness. Hopefully this makes sense to people. Brian Lloyd Lucent Technologies brian@lcp.livingston.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6399 - voice +1.530.676.3442 - fax O- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Feb 17 16:02:26 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA18959; Tue, 17 Feb 1998 16:02:13 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 17 Feb 1998 16:00:09 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA18890 for ietf-ppp-outgoing; Tue, 17 Feb 1998 16:00:08 -0500 (EST) Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA18880 for ; Tue, 17 Feb 1998 16:00:01 -0500 (EST) Received: from claret.cisco.com (claret.cisco.com [171.69.160.39]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with SMTP id MAA06367; Tue, 17 Feb 1998 12:55:50 -0800 (PST) Date: Tue, 17 Feb 1998 15:55:50 -0500 (EST) From: "W. Mark Townsley" Reply-To: "W. Mark Townsley" To: Philip Rakity cc: brian@lcp.livingston.com, l2tp@zendo.com, ietf working group Subject: Re: LAC -> LNS Interaction Problem (LCP) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Tue, 17 Feb 1998, Philip Rakity wrote: > > Mark, > > A number of folks have raised significant issues with L2TP concerning the > interaction between the LAC/LNS. I was wondering is you have some > suggestions on how we should proceed. Phillip, I am well aware of the issues that have been raised recently. While away last week, I left my voice on draft issues in the capable hands of Andy and Bill. I have been giving some of these issues more thought since my return and would like to come up with something that is workable but does not derail the spec. I consider the latter of signifigant importance. How should we proceed? As we always do, by writing code, getting together, and giving things a whirl. We have overcome more signifigant problems in the past, and assuming it does not float away in the rainstorms, we will all be in San Francisco next week to talk about them in person. In general, I think it foolish to change the spec one or two weeks before an interoperability bakeoff. We have had months, even years, to discuss these items. It is bothersome that they are appearing this late in the game. As has been stated, at some point you have to bite the bullet and move on. I would also echo Richard's remarks that some of the items discussed this past week are intractable by nature and as such are important to be noted, but do not affect the protocol message exchange per se. On these items, I think enough has been said. - Mark > > I have copied to e-mails below for your information. > > kind regards, > > Philip Rakity > > > ============================================================ > >From pmr@flowpoint.com Tue Feb 17 11:36:26 1998 > Date: Thu, 12 Feb 1998 22:54:06 -0800 (PST) > From: Philip Rakity > To: William Palter > Cc: l2tp@zendo.com, ietf-ppp@merit.edu > Subject: Re: L2TP - PPP encapsulations and LCP renegotiation > > > Bill, > > On Thu, 12 Feb 1998, William Palter wrote: > > > > > > > I think we are losing a little perspective on what we set out to > > do and what we have already achieved. We set out to try and merge L2F and > > PPTP incorporating the best features of both, and to get the specification > > done quickly so that we would not end up with three standards and need to > > support all of them in every implementation (in order to be competitive). > > We have also had two successful backoffs in between which we have done > > some tweaking to the protocol, the next backoff is scheduled in less than > > two weeks. > > > > > > LCP renegotiation really falls into 4 cases, these cases are > > > > > > 1) Client and LAC in the same box, an example of this is > > voluntary tunneling in windows NT, in this case the > > PPP client should have enough knowledge about the fact that > > it is being tunneled thru L2TP that it should negotiate > > appropriate options with the LNS (since it knows that there > > really is not physical layer PPP session). > > > > > > 2) LAC negotiates LCP and then forwards the session. In this case > > the LNS should be able to get enough info from the proxy LCP > > info that if it renegotiates LCP it can use options that are > > compatible with the LAC. > > > > > > 3) HDLC/AHDLC client dialing into a LAC and being forwarded to > > an LNS without LCP being negotiated by the LAC. When this > > occurs the LNS needs to be conservative in what it negotiates > > with the client, but we have shown inter operability with the > > in the past two backoffs. > > > This can be fixed by either passing the MRU information etc to the LNS or > specifing options in the specification that make this work. The question > is what is the correct approach to resolve the problem; eg DEFINE > conservative. > > > > > > > > 4) non-HDLC type clients connecting to a LAC being forwarded to > > an LNS. This is the real sticky case, since the LNS really > > has no idea what LCP options to negotiate with the client, > > but I think that if the LNS is conservative in what it does > > and takes some hints from the client, we should be able to > > inter-operate. We really haven't had any experience in the > > previous backoffs with this case. > > > > > > > > As for framing in the data packets, we choose basicly the HDLC > > type framing that most PPP clients support with the assumption that > > LACs could do some simple framing conversion if it were needed, if > > we had to do it again I believe that we probably would have chosen > > to strip the 0xff 0x03, move the protocol field into the L2TP header, > > and just send the data part of the PPP packet, if we knew then what > > we know now. But changing this now would break a lot of the interop > > that we have already done. > > > > This the problem that the interoperability testing is supposed to > show up. > > > Why not define the message flow between the LAC and LNS that are > needed to fix this problem, then define the default action, that occurs > when NO messages are passed. The default action maps the current > implementations and the messages define the action that a full function > LAC/LNS will implement. The interoperability test session can validate > the draft without the message exchange. If we add text to the draft NOW > to handle the message exchange, then some of us might be able to test this > at the interoperability test session. (We are prepared to put code into > our system to deal with this), and if we can interoperate with other > folks, then we can move the draft towards an RFC number. > > > > > > > > If we decide at this point to go back and try to build a protocol > > that can tunnel and support every possible combination of LCP options > > (such as different FCSes or COBS or anything else that maybe dreamt > > up) we will end up needing a few more backoffs and probably will end > > up publishing this draft after its usefulness has passed. > > > > > > Bill Palter > > > > >From brian@lcp.livingston.com Tue Feb 17 11:36:54 1998 > Date: Fri, 13 Feb 1998 10:20:00 -0800 > From: Brian Lloyd > To: l2tp@zendo.com, ietf-ppp@merit.edu > Subject: Re: L2TP - PPP encapsulations and LCP renegotiation > > At 21:58 -0800 2/12/98, William Palter wrote: > > Everything you have written up to here makes sense to me. > > > As for framing in the data packets, we choose basicly the HDLC > > type framing that most PPP clients support with the assumption that > > LACs could do some simple framing conversion if it were needed, if > > we had to do it again I believe that we probably would have chosen > > to strip the 0xff 0x03, move the protocol field into the L2TP header, > > and just send the data part of the PPP packet, if we knew then what > > we know now. But changing this now would break a lot of the interop > > that we have already done. > > You just stated the key factor, "if we knew then what we know now." OK, > you know it now. You know that the assumptions originally made were > flawed. You know where the flaw is. FIX IT! Don't screw around moaning > about interoperability testing that has already been done. FIX IT! DO IT > RIGHT! Then go back and do new interoperability testing. That is how you > end up with good protocols with logical, straight-forward implementations > instead of hacked up kludges that don't always converge, aren't likely to > interoperate without case-by-case tweaking, and won't adapt to new > technologies when the appear. Failure to "do the right thing" is a support > nightmare. > > > If we decide at this point to go back and try to build a protocol > > that can tunnel and support every possible combination of LCP options > > (such as different FCSes or COBS or anything else that maybe dreamt > > up) we will end up needing a few more backoffs and probably will end > > up publishing this draft after its usefulness has passed. > > What is going on here? Do we have marketing people running the IETF > instead of engineers who write code? (Gawd, I am starting to sound like > Bill Simpson. Someone please shoot me now.) Is the new attitude, "it is > more important to get it out than to get it right?" Yeah, I guess it then > becomes the customer's problem. > > Well, I believe that it should be possible to define the protocol generally > correctly in a week or two. We will need a couple of implementations to do > preliminary testing which may result in tweaking the protocol. We get a > few more people to implement the tweaked protocol and we do another > bake-off. > > So you are worried about the different kinds of point-to-point framing you > may run into out there and and in the future. If that is your concern, > then isolate the framing to the link layer and don't propagate that back up > the stack to the network layer. Now if someone comes up with a new way of > framing data over the link, the network layer doesn't need to worry about > it. Problem solved. > > OK, how about it stated in more detail. The problem is that the LNS really > shouldn't have to know about what is going on down at the LCP layer. The > LAC and the remote host negotiate the framing options because they know > what the hardware looks like and know the requirements for the local link. > Once that happens the LCP layer in the LAC communicates with the > authentication/MP/NCP layers (phases?) in the LNS via L2TP and says, "you > have a good pipe over which you may exchange packets with the remote > client." Now your PPP "network layer" packets consist of a PPP payload > preceeded by a protocol ID field. There is no framing cruft that needs to > go back and forth because the envelope you are using; e.g. UDP, FR, or > X.25; provides complete delineation of the payload boundaries. So if you > don't need to send extra cruft, don't send it. > > The fly in this ointment is the fact that the LCP layer also offers > the MP MMRU option to indicate that the virtual NAS (I want some different > name here to denote the system that is the logical fusion of LNS and LAC) > offers and supports MP. That means that the LAC needs to know ahead of > time that the LNS is prepared to support MP. I had this ugly little > feeling in the pit of my stomach several years ago that piggybacking the MP > option as part of the LCP negotiation (read "gross violation of layering") > would come back and bite me some day. > > And let me reiterate one thing: just because you have code ready to ship > doesn't mean that you should ship it if it is wrong or that you won't ship > updates becuase you have learned something new or better. Think about it, > solve the problems, roll new code, and then test it. Repeat until it is > right. > > Where the heck is our WG chaircritter? Karl, you should be doing this > yelling about the meta issues, not me. You've been there. Please tell > them; how many times did you change your PPP code at Morningstar while we > were working out the problems with the base PPP spec? How many times did > you ship updates to your customers because we discovered that we needed to > change something based on experiential data? > > Folks, just because you have code out there doesn't mean you can't change > your code for the better. Do you best to support backward compatibility > but don't be slavish about it. If you have to abandon an older version of > a protocol because it is completely incompatible with the correct version > of a protocol, sobeit. > > I apologize for jumping back and forth between the technical issue(s) and > the meta issue. This message was stream of consiousness. Hopefully this > makes sense to people. > > > Brian Lloyd Lucent Technologies > brian@lcp.livingston.com 3461 Robin Lane, Suite 1 > http://www.livingston.com Cameron Park, CA 95682 > +1.530.676.6399 - voice +1.530.676.3442 - fax O- > > > > > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Feb 18 03:57:57 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id DAA04754; Wed, 18 Feb 1998 03:57:46 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 18 Feb 1998 03:55:07 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id DAA04686 for ietf-ppp-outgoing; Wed, 18 Feb 1998 03:55:06 -0500 (EST) Received: from alcatel.fr (news2.alcatel.fr [194.133.58.131]) by merit.edu (8.8.7/8.8.5) with ESMTP id DAA04678 for ; Wed, 18 Feb 1998 03:54:58 -0500 (EST) From: CARLOS.SANCHEZ@telspace.alcatel.fr Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.244]) by mailgate.alcatel.fr (Alcanet/SMTP) with ESMTP id JAA03898; Wed, 18 Feb 1998 09:57:05 +0100 Received: from lune.telspace.alcatel.fr (lune.telspace.alcatel.fr [155.132.144.65]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id JAA09699; Wed, 18 Feb 1998 09:50:10 +0100 (MET) Received: from telss1.telspace.alcatel.fr (telss1.telspace.alcatel.fr [155.132.51.4]) by lune (8.7.6/8.7.3) with SMTP id JAA15575; Wed, 18 Feb 1998 09:52:50 +0100 (MET) Received: from eole.telspace.alcatel.fr by telss1.telspace.alcatel.fr (4.1/SMI-4.1) id AA24066; Wed, 18 Feb 98 09:43:59 +0100 Received: from localhost by eole.telspace.alcatel.fr with SMTP (1.40.112.12/16.2) id AA249161343; Wed, 18 Feb 1998 09:42:23 +0100 X-Openmail-Hops: 1 Date: Wed, 18 Feb 98 09:42:13 +0100 Message-Id: In-Reply-To: Subject: =?ISO-8859-1?Q?R=E9p_:_LAC_->_LNS_Interaction_Problem_(LCP)?= Mime-Version: 1.0 To: pmr@flowpoint.com Cc: brian@lcp.livingston.com, l2tp@zendo.com, ietf-ppp@merit.edu, townsley@cisco.com Content-Type: text/plain; charset=ISO-8859-1; name="LAC" Content-Disposition: inline; filename="LAC" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by merit.edu id DAA04679 Sender: owner-ietf-ppp@merit.edu I think all problem comes from to points: 1- PPP is allowed to renegotiate LCP parameters whenever It wants 2- L2TP is physical medium dependent. Each behavior by itself is not really a problem, but both together .... I see a solution which keep L2TP draft almost like it is and also touches PPP: 1- A new LCP option extension could be introduced. This option forbids new LCP negotiations for all PPP connection life. New LCP parameters imply to close and reopen PPP. 2- AVPs: Initial Received LCP Confreq Last Sent LCP Confreq Last Received LCP Confreq MUST appear in Incomig-Call-Connected message. Last Sent and Received LCP Confreq are modified to include new LCP option forbiding new LCP negotiation. LNS will keep initial parameters negotiated by the LAC. This solution forgets that maybe MRU negotiated by the LAC can not be supported by LNS. In that case LNS should close session suggesting new MRU to the LAC, This MRU value should be borne in mind by the LAC in the next LCP negotiation. IMHO Carlos ____________________________ Séparateur Réponse ________________________________ Objet : LAC -> LNS Interaction Problem (LCP) Auteur : pmr (pmr@flowpoint.com) à SMTP Date : 17/02/98 20:41 Mark, A number of folks have raised significant issues with L2TP concerning the interaction between the LAC/LNS. I was wondering is you have some suggestions on how we should proceed. I have copied to e-mails below for your information. kind regards, Philip Rakity ============================================================ From pmr@flowpoint.com Tue Feb 17 11:36:26 1998 Date: Thu, 12 Feb 1998 22:54:06 -0800 (PST) From: Philip Rakity To: William Palter Cc: l2tp@zendo.com, ietf-ppp@merit.edu Subject: Re: L2TP - PPP encapsulations and LCP renegotiation Bill, On Thu, 12 Feb 1998, William Palter wrote: > > > I think we are losing a little perspective on what we set out to > do and what we have already achieved. We set out to try and merge L2F and > PPTP incorporating the best features of both, and to get the specification > done quickly so that we would not end up with three standards and need to > support all of them in every implementation (in order to be competitive). > We have also had two successful backoffs in between which we have done > some tweaking to the protocol, the next backoff is scheduled in less than > two weeks. > > > LCP renegotiation really falls into 4 cases, these cases are > > > 1) Client and LAC in the same box, an example of this is > voluntary tunneling in windows NT, in this case the > PPP client should have enough knowledge about the fact that > it is being tunneled thru L2TP that it should negotiate > appropriate options with the LNS (since it knows that there > really is not physical layer PPP session). > > > 2) LAC negotiates LCP and then forwards the session. In this case > the LNS should be able to get enough info from the proxy LCP > info that if it renegotiates LCP it can use options that are > compatible with the LAC. > > > 3) HDLC/AHDLC client dialing into a LAC and being forwarded to > an LNS without LCP being negotiated by the LAC. When this > occurs the LNS needs to be conservative in what it negotiates > with the client, but we have shown inter operability with the > in the past two backoffs. This can be fixed by either passing the MRU information etc to the LNS or specifing options in the specification that make this work. The question is what is the correct approach to resolve the problem; eg DEFINE conservative. > > > 4) non-HDLC type clients connecting to a LAC being forwarded to > an LNS. This is the real sticky case, since the LNS really > has no idea what LCP options to negotiate with the client, > but I think that if the LNS is conservative in what it does > and takes some hints from the client, we should be able to > inter-operate. We really haven't had any experience in the > previous backoffs with this case. > > > > As for framing in the data packets, we choose basicly the HDLC > type framing that most PPP clients support with the assumption that > LACs could do some simple framing conversion if it were needed, if > we had to do it again I believe that we probably would have chosen > to strip the 0xff 0x03, move the protocol field into the L2TP header, > and just send the data part of the PPP packet, if we knew then what > we know now. But changing this now would break a lot of the interop > that we have already done. This the problem that the interoperability testing is supposed to show up. Why not define the message flow between the LAC and LNS that are needed to fix this problem, then define the default action, that occurs when NO messages are passed. The default action maps the current implementations and the messages define the action that a full function LAC/LNS will implement. The interoperability test session can validate the draft without the message exchange. If we add text to the draft NOW to handle the message exchange, then some of us might be able to test this at the interoperability test session. (We are prepared to put code into our system to deal with this), and if we can interoperate with other folks, then we can move the draft towards an RFC number. > > > If we decide at this point to go back and try to build a protocol > that can tunnel and support every possible combination of LCP options > (such as different FCSes or COBS or anything else that maybe dreamt > up) we will end up needing a few more backoffs and probably will end > up publishing this draft after its usefulness has passed. > > > Bill Palter From brian@lcp.livingston.com Tue Feb 17 11:36:54 1998 Date: Fri, 13 Feb 1998 10:20:00 -0800 From: Brian Lloyd To: l2tp@zendo.com, ietf-ppp@merit.edu Subject: Re: L2TP - PPP encapsulations and LCP renegotiation At 21:58 -0800 2/12/98, William Palter wrote: Everything you have written up to here makes sense to me. > As for framing in the data packets, we choose basicly the HDLC > type framing that most PPP clients support with the assumption that > LACs could do some simple framing conversion if it were needed, if > we had to do it again I believe that we probably would have chosen > to strip the 0xff 0x03, move the protocol field into the L2TP header, > and just send the data part of the PPP packet, if we knew then what > we know now. But changing this now would break a lot of the interop > that we have already done. You just stated the key factor, "if we knew then what we know now." OK, you know it now. You know that the assumptions originally made were flawed. You know where the flaw is. FIX IT! Don't screw around moaning about interoperability testing that has already been done. FIX IT! DO IT RIGHT! Then go back and do new interoperability testing. That is how you end up with good protocols with logical, straight-forward implementations instead of hacked up kludges that don't always converge, aren't likely to interoperate without case-by-case tweaking, and won't adapt to new technologies when the appear. Failure to "do the right thing" is a support nightmare. > If we decide at this point to go back and try to build a protocol > that can tunnel and support every possible combination of LCP options > (such as different FCSes or COBS or anything else that maybe dreamt > up) we will end up needing a few more backoffs and probably will end > up publishing this draft after its usefulness has passed. What is going on here? Do we have marketing people running the IETF instead of engineers who write code? (Gawd, I am starting to sound like Bill Simpson. Someone please shoot me now.) Is the new attitude, "it is more important to get it out than to get it right?" Yeah, I guess it then becomes the customer's problem. Well, I believe that it should be possible to define the protocol generally correctly in a week or two. We will need a couple of implementations to do preliminary testing which may result in tweaking the protocol. We get a few more people to implement the tweaked protocol and we do another bake-off. So you are worried about the different kinds of point-to-point framing you may run into out there and and in the future. If that is your concern, then isolate the framing to the link layer and don't propagate that back up the stack to the network layer. Now if someone comes up with a new way of framing data over the link, the network layer doesn't need to worry about it. Problem solved. OK, how about it stated in more detail. The problem is that the LNS really shouldn't have to know about what is going on down at the LCP layer. The LAC and the remote host negotiate the framing options because they know what the hardware looks like and know the requirements for the local link. Once that happens the LCP layer in the LAC communicates with the authentication/MP/NCP layers (phases?) in the LNS via L2TP and says, "you have a good pipe over which you may exchange packets with the remote client." Now your PPP "network layer" packets consist of a PPP payload preceeded by a protocol ID field. There is no framing cruft that needs to go back and forth because the envelope you are using; e.g. UDP, FR, or X.25; provides complete delineation of the payload boundaries. So if you don't need to send extra cruft, don't send it. The fly in this ointment is the fact that the LCP layer also offers the MP MMRU option to indicate that the virtual NAS (I want some different name here to denote the system that is the logical fusion of LNS and LAC) offers and supports MP. That means that the LAC needs to know ahead of time that the LNS is prepared to support MP. I had this ugly little feeling in the pit of my stomach several years ago that piggybacking the MP option as part of the LCP negotiation (read "gross violation of layering") would come back and bite me some day. And let me reiterate one thing: just because you have code ready to ship doesn't mean that you should ship it if it is wrong or that you won't ship updates becuase you have learned something new or better. Think about it, solve the problems, roll new code, and then test it. Repeat until it is right. Where the heck is our WG chaircritter? Karl, you should be doing this yelling about the meta issues, not me. You've been there. Please tell them; how many times did you change your PPP code at Morningstar while we were working out the problems with the base PPP spec? How many times did you ship updates to your customers because we discovered that we needed to change something based on experiential data? Folks, just because you have code out there doesn't mean you can't change your code for the better. Do you best to support backward compatibility but don't be slavish about it. If you have to abandon an older version of a protocol because it is completely incompatible with the correct version of a protocol, sobeit. I apologize for jumping back and forth between the technical issue(s) and the meta issue. This message was stream of consiousness. Hopefully this makes sense to people. Brian Lloyd Lucent Technologies brian@lcp.livingston.com 3461 Robin Lane, Suite 1 http://www.livingston.com Cameron Park, CA 95682 +1.530.676.6399 - voice +1.530.676.3442 - fax O- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Feb 18 08:53:01 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA09198; Wed, 18 Feb 1998 08:52:24 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 18 Feb 1998 08:48:58 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA09142 for ietf-ppp-outgoing; Wed, 18 Feb 1998 08:48:57 -0500 (EST) Received: from ntserver.newoak.com ([146.115.61.251]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA09138 for ; Wed, 18 Feb 1998 08:48:53 -0500 (EST) Received: from rshea ([10.0.1.243]) by ntserver.newoak.com (Netscape Mail Server v2.02) with ESMTP id AAA222 for ; Wed, 18 Feb 1998 08:49:49 -0500 Message-ID: <34EAE695.25E777C7@BayNetworks.com> Date: Wed, 18 Feb 1998 08:48:05 -0500 From: Richard Shea Reply-To: rshea@BayNetworks.com Organization: Bay Networks X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: Re: Rép : LAC -> LNS Interaction Problem (LCP) X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu CARLOS.SANCHEZ@telspace.alcatel.fr wrote: > [..] Note: I answered this email on the L2TP list but didn't copy ietf-ppp in order to contain the conversation and cut down on repeat emails for most of the people involved. Richard. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Richard Shea rshea@BayNetworks.com Bay Networks, Extranet Access 978-266-1011 x210 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Feb 18 09:51:54 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA10345; Wed, 18 Feb 1998 09:51:49 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 18 Feb 1998 09:51:12 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA10318 for ietf-ppp-outgoing; Wed, 18 Feb 1998 09:51:12 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA10314 for ; Wed, 18 Feb 1998 09:51:07 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA00745; Wed, 18 Feb 1998 09:51:01 -0500 (EST) Message-Id: <199802181451.JAA00745@ns.ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@merit.edu From: The IESG Subject: Protocol Action: Mobile-IPv4 Configuration Option for PPP IPCP to Proposed Standard Date: Wed, 18 Feb 1998 09:51:01 -0500 Sender: owner-ietf-ppp@merit.edu The IESG has approved the Internet-Draft 'Mobile-IPv4 Configuration Option for PPP IPCP' as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. This document updates (but does not replace) one aspect of RFC 2002. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary Mobile IP defines media-independent procedures by which a Mobile Node can maintain existing transport and application-layer connections despite changing its point-of-attachment to the Internet and without changing its IP address. As currently specified, Mobile IP Foreign Agents which support Mobile Node connections via PPP can do so only by first assigning unique addresses to those Mobile Nodes, defeating one of the primary advantages of Foreign Agents. This document corrects this problem by defining the Mobile-IPv4 Configuration Option to the IPCP and specifies the proper interaction between a mobile node and a peer through which the mobile node connects to the Internet (using PPP). Using this option, two peers can communicate their support for Mobile IP during the IPCP phase of PPP. Working Group Summary The Working Group last call produced no issues with this document. Protocol Quality This document has been reviewed by Jeffrey Burgan and Thomas Narten of the IESG. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Feb 18 15:15:00 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA16701; Wed, 18 Feb 1998 15:14:53 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 18 Feb 1998 15:13:43 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA16654 for ietf-ppp-outgoing; Wed, 18 Feb 1998 15:13:43 -0500 (EST) Received: from chaos.enteka.com (chaos.enteka.com [204.179.107.70]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA16647 for ; Wed, 18 Feb 1998 15:13:38 -0500 (EST) Received: (from philipp@localhost) by chaos.enteka.com (8.8.8/8.8.8) id MAA11666; Wed, 18 Feb 1998 12:12:26 -0800 (PST) Date: Wed, 18 Feb 1998 12:12:26 -0800 (PST) From: "Philip A. Prindeville" Message-Id: <199802182012.MAA11666@chaos.enteka.com> To: CARLOS.SANCHEZ@telspace.alcatel.fr, pmr@flowpoint.com Cc: brian@lcp.livingston.com, ietf-ppp@merit.edu, l2tp@zendo.com, townsley@cisco.com Subject: Re: =?ISO-8859-1?Q?R=E9p_:_LAC_->_LNS_Interaction_Problem_(LCP)?= Sender: owner-ietf-ppp@merit.edu > From: CARLOS.SANCHEZ@telspace.alcatel.fr > Date: Wed, 18 Feb 98 09:42:13 +0100 > Subject: =?ISO-8859-1?Q?R=E9p_:_LAC_->_LNS_Interaction_Problem_(LCP)?= > To: pmr@flowpoint.com > Cc: brian@lcp.livingston.com, l2tp@zendo.com, ietf-ppp@merit.edu, > townsley@cisco.com > I think all problem comes from to points: > > 1- PPP is allowed to renegotiate LCP parameters whenever It wants > > 2- L2TP is physical medium dependent. > > Each behavior by itself is not really a problem, but both together .... > > I see a solution which keep L2TP draft almost like it is and also > touches PPP: > > 1- A new LCP option extension could be introduced. This option > forbids new LCP negotiations for all PPP connection life. New LCP > parameters imply to close and reopen PPP. I think that anything that requires changes to the end-user's machine is unrealistic. The amount of time taken to update the millions of machines out there (some of which are undoubtedly still running Windows 3.11, or MacOS 6.0) is too long. And an important property of this protocol has been that, barring severe network degradation between the LNS and the LAC, that its presence should be transparent. > > 2- AVPs: > > Initial Received LCP Confreq > Last Sent LCP Confreq > Last Received LCP Confreq Hmmmm... Reminds me of L2F. (Just out of curiousity, who many of you out there implemented L2F? Pls. mail me off-line if you did.) > MUST appear in Incomig-Call-Connected message. This I could live with. > Last Sent and Received LCP Confreq are modified to include new LCP > option forbiding new LCP negotiation. LNS will keep initial parameters > negotiated by the LAC. This, on the other hand, no. > This solution forgets that maybe MRU negotiated by the LAC can not > be supported by LNS. In that case LNS should close session suggesting > new MRU to the LAC, This MRU value should be borne in mind by the LAC > in the next LCP negotiation. You want to carry state over from one call to the next? I don't know about this.... Je ne suis pas du tout sur de cela. -Philip > IMHO > > Carlos - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 19 13:12:21 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA02904; Thu, 19 Feb 1998 13:11:47 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 19 Feb 1998 13:04:19 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA02680 for ietf-ppp-outgoing; Thu, 19 Feb 1998 13:04:18 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA02673 for ; Thu, 19 Feb 1998 13:04:07 -0500 (EST) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id KAA00187; Thu, 19 Feb 1998 10:04:05 -0800 Received: from ascend.com by ascend.com with ESMTP id KAA09714; Thu, 19 Feb 1998 10:04:18 -0800 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id KAA03929; Thu, 19 Feb 1998 10:04:17 -0800 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id KAA21162; Thu, 19 Feb 1998 10:04:01 -0800 Date: Thu, 19 Feb 1998 10:04:01 -0800 Message-Id: <199802191804.KAA21162@gump.eng.ascend.com> From: Karl Fox To: l2tp@zendo.com, ietf-ppp@merit.edu Subject: Various ongoing L2TP controversies Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu I just now finally got caught up with the L2TP mailing list, and I must commend all those who contributed--you have brought up a lot of good points and made some really good suggestions. Although I'm not an L2TP implementor (and thus my judgment may be suspect), I have not yet seen any issues where bits-on-the-wire changes were requested that couldn't be dealt with either with no changes to the protocol or with a later optional facility. That said, I believe there may be a few clarifications and corrections that need to be made; I trust Mark Townsley, Bill Palter and Andy Valencia have been keeping track of these. To those who have said L2TP could have been done better: I agree! I only lament that many of us have been so busy over the last 20 months that we couldn't take the time to review the protocol until it was too late. Which, by the way, it now is. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 19 18:16:53 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA08178; Thu, 19 Feb 1998 18:16:25 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 19 Feb 1998 18:14:48 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA08142 for ietf-ppp-outgoing; Thu, 19 Feb 1998 18:14:47 -0500 (EST) Received: from tbu1.hifn.com (mailman.hifn.com [206.19.120.66]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA08138 for ; Thu, 19 Feb 1998 18:14:43 -0500 (EST) Received: by tbu1.hifn.com with Internet Mail Service (5.0.1458.49) id <1Y4JRQZJ>; Thu, 19 Feb 1998 15:17:47 -0800 Message-ID: <6297CD447F92D11199F5006097BA9D1E02EABF@tbu1.hifn.com> From: Robert Friend To: IETF-PPP Subject: Update rfc1974? Date: Thu, 19 Feb 1998 15:17:44 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Hi All, I have been trying to work with the Microsoft representatives on this issue since the Memphis meeting, but I never received a response. My questions to this group are: 1) Are these 2 issues real issues with the document? 2) Do we want to change the rfc to reflect this updated information on these 2 issues? 3) Is the information below accurate for issue #3? 4) Does anyone know the answers to questions #1 or issue #2 below? Here are the issues: From the Memphis meeting we had an issue with rfc1974, extended mode. Also, I have a question about extended mode. 1) First my question: In section 5. on page 15, it says that extended mode only supports a history count of 1. Does this mean that a history count of 0 will be protocol rejected? Alternatively, can the implementation negotiate a history count of 1 and set the bit-A on every packet? Will either of these 2 approaches break Win 95? 2) From the Memphis meeting in April, there was confusion about how Win95 deals with (or doesn't deal with) protocol field compression (PFC). I don't know if this ever got resolved (I couldn't find any email to document this). So, I thought I would ask you how Win95 deals with PFC. Assuming PFC is negotiated first, then does PFC need to be un-negotiated on the link if extended mode is negotiated? It seems that the second to last paragraph of section 5.1 must change, but I don't know what to change this paragraph to. 3) Lastly, here is the text from Phil Rakity. I don't know if it has been blessed by you [Microsoft]. Could you [Microsoft or PPPEXT] please bless it. ORIGINAL TEXT ============= 5.4. Extended Mode Synchronization Packets may be lost during transfer. If the decompressor maintained coherency count does not match the coherency count received in the compressed packet or if the decompressor detects that a received packet is corrupted, the decompressor drops the packet and sends a CCP Reset-Request packet. The compressor on receiving this packet resets the history buffer and sets the PACKET_FLUSHED bit in the next frame it sends. The decompressor on receiving a packet with its PACKET_FLUSHED bit set, resets its history buffer and sets its coherency count to the one shipped by the compressor in that packet. Thus synchronization is achieved without a Reset-Ack packet. NEW TEXT ======= 5.4. Extended Mode Synchronization Packets may be lost during transfer. If the decompressor maintained coherency count does not match the coherency count received in the compressed packet or if the decompressor detects that a received packet is corrupted, or if the decompressor is waiting for synchronization and the coherency count is correct but the PACKET_FLUSHED bit is not set, the decompressor drops the packet and sends a CCP Reset-Request packet. The compressor on receiving the CCP Reset-Request Packet packet resets the history buffer and sets the PACKET_FLUSHED bit in the next frame it sends. The decompressor on receiving a packet with its PACKET_FLUSHED bit set, resets its history buffer and sets its coherency count to the one shipped by the compressor in that packet. Thus synchronization is achieved without a Reset-Ack packet. Implementation Note: The decompressor should reset the history when a corrupted packet was received (eg no end marker) to ensure that the decompressor is in a well known state and not rely on the protocol to flush the history. P.S. There is a PPP bakeoff by the San Francisco Airport next week. Will there be a Microsoft representative there for a discussion about this? I plan to be there Wednesday & Thursday. I would like to resolve these issues. Thanks, _____________________________________________________________ Robert C. Friend Hi/fn Applications Engineering 5973 Avenida Encinas, Suite 110 voice: (760) 827-4542 Carlsbad, CA 92008 FAX: (760) 827-4577 email: rfriend@hifn.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 20 02:12:49 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id CAA12616; Fri, 20 Feb 1998 02:12:38 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 20 Feb 1998 02:11:10 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id CAA12581 for ietf-ppp-outgoing; Fri, 20 Feb 1998 02:11:09 -0500 (EST) Received: from santaclara01.pop.internex.net (santaclara01.pop.internex.net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id CAA12577 for ; Fri, 20 Feb 1998 02:11:05 -0500 (EST) Received: from flowpoint.com ([192.84.210.69]) by santaclara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA24909; Thu, 19 Feb 1998 23:11:03 -0800 Received: from localhost (pmr@localhost) by flowpoint.com (8.8.7/8.8.4) with SMTP id XAA07623; Thu, 19 Feb 1998 23:11:08 -0800 Date: Thu, 19 Feb 1998 23:11:08 -0800 (PST) From: Philip Rakity X-Sender: pmr@flowpnt To: Robert Friend cc: IETF-PPP Subject: Re: Update rfc1974? In-Reply-To: <6297CD447F92D11199F5006097BA9D1E02EABF@tbu1.hifn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Bob, If you are going to change rfc1974, there is one more item that may need changing. I am not sure if it belongs in rfc1974 or in L2TP, but it certainly belongs somewhere. The problem is that using STAC LZS (type 3) compression, or any compression method that contains a sequence number; is not a good idea if there is a good chance that packets will be dropped (eg: as in tunneling through) the internet. The cost of recovery is very high (reset req, ack, etc). It is better to use STAC 0 (no history). So, where should we put in text about what is recommended. It is certainly is a good idea to require everyone support STAC LZS (as is in the spec), but we need for words that an implementation requesting compression when connected through a tunnel should request STAC 0 (no history). regards, Philip Rakity FlowPoint On Thu, 19 Feb 1998, Robert Friend wrote: > Hi All, > > I have been trying to work with the Microsoft representatives on this > issue since the Memphis meeting, but I never received a response. My > questions to this group are: > > 1) Are these 2 issues real issues with the document? > 2) Do we want to change the rfc to reflect this updated information on > these 2 issues? > 3) Is the information below accurate for issue #3? > 4) Does anyone know the answers to questions #1 or issue #2 below? > > Here are the issues: > > >From the Memphis meeting we had an issue with rfc1974, extended mode. > Also, I have a question about extended mode. > > 1) First my question: In section 5. on page 15, it says that extended > mode only supports a history count of 1. Does this mean that a history > count of 0 will be protocol rejected? Alternatively, can the > implementation negotiate a history count of 1 and set the bit-A on every > packet? Will either of these 2 approaches break Win 95? > > 2) From the Memphis meeting in April, there was confusion about how > Win95 deals with (or doesn't deal with) protocol field compression > (PFC). I don't know if this ever got resolved (I couldn't find any > email to document this). So, I thought I would ask you how Win95 deals > with PFC. Assuming PFC is negotiated first, then does PFC need to be > un-negotiated on the link if extended mode is negotiated? It seems that > the second to last paragraph of section 5.1 must change, but I don't > know what to change this paragraph to. > > 3) Lastly, here is the text from Phil Rakity. I don't know if it has > been blessed by you [Microsoft]. Could you [Microsoft or PPPEXT] please > bless it. > > ORIGINAL TEXT > ============= > > > 5.4. Extended Mode Synchronization > > Packets may be lost during transfer. If the decompressor maintained > coherency count does not match the coherency count received in the > compressed packet or if the decompressor detects that a received > packet is corrupted, the decompressor drops the packet and sends a > CCP Reset-Request packet. The compressor on receiving this packet > resets the history buffer and sets the PACKET_FLUSHED bit in the next > frame it sends. The decompressor on receiving a packet with its > PACKET_FLUSHED bit set, resets its history buffer and sets its > coherency count to the one shipped by the compressor in that packet. > > Thus synchronization is achieved without a Reset-Ack packet. > > > NEW TEXT > ======= > > 5.4. Extended Mode Synchronization > > Packets may be lost during transfer. If the decompressor > maintained > coherency count does not match the coherency count received in > the > compressed packet or if the decompressor detects that a received > packet is corrupted, or if the decompressor is waiting for > synchronization and the coherency count is correct but the > PACKET_FLUSHED bit is not set, the decompressor drops the packet > and > sends a CCP Reset-Request packet. The compressor on receiving > the > CCP Reset-Request Packet packet resets the history buffer and > sets > the PACKET_FLUSHED bit in the next frame it sends. The > decompressor > on receiving a packet with its PACKET_FLUSHED bit set, resets > its > history buffer and sets its coherency count to the one shipped > by > the compressor in that packet. > > Thus synchronization is achieved without a Reset-Ack packet. > > Implementation Note: The decompressor should reset the history > when > a corrupted packet was received (eg no end marker) to ensure > that > the decompressor is in a well known state and not rely on the > protocol to flush the history. > > P.S. There is a PPP bakeoff by the San Francisco Airport next week. > Will there be a Microsoft representative there for a discussion about > this? I plan to be there Wednesday & Thursday. I would like to resolve > these issues. > > Thanks, > _____________________________________________________________ > > Robert C. Friend Hi/fn > Applications Engineering 5973 Avenida Encinas, Suite 110 > voice: (760) 827-4542 Carlsbad, CA 92008 > FAX: (760) 827-4577 email: rfriend@hifn.com > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 20 04:18:01 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id EAA13336; Fri, 20 Feb 1998 04:17:55 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 20 Feb 1998 04:16:49 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA13312 for ietf-ppp-outgoing; Fri, 20 Feb 1998 04:16:49 -0500 (EST) Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by merit.edu (8.8.7/8.8.5) with ESMTP id EAA13308 for ; Fri, 20 Feb 1998 04:16:45 -0500 (EST) Received: from claret.cisco.com (claret.cisco.com [171.69.160.39]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with SMTP id BAA27130; Fri, 20 Feb 1998 01:14:53 -0800 (PST) Date: Fri, 20 Feb 1998 04:14:53 -0500 (EST) From: "W. Mark Townsley" To: Philip Rakity cc: Robert Friend , IETF-PPP Subject: Re: Update rfc1974? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Thu, 19 Feb 1998, Philip Rakity wrote: > > > Bob, > > If you are going to change rfc1974, there is one more item that may need > changing. I am not sure if it belongs in rfc1974 or in L2TP, but it > certainly belongs somewhere. The current L2TP draft speaks to the pros and cons of stateful compression and encryption techniques over an [L2TP][UDP][IP] tunnel in section 8.1. > > The problem is that using STAC LZS (type 3) compression, or any > compression method that contains a sequence number; is not a good idea if > there is a good chance that packets will be dropped (eg: as in tunneling > through) the internet. The cost of recovery is very high (reset req, ack, > etc). It is better to use STAC 0 (no history). So, where should we put > in text about what is recommended. > > It is certainly is a good idea to require everyone support STAC LZS (as is > in the spec), but we need for words that an implementation requesting > compression when connected through a tunnel should request STAC 0 (no > history). > > regards, > > Philip Rakity > FlowPoint > > On Thu, 19 Feb 1998, Robert Friend wrote: > > > Hi All, > > > > I have been trying to work with the Microsoft representatives on this > > issue since the Memphis meeting, but I never received a response. My > > questions to this group are: > > > > 1) Are these 2 issues real issues with the document? > > 2) Do we want to change the rfc to reflect this updated information on > > these 2 issues? > > 3) Is the information below accurate for issue #3? > > 4) Does anyone know the answers to questions #1 or issue #2 below? > > > > Here are the issues: > > > > >From the Memphis meeting we had an issue with rfc1974, extended mode. > > Also, I have a question about extended mode. > > > > 1) First my question: In section 5. on page 15, it says that extended > > mode only supports a history count of 1. Does this mean that a history > > count of 0 will be protocol rejected? Alternatively, can the > > implementation negotiate a history count of 1 and set the bit-A on every > > packet? Will either of these 2 approaches break Win 95? > > > > 2) From the Memphis meeting in April, there was confusion about how > > Win95 deals with (or doesn't deal with) protocol field compression > > (PFC). I don't know if this ever got resolved (I couldn't find any > > email to document this). So, I thought I would ask you how Win95 deals > > with PFC. Assuming PFC is negotiated first, then does PFC need to be > > un-negotiated on the link if extended mode is negotiated? It seems that > > the second to last paragraph of section 5.1 must change, but I don't > > know what to change this paragraph to. > > > > 3) Lastly, here is the text from Phil Rakity. I don't know if it has > > been blessed by you [Microsoft]. Could you [Microsoft or PPPEXT] please > > bless it. > > > > ORIGINAL TEXT > > ============= > > > > > > 5.4. Extended Mode Synchronization > > > > Packets may be lost during transfer. If the decompressor maintained > > coherency count does not match the coherency count received in the > > compressed packet or if the decompressor detects that a received > > packet is corrupted, the decompressor drops the packet and sends a > > CCP Reset-Request packet. The compressor on receiving this packet > > resets the history buffer and sets the PACKET_FLUSHED bit in the next > > frame it sends. The decompressor on receiving a packet with its > > PACKET_FLUSHED bit set, resets its history buffer and sets its > > coherency count to the one shipped by the compressor in that packet. > > > > Thus synchronization is achieved without a Reset-Ack packet. > > > > > > NEW TEXT > > ======= > > > > 5.4. Extended Mode Synchronization > > > > Packets may be lost during transfer. If the decompressor > > maintained > > coherency count does not match the coherency count received in > > the > > compressed packet or if the decompressor detects that a received > > packet is corrupted, or if the decompressor is waiting for > > synchronization and the coherency count is correct but the > > PACKET_FLUSHED bit is not set, the decompressor drops the packet > > and > > sends a CCP Reset-Request packet. The compressor on receiving > > the > > CCP Reset-Request Packet packet resets the history buffer and > > sets > > the PACKET_FLUSHED bit in the next frame it sends. The > > decompressor > > on receiving a packet with its PACKET_FLUSHED bit set, resets > > its > > history buffer and sets its coherency count to the one shipped > > by > > the compressor in that packet. > > > > Thus synchronization is achieved without a Reset-Ack packet. > > > > Implementation Note: The decompressor should reset the history > > when > > a corrupted packet was received (eg no end marker) to ensure > > that > > the decompressor is in a well known state and not rely on the > > protocol to flush the history. > > > > P.S. There is a PPP bakeoff by the San Francisco Airport next week. > > Will there be a Microsoft representative there for a discussion about > > this? I plan to be there Wednesday & Thursday. I would like to resolve > > these issues. > > > > Thanks, > > _____________________________________________________________ > > > > Robert C. Friend Hi/fn > > Applications Engineering 5973 Avenida Encinas, Suite 110 > > voice: (760) 827-4542 Carlsbad, CA 92008 > > FAX: (760) 827-4577 email: rfriend@hifn.com > > > > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 20 13:21:25 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA19311; Fri, 20 Feb 1998 13:20:41 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 20 Feb 1998 13:15:39 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA19123 for ietf-ppp-outgoing; Fri, 20 Feb 1998 13:15:38 -0500 (EST) Received: from santaclara01.pop.internex.net (santaclara01.pop.internex.net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA19112 for ; Fri, 20 Feb 1998 13:15:29 -0500 (EST) Received: from flowpoint.com ([192.84.210.69]) by santaclara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA12368; Fri, 20 Feb 1998 10:15:27 -0800 Received: from localhost (pmr@localhost) by flowpoint.com (8.8.7/8.8.4) with SMTP id KAA21550; Fri, 20 Feb 1998 10:15:30 -0800 Date: Fri, 20 Feb 1998 10:15:29 -0800 (PST) From: Philip Rakity X-Sender: pmr@flowpnt To: "W. Mark Townsley" cc: Robert Friend , IETF-PPP Subject: Re: Update rfc1974? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Mark, You are correct that the draft talks about the use/non-use of state based compression schemes. However, no mention is specifically made of STAC compression (rfc 1974). I believe that if rfc1974 is used with a tunnel, then STAC 0 should be proposed. The rfc1974 text (if revised) should include words this effect. Philip Rakity On Fri, 20 Feb 1998, W. Mark Townsley wrote: > On Thu, 19 Feb 1998, Philip Rakity wrote: > > > > > > > Bob, > > > > If you are going to change rfc1974, there is one more item that may need > > changing. I am not sure if it belongs in rfc1974 or in L2TP, but it > > certainly belongs somewhere. > > The current L2TP draft speaks to the pros and cons of stateful compression > and encryption techniques over an [L2TP][UDP][IP] tunnel in section 8.1. > > > > > The problem is that using STAC LZS (type 3) compression, or any > > compression method that contains a sequence number; is not a good idea if > > there is a good chance that packets will be dropped (eg: as in tunneling > > through) the internet. The cost of recovery is very high (reset req, ack, > > etc). It is better to use STAC 0 (no history). So, where should we put > > in text about what is recommended. > > > > It is certainly is a good idea to require everyone support STAC LZS (as is > > in the spec), but we need for words that an implementation requesting > > compression when connected through a tunnel should request STAC 0 (no > > history). > > > > regards, > > > > Philip Rakity > > FlowPoint > > > > On Thu, 19 Feb 1998, Robert Friend wrote: > > > > > Hi All, > > > > > > I have been trying to work with the Microsoft representatives on this > > > issue since the Memphis meeting, but I never received a response. My > > > questions to this group are: > > > > > > 1) Are these 2 issues real issues with the document? > > > 2) Do we want to change the rfc to reflect this updated information on > > > these 2 issues? > > > 3) Is the information below accurate for issue #3? > > > 4) Does anyone know the answers to questions #1 or issue #2 below? > > > > > > Here are the issues: > > > > > > >From the Memphis meeting we had an issue with rfc1974, extended mode. > > > Also, I have a question about extended mode. > > > > > > 1) First my question: In section 5. on page 15, it says that extended > > > mode only supports a history count of 1. Does this mean that a history > > > count of 0 will be protocol rejected? Alternatively, can the > > > implementation negotiate a history count of 1 and set the bit-A on every > > > packet? Will either of these 2 approaches break Win 95? > > > > > > 2) From the Memphis meeting in April, there was confusion about how > > > Win95 deals with (or doesn't deal with) protocol field compression > > > (PFC). I don't know if this ever got resolved (I couldn't find any > > > email to document this). So, I thought I would ask you how Win95 deals > > > with PFC. Assuming PFC is negotiated first, then does PFC need to be > > > un-negotiated on the link if extended mode is negotiated? It seems that > > > the second to last paragraph of section 5.1 must change, but I don't > > > know what to change this paragraph to. > > > > > > 3) Lastly, here is the text from Phil Rakity. I don't know if it has > > > been blessed by you [Microsoft]. Could you [Microsoft or PPPEXT] please > > > bless it. > > > > > > ORIGINAL TEXT > > > ============= > > > > > > > > > 5.4. Extended Mode Synchronization > > > > > > Packets may be lost during transfer. If the decompressor maintained > > > coherency count does not match the coherency count received in the > > > compressed packet or if the decompressor detects that a received > > > packet is corrupted, the decompressor drops the packet and sends a > > > CCP Reset-Request packet. The compressor on receiving this packet > > > resets the history buffer and sets the PACKET_FLUSHED bit in the next > > > frame it sends. The decompressor on receiving a packet with its > > > PACKET_FLUSHED bit set, resets its history buffer and sets its > > > coherency count to the one shipped by the compressor in that packet. > > > > > > Thus synchronization is achieved without a Reset-Ack packet. > > > > > > > > > NEW TEXT > > > ======= > > > > > > 5.4. Extended Mode Synchronization > > > > > > Packets may be lost during transfer. If the decompressor > > > maintained > > > coherency count does not match the coherency count received in > > > the > > > compressed packet or if the decompressor detects that a received > > > packet is corrupted, or if the decompressor is waiting for > > > synchronization and the coherency count is correct but the > > > PACKET_FLUSHED bit is not set, the decompressor drops the packet > > > and > > > sends a CCP Reset-Request packet. The compressor on receiving > > > the > > > CCP Reset-Request Packet packet resets the history buffer and > > > sets > > > the PACKET_FLUSHED bit in the next frame it sends. The > > > decompressor > > > on receiving a packet with its PACKET_FLUSHED bit set, resets > > > its > > > history buffer and sets its coherency count to the one shipped > > > by > > > the compressor in that packet. > > > > > > Thus synchronization is achieved without a Reset-Ack packet. > > > > > > Implementation Note: The decompressor should reset the history > > > when > > > a corrupted packet was received (eg no end marker) to ensure > > > that > > > the decompressor is in a well known state and not rely on the > > > protocol to flush the history. > > > > > > P.S. There is a PPP bakeoff by the San Francisco Airport next week. > > > Will there be a Microsoft representative there for a discussion about > > > this? I plan to be there Wednesday & Thursday. I would like to resolve > > > these issues. > > > > > > Thanks, > > > _____________________________________________________________ > > > > > > Robert C. Friend Hi/fn > > > Applications Engineering 5973 Avenida Encinas, Suite 110 > > > voice: (760) 827-4542 Carlsbad, CA 92008 > > > FAX: (760) 827-4577 email: rfriend@hifn.com > > > > > > > > > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 20 13:45:09 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA19840; Fri, 20 Feb 1998 13:44:49 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 20 Feb 1998 13:44:15 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA19814 for ietf-ppp-outgoing; Fri, 20 Feb 1998 13:44:14 -0500 (EST) Received: from nickel.network-alchemy.com (Nickel.Network-Alchemy.Com [199.46.17.146]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA19810 for ; Fri, 20 Feb 1998 13:44:09 -0500 (EST) Received: from sodium.network-alchemy.com (localhost.Network-Alchemy.COM [127.0.0.1]) by nickel.network-alchemy.com (8.8.7/8.8.8) with ESMTP id KAA09908 for ; Fri, 20 Feb 1998 10:43:33 -0800 (PST) (envelope-from palter@network-alchemy.com) Message-Id: <199802201843.KAA09908@nickel.network-alchemy.com> Cc: ietf-ppp@merit.edu Subject: Re: Update rfc1974 From: Bill Palter Date: Fri, 20 Feb 1998 10:43:33 -0800 Sender: owner-ietf-ppp@merit.edu > > Mark, > > You are correct that the draft talks about the use/non-use of state based > compression schemes. However, no mention is specifically made of STAC > compression (rfc 1974). > > I believe that if rfc1974 is used with a tunnel, then STAC 0 should be > proposed. The rfc1974 text (if revised) should include words this effect. > > Philip Rakity This is a little over generalized, there are many cases of using l2tp tunnels where loss and/or resequencing of packets does not occur. > > > On Fri, 20 Feb 1998, W. Mark Townsley wrote: > > > On Thu, 19 Feb 1998, Philip Rakity wrote: > > > > > > > > > > > Bob, > > > > > > If you are going to change rfc1974, there is one more item that may need > > > changing. I am not sure if it belongs in rfc1974 or in L2TP, but it > > > certainly belongs somewhere. > > > > The current L2TP draft speaks to the pros and cons of stateful compression > > and encryption techniques over an [L2TP][UDP][IP] tunnel in section 8.1. > > > > > > > > The problem is that using STAC LZS (type 3) compression, or any > > > compression method that contains a sequence number; is not a good idea if > > > there is a good chance that packets will be dropped (eg: as in tunneling > > > through) the internet. The cost of recovery is very high (reset req, ack, > > > etc). It is better to use STAC 0 (no history). So, where should we put > > > in text about what is recommended. > > > > > > It is certainly is a good idea to require everyone support STAC LZS (as is > > > in the spec), but we need for words that an implementation requesting > > > compression when connected through a tunnel should request STAC 0 (no > > > history). > > > > > > regards, > > > > > > Philip Rakity > > > FlowPoint > > > > > > On Thu, 19 Feb 1998, Robert Friend wrote: > > > > > > > Hi All, > > > > > > > > I have been trying to work with the Microsoft representatives on this > > > > issue since the Memphis meeting, but I never received a response. My > > > > questions to this group are: > > > > > > > > 1) Are these 2 issues real issues with the document? > > > > 2) Do we want to change the rfc to reflect this updated information on > > > > these 2 issues? > > > > 3) Is the information below accurate for issue #3? > > > > 4) Does anyone know the answers to questions #1 or issue #2 below? > > > > > > > > Here are the issues: > > > > > > > > >From the Memphis meeting we had an issue with rfc1974, extended mode. > > > > Also, I have a question about extended mode. > > > > > > > > 1) First my question: In section 5. on page 15, it says that extended > > > > mode only supports a history count of 1. Does this mean that a history > > > > count of 0 will be protocol rejected? Alternatively, can the > > > > implementation negotiate a history count of 1 and set the bit-A on every > > > > packet? Will either of these 2 approaches break Win 95? > > > > > > > > 2) From the Memphis meeting in April, there was confusion about how > > > > Win95 deals with (or doesn't deal with) protocol field compression > > > > (PFC). I don't know if this ever got resolved (I couldn't find any > > > > email to document this). So, I thought I would ask you how Win95 deals > > > > with PFC. Assuming PFC is negotiated first, then does PFC need to be > > > > un-negotiated on the link if extended mode is negotiated? It seems that > > > > the second to last paragraph of section 5.1 must change, but I don't > > > > know what to change this paragraph to. > > > > > > > > 3) Lastly, here is the text from Phil Rakity. I don't know if it has > > > > been blessed by you [Microsoft]. Could you [Microsoft or PPPEXT] please > > > > bless it. > > > > > > > > ORIGINAL TEXT > > > > ============= > > > > > > > > > > > > 5.4. Extended Mode Synchronization > > > > > > > > Packets may be lost during transfer. If the decompressor maintained > > > > coherency count does not match the coherency count received in the > > > > compressed packet or if the decompressor detects that a received > > > > packet is corrupted, the decompressor drops the packet and sends a > > > > CCP Reset-Request packet. The compressor on receiving this packet > > > > resets the history buffer and sets the PACKET_FLUSHED bit in the next > > > > frame it sends. The decompressor on receiving a packet with its > > > > PACKET_FLUSHED bit set, resets its history buffer and sets its > > > > coherency count to the one shipped by the compressor in that packet. > > > > > > > > Thus synchronization is achieved without a Reset-Ack packet. > > > > > > > > > > > > NEW TEXT > > > > ======= > > > > > > > > 5.4. Extended Mode Synchronization > > > > > > > > Packets may be lost during transfer. If the decompressor > > > > maintained > > > > coherency count does not match the coherency count received in > > > > the > > > > compressed packet or if the decompressor detects that a received > > > > packet is corrupted, or if the decompressor is waiting for > > > > synchronization and the coherency count is correct but the > > > > PACKET_FLUSHED bit is not set, the decompressor drops the packet > > > > and > > > > sends a CCP Reset-Request packet. The compressor on receiving > > > > the > > > > CCP Reset-Request Packet packet resets the history buffer and > > > > sets > > > > the PACKET_FLUSHED bit in the next frame it sends. The > > > > decompressor > > > > on receiving a packet with its PACKET_FLUSHED bit set, resets > > > > its > > > > history buffer and sets its coherency count to the one shipped > > > > by > > > > the compressor in that packet. > > > > > > > > Thus synchronization is achieved without a Reset-Ack packet. > > > > > > > > Implementation Note: The decompressor should reset the history > > > > when > > > > a corrupted packet was received (eg no end marker) to ensure > > > > that > > > > the decompressor is in a well known state and not rely on the > > > > protocol to flush the history. > > > > > > > > P.S. There is a PPP bakeoff by the San Francisco Airport next week. > > > > Will there be a Microsoft representative there for a discussion about > > > > this? I plan to be there Wednesday & Thursday. I would like to resolve > > > > these issues. > > > > > > > > Thanks, > > > > _____________________________________________________________ > > > > > > > > Robert C. Friend Hi/fn > > > > Applications Engineering 5973 Avenida Encinas, Suite 110 > > > > voice: (760) 827-4542 Carlsbad, CA 92008 > > > FAX: (760) 827-4577 email: rfriend@hifn.com > > > > > > > > > > > > > > > > > - -- Bill Palter (Palter@Network-Alchemy.com) Network Alchemy, Santa Cruz, CA - --KAA09863.888000022/nickel.network-alchemy.com-- ------- End of Forwarded Message - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 20 13:57:02 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA20286; Fri, 20 Feb 1998 13:56:59 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 20 Feb 1998 13:56:28 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA20237 for ietf-ppp-outgoing; Fri, 20 Feb 1998 13:56:27 -0500 (EST) Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA20233 for ; Fri, 20 Feb 1998 13:56:22 -0500 (EST) Received: from claret.cisco.com (claret.cisco.com [171.69.160.39]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with SMTP id KAA11496; Fri, 20 Feb 1998 10:55:17 -0800 (PST) Date: Fri, 20 Feb 1998 13:55:15 -0500 (EST) From: "W. Mark Townsley" To: Philip Rakity cc: Robert Friend , IETF-PPP Subject: Re: Update rfc1974? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Fri, 20 Feb 1998, Philip Rakity wrote: > > Mark, > > You are correct that the draft talks about the use/non-use of state based > compression schemes. However, no mention is specifically made of STAC > compression (rfc 1974). Stating the relative dangers of using stateful protocols in general is as far as I would like to go in the l2tp draft. I have no desire to get into specifying any particular compression algorithm(s) as you seem to be suggesting (I also might point out that Stac is an informational RFC that uses a licensed compression technique). A more proper place is in the Stac RFC itself. > > I believe that if rfc1974 is used with a tunnel, then STAC 0 should be > proposed. The rfc1974 text (if revised) should include words this effect. > > Philip Rakity > > > On Fri, 20 Feb 1998, W. Mark Townsley wrote: > > > On Thu, 19 Feb 1998, Philip Rakity wrote: > > > > > > > > > > > Bob, > > > > > > If you are going to change rfc1974, there is one more item that may need > > > changing. I am not sure if it belongs in rfc1974 or in L2TP, but it > > > certainly belongs somewhere. > > > > The current L2TP draft speaks to the pros and cons of stateful compression > > and encryption techniques over an [L2TP][UDP][IP] tunnel in section 8.1. > > > > > > > > The problem is that using STAC LZS (type 3) compression, or any > > > compression method that contains a sequence number; is not a good idea if > > > there is a good chance that packets will be dropped (eg: as in tunneling > > > through) the internet. The cost of recovery is very high (reset req, ack, > > > etc). It is better to use STAC 0 (no history). So, where should we put > > > in text about what is recommended. > > > > > > It is certainly is a good idea to require everyone support STAC LZS (as is > > > in the spec), but we need for words that an implementation requesting > > > compression when connected through a tunnel should request STAC 0 (no > > > history). > > > > > > regards, > > > > > > Philip Rakity > > > FlowPoint > > > > > > On Thu, 19 Feb 1998, Robert Friend wrote: > > > > > > > Hi All, > > > > > > > > I have been trying to work with the Microsoft representatives on this > > > > issue since the Memphis meeting, but I never received a response. My > > > > questions to this group are: > > > > > > > > 1) Are these 2 issues real issues with the document? > > > > 2) Do we want to change the rfc to reflect this updated information on > > > > these 2 issues? > > > > 3) Is the information below accurate for issue #3? > > > > 4) Does anyone know the answers to questions #1 or issue #2 below? > > > > > > > > Here are the issues: > > > > > > > > >From the Memphis meeting we had an issue with rfc1974, extended mode. > > > > Also, I have a question about extended mode. > > > > > > > > 1) First my question: In section 5. on page 15, it says that extended > > > > mode only supports a history count of 1. Does this mean that a history > > > > count of 0 will be protocol rejected? Alternatively, can the > > > > implementation negotiate a history count of 1 and set the bit-A on every > > > > packet? Will either of these 2 approaches break Win 95? > > > > > > > > 2) From the Memphis meeting in April, there was confusion about how > > > > Win95 deals with (or doesn't deal with) protocol field compression > > > > (PFC). I don't know if this ever got resolved (I couldn't find any > > > > email to document this). So, I thought I would ask you how Win95 deals > > > > with PFC. Assuming PFC is negotiated first, then does PFC need to be > > > > un-negotiated on the link if extended mode is negotiated? It seems that > > > > the second to last paragraph of section 5.1 must change, but I don't > > > > know what to change this paragraph to. > > > > > > > > 3) Lastly, here is the text from Phil Rakity. I don't know if it has > > > > been blessed by you [Microsoft]. Could you [Microsoft or PPPEXT] please > > > > bless it. > > > > > > > > ORIGINAL TEXT > > > > ============= > > > > > > > > > > > > 5.4. Extended Mode Synchronization > > > > > > > > Packets may be lost during transfer. If the decompressor maintained > > > > coherency count does not match the coherency count received in the > > > > compressed packet or if the decompressor detects that a received > > > > packet is corrupted, the decompressor drops the packet and sends a > > > > CCP Reset-Request packet. The compressor on receiving this packet > > > > resets the history buffer and sets the PACKET_FLUSHED bit in the next > > > > frame it sends. The decompressor on receiving a packet with its > > > > PACKET_FLUSHED bit set, resets its history buffer and sets its > > > > coherency count to the one shipped by the compressor in that packet. > > > > > > > > Thus synchronization is achieved without a Reset-Ack packet. > > > > > > > > > > > > NEW TEXT > > > > ======= > > > > > > > > 5.4. Extended Mode Synchronization > > > > > > > > Packets may be lost during transfer. If the decompressor > > > > maintained > > > > coherency count does not match the coherency count received in > > > > the > > > > compressed packet or if the decompressor detects that a received > > > > packet is corrupted, or if the decompressor is waiting for > > > > synchronization and the coherency count is correct but the > > > > PACKET_FLUSHED bit is not set, the decompressor drops the packet > > > > and > > > > sends a CCP Reset-Request packet. The compressor on receiving > > > > the > > > > CCP Reset-Request Packet packet resets the history buffer and > > > > sets > > > > the PACKET_FLUSHED bit in the next frame it sends. The > > > > decompressor > > > > on receiving a packet with its PACKET_FLUSHED bit set, resets > > > > its > > > > history buffer and sets its coherency count to the one shipped > > > > by > > > > the compressor in that packet. > > > > > > > > Thus synchronization is achieved without a Reset-Ack packet. > > > > > > > > Implementation Note: The decompressor should reset the history > > > > when > > > > a corrupted packet was received (eg no end marker) to ensure > > > > that > > > > the decompressor is in a well known state and not rely on the > > > > protocol to flush the history. > > > > > > > > P.S. There is a PPP bakeoff by the San Francisco Airport next week. > > > > Will there be a Microsoft representative there for a discussion about > > > > this? I plan to be there Wednesday & Thursday. I would like to resolve > > > > these issues. > > > > > > > > Thanks, > > > > _____________________________________________________________ > > > > > > > > Robert C. Friend Hi/fn > > > > Applications Engineering 5973 Avenida Encinas, Suite 110 > > > > voice: (760) 827-4542 Carlsbad, CA 92008 > > > > FAX: (760) 827-4577 email: rfriend@hifn.com > > > > > > > > > > > > > > > > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 20 14:06:21 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA20516; Fri, 20 Feb 1998 14:06:19 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 20 Feb 1998 14:05:53 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA20491 for ietf-ppp-outgoing; Fri, 20 Feb 1998 14:05:52 -0500 (EST) Received: from nickel.network-alchemy.com (Nickel.Network-Alchemy.Com [199.46.17.146]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA20487 for ; Fri, 20 Feb 1998 14:05:47 -0500 (EST) Received: from sodium.network-alchemy.com (localhost.Network-Alchemy.COM [127.0.0.1]) by nickel.network-alchemy.com (8.8.7/8.8.8) with ESMTP id LAA10077; Fri, 20 Feb 1998 11:04:37 -0800 (PST) (envelope-from palter@network-alchemy.com) Message-Id: <199802201904.LAA10077@nickel.network-alchemy.com> To: Philip Rakity cc: Bill Palter , townsley@cisco.com, rfriend@hifn.com, ietf-ppp@merit.edu Subject: Re: Update rfc1974? From: Bill Palter In-reply-to: Your message of Fri, 20 Feb 1998 10:51:12 -0800. Date: Fri, 20 Feb 1998 11:04:36 -0800 Sender: owner-ietf-ppp@merit.edu > > Bill, > > Yes, but none of these occur over the internet. > > I tried to be general by using the word proposed vs required. STAC 3 is > required, but this is not a good idea for tunneling over the internet. > Can you suggest some words to satisfy both our needs ? > > Philip > I think that rfc1974 probable should not reference l2tp directly at all. Since its a general problem, 1974 probably should talk about optimizations over lossy networks (such as tunneling PPP over other transports), as time goes by I would be surprised if this problem does not show up in other places. In the l2tp draft I dont really see the need to reference STAC specificly, but we can beef up the warnings about the stateful compression schemes over the Internet. I feel that cross referencing warnings in RFC tends to make things get dated over time as protocol evolve into uses that they were not originally intended to do.... > > > > On Fri, 20 Feb 1998, Bill Palter wrote: > > > > > > > Mark, > > > > > > You are correct that the draft talks about the use/non-use of state based > > > compression schemes. However, no mention is specifically made of STAC > > > compression (rfc 1974). > > > > > > I believe that if rfc1974 is used with a tunnel, then STAC 0 should be > > > proposed. The rfc1974 text (if revised) should include words this effect. > > > > > > Philip Rakity > > > > This is a little over generalized, there are many cases of using > > l2tp tunnels where loss and/or resequencing of packets does not occur. > > > > > > > > > > > > > On Fri, 20 Feb 1998, W. Mark Townsley wrote: > > > > > > > On Thu, 19 Feb 1998, Philip Rakity wrote: > > > > > > > > > > > > > > > > > > > Bob, > > > > > > > > > > If you are going to change rfc1974, there is one more item that may need > > > > > changing. I am not sure if it belongs in rfc1974 or in L2TP, but it > > > > > certainly belongs somewhere. > > > > > > > > The current L2TP draft speaks to the pros and cons of stateful compression > > > > and encryption techniques over an [L2TP][UDP][IP] tunnel in section 8.1. > > > > > > > > > > > > > > The problem is that using STAC LZS (type 3) compression, or any > > > > > compression method that contains a sequence number; is not a good idea if > > > > > there is a good chance that packets will be dropped (eg: as in tunneling > > > > > through) the internet. The cost of recovery is very high (reset req, ack, > > > > > etc). It is better to use STAC 0 (no history). So, where should we put > > > > > in text about what is recommended. > > > > > > > > > > It is certainly is a good idea to require everyone support STAC LZS (as is > > > > > in the spec), but we need for words that an implementation requesting > > > > > compression when connected through a tunnel should request STAC 0 (no > > > > > history). > > > > > > > > > > regards, > > > > > > > > > > Philip Rakity > > > > > FlowPoint > > > > > > > > > > On Thu, 19 Feb 1998, Robert Friend wrote: > > > > > > > > > > > Hi All, > > > > > > > > > > > > I have been trying to work with the Microsoft representatives on this > > > > > > issue since the Memphis meeting, but I never received a response. My > > > > > > questions to this group are: > > > > > > > > > > > > 1) Are these 2 issues real issues with the document? > > > > > > 2) Do we want to change the rfc to reflect this updated information on > > > > > > these 2 issues? > > > > > > 3) Is the information below accurate for issue #3? > > > > > > 4) Does anyone know the answers to questions #1 or issue #2 below? > > > > > > > > > > > > Here are the issues: > > > > > > > > > > > > >From the Memphis meeting we had an issue with rfc1974, extended mode. > > > > > > Also, I have a question about extended mode. > > > > > > > > > > > > 1) First my question: In section 5. on page 15, it says that extended > > > > > > mode only supports a history count of 1. Does this mean that a history > > > > > > count of 0 will be protocol rejected? Alternatively, can the > > > > > > implementation negotiate a history count of 1 and set the bit-A on every > > > > > > packet? Will either of these 2 approaches break Win 95? > > > > > > > > > > > > 2) From the Memphis meeting in April, there was confusion about how > > > > > > Win95 deals with (or doesn't deal with) protocol field compression > > > > > > (PFC). I don't know if this ever got resolved (I couldn't find any > > > > > > email to document this). So, I thought I would ask you how Win95 deals > > > > > > with PFC. Assuming PFC is negotiated first, then does PFC need to be > > > > > > un-negotiated on the link if extended mode is negotiated? It seems that > > > > > > the second to last paragraph of section 5.1 must change, but I don't > > > > > > know what to change this paragraph to. > > > > > > > > > > > > 3) Lastly, here is the text from Phil Rakity. I don't know if it has > > > > > > been blessed by you [Microsoft]. Could you [Microsoft or PPPEXT] please > > > > > > bless it. > > > > > > > > > > > > ORIGINAL TEXT > > > > > > ============= > > > > > > > > > > > > > > > > > > 5.4. Extended Mode Synchronization > > > > > > > > > > > > Packets may be lost during transfer. If the decompressor maintained > > > > > > coherency count does not match the coherency count received in the > > > > > > compressed packet or if the decompressor detects that a received > > > > > > packet is corrupted, the decompressor drops the packet and sends a > > > > > > CCP Reset-Request packet. The compressor on receiving this packet > > > > > > resets the history buffer and sets the PACKET_FLUSHED bit in the next > > > > > > frame it sends. The decompressor on receiving a packet with its > > > > > > PACKET_FLUSHED bit set, resets its history buffer and sets its > > > > > > coherency count to the one shipped by the compressor in that packet. > > > > > > > > > > > > Thus synchronization is achieved without a Reset-Ack packet. > > > > > > > > > > > > > > > > > > NEW TEXT > > > > > > ======= > > > > > > > > > > > > 5.4. Extended Mode Synchronization > > > > > > > > > > > > Packets may be lost during transfer. If the decompressor > > > > > > maintained > > > > > > coherency count does not match the coherency count received in > > > > > > the > > > > > > compressed packet or if the decompressor detects that a received > > > > > > packet is corrupted, or if the decompressor is waiting for > > > > > > synchronization and the coherency count is correct but the > > > > > > PACKET_FLUSHED bit is not set, the decompressor drops the packet > > > > > > and > > > > > > sends a CCP Reset-Request packet. The compressor on receiving > > > > > > the > > > > > > CCP Reset-Request Packet packet resets the history buffer and > > > > > > sets > > > > > > the PACKET_FLUSHED bit in the next frame it sends. The > > > > > > decompressor > > > > > > on receiving a packet with its PACKET_FLUSHED bit set, resets > > > > > > its > > > > > > history buffer and sets its coherency count to the one shipped > > > > > > by > > > > > > the compressor in that packet. > > > > > > > > > > > > Thus synchronization is achieved without a Reset-Ack packet. > > > > > > > > > > > > Implementation Note: The decompressor should reset the history > > > > > > when > > > > > > a corrupted packet was received (eg no end marker) to ensure > > > > > > that > > > > > > the decompressor is in a well known state and not rely on the > > > > > > protocol to flush the history. > > > > > > > > > > > > P.S. There is a PPP bakeoff by the San Francisco Airport next week. > > > > > > Will there be a Microsoft representative there for a discussion about > > > > > > this? I plan to be there Wednesday & Thursday. I would like to resolve > > > > > > these issues. > > > > > > > > > > > > Thanks, > > > > > > _____________________________________________________________ > > > > > > > > > > > > Robert C. Friend Hi/fn > > > > > > Applications Engineering 5973 Avenida Encinas, Suite 110 > > > > > > voice: (760) 827-4542 Carlsbad, CA 92008 > > > > > FAX: (760) 827-4577 email: rfriend@hifn.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Bill Palter (Palter@Network-Alchemy.com) > > Network Alchemy, Santa Cruz, CA > > > -- Bill Palter (Palter@Network-Alchemy.com) Network Alchemy, Santa Cruz, CA - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 20 16:20:32 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA23700; Fri, 20 Feb 1998 16:20:27 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 20 Feb 1998 16:18:24 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA23566 for ietf-ppp-outgoing; Fri, 20 Feb 1998 16:18:24 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.223.106]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA23562 for ; Fri, 20 Feb 1998 16:18:17 -0500 (EST) Received: from anfreema-pc.cisco.com (dhcp-f-185.cisco.com [171.68.234.185]) by diablo.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id NAA12060; Fri, 20 Feb 1998 13:17:14 -0800 (PST) Message-Id: <3.0.2.32.19980220131554.0096be30@diablo.cisco.com> X-Sender: anfreema@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 20 Feb 1998 13:15:54 -0800 To: l2tp@zendo.com, ietf-ppp@merit.edu From: Anita Freeman Subject: CIUG PPP Workshop Group Meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu For those of you who have planned to attend only the Group Meeting of the CIUG PPP Interoperability Workshop on Thursday, Feb 26, 1998 (3-5 PM), the meeting day has been changed to: Wednesday, Feb 15, 1998 from 3-5 PM The location remains the same: Park Plaza International San Francisco (next to San Francisco Airport) 1177 Airport Blvd Burlingame, CA 650-342-9200 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 20 17:41:46 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA25746; Fri, 20 Feb 1998 17:41:43 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 20 Feb 1998 17:40:03 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA25668 for ietf-ppp-outgoing; Fri, 20 Feb 1998 17:40:02 -0500 (EST) Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA25663 for ; Fri, 20 Feb 1998 17:39:47 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA19528; Fri, 20 Feb 1998 14:32:23 -0800 (PST) Received: from tmpbeta.livingston.com ([149.198.65.50]) by server.livingston.com (8.8.5/8.6.9) with SMTP id OAA15325; Fri, 20 Feb 1998 14:38:10 -0800 (PST) Received: from localhost by tmpbeta.livingston.com (SMI-8.6/SMI-SVR4) id OAA01221; Fri, 20 Feb 1998 14:36:59 -0800 Date: Fri, 20 Feb 1998 14:36:58 -0800 (PST) From: Josh Richards X-Sender: jrichard@tmpbeta To: Anita Freeman cc: l2tp@zendo.com, ietf-ppp@merit.edu Subject: Re: CIUG PPP Workshop Group Meeting In-Reply-To: <3.0.2.32.19980220131554.0096be30@diablo.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On 20 Feb 1998, Anita Freeman wrote: > For those of you who have planned to attend only the Group Meeting of the > CIUG PPP Interoperability Workshop on Thursday, Feb 26, 1998 (3-5 PM), the > meeting day has been changed to: > > Wednesday, Feb 15, 1998 from 3-5 PM So everybody missed it then, eh? ;) I assume you mean the 25th. > > The location remains the same: > > Park Plaza International San Francisco (next to San Francisco Airport) > 1177 Airport Blvd > Burlingame, CA > 650-342-9200 > > ---- Josh Richards - - [Beta Engineer] LUCENT Technologies - Remote Access Business Unit (formerly Livingston Enterprises, Inc.) http://www.livingston.com/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 20 20:56:58 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA28829; Fri, 20 Feb 1998 20:56:38 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 20 Feb 1998 20:55:22 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA28798 for ietf-ppp-outgoing; Fri, 20 Feb 1998 20:55:21 -0500 (EST) Received: from tbu1.hifn.com (mailman.hifn.com [206.19.120.66]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA28794 for ; Fri, 20 Feb 1998 20:55:17 -0500 (EST) Received: by tbu1.hifn.com with Internet Mail Service (5.0.1458.49) id <1Y4JRRNR>; Fri, 20 Feb 1998 17:58:28 -0800 Message-ID: <6297CD447F92D11199F5006097BA9D1E02EB46@tbu1.hifn.com> From: Robert Friend To: Bill Palter , Philip Rakity Cc: townsley@cisco.com, ietf-ppp@merit.edu Subject: RE: Update rfc1974? Date: Fri, 20 Feb 1998 17:58:25 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Hi Guys, Thanks for the insight. I can add something about tunneling rfc1974 over lossy networks somewhere in the draft. However, I am still not clear on whether any changes *need* to be done? I.e. I haven't gotten my questions answered. Can anybody help here? Thanks, _____________________________________________________________ Robert C. Friend Hi/fn Applications Engineering 5973 Avenida Encinas, Suite 110 voice: (760) 827-4542 Carlsbad, CA 92008 FAX: (760) 827-4577 email: rfriend@hifn.com > -----Original Message----- > From: Bill Palter [SMTP:palter@network-alchemy.com] > Sent: Friday, February 20, 1998 11:05 AM > To: Philip Rakity > Cc: Bill Palter; townsley@cisco.com; rfriend@hifn.com; > ietf-ppp@merit.edu > Subject: Re: Update rfc1974? > > > > > Bill, > > > > Yes, but none of these occur over the internet. > > > > I tried to be general by using the word proposed vs required. STAC > 3 is > > required, but this is not a good idea for tunneling over the > internet. > > Can you suggest some words to satisfy both our needs ? > > > > Philip > > > > > I think that rfc1974 probable should not reference l2tp directly > > at all. Since its a general problem, 1974 probably should talk about > optimizations over lossy networks (such as tunneling PPP over other > transports), as time goes by I would be surprised if this problem does > not > show up in other places. In the l2tp draft I dont really see the need > to > reference STAC specificly, but we can beef up the warnings about the > stateful compression schemes over the Internet. I feel that cross > referencing > warnings in RFC tends to make things get dated over time as protocol > evolve > into uses that they were not originally intended to do.... > > > > > > > > > > > > On Fri, 20 Feb 1998, Bill Palter wrote: > > > > > > > > > > Mark, > > > > > > > > You are correct that the draft talks about the use/non-use of > state based > > > > compression schemes. However, no mention is specifically made > of STAC > > > > compression (rfc 1974). > > > > > > > > I believe that if rfc1974 is used with a tunnel, then STAC 0 > should be > > > > proposed. The rfc1974 text (if revised) should include words > this effect. > > > > > > > > Philip Rakity > > > > > > This is a little over generalized, there are many cases of using > > > > l2tp tunnels where loss and/or resequencing of packets does not > occur. > > > > > > > > > > > > > > > > > > On Fri, 20 Feb 1998, W. Mark Townsley wrote: > > > > > > > > > On Thu, 19 Feb 1998, Philip Rakity wrote: > > > > > > > > > > > > > > > > > > > > > > > Bob, > > > > > > > > > > > > If you are going to change rfc1974, there is one more item > that may need > > > > > > changing. I am not sure if it belongs in rfc1974 or in > L2TP, but it > > > > > > certainly belongs somewhere. > > > > > > > > > > The current L2TP draft speaks to the pros and cons of stateful > compression > > > > > and encryption techniques over an [L2TP][UDP][IP] tunnel in > section 8.1. > > > > > > > > > > > > > > > > > The problem is that using STAC LZS (type 3) compression, or > any > > > > > > compression method that contains a sequence number; is not a > good idea if > > > > > > there is a good chance that packets will be dropped (eg: as > in tunneling > > > > > > through) the internet. The cost of recovery is very high > (reset req, ack, > > > > > > etc). It is better to use STAC 0 (no history). So, where > should we put > > > > > > in text about what is recommended. > > > > > > > > > > > > It is certainly is a good idea to require everyone support > STAC LZS (as is > > > > > > in the spec), but we need for words that an implementation > requesting > > > > > > compression when connected through a tunnel should request > STAC 0 (no > > > > > > history). > > > > > > > > > > > > regards, > > > > > > > > > > > > Philip Rakity > > > > > > FlowPoint > > > > > > > > > > > > On Thu, 19 Feb 1998, Robert Friend wrote: > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > I have been trying to work with the Microsoft > representatives on this > > > > > > > issue since the Memphis meeting, but I never received a > response. My > > > > > > > questions to this group are: > > > > > > > > > > > > > > 1) Are these 2 issues real issues with the document? > > > > > > > 2) Do we want to change the rfc to reflect this updated > information on > > > > > > > these 2 issues? > > > > > > > 3) Is the information below accurate for issue #3? > > > > > > > 4) Does anyone know the answers to questions #1 or issue > #2 below? > > > > > > > > > > > > > > Here are the issues: > > > > > > > > > > > > > > >From the Memphis meeting we had an issue with rfc1974, > extended mode. > > > > > > > Also, I have a question about extended mode. > > > > > > > > > > > > > > 1) First my question: In section 5. on page 15, it says > that extended > > > > > > > mode only supports a history count of 1. Does this mean > that a history > > > > > > > count of 0 will be protocol rejected? Alternatively, can > the > > > > > > > implementation negotiate a history count of 1 and set the > bit-A on every > > > > > > > packet? Will either of these 2 approaches break Win 95? > > > > > > > > > > > > > > 2) From the Memphis meeting in April, there was confusion > about how > > > > > > > Win95 deals with (or doesn't deal with) protocol field > compression > > > > > > > (PFC). I don't know if this ever got resolved (I couldn't > find any > > > > > > > email to document this). So, I thought I would ask you > how Win95 deals > > > > > > > with PFC. Assuming PFC is negotiated first, then does PFC > need to be > > > > > > > un-negotiated on the link if extended mode is negotiated? > It seems that > > > > > > > the second to last paragraph of section 5.1 must change, > but I don't > > > > > > > know what to change this paragraph to. > > > > > > > > > > > > > > 3) Lastly, here is the text from Phil Rakity. I don't know > if it has > > > > > > > been blessed by you [Microsoft]. Could you [Microsoft or > PPPEXT] please > > > > > > > bless it. > > > > > > > > > > > > > > ORIGINAL TEXT > > > > > > > ============= > > > > > > > > > > > > > > > > > > > > > 5.4. Extended Mode Synchronization > > > > > > > > > > > > > > Packets may be lost during transfer. If the > decompressor maintained > > > > > > > coherency count does not match the coherency count > received in the > > > > > > > compressed packet or if the decompressor detects that a > received > > > > > > > packet is corrupted, the decompressor drops the packet > and sends a > > > > > > > CCP Reset-Request packet. The compressor on receiving > this packet > > > > > > > resets the history buffer and sets the PACKET_FLUSHED > bit in the next > > > > > > > frame it sends. The decompressor on receiving a packet > with its > > > > > > > PACKET_FLUSHED bit set, resets its history buffer and > sets its > > > > > > > coherency count to the one shipped by the compressor in > that packet. > > > > > > > > > > > > > > Thus synchronization is achieved without a Reset-Ack > packet. > > > > > > > > > > > > > > > > > > > > > NEW TEXT > > > > > > > ======= > > > > > > > > > > > > > > 5.4. Extended Mode Synchronization > > > > > > > > > > > > > > Packets may be lost during transfer. If the > decompressor > > > > > > > maintained > > > > > > > coherency count does not match the coherency > count received in > > > > > > > the > > > > > > > compressed packet or if the decompressor detects > that a received > > > > > > > packet is corrupted, or if the decompressor is > waiting for > > > > > > > synchronization and the coherency count is correct but > the > > > > > > > PACKET_FLUSHED bit is not set, the decompressor drops > the packet > > > > > > > and > > > > > > > sends a CCP Reset-Request packet. The compressor on > receiving > > > > > > > the > > > > > > > CCP Reset-Request Packet packet resets the history > buffer and > > > > > > > sets > > > > > > > the PACKET_FLUSHED bit in the next frame it sends. The > > > > > > > decompressor > > > > > > > on receiving a packet with its PACKET_FLUSHED bit set, > resets > > > > > > > its > > > > > > > history buffer and sets its coherency count to the one > shipped > > > > > > > by > > > > > > > the compressor in that packet. > > > > > > > > > > > > > > Thus synchronization is achieved without a > Reset-Ack packet. > > > > > > > > > > > > > > Implementation Note: The decompressor should reset the > history > > > > > > > when > > > > > > > a corrupted packet was received (eg no end marker) to > ensure > > > > > > > that > > > > > > > the decompressor is in a well known state and not rely > on the > > > > > > > protocol to flush the history. > > > > > > > > > > > > > > P.S. There is a PPP bakeoff by the San Francisco Airport > next week. > > > > > > > Will there be a Microsoft representative there for a > discussion about > > > > > > > this? I plan to be there Wednesday & Thursday. I would > like to resolve > > > > > > > these issues. > > > > > > > > > > > > > > Thanks, > > > > > > > > _____________________________________________________________ > > > > > > > > > > > > > > Robert C. Friend Hi/fn > > > > > > > Applications Engineering 5973 Avenida Encinas, Suite > 110 > > > > > > > voice: (760) 827-4542 Carlsbad, CA 92008 > > > > > > FAX: (760) 827-4577 email: rfriend@hifn.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Bill Palter (Palter@Network-Alchemy.com) > > > Network Alchemy, Santa Cruz, CA > > > > > > -- > Bill Palter (Palter@Network-Alchemy.com) > Network Alchemy, Santa Cruz, CA - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Feb 21 02:10:57 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id CAA01407; Sat, 21 Feb 1998 02:10:39 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Sat, 21 Feb 1998 02:03:35 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id CAA01344 for ietf-ppp-outgoing; Sat, 21 Feb 1998 02:03:35 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.223.106]) by merit.edu (8.8.7/8.8.5) with ESMTP id CAA01340 for ; Sat, 21 Feb 1998 02:03:31 -0500 (EST) Received: from anfreema-pc.cisco.com (anfreema-isdn1.cisco.com [171.70.254.10]) by diablo.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id XAA08852; Fri, 20 Feb 1998 23:02:28 -0800 (PST) Message-Id: <3.0.2.32.19980220230107.010a0330@diablo.cisco.com> X-Sender: anfreema@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 20 Feb 1998 23:01:07 -0800 To: l2tp@zendo.com, ietf-ppp@merit.edu From: Anita Freeman Subject: CIUG PPP Workshop Group Meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu I can't believe I have to resend this message - Yes, I meant Wednesday, Feb 25, 1998 from 3-5 PM...... ------------------------------------------------------------------------------ For those of you who have planned to attend only the Group Meeting of the CIUG PPP Interoperability Workshop on Thursday, Feb 26, 1998 (3-5 PM), the meeting day has been changed to: Wednesday, Feb 15, 1998 from 3-5 PM The location remains the same: Park Plaza International San Francisco (next to San Francisco Airport) 1177 Airport Blvd Burlingame, CA 650-342-9200 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Feb 24 04:02:58 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id EAA14580; Tue, 24 Feb 1998 04:01:14 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 24 Feb 1998 03:49:31 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id DAA14478 for ietf-ppp-outgoing; Tue, 24 Feb 1998 03:49:31 -0500 (EST) Received: from messenger.rnd.co.il ([209.88.177.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id DAA14474 for ; Tue, 24 Feb 1998 03:49:25 -0500 (EST) Received: by MESSENGER with Internet Mail Service (5.5.1960.3) id ; Tue, 24 Feb 1998 10:55:49 +0200 Message-ID: <0124851EDBF3D011AAA300008370C8671120FB@MESSENGER> From: Michael Liwerant To: "'ietf_ppp'" Subject: Stac LZS Compression with ASCEND Pipe Line 130 Date: Tue, 24 Feb 1998 10:55:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BD4101.FFB21CA0" Sender: owner-ietf-ppp@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_001_01BD4101.FFB21CA0 Content-Type: text/plain Hi All, I'll appreciate your advice regarding compatability of ASCEND Pipe Line 130 (Ver 5.0-Ap1) to RFC1974 for testing Stac LZS compression. It seems that the ASCEND 130 is sending a CCP configure-request packet containing a Stac LZS option length of 6 bytes (while RFC1974 specifies this field as 5 !!!) the actual result is an extra byte added between "History Count" and "Check Mode" fields. Has anyone met the same problem or did I miss something here ? Thanks for your response - Michael. ------ =_NextPart_001_01BD4101.FFB21CA0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Stac LZS Compression with ASCEND Pipe Line 130

Hi All,

I'll appreciate your advice regarding = compatability of ASCEND Pipe Line 130 (Ver 5.0-Ap1) to RFC1974 for = testing Stac LZS compression.

It seems that the ASCEND 130 is = sending a CCP configure-request packet containing a Stac LZS option = length of 6 bytes (while RFC1974 specifies this field as 5 !!!) the = actual result is an extra byte added between "History Count" = and "Check Mode" fields.

Has anyone met the same problem or did = I miss something here ?

Thanks for your response - = Michael.

------ =_NextPart_001_01BD4101.FFB21CA0-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Feb 24 08:47:50 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA16723; Tue, 24 Feb 1998 08:47:29 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 24 Feb 1998 08:40:32 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA16488 for ietf-ppp-outgoing; Tue, 24 Feb 1998 08:40:32 -0500 (EST) Received: from messenger.rnd.co.il ([209.88.177.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA16484 for ; Tue, 24 Feb 1998 08:40:27 -0500 (EST) Received: by MESSENGER with Internet Mail Service (5.5.1960.3) id ; Tue, 24 Feb 1998 15:46:50 +0200 Message-ID: <0124851EDBF3D011AAA300008370C8671120FC@MESSENGER> From: Michael Liwerant To: "'ietf_ppp'" Cc: Amichai Tal Subject: Stac LZS Compression with ASCEND Pipe Line 130 Date: Tue, 24 Feb 1998 15:46:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BD412A.A7B3FE70" Sender: owner-ietf-ppp@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_001_01BD412A.A7B3FE70 Content-Type: text/plain > Hi All, > > I'll appreciate your advice regarding compatability of ASCEND Pipe > Line 130 (Ver 5.0-Ap1) to RFC1974 for testing Stac LZS compression. > It seems that the ASCEND 130 is sending a CCP configure-request packet > containing a Stac LZS option length of 6 bytes (while RFC1974 > specifies this field as 5 !!!) the actual result is an extra byte > added between "History Count" and "Check Mode" fields. > > Has anyone met the same problem or did I miss something here ? > > Thanks for your response - Michael. ------ =_NextPart_001_01BD412A.A7B3FE70 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Stac LZS Compression with ASCEND Pipe Line 130

Hi All,

I'll appreciate your advice regarding = compatability of ASCEND Pipe Line 130 (Ver 5.0-Ap1) to RFC1974 for = testing Stac LZS compression.

It seems that the ASCEND 130 is = sending a CCP configure-request packet containing a Stac LZS option = length of 6 bytes (while RFC1974 specifies this field as 5 !!!) the = actual result is an extra byte added between "History Count" = and "Check Mode" fields.

Has anyone met the same problem = or did I miss = something here ?

Thanks for your response - = Michael.

------ =_NextPart_001_01BD412A.A7B3FE70-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Feb 24 12:51:18 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA27871; Tue, 24 Feb 1998 12:51:10 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 24 Feb 1998 12:50:18 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA27830 for ietf-ppp-outgoing; Tue, 24 Feb 1998 12:50:17 -0500 (EST) Received: from holmes.fia.net (root@holmes.fia.net [206.171.100.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA27826 for ; Tue, 24 Feb 1998 12:50:12 -0500 (EST) Received: from hotshot.stilink.com (smtp.stilink.com [207.212.2.106]) by holmes.fia.net (8.8.5/8.7.3) with ESMTP id JAA11532 for ; Tue, 24 Feb 1998 09:38:39 -0800 (PST) Received: by ded106-sjs.fia.net with Internet Mail Service (5.0.1458.49) id ; Tue, 24 Feb 1998 11:49:37 -0800 Message-ID: From: Jayant Kadambi To: Michael Liwerant Cc: Sanjay Dhawan , ietf-ppp@merit.edu Subject: FW: Stac PPP RFC Date: Tue, 24 Feb 1998 11:49:30 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu > This is an old document from Ascend which describes the Ascend PPP > Compression Policy. They support option 17 (Stac LZS option) with a > six byte packet instead of 5 bytes. There are many more deviations > from RFC1974 in terms of compressed packet format etc. > > Sanjay Dhawan > StarNet Technologies, Inc. > > > > > > Ascend PPP Compression Policy > Version x > 08 May 95 > > The following describes Ascend's implementation of PPP compression. > It is assumed that the reader is familiar with the STAC LZS > compression, > the PPP Compression Control Protocol ( CCP ) draft ( Dec 1993 ), and > the PPP Stacker LZS Compression Protocol draft ( Oct 1993 ). > > User Interface > > Ascend currently supports the STAC LZS data compression algorithm. > This option is enabled from the Connection Profile with the > "Link Comp=" option which is part of the "Encaps options..." submenu. > > Ethernet-> Connections-> < profile >-> Encaps options-> Link Comp > > For connections that use the default connection profile, the > compression > option is located under the Answer profile submenu under "PPP > options", > "Link Comp=". > > Ethernet-> Answer-> PPP options-> Link Comp > > When a call is placed/received the Link Comp field is checked to see > if the Stac compression is to be used. > > CCP Negotiation: > > Configure-Request (1): > > After LCP configuration is successfully negotiated, a CCP > configuration > request is sent out. The format is: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PPP Address | PPP Control | 0x80 | 0xfd | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x1 | id | Cfg Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | History Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Check Mode | Reset Mode | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > where: > PPP Address: PPP address field > PPP Control: PPP control field > 0x80fd: PPP datalink protocol field using 0x80fd > which is for data compression. > 0x1: CCP Configure-Request > id: identification field > Cfg Length: length of the configuration data portion. > Type: CCP type using 0x11 for Stac compression > ( value used is from [1]. [2] has a kludge > value of 5 ) > Length: Length of this configuration option (6) > History Count: Specifies the maximum number of Compression > histories. Currently only 1 is supported. > ( [2] allows 1-65768 ) > Check Mode: Indicates support the type of checksum used. > The default is LCB (1). > ( [2] allows LCB(1) or CRC (2) ) > Reset Mode: Indicates the reset policy being used. > The value here is (3) - an Ascend extension > which resets when needed. It also uses a > history > generation number that is passed in the > compressed frames. ( [2] specifies single > packet > reset(1) or allow multiple packets(2); > multiple > packets is not supported ) > > Configure-Ack (2): > > A configure ack is sent when the history count, check and reset mode > are acceptable. > > Configure-Nak (3): > > A configure nak is sent if the history count, check mode, or reset > mode > are not acceptable by the local box. > > Terminate-Ack (6): > > If a CCP request is received and the local box does not support > compression a Terminate Ack is sent: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PPP Address | PPP Control | 0x80 | 0xfd | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x6 | id | Cfg Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > where: > PPP Address: PPP address field > PPP Control: PPP control field > 0x80fd: PPP datalink protocol field using 0x80fd > 0x6: CCP Terminate-Ack > id: identification field > Cfg Length: length of the configuration data portion. > ( 4 ) > Type: CCP type using 0x11 for Stac compression > > > Data Transfer: > > The format of the compressed data packets is: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PPP Address | PPP Control | 0x00 | 0xfd | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | original PPP protocol | uncompressed length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | history gen | data ..... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LCB / CRC | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > where: > PPP Address: PPP address field > PPP Control: PPP control field > 0x00fd: datalink protocol field specifying > compression > original protocol: The original PPP protocol of the > packet. eg. if IP the the value is > 0x0021 > uncompressed length: the length of the uncompressed data. > history gen: this field exists IF the Ascend reset > mode is negotiated. If it is not, > then this field doesn't exist. > data: the compressed data > LCB or CRC: 1 byte checksum (LCB) or 2 byte CRC. > > > History Generation and CCP reset Scheme: > > The Ascend reset policy using the history generation number is as > follows: > > Each box that supports this resetMode will use the history generation > field of a compressed packet as a "synchronization" indicator between > the sender's send history and the receiver's receive history. > The sending side's "send history number" ( sendHist ) is the value > that > is put into the history field of the compressed packet. The receiver > uses > the passed history number to see if it matches it's "receive history > number" (recevHist ). If it does, then the receiver will try and > decompress > the packet. > This history number will only change if a compression/decompression > fails, > in which case the value is incremented by 1. > The receive side can instruct the sender to reset it's send history > table > by using the CCP Reset Request message. The format is: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PPP Address | PPP Control | 0x80 | 0xfd | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Code | id | Cfg Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | history gen | > +-+-+-+-+-+-+-+-+ > > where: > PPP Address: PPP address field > PPP Control: PPP control field > 0x80fd: PPP datalink protocol field using 0x80fd > Code: CCP Reset-Request (14) > id: identification field > Cfg Length: length of the configuration data portion. > history gen: NEW history generation number to synchronize > on > > Conditions for sender to reset it's send history table: > > 1) compression fails > a) if a previous packet has been sent with the current history > number, then increment sendHist. > 2) received CCP reset request from the receiver with a history number > > sendHist. > a) reset send history table > b) set sendHist to the history number passed in the reset > packet. > 3) receive CCP reset request from the receive side with a history > number > <= sendHist. > a) ignore it > > Conditions for receiver to reset it's receive history table. > > 1) received a compression packet whose history is < recvHist > a) ignore the compressed packet > b) send a CCP Compression reset with the recvHist's value > to the sender > 2) received a compression packet whose history is > recvHist > a) reset the receive history table > b) try and decompress ( see decompress failure below ) > 3) received a compression packet whose history is = recvHist > a) try and decompress ( see decompress failure below ) > 4) decompression fails > a) reset receive history > b) increment recvHistory > c) send a CCP Compression reset with the NEW history number > to the sender. > > > The CCP reset scheme specified in [1] is not implemented. > > > > [1] Rand, D.; "The PPP Compression Control Protocol ( CCP ) > draft-ietf-pppext-compression-03.txt", December 1993. > > [2] Lutz, R.; "PPP Stacker LZS Compression Protocol > draft-ietf-pppext-stacker-00.txt", October 1993. > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Feb 24 21:03:42 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id VAA05668; Tue, 24 Feb 1998 21:03:21 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 24 Feb 1998 21:02:36 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA05633 for ietf-ppp-outgoing; Tue, 24 Feb 1998 21:02:34 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.7/8.8.5) with SMTP id VAA05624 for ; Tue, 24 Feb 1998 21:02:24 -0500 (EST) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id SAA28307; Tue, 24 Feb 1998 18:02:17 -0800 Received: from ascend.com by ascend.com with ESMTP id SAA16507; Tue, 24 Feb 1998 18:01:59 -0800 Received: from ascend.com by ascend.com id RAA21733; Tue, 24 Feb 1998 17:58:41 -0800 Message-Id: <3.0.5.32.19980224175834.00aa9700@darla.ascend.com> X-Sender: mhold@darla.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 24 Feb 1998 17:58:34 -0800 To: Michael Liwerant From: Matt Holdrege Subject: Re: Stac LZS Compression with ASCEND Pipe Line 130 Cc: "'ietf_ppp'" In-Reply-To: <0124851EDBF3D011AAA300008370C8671120FB@MESSENGER> Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu At 10:55 AM 2/24/98 +0200, Michael Liwerant wrote: >>>> ArialHi All, ArialI'll appreciate your advice regarding compatability of ASCEND Pipe Line 130 (Ver 5.0-Ap1) to RFC1974 for testing Stac LZS compression. ArialIt seems that the ASCEND 130 is sending a CCP configure-request packet containing a Stac LZS option length of 6 bytes (while RFC1974 specifies this field as 5 !!!) the actual result is an extra byte added between "History Count" and "Check Mode" fields. ArialHas anyone met the same problem or did I miss something here ? ArialThanks for your response - Michael. <<<<<<<< Ascend's STAC predated RFC 1974. Now you have a configurable choice of STAC or STAC-9 on Ascend units. STAC-9 is based on draft 9 of what became RFC 1974. STAC works with legacy Ascend software. Matt Holdrege http://www.ascend.com matt@ascend.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 26 11:53:57 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA06123; Thu, 26 Feb 1998 11:53:36 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 26 Feb 1998 11:48:51 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA06032 for ietf-ppp-outgoing; Thu, 26 Feb 1998 11:48:51 -0500 (EST) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA06017 for ; Thu, 26 Feb 1998 11:48:43 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id LAA44902; Thu, 26 Feb 1998 11:48:36 -0500 (EST) Received: from lankeeper.raleigh.ibm.com (lankeeper.raleigh.ibm.com [9.37.234.115]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA34852; Thu, 26 Feb 1998 11:48:38 -0500 Received: from socks11.raleigh.ibm.com by lankeeper.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03-RAL) id AA06433; Thu, 26 Feb 1998 11:39:57 -0500 Message-Id: <34F59EEB.7876@vnet.ibm.com> Date: Thu, 26 Feb 1998 11:57:15 -0500 From: Don Grosser Reply-To: dgrosser@vnet.ibm.com Organization: Remote Access Software Development X-Mailer: Mozilla 3.01Gold (Win95; I) Mime-Version: 1.0 To: l2tp@zendo.com, ietf-ppp@merit.edu Subject: Minutes from CIUG bakeoff town meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Here are the minutes from the town meeting at the CIUG interoperability workshop in San Francisco. Please report any issues or mistakes to the mailing list. Wednesday, February 25, 1998 o Tested at the bakeoff: - MLPPP - no issues - BACP/BAP - no issues - CCP - no specification issues - MPPE - no issues - ECP - no issues - EAP - no issues, tested with MD5 only - AO/DI - no issues - L2TP - see comments below... o Not tested at the bakeoff (but were listed): - IPSEC w/L2TP o Next bakeoff: - functions that will be tested: + CCP + L2TP + ECP (with stateless option) + EAP + MPPE + AO/DI - Bob Larribeau will post which protocols will be tested before the next bakeoff. Please send any additional reqests to bob@larribeau.com. o L2TP 1.) typographical problems: + Everyone is strongly encouraged to send typos in draft 09 to the L2TP mailing list. 2.) Clarifications: + It was noted that ACKs should not be delayed on lossy networks > Mark Townsley said that the recommended ACK strategy is modeled after TCP & PPTP. Further, an implementation is free to choose an alternative RTT calculation. + It was noted that bearer and framing types should be clarified > Bill Palter said that framing type is a hint for incoming calls and what is desired for outgoing calls. It is also used for logging purposes. > Clarification will be added. + Clarification for the dialed-number and sub-address semantics will be added. + Most of section 8.1 will be moved to a new lossy-network appendix. + It was noted that examples of partial authentication between the client and LAC should be included. > Mark Townsley said that partial authentication should not violate PPP from the client's perspective. > Examples for common situations will be added. + It was noted that hostname semantics should be clarified. No NULL characters should be included in the hostname AVP. A byte-by-byte check should be sufficient. Presence of the lenth field in the AVP is enough of an inditcation that the string should not be NULL-terminiated. > No clarifying text will be added. + It was noted that one vendor only ACks MRU of 1500 > This is a TCP/MSS/host requirements problem or specific implementation issue rather than a problem with PPP or L2TP. + CHAP re-challenge was a problem for one vendor when the LNS challenged the client with a different name than the name sent in the original challenge from the LAC. The client recognized it was challenged by 2 different peers and hung up. > Karl Fox suggested a knob for the client to turn off this check. + The draft will be updated to state that it is HDLC "slanted". > It was noted that tunneling PPP over X25 could be problematic. + The draft will be updated to say that you can't hide the hostname AVP in any packet or assigned-tunnel-id AVP in the StopCCN. + It was noted that the draft needs to be consistent with its use of the Mandatory-Bit among the table, text and graphics. > Everyone is encouraged to post inconsistencies to the list. + It was noted that there should be more guidance for LCP options on the LNS. > The draft will be changed to point to existing encapsulation specifications for initial parameter suggestions. 3.) Changes to bits over the network + It was noted that we should consider not sending 'FF 03' over the tunnel. > Karl Fox said that it is too late for such a large change to the draft. -- Donald B. Grosser grosser@raleigh.ibm.com IBM Corporation Phone (919)254-2160 Remote Access Software Fax (919)543-7378 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Feb 26 17:38:31 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA13456; Thu, 26 Feb 1998 17:38:24 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 26 Feb 1998 17:37:53 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA13425 for ietf-ppp-outgoing; Thu, 26 Feb 1998 17:37:53 -0500 (EST) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA13421 for ; Thu, 26 Feb 1998 17:37:48 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id RAA75584; Thu, 26 Feb 1998 17:37:41 -0500 (EST) Received: from lankeeper.raleigh.ibm.com (lankeeper.raleigh.ibm.com [9.37.234.115]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA28296; Thu, 26 Feb 1998 17:37:44 -0500 Received: from socks9.raleigh.ibm.com by lankeeper.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03-RAL) id AA06185; Thu, 26 Feb 1998 17:29:02 -0500 Message-Id: <34F5F0B0.7E4F@vnet.ibm.com> Date: Thu, 26 Feb 1998 17:46:08 -0500 From: Don Grosser Reply-To: dgrosser@vnet.ibm.com Organization: Remote Access Software Development X-Mailer: Mozilla 3.01Gold (Win95; I) Mime-Version: 1.0 To: l2tp@zendo.com, ietf-ppp@merit.edu Subject: Re: Minutes from CIUG bakeoff town meeting References: <34F59EEB.7876@vnet.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Don Grosser wrote: > + It was noted that ACKs should not be delayed on lossy networks > > Mark Townsley said that the recommended ACK strategy is > modeled after TCP & PPTP. Further, an implementation is > free to choose an alternative RTT calculation. expanding on this item... The recommendation was to not change the wording on congestion control. The text ALLOWS sending ACKs on a per packet basis, but suggests other techniques that should be used (eg DELAYED ACKS). -- Donald B. Grosser grosser@raleigh.ibm.com IBM Corporation Phone (919)254-2160 Remote Access Software Fax (919)543-7378 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Feb 27 20:05:27 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA09548; Fri, 27 Feb 1998 20:04:53 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 27 Feb 1998 19:57:56 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA09475 for ietf-ppp-outgoing; Fri, 27 Feb 1998 19:57:55 -0500 (EST) Received: from mailserver1.picknowl.com.au (mailserver1.picknowl.com.au [203.24.77.4]) by merit.edu (8.8.7/8.8.5) with SMTP id TAA09470 for ; Fri, 27 Feb 1998 19:57:50 -0500 (EST) Received: from dialin021.picknowl.com.au (dialin021.picknowl.com.au [203.24.76.21]) by mailserver1.picknowl.com.au (NTMail 3.02.13) with ESMTP id ea047168 for ; Sat, 28 Feb 1998 11:27:35 +1030 From: "Shingumi Resources Pty Ltd ACN 080370092" To: Subject: giveaway Date: Sat, 28 Feb 1998 11:25:18 +1030 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Message-Id: <00573560207579@picknowl.com.au> Sender: owner-ietf-ppp@merit.edu Dear Lesson Planner The email address was found at your web site for your school. We believe you might be able to benefit from information about our company and products. Shingumi Resources Pty Ltd is able to provide your school with teaching resources about Japanese culture. Our present special is the $35.00 Daily Life in Japan Unit. This 12-lesson unit is EXCEPTIONAL value and may be photocopied for a single class. Order now and receive 10% discount as well as all of the above. Orders must be received within 30 days of this email. We will be happy to supply you with a free sample of our Japanese culture lessons. Respond to this email to order. We would like to keep you informed of our new education products. If you would like to receive no further mailings please reply with the word "remove' typed in the subject field. Sales Department Shingumi Resources Pty Ltd - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Feb 28 08:53:47 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA15263; Sat, 28 Feb 1998 08:53:14 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Sat, 28 Feb 1998 08:47:20 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA15199 for ietf-ppp-outgoing; Sat, 28 Feb 1998 08:47:19 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.7/8.8.5) with SMTP id IAA15195 for ; Sat, 28 Feb 1998 08:47:15 -0500 (EST) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id FAA15393 for ; Sat, 28 Feb 1998 05:47:14 -0800 Received: from ascend.com by ascend.com with ESMTP id FAA01317 for ; Sat, 28 Feb 1998 05:47:10 -0800 Received: from ascend.com by ascend.com id FAA17757; Sat, 28 Feb 1998 05:43:43 -0800 Message-Id: <3.0.5.32.19980228054600.008fd180@darla.ascend.com> X-Sender: mhold@darla.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 28 Feb 1998 05:46:00 -0800 To: ietf-ppp@merit.edu From: Matt Holdrege Subject: PPPEXT WG Los Angeles agenda call Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Now is the time to submit items for the LA agenda. Our sessions are as follows: Monday, March 30 at 1530-1730 (opposite tls, ecn, manet, mboned) Tuesday, March 31 at 0900-1000 (opposite ospf, otp) So please get your requests for time in as soon as possible. Please try to give presentations that are not simply recitations of drafts. Our time is valuable and we need to dedicate it to low-latency discussions of technical points. P.S. I have not taken over as the WG chair. That is still held by Karl Fox, but Karl will be unfortunately unavailable during this IETF meeting so I have been asked to step in as a sort of "meeting facilitator". I trust you will give me your trust and we can have a couple of productive sessions in Los Angeles. Matt Holdrege http://www.ascend.com matt@ascend.com - - - - - - - - - - - - - - - - -