From owner-ietf-ppp@merit.edu Thu Apr 2 19:14:13 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id TAA00427; Thu, 2 Apr 1998 19:13:50 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 2 Apr 1998 19:08:15 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA00352 for ietf-ppp-outgoing; Thu, 2 Apr 1998 19:08:14 -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 TAA00345 for ; Thu, 2 Apr 1998 19:07:59 -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 QAA16221; Thu, 2 Apr 1998 16:07:54 -0800 Received: from ascend.com by ascend.com with ESMTP id QAA12038; Thu, 2 Apr 1998 16:07:57 -0800 Received: from ascend.com by ascend.com id QAA23334; Thu, 2 Apr 1998 16:04:18 -0800 Message-Id: <3.0.5.32.19980401160735.008dfce0@darla.ascend.com> X-Sender: mhold@darla.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 01 Apr 1998 16:07:35 -0800 To: ietf-ppp@merit.edu From: Matt Holdrege Subject: PPPEXT WG minutes from LA Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Point-to-Point Protocol Extensions Working Group Minutes The PPPext working group met in two sessions, Monday 30 March 1998 at 15:30 - 17:30, and Tuesday 31 March 1998 from 09:00 to 10:00. Matt Holdrege was chairing in place of Karl Fox, who was unable to attend. Minutes were taken by Andy Malis. Session 1: Ken Peirce presented L2TP integration with MPLS Ken gave an overview of MPLS and how it and L2TP could relate to each other. The purpose of his draft is to see if the MPLS label could be used to provide a gross-level QoS and performance specifier on the path. Two possible uses are: 1. Allow the LNS to take advantage of knowledge of existing label switched paths - explicit routes for load balancing. 2. Allow the LNS to "seed" the MPLS mlabel stack to permit fast flow recognition when it reaches the LNS from the LAC. Question during discussion: L2TP has a protocol to allow you to negotiate the mlabel through the AVP. Is there precedent for this, and can other protocols do this? Answer: Not yet, but a similar approach has been discussed in the MPLS group regarding RSVP. You can use this method to set up an explicit route for the tunnel. Ken Peirce also presented L2TP and Differential Services. Ken gave an introduction to the work in the diff-serv working group. The current strawman proposal uses a five-bit "Per-hop behavior", one bit of "In/Out", and two currently unused bits (N.B.: the diff-serv group dropped the "In/Out" bit later in the week). A host will make an explicit bandwidth request to a bandwidth broker. The LNS will use the diff-serv byte to tell the LAC the appropriate value of the byte in the IPv4 header for a call. The LAC may suggest a value, but should consider a value suggested by the LNS to take precedence. The diff-serv octet allows differentiated services to be applied on a per-call basis. You can do differentiated services within a tunnel, and then put a diff-serv octet on the packets for the tunnel itself. Ken intends to ask the PPPext WG to standardize these two drafts. Dave Allan presented his MARS Proxy draft. This was originally presented at the ADSL BOF at the Washington IETF meeting. Starting with the PPP over ATM model for ADSL, this draft allows the provider to add IP multicast for bandwidth-intensive applications. It will use an ATM point-to-multipoint tree instead of PPP over ATM point-to-point connections for the data path. Direct end-host access to MARS has several issues, including provisioning, authentication, and VC frugality, so he is proposing that a proxy be used on behalf of the end users. His proposal is to use a PAP/CHAP authenticated PPP/ATM VC and IGMP. The RAS interworks the IGMP and MARS interaction. The draft allows you to use ATM multicasting or a multicast server (MCS). The MARS proxy will be run by the server provider on behalf of the clients, which have a PPP connection to the proxy. The client uses IGMP to interact with the proxy, just as if it were on a LAN. The MARS proxy then interworks that into the MARS protocol on behalf of the end client. There are several issues: 1. Redirected packet detection. This needs to use type 2 encapsulation, which has MTU implications. 2. The subnet model is broken by this approach. PPP uses host routes, there is no subnet. 3. Use of the source host address and source protocol address changes to permit a proxy to issue a join on behalf of a client. 4. MARS implementations must track group membership by cluster member ID, not ATM address. 5. The MARS client must be able to accept incoming calls - there is not current mechanism to authenticate those calls. There was one question from the audience: You've requested some changes to MARS multicast infrastructure. You are augmenting the PPP session with the multicast service, but this would have been better presented in the ION group? Andy Malis answered this question, stating that this isn't possible due to the current IESG policy to not take on new work in the ion working group, to give the group a chance to get implementation and interoperability experience with its current set of protocols. Bill Palter and Mark Townsley presented an L2TP update. The current L2TP schedule is: 2/23: PPP CIUG interoperability workshop, third workshop with L2TP implementations present, numerous interoperable implementations 3/14: draft 10 was posted to the L2TP mailing list. No bits on the wire changed, just clarifications in the text. 3/15: Karl Fox issued a 2nd WG last call. 3/19: Draft 10 rev II (aka draft 11) was posted to the L2TP mailing list with apologies. 3/20: Karl sent email to the area directors to recommend that L2TP be published as a Proposed Standard RFC. This will occur once the internet draft blackout period ends, and the final version of the draft is available in the internet-drafts directory. There is already lots of interoperability experience; however, there will be another interoperability bakeoff after the next IETF. Question from George Gross: Since this moving to Proposed status, can the framing issue (how to carry non-HLDC framing over L2TP) be revisited? Answer: No, not at this time, but later. But it would need a lot of consensus to change at this time, and would need to be done in a separate document. This would really be an extension that can be in a separate draft. Glen Zorn spoke on MS-MPPE, MS-CHAP, and character set/language negotiation in LCP. The Microsoft specifications are informational documents describing proprietary documents, and the only comments allowed are regarding their completeness or understandability. The important part is that people be able to implement the protocols as documented. He asked for comments on the MS-CHAP document. There were none. He asked for comments on the MS-MPPE document. He's already received a number of comments, and has revised it twice already. Most of the changes are clarifications and examples. The third draft is non-proprietary and standards track, and technical comments are invited. Question from Craig Fox: There was concern regarding string matching in the options in the specification, and whether we can at least list the valid strings, and have numbers associated with them. However, there is a problem with this: there is already a list of character sets and languages with IANA, and we would have to ask IANA to number them and publish them with their numbers. Answer: This will be investigated. Craig volunteered to enumerate the character sets in order to present the enumerated list to IANA. This would modify the draft to make the length of the string three or four, and just use the numbers. There was also discussion on possibly improving the negotiation procedure. The spec will allow multiple languages and character sets in a single request, and if you ACK more than one, then the first one in the ACK will be the one used. There was a comment that this may conflict with standard PPP option mechanisms. If the option is rejected, it goes to the default. There was a suggestion to support more than one option in the configure request, because you don't know how the server is going to be configured. This will be taken to the list - there was no final decision made in the group. There were several questions concerning details in the MPPE draft, which Glen answered. What does the MPPE receiver do when the flush bit is set because of compression expansion? Does the key get updated, or does it go back to the original key? A: The key only gets updated whenever there is data loss, or when the flush bit is set (it is being treated as packet loss). Q: You're initializing with the current key, rather than rekeying? A: The receiver must reinitialize its tables but does not rekey. But you do rekey in stateless mode on every packet. This will be further discussed offline and then they will let the list know the result. George Gross spoke on PPP over AAL5. George announced a compromise agreement for PPP over AAL5 to allow the draft to be approved by the IESG. The IESG was concerned about interoperability, especially when interworking with an RFC 1973 (PPP over FR) endpoint. The essence is that the internet draft will require both VC-multiplexed and multiprotocol-encapsulated PPP in order to be conformant. There will also be modifications on the signaling section, and an exception to the VC-multiplexed requirement for interworking with RFC 1973. There was an interoperability testing event at UNH last week, and George will be making some updates to the draft based upon that experience. Matt Holdrege asked the group whether L2TP over non-IP media, such as AAL5, is important, and whether the WG should be working on L2TP over AAL5 in particular. This was felt to be important several years ago, but it seems to have cooled off somewhat. A comment was made that L2TP over FR might make more sense than AAL5. There was another comment made that there needs to be a multiplexing mechanism to allow multiple L2TP sessions. There are also people looking at L2TP bridges. Rohit Verma said that he would be willing to work on L2TP over non-IP networks. Mark said that the L2TP draft is already pretty self-sufficient (just section 8 is IP-specific). Rohit said that there were some open issues that could be discussed in the draft. Carsten Bormann spoke about ISSLOW issues: Integrated Services on low-bitrate links. Up to now, Integrated Services has been on high-speed links only. ISSLOW was meant to extend this to modem lines up to 56 Kbps, ISDN, low speed leased lines up to 128K, fractional T1, etc. The three problems are: 1. Low-speed links blocked by large frames, which kill latency for real-time packets, fixed by fragmentation and suspend/resume; 2. The header overhead, fixed with header compression; 3. It's difficult to reserve bandwidth when header compression produces variable results. This is still an open issue. One thing that may come up in this group to help support ISSLOW is link characteristic determination, such as round-trip delay. Another open issue is real-time encapsulation, which is need to minimize worst case end-to-end delay for real-time streams, maximize available bandwidth, minimize overhead, and be predicable enough for admission control. It cooperate nicely with PPP, work with existing chips and router systems, and be future proof (for example, modem protocol developments). The possible design avenues are abort/suspend, cell-oriented + final bit vs. suspend/resume, where to place the suspend information, how many priorities, and where to put error control. Two solutions need to be provided: 1. Transmitter fragments large packets down to the latency goal (for example, about 128 bytes). You must pay fragment overhead (similar to cell tax for ATM). PPP multilink is almost it. 2. For the best latency, send an interrupt packet immediately. You need a way to suspend the frame being sent. Challenge: Define a scheme where fragmenters and suspenders can happily interoperate. Fortunately, this is just a differentiation on the sending side. PPP multilink has one problem: the serial sequence numbering does not allow suspension, but you can still send intervening non-multilink packets. So you can send two multilink fragments separated by a non-multilink packet. However, this only provides a single level of priority. If you need more than two levels, you need to add two "class" bits to the standard PPP multilink header. This allows 4 instances of the PPP multilink protocol to run in parallel with four sequence spaces. This is in draft-issll-isslow-mcml-0x.txt. Real-time framing allows suspending of packets at any time. This is compatible with type-2 receivers (which have basic HDLC hardware). Multilink support is optional. The approach is that there is a second-level scan. HDLC framing is unchanged, but in the payload of the HDLC frames, there is a fragment suspend escape (FSE), 0xDE. There is a new compressed multilink header, from three bytes to one byte: 3-bit sequence number, 3-bit class number, one R bit (which is the inverted B bit), and a "1" in the low bit. The bit combination 0xFF cannot be used, so class 7 cannot be suspended and does not need a sequence number. 0xFF is an escape back to normal PPP headers. When a 0xDE occurs in the data, it has to be escaped using a form of byte stuffing so that a suspension does not occur. There is a maximum expansion of 25%. There are MRU issues, and a single-automaton implementation requires a two-byte delay for CRC. There are two new LCP options: Multilink header format option (27), and Prefix elision (26). They could not use option 18 for the former because of backwards compatibility issues. The latter is somewhat odd, in that it negotiates the behavior of the sender rather than the receiver. How does this relate to Consistent Overhead Bytes Stuffing (COBS)? It produces better efficiency, but is not compatible with current HDLC chips. It could be used instead of HDLC as the outer encapsulation of the frames. This is good for high-sped links such as SONET (very efficient to implement). In the ISSLL group, there has been a last call for the work described here. The purpose of this talk was to introduce the work to the group and invite their comments to the last call. There were several comments regarding the prefix elision option. There was some concern expressed because it is negotiating the sender behavior. There was a question why the short header negotiation was part of option 27, rather than 18. At this point, Carsten's presentation was interrupted by the end of the session. Second session: Dave Thaler quickly presented the tunnel MIB. The tunnel MIB extends the interfaces MIB for certain rows, and the L2TP MIB further extends the tunnel MIB. They share the same ifIndex value for the applicable rows. Evan Caves presented the L2TP MIB. There are four L2TP MIB groups, the scalar group, the tunnel group, the session group, and the transport group. Proposed changes and issues: * Relationship to Dave Thaler's Tunnel MIB - this will be updated * How is the session table instantiated? * Tunnel Domain Group * Configuration Table * Statistics Table - more appropriate to have statistics based on groups of hosts * Reduce number of objects They intend to add a tunnel session table in the tunnel MIB to correspond with the L2TP session table. Comment: That approach is preferred to having to walk the entire MIB table to find session table entries. Comment: There need to be more statistics for the LNC, and the MIB is IP-centric. L2TP will be run over other media besides IP. Matt asked that detailed comments be addressed to the list. John Shriver presented some MIB issues that he had sent to the list. Tunnel configuration lookup rules are a key issue - tunnel configuration is really very different at the LAC and LNS. It may be better to have different tables for calling and called parties. The row-create model of the configuration tables is completely ignored. There needs to be a good deal more thinking about how the various parts of configuration fit together. There was discussion of how the tables should be indexed for best lookup capabilities. This will be further discussed on the list. The discussion as a whole will be taken back to the list. The tunnel table will be instantiated in the ifTable. There was no consensus on how to instantiate the L2TP session entries, whether in the ifTable or in the L2TP tunnel table. Carsten Bormann continued his ISSLOW talk from the first session. He is going to make the following updates to the spec, both regarding option 27 (multilink header format): * Explain multiple occurrences * Add parameter for number of suspendable classes, so that it can be negotiated The replacement text will be sent to the PPPext email list. However, since it has already been through last-call in ISSLL, he would propose to end the discussion by April 20. The prefix elision option (27) is going to be moved to a separate draft, with more discussion, based upon yesterday's discussion. The group discussed whether to have multiple options in LCP, or to have one option with multiple bits to select various behaviors. There were concerns that these options could cause multiple rounds of option negotiation. There were suggestions to make certain choices mandatory, to help options negotiation converge. The option numbers 27 and 26 have been assigned by IANA. Bernard Aboba spoke on L2TP security. A new draft has been sent out. Key management has been taken out, and replaced by a pointer to ipsec. Please send comments to the list. There was discussion about when the L2TP security draft should be advanced. Matt suggested that it have a security review for comments, and then go to WG last call. The suggestion was made that the security folks are overloaded, and it might be better to get their attention by going directly to last call. Matt Holdrege http://www.ascend.com matt@ascend.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Apr 3 04:39:16 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id EAA05308; Fri, 3 Apr 1998 04:39:02 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 3 Apr 1998 04:36:48 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA05285 for ietf-ppp-outgoing; Fri, 3 Apr 1998 04:36:48 -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 EAA05281 for ; Fri, 3 Apr 1998 04:36:44 -0500 (EST) Received: from localhost (uucp@localhost) by btmplq.god.bel.alcatel.be (8.6.5/8.6.5) id LAA01822 for ; Fri, 3 Apr 1998 11:35:18 +0200 Received: from we2ws118.sebb.bel.alcatel.be(138.203.168.118) by btmplq via smap (V1.3) id sma001793; Fri Apr 3 11:35:12 1998 Message-ID: <3524AD98.80D6F521@sebb.bel.alcatel.be> Date: Fri, 03 Apr 1998 11:36:24 +0200 From: Tim Van Herck Reply-To: herckt@sebb.bel.alcatel.be Organization: Alcatel Telecom - Access Systems Division X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: ietf-ppp-request@merit.edu Content-Type: multipart/mixed; boundary="------------C9ADA168CDC037EE2AB25CE8" Sender: owner-ietf-ppp@merit.edu This is a multi-part message in MIME format. --------------C9ADA168CDC037EE2AB25CE8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ietf-ppp-request@merit.edu --------------C9ADA168CDC037EE2AB25CE8 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tim Van Herck Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Tim Van Herck n: Van Herck;Tim org: Alcatel Telecom -- Access Systems Division adr: Francis Wellensplein 1;;;Antwerpen;;B - 2018;Belgium email;internet: herckt@sebb.bel.alcatel.be title: System & Network Integration Engineer tel;work: + 32 3 240 8191 tel;fax: + 32 3 240 9920 x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------C9ADA168CDC037EE2AB25CE8-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Apr 7 10:13:47 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA00450; Tue, 7 Apr 1998 10:13:19 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Apr 1998 10:05:31 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA00219 for ietf-ppp-outgoing; Tue, 7 Apr 1998 10:05:30 -0400 (EDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA00215 for ; Tue, 7 Apr 1998 10:05:26 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id KAA28335; Tue, 7 Apr 1998 10:05:22 -0400 (EDT) Message-Id: <199804071405.KAA28335@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-mppe-01.txt Date: Tue, 07 Apr 1998 10:05:21 -0400 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 : Microsoft Point-To-Point Encryption (MPPE) Protocol Author(s) : G. Zorn, G. Pall Filename : draft-ietf-pppext-mppe-01.txt Pages : 15 Date : 06-Apr-98 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links. This document describes the use of the Microsoft Point to Point Encryp- tion (MPPE) to enhance the confidentiality of encrypted PPP-encapsulated packets. 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-mppe-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-mppe-01.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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-mppe-01.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980406155310.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-mppe-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-mppe-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980406155310.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Apr 7 10:13:47 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA00458; Tue, 7 Apr 1998 10:13:20 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Apr 1998 10:05:20 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA00207 for ietf-ppp-outgoing; Tue, 7 Apr 1998 10:05:19 -0400 (EDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA00203 for ; Tue, 7 Apr 1998 10:05:15 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id KAA28302; Tue, 7 Apr 1998 10:05:11 -0400 (EDT) Message-Id: <199804071405.KAA28302@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu, l2tp@zendo.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-l2tp-10.txt Date: Tue, 07 Apr 1998 10:05:10 -0400 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' Author(s) : A. Rubens, W. Palter, T. Kolar, G. Pall, M. Littlewood, A. Valencia, K. Hamzeh, W. Verthein, J. Taarud, W. Townsley Filename : draft-ietf-pppext-l2tp-10.txt Pages : 92 Date : 06-Apr-98 Virtual dial-up allows many separate and autonomous protocol domains to share common access infrastructure including modems, Access Servers, and ISDN routers. RFC 1661 specifies multi-protocol dial-up via PPP [1]. This document describes the Layer Two Tunneling Protocol (L2TP) which permits the tunneling of the link layer (i.e., HDLC, async HDLC) of PPP. Using such tunnels, it is possible to divorce the location of the initial dial-up server from the location at which the dial-up protocol connection is terminated and access to the network provided. 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-10.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-l2tp-10.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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-l2tp-10.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980406141905.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tp-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tp-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980406141905.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Apr 7 10:13:47 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA00454; Tue, 7 Apr 1998 10:13:19 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Apr 1998 10:05:09 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA00195 for ietf-ppp-outgoing; Tue, 7 Apr 1998 10:05:09 -0400 (EDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA00191 for ; Tue, 7 Apr 1998 10:05:04 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id KAA28243; Tue, 7 Apr 1998 10:05:00 -0400 (EDT) Message-Id: <199804071405.KAA28243@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-lbd-00.txt Date: Tue, 07 Apr 1998 10:04:59 -0400 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 : PPP Link Balancing Detection (LBD) Author(s) : J. Carlson Filename : draft-ietf-pppext-lbd-00.txt Pages : 5 Date : 06-Apr-98 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows the detection of optional link handling procedures, as well as a Multilink procedure (MP) [2] which allows operation over multiple physical links. This document defines an extension to MP called Link Balancing Detection (LBD). 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-lbd-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-lbd-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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-lbd-00.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980406140836.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-lbd-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-lbd-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980406140836.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Apr 7 11:10:30 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA01693; Tue, 7 Apr 1998 11:10:28 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Apr 1998 11:08:32 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA01621 for ietf-ppp-outgoing; Tue, 7 Apr 1998 11:08:30 -0400 (EDT) Received: from lynx.europe.shiva.com (lynx.europe.shiva.com [134.191.64.5]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA01610 for ; Tue, 7 Apr 1998 11:08:23 -0400 (EDT) Received: from chryses.europe.shiva.com (gerry@chryses.europe.shiva.com [134.191.8.223]) by lynx.europe.shiva.com (8.8.8/8.8.8) with ESMTP id QAA14036; Tue, 7 Apr 1998 16:07:50 +0100 (BST) Received: from localhost (gerry@localhost) by chryses.europe.shiva.com (8.8.8/8.8.8) with SMTP id QAA07675; Tue, 7 Apr 1998 16:07:38 +0100 (BST) Date: Tue, 7 Apr 1998 16:07:37 +0100 (BST) From: Gerry Meyer To: James Carlson cc: ietf-ppp@merit.edu Subject: Re: An MP alternative In-Reply-To: <199803271408.JAA02376@ironbridgenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Since the only rational given for your proposal is that fragmentation is undesirable on high speed links, would it not be more appropriate to include a sentence to that effect in the next multilink RFC (which must be ready to advance by now). Gerry On Fri, 27 Mar 1998, James Carlson wrote: > I'd like to propose the following as an alternative to full-blown MP > for very high speed (ie, SONET/SDH) systems using PPP. I think the > rest of the text stands on its own. Please post any comments to the > list. Thanks! > > > > > > PPP Working Group J. Carlson > Internet Draft IronBridge Networks > expires in six months April 1998 > > > PPP Link Balancing Detection (LBD) > > > Status of this Memo > > This document is the product of the Point-to-Point Protocol > Extensions Working Group of the Internet Engineering Task Force > (IETF). Comments should be submitted to the ietf-ppp@merit.edu > mailing list. > > Distribution of this memo is unlimited. > > This document is an Internet-Draft. Internet-Drafts are working > documents of the Internet Engineering Task Force (IETF), its areas, > and its working groups. Note that other groups may also distribute > working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months. Internet-Drafts may be updated, replaced, or obsoleted by > other documents at any time. It is not appropriate to use Internet- > Drafts as reference material or to cite them other than as a > ``working draft'' or ``work in progress.'' > > To learn the current status of any Internet-Draft, please check the > 1id-abstracts.txt listing contained in the Internet-Drafts Shadow > Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or > munnari.oz.au. > > Abstract > > The Point-to-Point Protocol (PPP) [1] provides a standard method for > transporting multi-protocol datagrams over point-to-point links. > > PPP also defines an extensible Link Control Protocol, which allows > the detection of optional link handling procedures, as well as a > Multilink procedure (MP) [2] which allows operation over multiple > physical links. This document defines an extension to MP called Link > Balancing Detection (LBD). > > > > > > > > > Carlson expires October 1998 [Page 1] > > INTERNET DRAFT PPP Link Balancing Detection April 1998 > > > Table of Contents > > 1. Introduction ........................................... 2 > 1.1. Conventions ............................................ 3 > 2. MRRU Configuration Option Modification ................. 3 > 3. Bundle Establishment ................................... 3 > 4. Bundle Tear-Down ....................................... 4 > 5. Message Distribution ................................... 4 > 6. Security Issues ........................................ 5 > 7. References ............................................. 5 > 8. Authors' Addresses ..................................... 5 > > > 1. Introduction > > Standard PPP negotiation allows for two types of links with regard to > multiple link layer entities. The standard type of PPP link is nego- > tiated without the Maximum-Receive-Reconstructed-Unit (MRRU) option > and appears as a separate network interface to the network layer and > to routing protocols. The Multilink PPP (MP) [2] type of link uses > the MRRU option and allows multiple PPP links to be bundled into one > network interface. An MP link appears as a single network interface > to the network layer and to routing protocols. > > There are many advantages having multiple links between two nodes > appear at the network layer to be a single link. One is that less > stress is placed on scarce routing system resources, and another is > that routing system stability in the face of errors is usually > higher. > > The main disadvantage to the current MP technique is that it does not > constrain the fragmentation which may be done by the peer. For sys- > tems employing general purpose CPUs in the data path and with > scatter-gather direct memory access (DMA) capability, this is often > not a problem. For systems with very high bandwidth capabilities, > these features are often infeasible, and this problem makes MP unus- > able. > > This draft describes a method similar to (and compatible with) MP for > detecting multiple links to the same node, but without the fragmenta- > tion or reordering protection of MP. Instead, datagrams are distri- > buted intact among the links in any convenient manner, including > based on an IP [3] address hash or simple round-robbin service. > > > > > > > > > Carlson expires October 1998 [Page 2] > > INTERNET DRAFT PPP Link Balancing Detection April 1998 > > > 1.1. Conventions > > The following language conventions are used in the items of specifi- > cation in this document: > > o MUST, SHALL, or MANDATORY -- This item is an absolute require- > ment of the specification. > > o SHOULD or RECOMMEND -- This item should generally be followed > for all but exceptional circumstances. > > o MAY or OPTIONAL -- This item is truly optional and may be fol- > lowed or ignored according to the needs of the implementor. > > > 2. MRRU Configuration Option Modification > > The MRRU option from MP is modified to allow a new distinguished > value. This value is zero, and indicates that the Configure-Request > sender wishes to bundle multiple links but refuses to reconstruct > received fragmented datagrams or to use the header as defined in MP. > > The receiver of Configure-Request with MRRU set to zero MAY > Configure-Reject it to disable all MP support, including LBD, or MAY > send Configure-Nak with a hint set non-zero to request standard MP > support, or MAY send Configure-Ack to indicate its willingness to run > LBD. > > Both peers MUST agree that MRRU is not in effect, or that it is zero, > or that it has a non-zero value. If MRRU has a non-zero value, how- > ever, it need not be identical in each direction. If LCP goes to > Open state with the MRRUs set to an illegal set of values (id est, > one zero and the other non-zero), then an implementation SHOULD ter- > minate the link or MAY choose to renegotiate LCP. > > > > 3. Bundle Establishment > > As with MP, bundle establishment is based on a combination of the > peer's supplied endpoint discriminator (ED) and the peer's identity > as determined via link authentication. The algorithm used for LBD is > identical to the MP algorithm, and is documented here only for con- > venience. > > When authentication (if any was negotiated via LCP) is complete, a > check is made before attempting to negotiate any Network Control Pro- > tocols (NCPs). If an MRRU (either zero or non-zero) is agreed to by > > > > Carlson expires October 1998 [Page 3] > > INTERNET DRAFT PPP Link Balancing Detection April 1998 > > > both peers and if there is an existing LBD bundle where the ED (or > lack thereof) matches the new link's ED (or lack), and the authenti- > cated peer name (or lack thereof) match the new link's peer name (or > lack), then this new link should be made part of the bundle and no > new NCPs are created. Otherwise, this is a separate link, and NCPs > should be started. > > If the local and remote MRRU values do not agree with the bundle, > then the link SHOULD be terminated. An implementation MAY choose > instead to renegotiate LCP to repair the error. If the MRRU values > are zero, then the MRU values MUST also be checked in the same > manner. > > When LBD is in effect, in contrast with standard MP, the value adver- > tised to the network layer as the MTU MUST be the peer's requested > MRU (or any smaller value), rather than the negotiated MRRU. > > > > 4. Bundle Tear-Down > > Tear-down is identical to standard MP and is thus not covered here. > > > > 5. Message Distribution > > To distribute messages among the links, a few simple rules must be > followed. > > First, since PPP negotiation does not withstand reordering, all PPP > negotiation messages MUST be sent over a single link to avoid possi- > ble reordering. The first link in a bundle MUST be used to transmit > PPP messages until this link is terminated. If the first link is > terminated, then one remaining link in the bundle MUST be chosen for > subsequent messages. Once that link is chosen, an implementation > MUST continue sending all PPP negotiation messages over that single > link. Any remaining link in the bundle MAY be chosen, and it is > entirely possible that each peer may choose a different link without > harm to the PPP protocol. > > Second, PPP negotiation messages MUST be handled when received on any > link. An implementation MAY choose to terminate the last link over > which negotiation was received if negotiation is received over a dif- > ferent link, since this transition implies that the peer has already > terminated the prior link. > > Third, network datagrams SHOULD be distributed over all links as > > > > Carlson expires October 1998 [Page 4] > > INTERNET DRAFT PPP Link Balancing Detection April 1998 > > > evenly as possible. There are no requirements that any particular > distribution algorithm be used. Note, however, that some network > protocols behave poorly when subjected to message reordering, so > techniques which prevent reordering (such as deterministic hashes of > network layer addresses) are encouraged. > > Fourth, the common but technically non-standard practice of using LCP > Terminate-Request to gracefully terminate a link without data loss is > encouraged in LBD implementations. To do this, an implementation > leaves Open state on sending LCP Terminate-Request, but, contrary to > RFC 1661 [1], continues processing received datagrams until the peer > replies with LCP Terminate-Ack. > > > > 6. Security Issues > > The authentication and bundling techniques are identical to standard > MP and the security issues are the same as with RFC 1990. > > > > 7. References > > [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, > 07/21/1994 > > [2] K. Sklower, et al, "The PPP Multilink Protocol (MP)", RFC 1990, > 08/1996 > > [3] J. Postel, "Internet Protocol", RFC 791, 09/01/1981 > > > 8. Author's Address > > James Carlson > IronBridge Networks > 55 Hayden Avenue > Lexington MA 02173-7999 > > Phone: +1 781 402 8032 > Fax: +1 781 402 8092 > Email: carlson@ironbridgenetworks.com > > > > > > > > > Carlson expires October 1998 [Page 5] > > > -- > 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 Apr 7 12:03:20 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA02756; Tue, 7 Apr 1998 12:03:03 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Apr 1998 12:00:00 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA02672 for ietf-ppp-outgoing; Tue, 7 Apr 1998 11:59:59 -0400 (EDT) Received: from ironbridgenetworks.com ([146.115.140.2]) by merit.edu (8.8.7/8.8.5) with SMTP id LAA02668 for ; Tue, 7 Apr 1998 11:59:55 -0400 (EDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id LAA03788; Tue, 7 Apr 1998 11:59:50 -0400 Date: Tue, 7 Apr 1998 11:59:50 -0400 Message-Id: <199804071559.LAA03788@ironbridgenetworks.com> From: James Carlson To: gerry@europe.shiva.com CC: ietf-ppp@merit.edu In-reply-to: (message from Gerry Meyer on Tue, 7 Apr 1998 16:07:37 +0100 (BST)) Subject: Re: An MP alternative References: Sender: owner-ietf-ppp@merit.edu > Since the only rational given for your proposal is that > fragmentation is undesirable on high speed links, would it not > be more appropriate to include a sentence to that effect in the > next multilink RFC (which must be ready to advance by now). That's a perfectly acceptable solution to me provided that the next MP RFC describes that this is an option, and how to properly negotiate that both peers want to do this. (It's not clear what the dividing line between "low" and "high" speed links might be, and the line probably moves over time, and the position of the line at any point in time probably also depends on the architecture of the device itself. This argues that it should be a negotiable item, rather than just a convention for usage.) I think this amounts to a little more than a single sentence (but only a little more). There's certainly more than one way to skin this cat, and I'm not wedded to either solution (separate RFC or integrated). Any comments from Mr. Sklower (et al)? (It's been pointed out to me in private email that I didn't adequately note that, for instance, OSPF can detect ECMP. This is a more general mechanism, since the equal cost paths might take arbitrary walks through the topology, and it does have scaling problems which are exacerbated by having multiple parallel links. The good thing about this approach is that with a given set of constraints on OSPF, a network can scale further by using this simple mechanism.) (It was also pointed out that a "minor" modification to OSPF could allow it to detect that a set of links were all connected to a single peer and then emit a single LSA for the group of links. This does require a modified OSPF at both ends [it just won't do to have one side generate a single LSA and the other generate many] but it doesn't seem as simple as this mechanism.) -- 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 Apr 7 12:28:32 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA03311; Tue, 7 Apr 1998 12:28:29 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Apr 1998 12:25:30 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA03223 for ietf-ppp-outgoing; Tue, 7 Apr 1998 12:25:29 -0400 (EDT) Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA03216 for ; Tue, 7 Apr 1998 12:25:23 -0400 (EDT) Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id JAA12962 for ; Tue, 7 Apr 1998 09:24:52 -0700 (PDT) Date: Tue, 7 Apr 1998 09:24:52 -0700 (PDT) From: John Bray Reply-To: John Bray To: ietf-ppp@merit.edu Subject: Re: An MP alternative In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Tue, 7 Apr 1998, Gerry Meyer wrote: > > Since the only rational given for your proposal is that > fragmentation is undesirable on high speed links, would it not > be more appropriate to include a sentence to that effect in the > next multilink RFC (which must be ready to advance by now). > > Gerry I agree, the issue is really whether you want fragmentation or not. Removing multilink headers completely means you can only support protocols that are insensitive to reordering unless you force such packets over one link. An option which disables fragmentation without also removing MP headers would be more desireable. John > > > > On Fri, 27 Mar 1998, James Carlson wrote: > > > I'd like to propose the following as an alternative to full-blown MP > > for very high speed (ie, SONET/SDH) systems using PPP. I think the > > rest of the text stands on its own. Please post any comments to the > > list. Thanks! > > > > > > > > > > > > PPP Working Group J. Carlson > > Internet Draft IronBridge Networks > > expires in six months April 1998 > > > > > > PPP Link Balancing Detection (LBD) > > > > > > Status of this Memo > > > > This document is the product of the Point-to-Point Protocol > > Extensions Working Group of the Internet Engineering Task Force > > (IETF). Comments should be submitted to the ietf-ppp@merit.edu > > mailing list. > > > > Distribution of this memo is unlimited. > > > > This document is an Internet-Draft. Internet-Drafts are working > > documents of the Internet Engineering Task Force (IETF), its areas, > > and its working groups. Note that other groups may also distribute > > working documents as Internet-Drafts. > > > > Internet-Drafts are draft documents valid for a maximum of six > > months. Internet-Drafts may be updated, replaced, or obsoleted by > > other documents at any time. It is not appropriate to use Internet- > > Drafts as reference material or to cite them other than as a > > ``working draft'' or ``work in progress.'' > > > > To learn the current status of any Internet-Draft, please check the > > 1id-abstracts.txt listing contained in the Internet-Drafts Shadow > > Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or > > munnari.oz.au. > > > > Abstract > > > > The Point-to-Point Protocol (PPP) [1] provides a standard method for > > transporting multi-protocol datagrams over point-to-point links. > > > > PPP also defines an extensible Link Control Protocol, which allows > > the detection of optional link handling procedures, as well as a > > Multilink procedure (MP) [2] which allows operation over multiple > > physical links. This document defines an extension to MP called Link > > Balancing Detection (LBD). > > > > > > > > > > > > > > > > > > Carlson expires October 1998 [Page 1] > > > > INTERNET DRAFT PPP Link Balancing Detection April 1998 > > > > > > Table of Contents > > > > 1. Introduction ........................................... 2 > > 1.1. Conventions ............................................ 3 > > 2. MRRU Configuration Option Modification ................. 3 > > 3. Bundle Establishment ................................... 3 > > 4. Bundle Tear-Down ....................................... 4 > > 5. Message Distribution ................................... 4 > > 6. Security Issues ........................................ 5 > > 7. References ............................................. 5 > > 8. Authors' Addresses ..................................... 5 > > > > > > 1. Introduction > > > > Standard PPP negotiation allows for two types of links with regard to > > multiple link layer entities. The standard type of PPP link is nego- > > tiated without the Maximum-Receive-Reconstructed-Unit (MRRU) option > > and appears as a separate network interface to the network layer and > > to routing protocols. The Multilink PPP (MP) [2] type of link uses > > the MRRU option and allows multiple PPP links to be bundled into one > > network interface. An MP link appears as a single network interface > > to the network layer and to routing protocols. > > > > There are many advantages having multiple links between two nodes > > appear at the network layer to be a single link. One is that less > > stress is placed on scarce routing system resources, and another is > > that routing system stability in the face of errors is usually > > higher. > > > > The main disadvantage to the current MP technique is that it does not > > constrain the fragmentation which may be done by the peer. For sys- > > tems employing general purpose CPUs in the data path and with > > scatter-gather direct memory access (DMA) capability, this is often > > not a problem. For systems with very high bandwidth capabilities, > > these features are often infeasible, and this problem makes MP unus- > > able. > > > > This draft describes a method similar to (and compatible with) MP for > > detecting multiple links to the same node, but without the fragmenta- > > tion or reordering protection of MP. Instead, datagrams are distri- > > buted intact among the links in any convenient manner, including > > based on an IP [3] address hash or simple round-robbin service. > > > > > > > > > > > > > > > > > > Carlson expires October 1998 [Page 2] > > > > INTERNET DRAFT PPP Link Balancing Detection April 1998 > > > > > > 1.1. Conventions > > > > The following language conventions are used in the items of specifi- > > cation in this document: > > > > o MUST, SHALL, or MANDATORY -- This item is an absolute require- > > ment of the specification. > > > > o SHOULD or RECOMMEND -- This item should generally be followed > > for all but exceptional circumstances. > > > > o MAY or OPTIONAL -- This item is truly optional and may be fol- > > lowed or ignored according to the needs of the implementor. > > > > > > 2. MRRU Configuration Option Modification > > > > The MRRU option from MP is modified to allow a new distinguished > > value. This value is zero, and indicates that the Configure-Request > > sender wishes to bundle multiple links but refuses to reconstruct > > received fragmented datagrams or to use the header as defined in MP. > > > > The receiver of Configure-Request with MRRU set to zero MAY > > Configure-Reject it to disable all MP support, including LBD, or MAY > > send Configure-Nak with a hint set non-zero to request standard MP > > support, or MAY send Configure-Ack to indicate its willingness to run > > LBD. > > > > Both peers MUST agree that MRRU is not in effect, or that it is zero, > > or that it has a non-zero value. If MRRU has a non-zero value, how- > > ever, it need not be identical in each direction. If LCP goes to > > Open state with the MRRUs set to an illegal set of values (id est, > > one zero and the other non-zero), then an implementation SHOULD ter- > > minate the link or MAY choose to renegotiate LCP. > > > > > > > > 3. Bundle Establishment > > > > As with MP, bundle establishment is based on a combination of the > > peer's supplied endpoint discriminator (ED) and the peer's identity > > as determined via link authentication. The algorithm used for LBD is > > identical to the MP algorithm, and is documented here only for con- > > venience. > > > > When authentication (if any was negotiated via LCP) is complete, a > > check is made before attempting to negotiate any Network Control Pro- > > tocols (NCPs). If an MRRU (either zero or non-zero) is agreed to by > > > > > > > > Carlson expires October 1998 [Page 3] > > > > INTERNET DRAFT PPP Link Balancing Detection April 1998 > > > > > > both peers and if there is an existing LBD bundle where the ED (or > > lack thereof) matches the new link's ED (or lack), and the authenti- > > cated peer name (or lack thereof) match the new link's peer name (or > > lack), then this new link should be made part of the bundle and no > > new NCPs are created. Otherwise, this is a separate link, and NCPs > > should be started. > > > > If the local and remote MRRU values do not agree with the bundle, > > then the link SHOULD be terminated. An implementation MAY choose > > instead to renegotiate LCP to repair the error. If the MRRU values > > are zero, then the MRU values MUST also be checked in the same > > manner. > > > > When LBD is in effect, in contrast with standard MP, the value adver- > > tised to the network layer as the MTU MUST be the peer's requested > > MRU (or any smaller value), rather than the negotiated MRRU. > > > > > > > > 4. Bundle Tear-Down > > > > Tear-down is identical to standard MP and is thus not covered here. > > > > > > > > 5. Message Distribution > > > > To distribute messages among the links, a few simple rules must be > > followed. > > > > First, since PPP negotiation does not withstand reordering, all PPP > > negotiation messages MUST be sent over a single link to avoid possi- > > ble reordering. The first link in a bundle MUST be used to transmit > > PPP messages until this link is terminated. If the first link is > > terminated, then one remaining link in the bundle MUST be chosen for > > subsequent messages. Once that link is chosen, an implementation > > MUST continue sending all PPP negotiation messages over that single > > link. Any remaining link in the bundle MAY be chosen, and it is > > entirely possible that each peer may choose a different link without > > harm to the PPP protocol. > > > > Second, PPP negotiation messages MUST be handled when received on any > > link. An implementation MAY choose to terminate the last link over > > which negotiation was received if negotiation is received over a dif- > > ferent link, since this transition implies that the peer has already > > terminated the prior link. > > > > Third, network datagrams SHOULD be distributed over all links as > > > > > > > > Carlson expires October 1998 [Page 4] > > > > INTERNET DRAFT PPP Link Balancing Detection April 1998 > > > > > > evenly as possible. There are no requirements that any particular > > distribution algorithm be used. Note, however, that some network > > protocols behave poorly when subjected to message reordering, so > > techniques which prevent reordering (such as deterministic hashes of > > network layer addresses) are encouraged. > > > > Fourth, the common but technically non-standard practice of using LCP > > Terminate-Request to gracefully terminate a link without data loss is > > encouraged in LBD implementations. To do this, an implementation > > leaves Open state on sending LCP Terminate-Request, but, contrary to > > RFC 1661 [1], continues processing received datagrams until the peer > > replies with LCP Terminate-Ack. > > > > > > > > 6. Security Issues > > > > The authentication and bundling techniques are identical to standard > > MP and the security issues are the same as with RFC 1990. > > > > > > > > 7. References > > > > [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, > > 07/21/1994 > > > > [2] K. Sklower, et al, "The PPP Multilink Protocol (MP)", RFC 1990, > > 08/1996 > > > > [3] J. Postel, "Internet Protocol", RFC 791, 09/01/1981 > > > > > > 8. Author's Address > > > > James Carlson > > IronBridge Networks > > 55 Hayden Avenue > > Lexington MA 02173-7999 > > > > Phone: +1 781 402 8032 > > Fax: +1 781 402 8092 > > Email: carlson@ironbridgenetworks.com > > > > > > > > > > > > > > > > > > Carlson expires October 1998 [Page 5] > > > > > > -- > > 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 Apr 7 13:22:20 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA04297; Tue, 7 Apr 1998 13:22:16 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Apr 1998 13:19:11 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA04217 for ietf-ppp-outgoing; Tue, 7 Apr 1998 13:19:10 -0400 (EDT) Received: from ironbridgenetworks.com ([146.115.140.2]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA04210 for ; Tue, 7 Apr 1998 13:19:05 -0400 (EDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id NAA06555; Tue, 7 Apr 1998 13:18:59 -0400 Date: Tue, 7 Apr 1998 13:18:59 -0400 Message-Id: <199804071718.NAA06555@ironbridgenetworks.com> From: James Carlson To: bray@cisco.com CC: ietf-ppp@merit.edu In-reply-to: (message from John Bray on Tue, 7 Apr 1998 09:24:52 -0700 (PDT)) Subject: Re: An MP alternative References: Sender: owner-ietf-ppp@merit.edu > > Since the only rational given for your proposal is that > > fragmentation is undesirable on high speed links, would it not > > be more appropriate to include a sentence to that effect in the > > next multilink RFC (which must be ready to advance by now). > > > > Gerry > > I agree, the issue is really whether you want fragmentation or not. > Removing multilink headers completely means you can only support > protocols that are insensitive to reordering unless you force such > packets over one link. An option which disables fragmentation without > also removing MP headers would be more desireable. I disagree. Removing the MP headers (or at least the normal affect of the headers) is also required here. There are two points here. The first is that fragmentation by the peer is harmful to an all-hardware implementation since it implies aribrary-sized data block handling. The second is that the reordering implied by the MP sequence numbers is itself also harmful in hardware implementations since it implies dedicated message-sorting input queues which are problematic at high speed. It is not the case that without MP sequence numbers that I am necessarily reordering any messages where it would matter. In section 5 of the draft I carefully delineate usage conventions and implementation options which prevent harmful reordering. For IPv4, for instance, outgoing link determination based on a hash of source and destination addresses prevents reordering within a TCP stream, which is generally a goal of MP sequencing. The choice of links for PPP negotiation messages is also covered in that section. The goal of this draft is to arrive at a variant of MP which has the low overhead and simple hardware implementation of traditional load balancing while retaining the valuable negotiation and single-NCP model of MP. -- 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 Apr 7 13:55:40 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA05006; Tue, 7 Apr 1998 13:55:40 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Apr 1998 13:52:49 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA04897 for ietf-ppp-outgoing; Tue, 7 Apr 1998 13:52:48 -0400 (EDT) Received: from tn.com (comfrey.telenetworks.com [205.217.58.4]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA04890 for ; Tue, 7 Apr 1998 13:52:43 -0400 (EDT) Received: by tn.com (921113.SGI/940127.1517.TN) id AA01981; Tue, 7 Apr 98 11:00:32 -0700 Message-Id: <9804071800.AA01981@tn.com> From: "Greg Kendall" To: "ietf-ppp@merit.edu" Date: Tue, 07 Apr 98 10:48:07 Reply-To: "Greg Kendall" X-Mailer: Greg Kendall's Registered PMMail 1.53 For OS/2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: L2TP draft 10 question Sender: owner-ietf-ppp@merit.edu I note that Physical Channel ID is mandatory for ICRP and optional for OCRQ. Is that correct? Greg Kendall Telenetworks 625 Second Street, S100 Petaluma, CA 94952 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Apr 7 13:52:28 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA04883; Tue, 7 Apr 1998 13:52:26 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Apr 1998 13:49:25 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA04802 for ietf-ppp-outgoing; Tue, 7 Apr 1998 13:49:24 -0400 (EDT) Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA04798 for ; Tue, 7 Apr 1998 13:49:20 -0400 (EDT) Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id KAA24599; Tue, 7 Apr 1998 10:48:42 -0700 (PDT) Date: Tue, 7 Apr 1998 10:48:41 -0700 (PDT) From: John Bray Reply-To: John Bray To: James Carlson cc: ietf-ppp@merit.edu Subject: Re: An MP alternative In-Reply-To: <199804071718.NAA06555@ironbridgenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Tue, 7 Apr 1998, James Carlson wrote: > > > Since the only rational given for your proposal is that > > > fragmentation is undesirable on high speed links, would it not > > > be more appropriate to include a sentence to that effect in the > > > next multilink RFC (which must be ready to advance by now). > > > > > > Gerry > > > > I agree, the issue is really whether you want fragmentation or not. > > Removing multilink headers completely means you can only support > > protocols that are insensitive to reordering unless you force such > > packets over one link. An option which disables fragmentation without > > also removing MP headers would be more desireable. > > I disagree. Removing the MP headers (or at least the normal affect of > the headers) is also required here. > > There are two points here. The first is that fragmentation by the > peer is harmful to an all-hardware implementation since it implies > aribrary-sized data block handling. The second is that the reordering > implied by the MP sequence numbers is itself also harmful in hardware > implementations since it implies dedicated message-sorting input > queues which are problematic at high speed. OK. In some cases it may be desirable to omit the headers. I contend that I might want to keep the headers but turn off fragmentation. I think this should be separately negotiable. > > It is not the case that without MP sequence numbers that I am > necessarily reordering any messages where it would matter. In section > 5 of the draft I carefully delineate usage conventions and > implementation options which prevent harmful reordering. For IPv4, > for instance, outgoing link determination based on a hash of source > and destination addresses prevents reordering within a TCP stream, > which is generally a goal of MP sequencing. The choice of links for > PPP negotiation messages is also covered in that section. I understand. You're forcing packets that are sequence sensitive over a given link (regardless of how you accomplish that). So packets for a given TCP connection (to use your example) always travel over one link. It seems to me that kind of limits the amount of adaptive link balancing you can do. Now what about stateful data compression? You would have to support multiple compression histories (at least one per link), or do per-link compression, wouldn't you? John > > The goal of this draft is to arrive at a variant of MP which has the > low overhead and simple hardware implementation of traditional load > balancing while retaining the valuable negotiation and single-NCP > model of MP. > > -- > 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 Apr 7 14:37:01 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA06255; Tue, 7 Apr 1998 14:36:48 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Apr 1998 14:36:24 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA06216 for ietf-ppp-outgoing; Tue, 7 Apr 1998 14:36:24 -0400 (EDT) Received: from ironbridgenetworks.com ([146.115.140.2]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA06209 for ; Tue, 7 Apr 1998 14:36:18 -0400 (EDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id OAA17452; Tue, 7 Apr 1998 14:36:07 -0400 Date: Tue, 7 Apr 1998 14:36:07 -0400 Message-Id: <199804071836.OAA17452@ironbridgenetworks.com> From: James Carlson To: bray@cisco.com CC: ietf-ppp@merit.edu In-reply-to: (message from John Bray on Tue, 7 Apr 1998 10:48:41 -0700 (PDT)) Subject: Re: An MP alternative References: Sender: owner-ietf-ppp@merit.edu > > There are two points here. The first is that fragmentation by the > > peer is harmful to an all-hardware implementation since it implies > > aribrary-sized data block handling. The second is that the reordering > > implied by the MP sequence numbers is itself also harmful in hardware > > implementations since it implies dedicated message-sorting input > > queues which are problematic at high speed. > > OK. In some cases it may be desirable to omit the headers. I contend > that I might want to keep the headers but turn off fragmentation. I > think this should be separately negotiable. Ok; at that point I think we might require a new mechanism. I suppose that you could use another distinguished MRRU value (say 1?) to indicate the option of handling sequencing with the normal headers but with no fragmentation or reassembly supported (all 'fragments' have B and E bits set). It's not entirely clear to me what the application for this mode might be, but it doesn't sound unreasonable. > I understand. You're forcing packets that are sequence sensitive over > a given link (regardless of how you accomplish that). So packets for > a given TCP connection (to use your example) always travel over one > link. It seems to me that kind of limits the amount of adaptive link > balancing you can do. Yes, that is the case whenever traditional load balancing is done. The general mechanism is to include enough data in the hash such that a given flow lands on an almost "random" link, but that it lands on at most one link. The happy accident that occurs here is that multiple parallel very high speed links also tend to have aggregate traffic for which hashing works nicely to do load balancing. > Now what about stateful data compression? You would have to support > multiple compression histories (at least one per link), or do per-link > compression, wouldn't you? Gee whiz! If I could do data compression at these speeds, I'd probably have no trouble with variable-sized blocks. ;-} Seriously, yes, I considered that. Both ECP and CCP would need to be done with the per-link (00FB and 0055) variants in this case, or at least the mostly-unused "multiple histories" feature of some compression algorithms would need to be used. -- 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 Apr 7 16:30:39 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA10049; Tue, 7 Apr 1998 16:30:16 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 7 Apr 1998 16:29:24 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA10001 for ietf-ppp-outgoing; Tue, 7 Apr 1998 16:29:23 -0400 (EDT) Received: from server.indra.com (server.indra.com [204.144.142.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA09997 for ; Tue, 7 Apr 1998 16:29:18 -0400 (EDT) Received: from indra.com (net.indra.com [204.144.142.1]) by server.indra.com (8.8.5/) with ESMTP id OAA10204 for ; Tue, 7 Apr 1998 14:29:19 -0600 (MDT) Received: (from calcite@localhost) by indra.com (8.8.5/Spike-8-1.0) with UUCP id OAA02454 for ietf-ppp@merit.edu; Tue, 7 Apr 1998 14:19:43 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/8.7.3) id NAA01234 for ietf-ppp@merit.edu; Tue, 7 Apr 1998 13:32:48 -0600 (MDT) Date: Tue, 7 Apr 1998 13:32:48 -0600 (MDT) From: Vernon Schryver Message-Id: <199804071932.NAA01234@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: An MP alternative Sender: owner-ietf-ppp@merit.edu I'm confused. If the MP header is removed and there is no fragmenting, then why do any MP negotiating? Given the relatively specialized, specially configured, or known-to-be cooperating peers, what's the point of MP negotiating? If there is no MP header or fragmenting, then how is this MP alternative different from what I've been calling 'BF&I multilink' for years, what various vendors including Livingston and Silicon Graphics have been shipping (and interoperating) for years, and what I understand to be what the Linux community calls "load balancing"? It must be that I've misunderstood. Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Apr 8 09:10:44 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA20100; Wed, 8 Apr 1998 09:10:10 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Apr 1998 09:03:55 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA19979 for ietf-ppp-outgoing; Wed, 8 Apr 1998 09:03:55 -0400 (EDT) Received: from ironbridgenetworks.com ([146.115.140.2]) by merit.edu (8.8.7/8.8.5) with SMTP id JAA19975 for ; Wed, 8 Apr 1998 09:03:50 -0400 (EDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id JAA15235; Wed, 8 Apr 1998 09:03:47 -0400 Date: Wed, 8 Apr 1998 09:03:47 -0400 Message-Id: <199804081303.JAA15235@ironbridgenetworks.com> From: James Carlson To: vjs@calcite.rhyolite.com CC: ietf-ppp@merit.edu In-reply-to: <199804071932.NAA01234@calcite.rhyolite.com> (message from Vernon Schryver on Tue, 7 Apr 1998 13:32:48 -0600 (MDT)) Subject: Re: An MP alternative References: <199804071932.NAA01234@calcite.rhyolite.com> Sender: owner-ietf-ppp@merit.edu > I'm confused. If the MP header is removed and there is no fragmenting, > then why do any MP negotiating? Given the relatively specialized, > specially configured, or known-to-be cooperating peers, what's the point > of MP negotiating? Because the underlying MP negotiation mechanism provides a number of worthwhile benefits: - It does negotiate, so changing versions of software at each end of the link, including going "back rev," should work, even if it causes a fall-back to multiple parallel network links exposed to routing software. - It pulls one more error-prone mechanism out of the equation. It is the case that load balanced links should all have the same MRU/MTU and that they should have the same network layer end-point addresses and options (if any). MP provides a reasonable mechanism to validate these things. - MP checks for other potentially disasterous misconfigurations, such as a new pipe configured with the wrong peer. > If there is no MP header or fragmenting, then how is this MP alternative > different from what I've been calling 'BF&I multilink' for years, what > various vendors including Livingston and Silicon Graphics have been > shipping (and interoperating) for years, and what I understand to be what > the Linux community calls "load balancing"? It's not different. Ross Callon and I had a conversation about scaling the routing protocols and I mentioned to him that load balancing would help greatly. He noted that despite much industry experience and common understanding, there was as yet no standard for doing this. To write a standard for it, I considered just codifying BF&I in an RFC, but then I realized that to be complete, I'd have to document what ought to be done with misconfigurations and other error cases. At that point, I'd be reinventing at least one half of MP. -- 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 Wed Apr 8 11:50:12 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA22686; Wed, 8 Apr 1998 11:49:59 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 8 Apr 1998 11:49:16 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA22649 for ietf-ppp-outgoing; Wed, 8 Apr 1998 11:49:15 -0400 (EDT) Received: from server.indra.com (server.indra.com [204.144.142.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA22645 for ; Wed, 8 Apr 1998 11:49:11 -0400 (EDT) Received: from indra.com (net.indra.com [204.144.142.1]) by server.indra.com (8.8.5/) with ESMTP id JAA29722 for ; Wed, 8 Apr 1998 09:49:12 -0600 (MDT) Received: (from calcite@localhost) by indra.com (8.8.5/Spike-8-1.0) with UUCP id JAA28859 for ietf-ppp@merit.edu; Wed, 8 Apr 1998 09:40:07 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/8.7.3) id JAA03625 for ietf-ppp@merit.edu; Wed, 8 Apr 1998 09:26:34 -0600 (MDT) Date: Wed, 8 Apr 1998 09:26:34 -0600 (MDT) From: Vernon Schryver Message-Id: <199804081526.JAA03625@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: An MP alternative Sender: owner-ietf-ppp@merit.edu > From: James Carlson > > then why do any MP negotiating? Given the relatively specialized, > > specially configured, or known-to-be cooperating peers, what's the point > > of MP negotiating? > > Because the underlying MP negotiation mechanism provides a number of > worthwhile benefits: > ... > > If there is no MP header or fragmenting, then how is this MP alternative > > different from what I've been calling 'BF&I multilink' for years, what > It's not different. Ross Callon and I had a conversation about > ... Ok, I guess. Personally, the only error detecting I see from using MP negotiations is mis-matched MRU's, and I don't see a problem there. Why not let the peers bring up links with varying MRUs? So what if you have 3 links with 9K MRU's and one link with 256? You'd just do the obvious, wouldn't you? There is nothing except the MRU that the MP negotiation can protect, is there? You might use end-point discriminators to ensure that the peers know that they are doing BF&I. I think you need more words than what I think are in your draft to avoid confusion among computers, implementors, and users. Because at least some MP installations switch freely between using and not using MP headers after having negotiated classic MP, I think you need an explicitly negotiated flag. Currently, and I think according to explicit words in RFC 1990, if you do not include an MP header, your packets are outside of the scope of MP. They can bypass the MP queues on the sender or the receiver. How do you keep one computer from thinking that a PPP packet without MP header is outside of the scope of MP in the old sense unless you explicitly negoiate the new scheme? Having an explicit bit in a Configure-Request would not only prevent that confusion among computers, but it would also keep implementors from accidentally agreeing to do something other than what they intended, and it would help users staring at PPP packet traces. I don't understand your position on the MRU vs. MRRU. It seems that you need the MRRU <= MRU, and probably <, to accomodate BCP, ECP, or CCP. Maybe that's what you meant, but that it seemed otherwise implies the words need to be tightened. I think it would be a bad idea to declare MRRU=0 to mean BF&I. Zero is too likely to be a bogus old-style MRRU requested by a lame old-style MP implementation. Just as it's better to make 0 be an illegal instruction to make applications core-dump sooner, it's better to make MRRU=0 illegal. Also consider the many years of hassles we have had in IPCP with the special meaning of 0. We should have enough LCP Configure-Request numbers remaining if you really need an explicit negotiation of BF&I. Personally, I don't see the utility of such chit-chat, other than perhaps end-point discriminators and/or the LCP ID. Your draft should mention that for IP protocols, it is generally desirable but not absolutely vital to not reorder packets, and why (e.g. TCP performance reductions due to reordering). Your talk of hashes sounds fine to me, but I am bothered by what I infer to be the notion that such schemes are 100% perfect in preventing re-ordering. Hashing aint perfect in practice. For example, when you add or remove link in the bundle, your hash function is likely to hiccup and could re-assign a stream to a different link, and so allow a little re-ordering. Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Apr 9 10:22:20 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA11663; Thu, 9 Apr 1998 10:21:54 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 9 Apr 1998 10:14:59 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA11504 for ietf-ppp-outgoing; Thu, 9 Apr 1998 10:14:59 -0400 (EDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA11500 for ; Thu, 9 Apr 1998 10:14:51 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id KAA12685; Thu, 9 Apr 1998 10:14:07 -0400 (EDT) Message-Id: <199804091414.KAA12685@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-aal5-05.txt Date: Thu, 09 Apr 1998 10:14:02 -0400 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 : PPP over AAL5 Author(s) : M. Kaycee, A. Malis, A. Lin, J. Stephens, G. Gross Filename : draft-ietf-pppext-aal5-05.txt Pages : 11 Date : 08-Apr-98 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets. 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-aal5-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-aal5-05.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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-aal5-05.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980408153854.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-aal5-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-aal5-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980408153854.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Apr 9 10:22:20 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA11665; Thu, 9 Apr 1998 10:21:54 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 9 Apr 1998 10:15:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA11521 for ietf-ppp-outgoing; Thu, 9 Apr 1998 10:15:19 -0400 (EDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA11511 for ; Thu, 9 Apr 1998 10:15:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id KAA12746; Thu, 9 Apr 1998 10:14:26 -0400 (EDT) Message-Id: <199804091414.KAA12746@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-funi-05.txt Date: Thu, 09 Apr 1998 10:14:25 -0400 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 : PPP Over FUNI Author(s) : M. Kaycee, A. Malis, A. Lin, J. Stephens, G. Gross Filename : draft-ietf-pppext-funi-05.txt Pages : 10 Date : 08-Apr-98 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ATM Frame User Network Interface (FUNI) for framing PPP encapsulated packets. 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-funi-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-funi-05.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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-funi-05.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980408173730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-funi-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-funi-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980408173730.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Apr 9 11:46:26 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA13029; Thu, 9 Apr 1998 11:46:19 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 9 Apr 1998 11:43:59 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA12977 for ietf-ppp-outgoing; Thu, 9 Apr 1998 11:43:59 -0400 (EDT) Received: from multi31.netcomi.com (heddaya@multi31.netcomi.com [204.58.155.231]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA12973 for ; Thu, 9 Apr 1998 11:43:54 -0400 (EDT) Received: (from heddaya@localhost) by multi31.netcomi.com (8.8.5/8.7.3) id KAA25973; Thu, 9 Apr 1998 10:43:27 -0500 Received: from strato-fe0.ultra.net (strato-fe0.ultra.net [146.115.8.190]) by multi31.netcomi.com (8.8.5/8.7.3) with ESMTP id KAA25964 for ; Thu, 9 Apr 1998 10:43:19 -0500 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by strato-fe0.ultra.net (8.8.8/ult.n14767) with ESMTP id LAA11950; Thu, 9 Apr 1998 11:43:36 -0400 (EDT) Received: (from adm@localhost) by ns.ietf.org (8.8.5/8.8.7a) id LAA14375 for ietf-123-outbound.05@ietf.org; Thu, 9 Apr 1998 11:05:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id KAA12685; Thu, 9 Apr 1998 10:14:07 -0400 (EDT) Message-Id: <199804091414.KAA12685@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Old-To: IETF-Announce:;;@ma.ultranet.com Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-aal5-05.txt Date: Thu, 09 Apr 1998 10:14:02 -0400 X-Loop: forwarded by cchiotasso@infolibria.com To: infolibria_cchiotasso@terra.net 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 : PPP over AAL5 Author(s) : M. Kaycee, A. Malis, A. Lin, J. Stephens, G. Gross Filename : draft-ietf-pppext-aal5-05.txt Pages : 11 Date : 08-Apr-98 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets. 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-aal5-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-aal5-05.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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-aal5-05.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980408153854.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-aal5-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-aal5-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980408153854.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Apr 9 12:24:28 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA13689; Thu, 9 Apr 1998 12:24:26 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 9 Apr 1998 12:23:46 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA13657 for ietf-ppp-outgoing; Thu, 9 Apr 1998 12:23:45 -0400 (EDT) Received: from multi31.netcomi.com (heddaya@multi31.netcomi.com [204.58.155.231]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA13652 for ; Thu, 9 Apr 1998 12:23:38 -0400 (EDT) Received: (from heddaya@localhost) by multi31.netcomi.com (8.8.5/8.7.3) id LAA27169; Thu, 9 Apr 1998 11:23:07 -0500 Received: from antiochus-fe0.ultra.net (antiochus-fe0.ultra.net [146.115.8.188]) by multi31.netcomi.com (8.8.5/8.7.3) with ESMTP id LAA27162 for ; Thu, 9 Apr 1998 11:23:06 -0500 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by antiochus-fe0.ultra.net (8.8.8/ult.n14767) with ESMTP id MAA30008; Thu, 9 Apr 1998 12:23:14 -0400 (EDT) Received: (from adm@localhost) by ns.ietf.org (8.8.5/8.8.7a) id LAA15044 for ietf-123-outbound.05@ietf.org; Thu, 9 Apr 1998 11:25:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id KAA12746; Thu, 9 Apr 1998 10:14:26 -0400 (EDT) Message-Id: <199804091414.KAA12746@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Old-To: IETF-Announce:;;@ma.ultranet.com Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-funi-05.txt Date: Thu, 09 Apr 1998 10:14:25 -0400 X-Loop: forwarded by cchiotasso@infolibria.com To: infolibria_cchiotasso@terra.net 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 : PPP Over FUNI Author(s) : M. Kaycee, A. Malis, A. Lin, J. Stephens, G. Gross Filename : draft-ietf-pppext-funi-05.txt Pages : 10 Date : 08-Apr-98 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ATM Frame User Network Interface (FUNI) for framing PPP encapsulated packets. 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-funi-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-funi-05.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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-funi-05.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980408173730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-funi-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-funi-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980408173730.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Apr 10 15:05:41 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA08696; Fri, 10 Apr 1998 15:03:48 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 10 Apr 1998 14:57:30 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA08483 for ietf-ppp-outgoing; Fri, 10 Apr 1998 14:57:29 -0400 (EDT) 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 OAA08476 for ; Fri, 10 Apr 1998 14:57:23 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id OAA42898; Fri, 10 Apr 1998 14:56:30 -0400 (EDT) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA32534; Fri, 10 Apr 1998 14:56:33 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id OAA17748; Fri, 10 Apr 1998 14:56:28 -0400 (EDT) Message-Id: <199804101856.OAA17748@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: Karl Fox cc: Jeffrey Burgan , ietf-ppp@merit.edu, l2tp@zendo.com, Mark Townsley , Bill Palter Subject: Re: L2TP to Proposed Standard In-reply-to: Your message of "Fri, 20 Mar 1998 12:47:41 PST." <199803202047.MAA28712@gump.eng.ascend.com> Date: Fri, 10 Apr 1998 14:56:28 -0400 From: Thomas Narten Sender: owner-ietf-ppp@merit.edu > The PPPEXT Working Group recommends that Layer Two Tunneling Protocol > "L2TP", draft-ietf-pppext-l2tp-10.txt, be advanced to Proposed > Standard. Quick question. Looking at the references in this document, there are several that are internet drafts: [2] A. Valencia, M. Littlewood, T. Kolar, "Layer 2 Forwarding", Internet draft, April 1996 [3] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, "Point-to-Point Tunneling Protocol", Internet draft, June 1996 [7] D. Carrel, L. Grant, "The TACACS+ Protocol", draft-grant-tacacs-00.txt, October 1996 [13] G. Zorn, D. Leifer, A. Rubens, J. Shriver, "RADIUS Attributes for Tunnel Protocol Support," draft-ietf-radius-tunnel-auth-04.txt, November 1997 An RFC can't reference a draft. You have three choices: 1) delete the reference completely. 2) change the reference to "work in progress". Note that this can only be done if the reference is unimportant with respect to implementing the draft. 3) wait until the other document is an RFC. Even in the this case, you can't have a Standards Track document reference a non-Standards Track document in a normative sense. I don't think the first 3 references will be an issue, as they aren't normative (i.e., aren't needed to implementat l2tp). However, the last one might be. Specifically, the document says: > The Private Group ID is a string corresponding to a table in the LNS > that defines the particular characteristics of the selected group. A > LAC MAY determine the Private Group ID from a RADIUS response > containing the PrivateGroupID attribute [13]. Is this a normative reference? Also, what is the status of draft [13]? Will it become a Standards Track document and will it be published anytime soon? Thomas - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Apr 10 16:05:56 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA09932; Fri, 10 Apr 1998 16:04:33 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 10 Apr 1998 16:01:05 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA09875 for ietf-ppp-outgoing; Fri, 10 Apr 1998 16:01:04 -0400 (EDT) Received: from watchdog-rtp.cisco.com (watchdog-rtp.cisco.com [171.68.122.101]) by merit.edu (8.8.7/8.8.5) with SMTP id QAA09868 for ; Fri, 10 Apr 1998 16:00:59 -0400 (EDT) Received: from claret.cisco.com (claret.cisco.com [171.69.160.39]) by watchdog-rtp.cisco.com (8.6.12/CISCO.SERVER.1.1) with SMTP id TAA22196; Fri, 10 Apr 1998 19:48:14 GMT Date: Fri, 10 Apr 1998 15:59:17 -0400 (EDT) From: "W. Mark Townsley" To: Thomas Narten cc: Karl Fox , Jeffrey Burgan , ietf-ppp@merit.edu, l2tp@zendo.com, Bill Palter Subject: Re: L2TP to Proposed Standard In-Reply-To: <199804101856.OAA17748@cichlid.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Fri, 10 Apr 1998, Thomas Narten wrote: > > The PPPEXT Working Group recommends that Layer Two Tunneling Protocol > > "L2TP", draft-ietf-pppext-l2tp-10.txt, be advanced to Proposed > > Standard. > > Quick question. Looking at the references in this document, there are > several that are internet drafts: > > [2] A. Valencia, M. Littlewood, T. Kolar, "Layer 2 Forwarding", Internet > draft, April 1996 > > [3] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, "Point-to-Point > Tunneling Protocol", Internet draft, June 1996 > > [7] D. Carrel, L. Grant, "The TACACS+ Protocol", draft-grant-tacacs-00.txt, > October 1996 > > [13] G. Zorn, D. Leifer, A. Rubens, J. Shriver, "RADIUS Attributes for > Tunnel Protocol Support," draft-ietf-radius-tunnel-auth-04.txt, > November 1997 > > An RFC can't reference a draft. You have three choices: > > 1) delete the reference completely. > > 2) change the reference to "work in progress". Note that this can only > be done if the reference is unimportant with respect to implementing > the draft. > > 3) wait until the other document is an RFC. Even in the this case, you > can't have a Standards Track document reference a non-Standards Track > document in a normative sense. > > I don't think the first 3 references will be an issue, as they aren't > normative (i.e., aren't needed to implementat l2tp). However, the last I agree, we can change them to work in progress as you suggest in 2. > one might be. Specifically, the document says: > > > The Private Group ID is a string corresponding to a table in the LNS > > that defines the particular characteristics of the selected group. A > > LAC MAY determine the Private Group ID from a RADIUS response > > containing the PrivateGroupID attribute [13]. > > Is this a normative reference? Also, what is the status of draft [13]? As this is only a MAY, by definition it is just a suggestion. I don't think there would be much opposition in removing it. > Will it become a Standards Track document and will it be published > anytime soon? The dissolution of the RADIUS working group will force them to decide quite soon what documents will advance and what documents will not. If this remains on their list of advancing documents, perhaps they could go together. However, untethering the documents is still probably the prudent choice. Unless I hear otherwise from the group, that is what we will plan on doing. Thanks, - Mark > > Thomas > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Apr 10 16:17:13 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA10135; Fri, 10 Apr 1998 16:15:50 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 10 Apr 1998 16:12:43 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA10071 for ietf-ppp-outgoing; Fri, 10 Apr 1998 16:12:43 -0400 (EDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA10066 for ; Fri, 10 Apr 1998 16:12:38 -0400 (EDT) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id NAA11816; Fri, 10 Apr 1998 13:12:02 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma011814; Fri Apr 10 13:11:41 1998 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id NAA06651; Fri, 10 Apr 1998 13:11:40 -0700 (PDT) From: Archie Cobbs Message-Id: <199804102011.NAA06651@bubba.whistle.com> Subject: Re: L2TP to Proposed Standard In-Reply-To: <199804101949.PAA27580@brill.shiva.com> from John Shriver at "Apr 10, 98 03:49:43 pm" To: jas@shiva.com (John Shriver) Date: Fri, 10 Apr 1998 13:11:40 -0700 (PDT) Cc: l2tp@zendo.com, ietf-ppp@merit.edu X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu John Shriver writes: > Citing L2F or PPTP as a "work in progress" would be less than > forthright. Can we cite an URL? They're certainly only of historical > interest. We could just leave off "internet draft", and just treat > them like old peices of paper. (Or someone can publish them as > Informational.) That reminds me of something I've been meaning to ask.. Shouldn't PPTP be published as informational? There certainly are a lot of implementations out there now. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Apr 10 16:45:13 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA11134; Fri, 10 Apr 1998 16:43:50 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 10 Apr 1998 16:40:21 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA11048 for ietf-ppp-outgoing; Fri, 10 Apr 1998 16:40:20 -0400 (EDT) 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 QAA11044 for ; Fri, 10 Apr 1998 16:40:12 -0400 (EDT) Received: (from vandys@localhost) by vandys-pc.cisco.com (8.8.5/8.8.5) id NAA18745; Fri, 10 Apr 1998 13:39:40 -0700 (PDT) Date: Fri, 10 Apr 1998 13:39:40 -0700 (PDT) From: Andy Valencia Message-Id: <199804102039.NAA18745@vandys-pc.cisco.com> To: archie@whistle.com Cc: ietf-ppp@merit.edu Subject: Re: L2TP to Proposed Standard Newsgroups: cisco.external.ietf.ppp References: <199804101949.PAA27580@brill.shiva.com> <199804102011.NAA06651@bubba.whistle.com> X-Newsreader: NN version 6.5.0 #1 (NOV) Sender: owner-ietf-ppp@merit.edu >Shouldn't PPTP be published as informational? There certainly are >a lot of implementations out there now. FYI, the IESG has advised me that Cisco may publish L2F as a historical document. Since PPTP and L2F have a very similar relationship to L2TP, that would argue that PPTP should be made available as a similar historical document. $0.02, Andy Valencia - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Apr 10 17:00:58 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA11527; Fri, 10 Apr 1998 16:59:37 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 10 Apr 1998 16:56:29 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA11465 for ietf-ppp-outgoing; Fri, 10 Apr 1998 16:56:28 -0400 (EDT) Received: from shultz.argon.com (shultz.argon.com [208.234.161.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA11461 for ; Fri, 10 Apr 1998 16:56:22 -0400 (EDT) Received: from baker (baker.argon.com [208.234.161.56]) by shultz.argon.com (8.8.6/8.8.6) with SMTP id QAA10398; Fri, 10 Apr 1998 16:55:15 -0400 (EDT) Message-Id: <3.0.5.32.19980410165514.00981b60@shultz.argon.com> X-Sender: esc@shultz.argon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 10 Apr 1998 16:55:14 -0400 To: issll@mercury.lcs.mit.edu From: "Eric S. Crawley" Subject: WG last call on draft-ietf-issll-isslow-rtf-02.txt Cc: ietf-ppp@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Folks, We are starting the WG last call on draft-ietf-issll-isslow-rtf-02.txt. The last call will end at 5PM EDT on Friday, April 24th. Please get any comments you have to the author or the mailing list by then. Thanks! Eric & John - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Apr 10 22:46:36 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id WAA15780; Fri, 10 Apr 1998 22:46:29 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 10 Apr 1998 22:43:47 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id WAA15737 for ietf-ppp-outgoing; Fri, 10 Apr 1998 22:43:46 -0400 (EDT) Received: from cbgw1.lucent.com (cbgw1.lucent.com [207.24.196.51]) by merit.edu (8.8.7/8.8.5) with SMTP id WAA15733 for ; Fri, 10 Apr 1998 22:43:41 -0400 (EDT) Received: from luna3.lc.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id WAA28673; Fri, 10 Apr 1998 22:42:54 -0400 Received: by luna3.lc.lucent.com (SMI-8.6/EMS-1.3.1 sol2) id WAA04943; Fri, 10 Apr 1998 22:41:05 -0400 Date: Fri, 10 Apr 1998 22:41:05 -0400 Message-Id: <199804110241.WAA04943@luna3.lc.lucent.com> From: gmg@luna3.lc.lucent.com (luna3!gmg) To: ietf-ppp@merit.edu Cc: gmgross@lucent.com Subject: PPP over AAL5 v05 ID Content-Type: text Sender: owner-ietf-ppp@merit.edu Hi, Attached below is a copy of an E-mail thread between David Allan, myself, the co-authors, and others concerning section 8 within v05 of the ID. It is repro'd here with Dave's permission, but with most E-mail headers snipped for the sake of brevity. The first E-mail also has the diffs between v04 and v05. I'm posting this E-mail exchange to the list because it discusses how to respond to the PPP encapsulation changing unexpectedly. Since v05 mandates support of *both* VC-mux'd and LCC encapsulated PPP, the procedure described in section 8 has become important so that implementations can assure recovery from PVC configuration mistakes. George ========= From gmg Fri Apr 3 10:34 EST 1998 Return-Path: Received: by luna3.lc.lucent.com (SMI-8.6/EMS-1.3.1 sol2) id KAA20993; Fri, 3 Apr 1998 10:34:19 -0500 Received: by luna3.lc.lucent.com (SMI-8.6/EMS-1.3.1 sol2) id KAA20950; Fri, 3 Apr 1998 10:34:10 -0500 Date: Fri, 3 Apr 1998 10:34:10 -0500 Message-Id: <199804031534.KAA20950@luna3.lc.lucent.com> From: gmg@luna3.lc.lucent.com (luna3!gmg) To: john@cayman.com, dallan@nortel.com, mjk@nj.paradyne.com, alin@shastanets.com, malis@ascend.com, jhalpern@newbridge.com, burgan@corp.home.net, james@newbridge.com Cc: gmgross@lucent.com Subject: PPP over AAL5 ID v05 Content-Type: text Content-Length: 25509 Hi folks, As per our discussions in Los Angles, I've revised the PPP over AAL5 Internet Draft to version 5. To make sure we're all in sync before doing the wider publication, I've sent this E-mail to both the co-authors and all those parties who were present at L. A. whom I think would have an interest in the revisions. If there are additional stakeholders whom I've missed, please contact me. The ID's complete text is attached below, after the "diff" output. I've snipped out of the "diff" output all the irrelevant changes. The v05 text is marked with "<" and the v04 text is marked with ">". Please review at your earliest convienance. I will be sending the final v05 edition to internet-drafts@ietf.org with all of your comments folded in at COB next Tuesday. Thank you. George (908) 580-4589 The main V5 versus V4 change is in section 4: 182,185c161,163 < 2. MUST support LLC encapsulated PPP payloads on PVCs as described < in section 6 below by mutual configuration or negotiation of both < end points. This technique is referred to as "LLC encapsulated < PPP". --- > 2. MAY use LLC encapsulated PPP payloads on PVCs as described in > section 6 below by mutual configuration or negotiation of both end > points. This technique is referred to as "LLC encapsulated PPP". 195,199c181,183 < use LLC encapsulated PPP payloads. Frame Relay/ATM FRF.8 inter-working < units are exempted from the requirement to support VC-multiplexed PPP. < This exemption allows the FR/ATM IWU to remain compliant with FRF.8 when < the PPP over AAL5 end point is inter-operating with an RFC1973 end < point. --- > use LLC encapsulated PPP payloads. Implementations that wish to inter- > operate with all potential end points MUST implement LLC-encapsulated > payloads. In section 6, a redundant sentance was deleted: 271c256,258 < multiplexed PPP over AAL5. --- > multiplexed PPP over AAL5. LLC encapsulated PPP minimizes the ATM/Frame > Relay inter-working translation complexity that occurs when a VCC is > connected to an RFC 1973 compliant end point. Section 6 is clarified as per a comment from Dirk Van Aken of Alcatel and Phil Rakity of Flowpoint (figure 3 was also changed): 293c274 < 4. followed by the PPP information field as per Figure 2. --- > 4. followed by the PPP information field. Section 7 entitled "Out-Of-Band Control Plane Signaling": 354c344 < offers LLC-encapsulated PPP in the caller's request. The called --- > offers VC-multiplexed PPP in the caller's request. The called 358c348 < negotiate the use of LLC-encapsulated PPP. --- > negotiate the use of VC-multiplexed PPP. Added to section 9, "LCP Configuration Options" to reflect UNH IOL experience: 441,454d430 < Implementation Note: < When an ATM AAL5 PVC is in the "Stopped" state, it is recommended < that the implementation wait for Configure-Requests. See the < implementation option in reference [1] section 4.2, the "Stopped < State" sub-section. ... snip draft-ietf-pppext-aal5-05.text.... From David.Allan.dallan@nt.com Wed Apr 8 15:13 EDT 1998 ... snip E-mail header .... Subject: RE: PPP over AAL5 ID v05 Date: Wed, 8 Apr 1998 13:12:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Content-Length: 900 Status: R George et al: In general I am happy with the I-D but section 8 still confuses me. If encapsulation is negotiated or provisioned, then it cannot unexpectedly change state, and expecting some form of heuristic to recognize some allegedly valid change seems a bit perverse. My feeling is that some editing turn-on-off failed . My edit would be that the first several paras. of the section should be deleted and the last 4 paras kept (starting with "Once PPP has entered...." with minor editing to indicate that deviations from provisioned (PVC) or negotiated (SVC) encapsulation are treated as such (call cleared-SVC or NCP/LCP tear down-PVC) regardless of the NCP state. Suggested text: "If a frame arrives deviating from the provisioned/negotiated encapsulation then the PPP link MUST:..." The rest appears fine! Regards Dave ----------------------- Dave Allan Nortel PDN Architecture Team From David.Allan.dallan@nt.com Wed Apr 8 21:02 EDT 1998 ... snip E-mail header ... Subject: RE: PPP over AAL5 ID v05 Date: Wed, 8 Apr 1998 19:02:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Content-Length: 2388 Status: R Joel: I think we are in agreement as to the general thrust (no changing of horse in midstream), you have defined how the system would react more accurately. So based upon your thinking, if the session is up, then a dynamic change in encap will be percieved as garbage. I presume that this would not be sufficient grounds to drop an SVC or terminate an NCP/LCP on a PVC immediately. I'd just silently discard everything and assume that sanity would eventually prevail. Actual behavior I suspect is that LCP loopbacks would eventually crap out and the system would take some higher level action. If the encap is not what I expect prior to establishing a PPP session, I will just silently discard all frames that are not well formed and (for SVC) call clearing would be a matter of local policy and good implementations. (If no valid PPP session established after X seconds, drop the line and reclaim the port). Strikes me that simple elimination of section 8 is the correct course....does that cover it? Regards Dave ----------------------- Dave Allan Nortel PDN Architecture Team From gmg Thu Apr 9 11:46 EDT 1998 ... snip E-mail header .... Subject: RE: PPP over AAL5 ID v05 Content-Type: text Content-Length: 1406 Hi Dave, As you might gather from the ID announcement on the IETF list, the cow has already left the barn for v05. Sorry, but as promised I had submitted the drafts 22:00 EST last Tuesday. I'm puzzled why section 8 is confusing for you. At this point, I had been hoping not to do further edits on the ID text unless it said something really "wrong". Perhaps section 8 would make more sense if one thought about a PVC that has its LCP in the "Stopped" state (see the new implementation note in section 9). Let's assume that the RAS is listening for an initial "Config-Request" from an ADSL subscriber. Suppose it is possible for the subscriber to inadvertantly and uni-laterally change their PPP encapsulation by accident (Bart Simpson pushed the wrong u-soft PVC configuration button ;-). The subscriber starts their "dial-up", which starts sending LCP Config-Requests to the RAS. The RAS detects and then switchs to the new encapsulation by examining the first several bytes of the PPP/AAL5 LCP payload. Once the LCP negotiation completes, any subsequent change in the encapsulation causes the PVC to flag an error and enter Termination state (or else SVC hang up) The only potential drawback that I could see happen is when changing from VC-mux'd to LLC-encap PPP dynamically is introducing other LLC-encap non-PPP protocols after the connection originally did not have them configured. George From David.Allan.dallan@nt.com Thu Apr 9 14:59 EDT 1998 ... snip E-mail header ... Subject: RE: PPP over AAL5 ID v05 Date: Thu, 9 Apr 1998 12:33:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Content-Length: 2457 Status: R So your suggestion is that the RAS is encap. agnostic when in the "idle" state and discovers religion once a session has started? I gather that what you are really trying to achieve is a RAS that requires no provisioning vis-a-vis encap. at the expense that it must parse and validate multiple frame formats. If so, then that should have been explicitly stated. I am nervous about that as a general mechanism of going forward as there are devices (e.g. FRF.8) that are exempt from meeting that (unstated) requirement. Dave ----------------------- Dave Allan Nortel PDN Architecture Team From gmg Thu Apr 9 16:37 EDT 1998 ... snip E-mail header .... Subject: RE: PPP over AAL5 ID v05 Content-Type: text Content-Length: 969 Status: R Hi, In retrospect, section 8 was added in reaction to the advent of LLC encapsulation being added to the ID. The goal was to recover from the potential PVC configuration errors. Making the RAS end point configuration simpler and dynamic was an unintended benefit. Unfortunately, when Bart Simpon clicks the wrong button, and re-configures his PVC to VC-mux'd PPP mode, then his PVC connection to an ATM/FR IWU will break. This particular scenario is not good ;-(.... However, I would argue that at least we've managed to reduce the probability of a PVC mis-configuration breaking the link to near zero. This is the best we can do, and I might add, it does *alot*. Network service providers will probably select one PPP encapsulation across their whole network. Only those subscribers who over-ride that policy AND are connected to an ATM/FR IWU are gonna get into trouble. This discourse probably has merit being re-send to the PPP list. Any objections? George From David.Allan.dallan@nt.com Thu Apr 9 17:53 EDT 1998 ... snip E-mail header... Subject: RE: PPP over AAL5 ID v05 Date: Thu, 9 Apr 1998 17:51:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Content-Length: 1994 Status: R George: I can't comment on how this affects any gate budgets as I've traditionally been more arch-S/W oriented but I do see the value in "being generous in what I receive". If there is a question, it is if there is a mechanism in FRF.8 IWUs to actually diagnose the result of Bart's roving finger once it frappez le fan? e.g. an uninterworkable frame count. As for posting this, I have not problem, ultimately we are clarifying somthing, I don't think we are creating controversy. And if we are, we'll find out ;-) Dave ----------------------- Dave Allan Nortel PDN Architecture Team - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sun Apr 12 12:51:20 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA01922; Sun, 12 Apr 1998 12:50:54 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sun, 12 Apr 1998 12:47:25 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA01888 for ietf-ppp-outgoing; Sun, 12 Apr 1998 12:47:24 -0400 (EDT) Received: from pinky.microsoft.com (pinky.microsoft.com [131.107.1.229]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA01884 for ; Sun, 12 Apr 1998 12:47:20 -0400 (EDT) Received: from glennz-2 (tide12.microsoft.com [131.107.3.22]) by pinky.microsoft.com (8.7.6/8.7.3) with SMTP id JAA06340; Sun, 12 Apr 1998 09:37:04 -0700 (PDT) Reply-To: "Glen Zorn" From: "Glen Zorn" To: "Karl Fox" , "Thomas Narten" Cc: "Jeffrey Burgan" , , , "Mark Townsley" , "Bill Palter" Subject: Re: L2TP to Proposed Standard Date: Sun, 12 Apr 1998 09:39:40 -0700 Message-ID: <01bd6631$972a3bc0$76fa1eac@glennz-2> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000B_01BD65F6.EACB63C0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_000B_01BD65F6.EACB63C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thomas Narten writes: >> The PPPEXT Working Group recommends that Layer Two Tunneling Protocol >> "L2TP", draft-ietf-pppext-l2tp-10.txt, be advanced to Proposed >> Standard. > >Quick question. Looking at the references in this document, there are >several that are internet drafts: > > [2] A. Valencia, M. Littlewood, T. Kolar, "Layer 2 Forwarding", Internet > draft, April 1996 > > [3] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, "Point-to-Point > Tunneling Protocol", Internet draft, June 1996 > > [7] D. Carrel, L. Grant, "The TACACS+ Protocol", draft-grant-tacacs-00.txt, > October 1996 > > [13] G. Zorn, D. Leifer, A. Rubens, J. Shriver, "RADIUS Attributes for > Tunnel Protocol Support," draft-ietf-radius-tunnel-auth-04.txt, > November 1997 > >An RFC can't reference a draft. You have three choices: > >1) delete the reference completely. > >2) change the reference to "work in progress". Note that this can only >be done if the reference is unimportant with respect to implementing >the draft. > >3) wait until the other document is an RFC. Even in the this case, you >can't have a Standards Track document reference a non-Standards Track >document in a normative sense. > >I don't think the first 3 references will be an issue, as they aren't >normative (i.e., aren't needed to implementat l2tp). However, the last >one might be. Specifically, the document says: > >> The Private Group ID is a string corresponding to a table in the LNS >> that defines the particular characteristics of the selected group. A >> LAC MAY determine the Private Group ID from a RADIUS response >> containing the PrivateGroupID attribute [13]. > >Is this a normative reference? Also, what is the status of draft [13]? >Will it become a Standards Track document and will it be published >anytime soon? I expect the document to advance to PS in the next month or so. > >Thomas > > > ------=_NextPart_000_000B_01BD65F6.EACB63C0 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD N:Zorn;Glen FN:Glen Zorn EMAIL;PREF;INTERNET:glennz@microsoft.com END:VCARD ------=_NextPart_000_000B_01BD65F6.EACB63C0-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sun Apr 12 22:16:40 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id WAA07676; Sun, 12 Apr 1998 22:16:36 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sun, 12 Apr 1998 22:15:42 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id WAA07648 for ietf-ppp-outgoing; Sun, 12 Apr 1998 22:15:41 -0400 (EDT) Received: from mail.msen.com (root@conch.msen.com [148.59.19.5]) by merit.edu (8.8.7/8.8.5) with ESMTP id WAA07644 for ; Sun, 12 Apr 1998 22:15:34 -0400 (EDT) Received: from [198.111.227.3] (dialin2273.isdn.umich.edu [198.111.227.3]) by mail.msen.com (8.8.8/8.8.5) with ESMTP id WAA14085; Sun, 12 Apr 1998 22:15:22 -0400 (EDT) X-Sender: del@conch.aa.msen.com Message-Id: In-Reply-To: References: <199804101856.OAA17748@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 12 Apr 1998 21:59:10 -0400 To: "W. Mark Townsley" , Thomas Narten From: Dory Ethan Leifer Subject: Re: L2TP to Proposed Standard Cc: Karl Fox , Jeffrey Burgan , ietf-ppp@merit.edu, l2tp@zendo.com, Bill Palter Sender: owner-ietf-ppp@merit.edu >> > The Private Group ID is a string corresponding to a table in the LNS >> > that defines the particular characteristics of the selected group. A >> > LAC MAY determine the Private Group ID from a RADIUS response >> > containing the PrivateGroupID attribute [13]. >> >> Is this a normative reference? Also, what is the status of draft [13]? > >As this is only a MAY, by definition it is just a suggestion. I don't >think there would be much opposition in removing it. The reference here is very important for implementors that don't know the history of the attribute - and as Glen mentioned, the Radius document is moving ahead. Dory - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Apr 13 09:40:15 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA13617; Mon, 13 Apr 1998 09:39:27 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 13 Apr 1998 09:32:12 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA13477 for ietf-ppp-outgoing; Mon, 13 Apr 1998 09:32:11 -0400 (EDT) Received: from watchdog-rtp.cisco.com (watchdog-rtp.cisco.com [171.68.122.101]) by merit.edu (8.8.7/8.8.5) with SMTP id JAA13473 for ; Mon, 13 Apr 1998 09:32:06 -0400 (EDT) Received: from claret.cisco.com (claret.cisco.com [171.69.160.39]) by watchdog-rtp.cisco.com (8.6.12/CISCO.SERVER.1.1) with SMTP id NAA15760; Mon, 13 Apr 1998 13:18:45 GMT Date: Mon, 13 Apr 1998 09:29:50 -0400 (EDT) From: "W. Mark Townsley" Reply-To: "W. Mark Townsley" To: Dory Ethan Leifer cc: Thomas Narten , Karl Fox , Jeffrey Burgan , ietf-ppp@merit.edu, l2tp@zendo.com, Bill Palter Subject: Re: L2TP to Proposed Standard In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Sun, 12 Apr 1998, Dory Ethan Leifer wrote: > >> > The Private Group ID is a string corresponding to a table in the LNS > >> > that defines the particular characteristics of the selected group. A > >> > LAC MAY determine the Private Group ID from a RADIUS response > >> > containing the PrivateGroupID attribute [13]. > >> > >> Is this a normative reference? Also, what is the status of draft [13]? > > > >As this is only a MAY, by definition it is just a suggestion. I don't > >think there would be much opposition in removing it. > > The reference here is very important for implementors that don't > know the history of the attribute - and as Glen mentioned, the > Radius document is moving ahead. OK, agreed. I still think there is a good argument for citing RADIUS as a 'work in progress' for now, and changing it to RFCxxxx when we move to draft standard (as was already suggested on the list). Thomas, will this be sufficient? - Mark > > Dory > > > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Apr 13 16:21:49 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA21339; Mon, 13 Apr 1998 16:21:34 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 13 Apr 1998 16:16:39 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA21130 for ietf-ppp-outgoing; Mon, 13 Apr 1998 16:16:39 -0400 (EDT) Received: from tbu1.hifn.com (mailman.hifn.com [206.19.120.66]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA21126 for ; Mon, 13 Apr 1998 16:16:29 -0400 (EDT) Received: by tbu1.hifn.com with Internet Mail Service (5.0.1458.49) id <1Y4JSF4J>; Mon, 13 Apr 1998 13:19:56 -0700 Message-ID: <6297CD447F92D11199F5006097BA9D1E06BEF8@tbu1.hifn.com> From: Robert Friend To: "'IETF-PPP'" Subject: PPP Default configuration Date: Mon, 13 Apr 1998 13:19:54 -0700 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 Hi to all CCP developers, I am conducting a survey regarding which settings you implement. That is what set of configuration options do you support in your CCP implementations? Also, I am wondering what are your default (or preferred) settings you try to negotiate to. As you know, there are 5 options that can be negotiated for rfc1974 (CCP with LZS compression): they are LCB, CRC, sequence numbers, extended mode, and none. I would like to know what is negotiated by implementations and what problems, if any, are experienced. This information will remain internal to Hi/fn and will not ever be published. Please send me private mail with this information. Regards, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 Mon Apr 13 17:11:57 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA22617; Mon, 13 Apr 1998 17:11:55 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 13 Apr 1998 17:07:36 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA22538 for ietf-ppp-outgoing; Mon, 13 Apr 1998 17:07:36 -0400 (EDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA22534 for ; Mon, 13 Apr 1998 17:07:29 -0400 (EDT) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id OAA05947; Mon, 13 Apr 1998 14:06:41 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma005945; Mon Apr 13 14:06:13 1998 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id OAA04302; Mon, 13 Apr 1998 14:06:12 -0700 (PDT) From: Archie Cobbs Message-Id: <199804132106.OAA04302@bubba.whistle.com> Subject: Re: PPP Default configuration In-Reply-To: <6297CD447F92D11199F5006097BA9D1E06BEF8@tbu1.hifn.com> from Robert Friend at "Apr 13, 98 01:19:54 pm" To: rfriend@hifn.com (Robert Friend) Date: Mon, 13 Apr 1998 14:06:12 -0700 (PDT) Cc: ietf-ppp@merit.edu X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Robert Friend writes: > I am conducting a survey regarding which settings you implement. That > is what set of configuration options do you support in your CCP > implementations? Also, I am wondering what are your default (or > preferred) settings you try to negotiate to. > > As you know, there are 5 options that can be negotiated for rfc1974 (CCP > with LZS compression): they are LCB, CRC, sequence numbers, extended > mode, and none. I would like to know what is negotiated by > implementations and what problems, if any, are experienced. > > This information will remain internal to Hi/fn and will not ever be > published. Please send me private mail with this information. It would be nice if you could publish this information... at least in summary form (you don't have to name names). -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Apr 14 07:48:55 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id HAA06723; Tue, 14 Apr 1998 07:47:10 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 14 Apr 1998 07:42:24 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id HAA06647 for ietf-ppp-outgoing; Tue, 14 Apr 1998 07:42:23 -0400 (EDT) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by merit.edu (8.8.7/8.8.5) with ESMTP id HAA06642 for ; Tue, 14 Apr 1998 07:42:19 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id HAA34470; Tue, 14 Apr 1998 07:42:00 -0400 (EDT) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id HAA06458; Tue, 14 Apr 1998 07:42:01 -0400 Received: from hygro.raleigh.ibm.com (lig32-224-57-24.us.lig-dial.ibm.com [32.224.57.24]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with ESMTP id HAA17212; Tue, 14 Apr 1998 07:41:58 -0400 (EDT) Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id HAA12945; Tue, 14 Apr 1998 07:13:18 -0400 Message-Id: <199804141113.HAA12945@hygro.raleigh.ibm.com> To: "W. Mark Townsley" cc: Dory Ethan Leifer , Karl Fox , Jeffrey Burgan , ietf-ppp@merit.edu, l2tp@zendo.com, Bill Palter Subject: Re: L2TP to Proposed Standard In-reply-to: Your message of "Mon, 13 Apr 1998 09:29:50 EDT." Date: Tue, 14 Apr 1998 07:13:17 -0400 From: Thomas Narten Sender: owner-ietf-ppp@merit.edu > OK, agreed. I still think there is a good argument for citing RADIUS as a > 'work in progress' for now, and changing it to RFCxxxx when we move to > draft standard (as was already suggested on the list). Thomas, will this > be sufficient? Probably not. An RFC can't point to a non-RFC (i.e. a draft or "work in progress) if an implementor needs access to that reference in order to implement the spec at hand. Saying that an implementation MAY want to take a specific action based on something specific in another document depends on the other document. The problem is what if that other thing gets redefined, or never gets published? Re: the PPTP/L2F documents. As noted in an earlier message, the latter document is already in the queue to be published as an RFC. Are the authors of the PPTP draft on this list, and are they willing to take an action item on getting it published as an RFC? For now, I'll assume that the Radius Attributes draft will be published as an RFC via the radius WG and that no special action is needed on our part. That leaves: > [7] D. Carrel, L. Grant, "The TACACS+ Protocol", draft-grant-tacacs-00.txt, > October 1996 Is the consensus to remove the reference to this one? Thomas - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Apr 14 09:03:29 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA07590; Tue, 14 Apr 1998 09:01:53 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 14 Apr 1998 09:01:27 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA07567 for ietf-ppp-outgoing; Tue, 14 Apr 1998 09:01:26 -0400 (EDT) Received: from gatekeeper.atml.co.uk (gatekeeper.virata.com [194.129.40.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA07563 for ; Tue, 14 Apr 1998 09:01:21 -0400 (EDT) Received: from boletus.atml.co.uk (root@boletus.atml.co.uk [10.1.3.2]) by gatekeeper.atml.co.uk (8.8.5/8.8.5) with ESMTP id OAA31384 for ; Tue, 14 Apr 1998 14:00:38 +0100 Received: from anawara.atml.co.uk (anawara.atml.co.uk [192.168.219.95]) by boletus.atml.co.uk (8.8.5/8.8.5) with ESMTP id OAA01540 for ; Tue, 14 Apr 1998 14:00:38 +0100 Received: from risso.atml.co.uk (risso.atml.co.uk [192.168.219.57]) by anawara.atml.co.uk (8.8.8/8.8.5) with SMTP id OAA06828 for ; Tue, 14 Apr 1998 14:00:37 +0100 (BST) Received: by risso.atml.co.uk with Microsoft Mail id <01BD67AD.425AEC20@risso.atml.co.uk>; Tue, 14 Apr 1998 13:57:27 +-100 Message-ID: <01BD67AD.425AEC20@risso.atml.co.uk> From: William Stoye To: "'ietf-ppp@merit.edu'" Subject: draft-ietf-pppext-aal5-05.txt Date: Tue, 14 Apr 1998 13:57:26 +-100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Hi, Ref section 7 para 2, for SVC establishment of a VC-multiplexed PPP connection, here's MY reading of what the BLLI should actually be: ref UNI 3.1 p213, the BLLI definition table: octet group 7: 0 11 01011 (extend; layer 3; TR9577) octet group 7a,7b (IPI indicator, Note 5): 0 1100 111 (extend; 0xCF top 7 bits) 1 1 000000 (noextend; 0xCF bottom bit; reserved) From these we determine: #define PPP_BLLI "\x6b\x67\xc0" #define PPP_BLLI_LEN 3 Does anyone disagree with this? I'd much rather agree this here than in the heat of some interop event... I don't believe there are any differences between UNI 3.0, UNI 3.1, Q.2931, IISP, UNI 4, PNNI 1.0 on this one (phew!). Does anyone know any different? Is this also true of the BLLI negotiation required? --William Stoye, Virata Limited. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Apr 14 12:19:14 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA11996; Tue, 14 Apr 1998 12:19:01 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 14 Apr 1998 12:16:26 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA11886 for ietf-ppp-outgoing; Tue, 14 Apr 1998 12:16:22 -0400 (EDT) Received: from tbu1.hifn.com (mailman.hifn.com [206.19.120.66]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA11867 for ; Tue, 14 Apr 1998 12:16:02 -0400 (EDT) Received: by tbu1.hifn.com with Internet Mail Service (5.0.1458.49) id <1Y4JSGB6>; Tue, 14 Apr 1998 09:19:27 -0700 Message-ID: <6297CD447F92D11199F5006097BA9D1E06BF10@tbu1.hifn.com> From: Robert Friend To: "'IETF-PPP'" , "'ciug@ciug.org'" Subject: RE: PPP Default configuration Date: Tue, 14 Apr 1998 09:19:24 -0700 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 Hello Everybody, Thank you to all of you who have responded. If you haven't had a chance, or are busy, it would be great if you could take just a few seconds to send me a mail soon. I am mainly thinking of you who attend the ISDN-PPP bake-offs and to relate the connection experiences you have had (which many of you already did :-). Anyway, thank you all again for responding. Regards, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: Robert Friend > Sent: Monday, April 13, 1998 1:20 PM > To: 'IETF-PPP' > Subject: PPP Default configuration > > Hi to all CCP developers, > > I am conducting a survey regarding which settings you implement. That > is what set of configuration options do you support in your CCP > implementations? Also, I am wondering what are your default (or > preferred) settings you try to negotiate to. > > As you know, there are 5 options that can be negotiated for rfc1974 > (CCP with LZS compression): they are LCB, CRC, sequence numbers, > extended mode, and none. I would like to know what is negotiated by > implementations and what problems, if any, are experienced. > > This information will remain internal to Hi/fn and will not ever be > published. Please send me private mail with this information. > > Regards, > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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 Tue Apr 14 21:04:28 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id VAA25679; Tue, 14 Apr 1998 21:04:22 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 14 Apr 1998 21:03:31 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA25641 for ietf-ppp-outgoing; Tue, 14 Apr 1998 21:03:30 -0400 (EDT) Received: from tbu1.hifn.com (mailman.hifn.com [206.19.120.66]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA25633 for ; Tue, 14 Apr 1998 21:03:23 -0400 (EDT) Received: by tbu1.hifn.com with Internet Mail Service (5.0.1458.49) id <1Y4JSGQ1>; Tue, 14 Apr 1998 18:06:54 -0700 Message-ID: <6297CD447F92D11199F5006097BA9D1E06BF27@tbu1.hifn.com> From: Robert Friend To: "'Archie Cobbs'" Cc: ietf-ppp@merit.edu, "'ciug@ciug.org'" Subject: RE: PPP Default configuration Date: Tue, 14 Apr 1998 18:06:53 -0700 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 I can do that (just the facts, no names), unless anyone objects. Does anyone object? Regards ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: Archie Cobbs [SMTP:archie@whistle.com] > Sent: Monday, April 13, 1998 2:06 PM > To: rfriend@hifn.com > Cc: ietf-ppp@merit.edu > Subject: Re: PPP Default configuration > > Robert Friend writes: > > I am conducting a survey regarding which settings you implement. > That > > is what set of configuration options do you support in your CCP > > implementations? Also, I am wondering what are your default (or > > preferred) settings you try to negotiate to. > > > > As you know, there are 5 options that can be negotiated for rfc1974 > (CCP > > with LZS compression): they are LCB, CRC, sequence numbers, extended > > mode, and none. I would like to know what is negotiated by > > implementations and what problems, if any, are experienced. > > > > This information will remain internal to Hi/fn and will not ever be > > published. Please send me private mail with this information. > > It would be nice if you could publish this information... at least > in summary form (you don't have to name names). > > -Archie > > ______________________________________________________________________ > _____ > Archie Cobbs * Whistle Communications, Inc. * > http://www.whistle.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Apr 14 23:19:26 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id XAA27431; Tue, 14 Apr 1998 23:19:16 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 14 Apr 1998 23:18:35 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id XAA27407 for ietf-ppp-outgoing; Tue, 14 Apr 1998 23:18:34 -0400 (EDT) Received: from manaslu.mos.com.np (root@manaslu.mos.com.np [202.52.255.3]) by merit.edu (8.8.7/8.8.5) with SMTP id XAA27403 for ; Tue, 14 Apr 1998 23:18:24 -0400 (EDT) Received: from kopila.mos.com.np (kopila.mos.com.np [202.52.255.20]) by manaslu.mos.com.np (8.6.9/8.6.9) with ESMTP id JAA18112; Wed, 15 Apr 1998 09:01:46 +0545 Received: (from badri@localhost) by kopila.mos.com.np (8.8.5/KRG1.0) id JAA12450; Wed, 15 Apr 1998 09:33:06 +0545 (NPT) Date: Wed, 15 Apr 1998 09:33:03 +0545 (NPT) From: Badri Ghimire To: Naganand Doraswamy cc: ipsec@tis.com, mpls@external.cisco.com, ietf-ppp@merit.edu, int-serv@ISI.EDU Subject: Re: VPN mailing list In-Reply-To: <3.0.32.19980208105656.00b7bb68@bl-mail1.corpeast.baynetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Hi, I'm trying to implement VPDN( Virtual Private Dialup Network) with Cisco routers and having a hard time. Can anyone point me to a right resources ( Mailing list, URL etc ) for it, mailing list would be the best. Any pointer on this would be highly appreciated. Thanks. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Apr 15 14:00:19 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA08361; Wed, 15 Apr 1998 13:59:47 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 15 Apr 1998 13:53:53 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA08228 for ietf-ppp-outgoing; Wed, 15 Apr 1998 13:53:52 -0400 (EDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA08224 for ; Wed, 15 Apr 1998 13:53:47 -0400 (EDT) Received: from boonmark-pc.juniper.net (boonmark-pc.juniper.net [208.197.169.204]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id KAA10932; Wed, 15 Apr 1998 10:52:41 -0700 (PDT) Received: (from boonmark@localhost) by boonmark-pc.juniper.net (8.8.7/8.7.3) id SAA17799; Wed, 15 Apr 1998 18:52:40 +0100 (BST) Date: Wed, 15 Apr 98 18:52:40 WET DST From: Pasvorn Boonmark To: Badri Ghimire Cc: Naganand Doraswamy , ipsec@tis.com, mpls@external.cisco.com, ietf-ppp@merit.edu, int-serv@isi.edu Subject: Re: VPN mailing list In-Reply-To: Your message of Wed, 15 Apr 1998 09:33:03 +0545 (NPT) Message-ID: Sender: owner-ietf-ppp@merit.edu > > Hi, > > I'm trying to implement VPDN( Virtual Private Dialup Network) with Cisco > routers and having a hard time. Can anyone point me to a right resources > ( Mailing list, URL etc ) for it, mailing list would be the best. Any > pointer on this would be highly appreciated. > > Thanks. > > > > Have you looked at the cco.cisco.com? You can send e-mail to "tac@cisco.com" to request for a case, or alternatively send e-mail to Cisco users mailing list "cisco@spot.colorado.edu" - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Apr 17 08:31:06 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA15098; Fri, 17 Apr 1998 08:29:56 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Apr 1998 08:21:37 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA14992 for ietf-ppp-outgoing; Fri, 17 Apr 1998 08:21:37 -0400 (EDT) Received: from cdnet51 (cdnet51.uestc.edu.cn [202.112.14.151]) by merit.edu (8.8.7/8.8.5) with SMTP id IAA14988 for ; Fri, 17 Apr 1998 08:21:24 -0400 (EDT) Received: from 163.net ([202.115.4.67]) by cdnet51 (5.x/SMI-SVR4) id AA13398; Fri, 17 Apr 1998 21:16:41 +0900 Message-Id: <35374A77.D961228@163.net> Date: Fri, 17 Apr 1998 20:26:31 +0800 From: lhy Organization: uestc X-Mailer: Mozilla 4.04 [en] (Win95; I) Mime-Version: 1.0 To: ietf-ppp@merit.edu Subject: send ppp to cdlhy@telekbird.com.cn Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Apr 17 10:37:45 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA16688; Fri, 17 Apr 1998 10:37:37 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Apr 1998 10:36:56 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA16659 for ietf-ppp-outgoing; Fri, 17 Apr 1998 10:36:55 -0400 (EDT) Received: from ironbridgenetworks.com ([146.115.140.2]) by merit.edu (8.8.7/8.8.5) with SMTP id KAA16652 for ; Fri, 17 Apr 1998 10:36:51 -0400 (EDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id KAA05201; Fri, 17 Apr 1998 10:33:38 -0400 Date: Fri, 17 Apr 1998 10:33:38 -0400 Message-Id: <199804171433.KAA05201@ironbridgenetworks.com> From: James Carlson To: vjs@calcite.rhyolite.com CC: ietf-ppp@merit.edu In-reply-to: <199804081526.JAA03625@calcite.rhyolite.com> (message from Vernon Schryver on Wed, 8 Apr 1998 09:26:34 -0600 (MDT)) Subject: Re: An MP alternative References: <199804081526.JAA03625@calcite.rhyolite.com> Sender: owner-ietf-ppp@merit.edu > Personally, the only error detecting I see from using MP negotiations is > mis-matched MRU's, and I don't see a problem there. Mismatched paths (over SONET/SDH infrastructure) or misidentified peers can be far more hazardous. As are links where the peer IP address is not what was expected. IPCP nicely handles the latter checks, and MP nicely specifies that there be only *one* IPCP negotiation session per bundle, which simplifies the error cases. > Why not let the peers > bring up links with varying MRUs? So what if you have 3 links with 9K > MRU's and one link with 256? You'd just do the obvious, wouldn't > you? The "obvious" is not so obvious when the implementation is in hardware. Knowing how and when to fragment (calculate MIN(link-MTU)?) depending on when the link is chosen is one part of the problem. The other part of the problem is that mismatched MRU/MTUs among links may well be configuration errors. > There is nothing except the MRU that the MP negotiation can protect, is > there? IPCP peer addresses. > You might use end-point discriminators to ensure that the peers know > that they are doing BF&I. Yes; that's essentially the point here. I could have written an I-D which says just that, but then it begs a number of questions, such as what to do in any error cases. I believe a tighter description of the usage is needed. > I think you need more words than what I think are in your draft to avoid > confusion among computers, implementors, and users. Because at least some > MP installations switch freely between using and not using MP headers > after having negotiated classic MP, I think you need an explicitly > negotiated flag. Currently, and I think according to explicit words in > RFC 1990, if you do not include an MP header, your packets are outside of > the scope of MP. They can bypass the MP queues on the sender or the > receiver. How do you keep one computer from thinking that a PPP packet > without MP header is outside of the scope of MP in the old sense unless > you explicitly negoiate the new scheme? All of the data is "outside the scope" in the old sense. None of it is sent with MP headers at all. None of it is sequenced or reordered. If this option is chosen, there's only one way to send data and negotiate per this I-D. The old in-or-out-of-MP ambiguity doesn't exist. > Having an explicit bit in a > Configure-Request would not only prevent that confusion among computers, > but it would also keep implementors from accidentally agreeing to do > something other than what they intended, and it would help users staring > at PPP packet traces. That's fair. Certainly MRRU==0 is noticable and distinguished, but I'm not opposed to a separate option. I'll try proposing one. > I don't understand your position on the MRU vs. MRRU. It seems that > you need the MRRU <= MRU, and probably <, to accomodate BCP, ECP, or CCP. > Maybe that's what you meant, but that it seemed otherwise implies the > words need to be tightened. No. I'm not reconstructing at all, so there's no MRRU at all. Since there's no reassembly, I need to show that the peer's MRU is exposed to the network layer as the local MTU, just like with non-MP links. > I think it would be a bad idea to declare MRRU=0 to mean BF&I. Zero is > too likely to be a bogus old-style MRRU requested by a lame old-style MP > implementation. Another good reason to use a separate option. I'd like to think people didn't do dumb things like this, but I can believe they did. > Your draft should mention that for IP protocols, it is generally desirable > but not absolutely vital to not reorder packets, and why (e.g. TCP > performance reductions due to reordering). Your talk of hashes sounds > fine to me, but I am bothered by what I infer to be the notion that such > schemes are 100% perfect in preventing re-ordering. Hashing aint perfect > in practice. For example, when you add or remove link in the bundle, your > hash function is likely to hiccup and could re-assign a stream to a > different link, and so allow a little re-ordering. Yes, link add/drop can cause a "little" reordering as the hash map changes. I should note this. -- 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 Fri Apr 17 11:47:39 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA17974; Fri, 17 Apr 1998 11:47:32 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Apr 1998 11:46:52 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA17939 for ietf-ppp-outgoing; Fri, 17 Apr 1998 11:46:52 -0400 (EDT) Received: from ironbridgenetworks.com ([146.115.140.2]) by merit.edu (8.8.7/8.8.5) with SMTP id LAA17932 for ; Fri, 17 Apr 1998 11:46:47 -0400 (EDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id LAA15906; Fri, 17 Apr 1998 11:46:46 -0400 Date: Fri, 17 Apr 1998 11:46:46 -0400 Message-Id: <199804171546.LAA15906@ironbridgenetworks.com> From: James Carlson To: ietf-ppp@merit.edu Subject: An update to LBD Sender: owner-ietf-ppp@merit.edu Before sending off for publication, I'd like to expose this to the criticism of the wg list. I've incorporated suggestions from Craig Fox and John Bray at Cisco (separate negotiation of fragmentation and header usage) and Vernon Schryver at SGI (refinements of reordering implications and MRRU/MRU). ==== PPP Working Group J. Carlson Internet Draft IronBridge Networks expires in six months April 1998 PPP Link Balancing Detection (LBD) Status of this Memo This document is the product of the Point-to-Point Protocol Extensions Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which allows the detection of optional link handling procedures, as well as a Multilink procedure (MP) [2] which allows operation over multiple physical links. This document defines an extension to MP called Link Balancing Detection (LBD) and the LCP options which control this extension. Carlson expires October 1998 [Page 1] INTERNET DRAFT PPP Link Balancing Detection April 1998 Table of Contents 1. Introduction ........................................... 2 1.1. Conventions ............................................ 3 2. No-Fragmentation Configuration Option Format ........... 3 3. No-MP-Headers Configuration Option Format .............. 4 4. Interaction With MRRU .................................. 5 5. Bundle Establishment ................................... 5 6. Bundle Tear-Down ....................................... 5 7. Message Distribution ................................... 6 8. Security Issues ........................................ 7 9. References ............................................. 7 10. Authors' Addresses ..................................... 7 1. Introduction Standard PPP negotiation allows for two types of links with regard to multiple link layer entities. The standard type of PPP link is nego- tiated without the Maximum-Receive-Reconstructed-Unit (MRRU) option and appears as a separate network interface to the network layer and to routing protocols. The Multilink PPP (MP) [2] type of link uses the MRRU option and allows multiple PPP links to be bundled into one network interface. An MP link appears as a single network interface to the network layer and to routing protocols. There are many advantages having multiple links between two nodes appear at the network layer to be a single link. While equal-cost multi-path balancing is certainly possible with modern interior gate- way protocols, less stress is placed on scarce routing system resources when link-layer detection is employed, allowing current routing protocols to scale farther. Also, routing system stability in the face of link failures is usually higher when individual links are not visible to the routing protocols. The main disadvantage to the current MP technique is that it does not constrain the fragmentation which may be done by the peer. For sys- tems employing general purpose CPUs in the data path and with scatter-gather direct memory access (DMA) capability, this is often not a problem. For systems with very high bandwidth capabilities, these features are often infeasible, and this problem makes MP unus- able. This draft describes a method similar to and compatible with MP for detecting multiple links to the same node, but without the fragmenta- tion or reordering protection of MP. Instead, datagrams are distri- buted without MP headers among the links in the bundle in any con- venient manner, including based on a hash or on round-robbin service. Carlson expires October 1998 [Page 2] INTERNET DRAFT PPP Link Balancing Detection April 1998 1.1. Conventions The following language conventions are used in the items of specifi- cation in this document: o MUST, SHALL, or MANDATORY -- This item is an absolute require- ment of the specification. o SHOULD or RECOMMEND -- This item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- This item is truly optional and may be fol- lowed or ignored according to the needs of the implementor. 2. No-Fragmentation Configuration Option Format A summary of the No-Fragmentation Configuration Option format for LCP is shown below. The fields are transmitted from left to right. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length 2 The sender of this option in a Configure-Request message is indicat- ing to its peer that it cannot support reassembly, and, thus the peer must not fragment messages that it sends. If MP without reassembly is supported in an implementation, then every LCP Configure-Request message MUST carry this option until rejected by the peer. If the peer Configure-Ack's this option, then it MUST NOT fragment frames using standard MP fragmentation. It MAY still use MP headers to preserve frame sequencing. If the peer Configure-Reject's this option, then the sender must remove this option from its next Configure-Request message and MAY decline to run MP by also removing its MRRU Configuration Option. Implementations MUST NOT Configure- Nak this option. Carlson expires October 1998 [Page 3] INTERNET DRAFT PPP Link Balancing Detection April 1998 3. No-MP-Headers Configuration Option Format A summary of the No-MP-Headers Configuration Option format for LCP is shown below. The fields are transmitted from left to right. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length 2 The sender of this option in a Configure-Request message is indicat- ing to its peer that it cannot support standard MP headers, and, thus the peer must not use MP headers on the messages that it sends. If standard MP is not supported but MP without headers (termed "Link Balancing Detection," or LBD, by this specification) is supported in an implementation, then every LCP Configure-Request message MUST carry this option until rejected by the peer. If this option is specified, then the No-Fragmentation option is unnecessary. Fragmentation without MP headers is not supported. If the peer Configure-Ack's this option, then it MUST NOT add MP headers or fragment frames. If the peer Configure-Reject's this option, then the sender must remove this option from its next Configure-Request message and MAY decline to run MP by also removing its MRRU Configuration Option. Implementations MUST NOT Configure- Nak this option. This option SHOULD not be used on links which are intended to carry network protocols which cannot tolerate reordering. See section blah for details. Carlson expires October 1998 [Page 4] INTERNET DRAFT PPP Link Balancing Detection April 1998 4. Interaction With MRRU The MRRU option from MP is still used to signal the desire to run MP, regardless of whether or not these options are present. If MRRU is not negotiated, then these options have no effect. If an MRRU is negotiated, then, as with standard MP, the peer's MRRU is advertised to the network layer as the MTU for the interface. When No-Fragmentation is used but No-MP-Headers is not used, MRRU should be set to the LCP MRU minus 6 (for long sequence numbers) or minus 4 (for short sequence numbers). When No-MP-Headers is used, MRRU should be set equal to the LCP MRU. 5. Bundle Establishment As with MP, bundle establishment is based on a combination of the peer's supplied endpoint discriminator (ED) and the peer's identity as determined via link authentication. The algorithm used for LBD is identical to the MP algorithm, and is documented here only for con- venience. When authentication (if any was negotiated via LCP) is complete, a check is made before attempting to negotiate any Network Control Pro- tocols (NCPs). If an MRRU is agreed to by both peers and if there is an existing LBD bundle where the ED (or lack thereof) matches the new link's ED (or lack), and the authenticated peer name (or lack thereof) match the new link's peer name (or lack), then this new link should be made part of the bundle and no new NCPs are created. Oth- erwise, this is a separate link, and NCPs should be started. If the local and remote MRRU values do not agree with the bundle or if the presence or absence of the No-Fragmentation or No-MP-Headers options does not agree with the bundle, then the link SHOULD be ter- minated. An implementation MAY choose instead to renegotiate LCP to repair the error. 6. Bundle Tear-Down Tear-down is identical to standard MP and is thus not covered here. Carlson expires October 1998 [Page 5] INTERNET DRAFT PPP Link Balancing Detection April 1998 7. Message Distribution To distribute messages among the links when LBD is in effect, a few simple rules must be followed. First, since PPP negotiation does not withstand reordering, all PPP negotiation messages MUST be sent over a single link to avoid possi- ble reordering. The first link in a bundle MUST be used to transmit PPP messages until this link is terminated. If the first link is terminated, then one remaining link in the bundle MUST be chosen for subsequent messages. Once that link is chosen, an implementation MUST continue sending all PPP negotiation messages over that single link. Any remaining link in the bundle MAY be chosen, and it is entirely possible that each peer may choose a different link without harm to the PPP protocol. Second, PPP negotiation messages MUST be handled when received on any link. An implementation MAY choose to terminate the last link over which negotiation was received if negotiation is received over a dif- ferent link, since this transition implies that the peer has already terminated the prior link. Third, network datagrams SHOULD be distributed over all links as evenly as possible. There are no requirements that any particular distribution algorithm be used. Note, however, that some network protocols behave poorly when subjected to message reordering, so techniques which prevent reordering (such as deterministic hashes of network layer addresses) are encouraged. (For TCP, reordering of IP datagrams usually causes a slow path in the state machine to be taken, and can trigger side-effects, such as fast retransmit.) Fourth, network datagrams from protocols which cannot withstand mes- sage reordering MUST be sent over a single link within the bundle, as with PPP negotiation above. Standard MP is preferred over LBD in these cases. Fifth, the common but technically non-standard practice of using LCP Terminate-Request to gracefully terminate a link without data loss is encouraged in LBD implementations. To do this, an implementation leaves Open state on sending LCP Terminate-Request, but, contrary to RFC 1661 [1], continues processing received datagrams until the peer replies with LCP Terminate-Ack. Carlson expires October 1998 [Page 6] INTERNET DRAFT PPP Link Balancing Detection April 1998 8. Security Issues The authentication and bundling techniques are identical to standard MP and the security issues are the same as with RFC 1990. 9. References [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 07/21/1994 [2] K. Sklower, et al, "The PPP Multilink Protocol (MP)", RFC 1990, 08/1996 [3] J. Postel, "Internet Protocol", RFC 791, 09/01/1981 10. Author's Address James Carlson IronBridge Networks 55 Hayden Avenue Lexington MA 02173-7999 Phone: +1 781 402 8032 Fax: +1 781 402 8092 Email: carlson@ironbridgenetworks.com Carlson expires October 1998 [Page 7] -- 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 Fri Apr 17 13:07:47 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA19994; Fri, 17 Apr 1998 13:07:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Apr 1998 13:07:12 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA19968 for ietf-ppp-outgoing; Fri, 17 Apr 1998 13:07:11 -0400 (EDT) Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA19960 for ; Fri, 17 Apr 1998 13:07:06 -0400 (EDT) Received: from zircon.acc.com by fennel.acc.com (4.1/SMI-4.1) id AA17419; Fri, 17 Apr 98 10:06:53 PDT Received: by zircon.acc.com (4.1/SMI-4.1) id AA02044; Fri, 17 Apr 98 13:06:34 EDT Date: Fri, 17 Apr 98 13:06:34 EDT From: rms@zircon.acc.com (Ron Stoughton) Message-Id: <9804171706.AA02044@zircon.acc.com> To: ietf-ppp@merit.edu Subject: CCP history number 0 Sender: owner-ietf-ppp@merit.edu An unnamed but popular ISDN TA sends a CCP Reset-Request with history number 0. RFC 1974 says that a Reset-Request with no history number (interpreted by me to mean a 4-byte Reset-Request) should be treated as a Reset-Request for history number 1. It does not say that a Reset-Request for history 0 should be treated similarly, although that might be a reasonable thing to do. Is this common practice, both to send history number 0 and to interpret it as history number 1? Ron Stoughton rms@acc.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Apr 17 13:31:08 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA20548; Fri, 17 Apr 1998 13:31:06 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Apr 1998 13:29:36 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA20474 for ietf-ppp-outgoing; Fri, 17 Apr 1998 13:29:35 -0400 (EDT) Received: from server.indra.com (server.indra.com [204.144.142.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA20470 for ; Fri, 17 Apr 1998 13:29:31 -0400 (EDT) Received: from indra.com (net.indra.com [204.144.142.1]) by server.indra.com (8.8.5/) with ESMTP id LAA14469 for ; Fri, 17 Apr 1998 11:29:31 -0600 (MDT) Received: (from calcite@localhost) by indra.com (8.8.5/Spike-8-1.0) with UUCP id LAA12942 for ietf-ppp@merit.edu; Fri, 17 Apr 1998 11:19:58 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/8.7.3) id LAA09441 for ietf-ppp@merit.edu; Fri, 17 Apr 1998 11:03:41 -0600 (MDT) Date: Fri, 17 Apr 1998 11:03:41 -0600 (MDT) From: Vernon Schryver Message-Id: <199804171703.LAA09441@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: An MP alternative Sender: owner-ietf-ppp@merit.edu > From: James Carlson > > Personally, the only error detecting I see from using MP negotiations is > > mis-matched MRU's, and I don't see a problem there. > > Mismatched paths (over SONET/SDH infrastructure) or misidentified > peers can be far more hazardous. As are links where the peer IP > address is not what was expected. IPCP nicely handles the latter > checks, and MP nicely specifies that there be only *one* IPCP > negotiation session per bundle, which simplifies the error cases. Yes, IPCP deals with IP address confusion. You don't need MP to require the administrative restriction of having only one set of state IP machines per bundle. You could instead do separate IPCP negotiations on each link, and administratively require them to have the same answers, or in other words, use the redundant IPCP config-requests and -acks as confirmation that the peers agree. Isn't that what everyone's BF&I Multilink implementations have done for years? > > Why not let the peers > > bring up links with varying MRUs? So what if you have 3 links with 9K > > MRU's and one link with 256? You'd just do the obvious, wouldn't > > you? > > The "obvious" is not so obvious when the implementation is in > hardware. Knowing how and when to fragment (calculate MIN(link-MTU)?) > depending on when the link is chosen is one part of the problem. The > other part of the problem is that mismatched MRU/MTUs among links may > well be configuration errors. I guess 'obvious' is in the eye of the beholder. What's obvious to me is "never fragment, and put big packets in queues with big enough MTU's". > > There is nothing except the MRU that the MP negotiation can protect, is > > there? > > IPCP peer addresses. I think the several interoperable, commercial BF&I Multlink implemementations require a single pair of IP addresses for the whole bundle, and manage that restriction without RFC 1717/1990. When my code detects inconsistent MRU's, MTU'S, MRRU's, MTRU's, or certain other parameters, it puts a snooty message in the log and an LCP Terminate-Request. > > You might use end-point discriminators to ensure that the peers know > > that they are doing BF&I. > > Yes; that's essentially the point here. I could have written an I-D > which says just that, but then it begs a number of questions, such as > what to do in any error cases. I believe a tighter description of the > usage is needed. I guess it wouldn't hurt to ensure that obvious stuff is written down. > > I think you need more words than what I think are in your draft to avoid > > confusion among computers, implementors, and users. ... > All of the data is "outside the scope" in the old sense. None of it > is sent with MP headers at all. None of it is sequenced or reordered. > > If this option is chosen, there's only one way to send data and > negotiate per this I-D. The old in-or-out-of-MP ambiguity doesn't > exist. But that wasn't entirely clear to me, which seems to mandate some more or different words. vjs - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Apr 17 13:51:15 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA21037; Fri, 17 Apr 1998 13:51:14 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Apr 1998 13:49:41 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA20929 for ietf-ppp-outgoing; Fri, 17 Apr 1998 13:49:40 -0400 (EDT) Received: from server.indra.com (server.indra.com [204.144.142.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA20925 for ; Fri, 17 Apr 1998 13:49:36 -0400 (EDT) Received: from indra.com (net.indra.com [204.144.142.1]) by server.indra.com (8.8.5/) with ESMTP id LAA15891 for ; Fri, 17 Apr 1998 11:49:36 -0600 (MDT) Received: (from calcite@localhost) by indra.com (8.8.5/Spike-8-1.0) with UUCP id LAA15134 for ietf-ppp@merit.edu; Fri, 17 Apr 1998 11:39:55 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/8.7.3) id LAA09537 for ietf-ppp@merit.edu; Fri, 17 Apr 1998 11:25:18 -0600 (MDT) Date: Fri, 17 Apr 1998 11:25:18 -0600 (MDT) From: Vernon Schryver Message-Id: <199804171725.LAA09537@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: An update to LBD Sender: owner-ietf-ppp@merit.edu > From: James Carlson > ... > The main disadvantage to the current MP technique is that it does not > constrain the fragmentation which may be done by the peer. For sys- > tems employing general purpose CPUs in the data path and with > scatter-gather direct memory access (DMA) capability, this is often > not a problem. For systems with very high bandwidth capabilities, > these features are often infeasible, and this problem makes MP unus- > able. I think that slightly misses the point. What you are trying to avoid is not merely fragmentation by the sender, but two other things: 1. fragment reassembly by the receiver 2. packet (and fragment) re-ordering by the receiver. It's easy, even in fast hardware, to fragment packets as you send them. (By "fast", I mean silicon GBytes/second, albeit not in routers or bridges.) The bigger hassles are reassembling arbitrary sized fragments and dealing with arbitrary orderings of the packets. IP fragment reassembly is messy, but PPP MP reassembly and re-ordering is far worse. The PPP MP re-ordering requirement, including detecting and dealing with lost packets and fragments requires a lot more machinery. > This draft describes a method similar to and compatible with MP for > detecting multiple links to the same node, but without the fragmenta- > tion or reordering protection of MP. Instead, datagrams are distri- > buted without MP headers among the links in the bundle in any con- > venient manner, including based on a hash or on round-robbin service. I don't see how this scheme is "compatible with MP." It is "similar" and "related," and it might be "semi-compatible" or "upward-compatible." It is not purely "compatible" because you cannot connect a typical PPP implementation that supports RFC 1990 to an implementation that supports this proposal and have things work well. On one hand, an implemenation of this scheme would not like MP fragments from RFC 1990 implementations, and there are RFC 1990 implementations that would not appreciate not receiving IP packets without MP headers while there are several links in the bundle. > ... > 2. No-Fragmentation Configuration Option Format > ... Implementations MUST NOT Configure- > Nak this option. Why not Configure-Nak for it? >... > A summary of the No-MP-Headers Configuration Option format for LCP is > ... > If this option is specified, then the No-Fragmentation option is > unnecessary. Fragmentation without MP headers is not supported. Instead of "not supported," how about "impossible"? > ... Implementations MUST NOT Configure- > Nak this option. Why not? vjs - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Apr 17 14:04:13 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA21368; Fri, 17 Apr 1998 14:04:12 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Apr 1998 14:03:59 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA21343 for ietf-ppp-outgoing; Fri, 17 Apr 1998 14:03:59 -0400 (EDT) Received: from ironbridgenetworks.com ([146.115.140.2]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA21336 for ; Fri, 17 Apr 1998 14:03:54 -0400 (EDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id OAA03998; Fri, 17 Apr 1998 14:00:37 -0400 Date: Fri, 17 Apr 1998 14:00:37 -0400 Message-Id: <199804171800.OAA03998@ironbridgenetworks.com> From: James Carlson To: vjs@calcite.rhyolite.com CC: ietf-ppp@merit.edu In-reply-to: <199804171703.LAA09441@calcite.rhyolite.com> (message from Vernon Schryver on Fri, 17 Apr 1998 11:03:41 -0600 (MDT)) Subject: Re: An MP alternative References: <199804171703.LAA09441@calcite.rhyolite.com> Sender: owner-ietf-ppp@merit.edu > > Mismatched paths (over SONET/SDH infrastructure) or misidentified > > peers can be far more hazardous. As are links where the peer IP > > address is not what was expected. IPCP nicely handles the latter > > checks, and MP nicely specifies that there be only *one* IPCP > > negotiation session per bundle, which simplifies the error cases. > > Yes, IPCP deals with IP address confusion. > > You don't need MP to require the administrative restriction of having only > one set of state IP machines per bundle. You could instead do separate > IPCP negotiations on each link, and administratively require them to have > the same answers, or in other words, use the redundant IPCP config-requests > and -acks as confirmation that the peers agree. Isn't that what everyone's > BF&I Multilink implementations have done for years? Yes, but, again, only by convention and by administrative intervention, not by standard and not by negotiation. > > The "obvious" is not so obvious when the implementation is in > > hardware. Knowing how and when to fragment (calculate MIN(link-MTU)?) > > depending on when the link is chosen is one part of the problem. The > > other part of the problem is that mismatched MRU/MTUs among links may > > well be configuration errors. > > I guess 'obvious' is in the eye of the beholder. What's obvious to me is > "never fragment, and put big packets in queues with big enough MTU's". Unless, of course, the point that does the distribution among links is before a switch fabric where it is impractical to have yet another table with all of the MTUs. Unless, of course, such redistribution would violate assumptions (or guarantees) about message reordering. This is why standardization is a reasonable thing. It's not necessarily the case that two implementors of good faith will always choose the same 'obvious' solution. > > IPCP peer addresses. > > I think the several interoperable, commercial BF&I Multlink > implemementations require a single pair of IP addresses for the whole > bundle, and manage that restriction without RFC 1717/1990. When my code > detects inconsistent MRU's, MTU'S, MRRU's, MTRU's, or certain other > parameters, it puts a snooty message in the log and an LCP > Terminate-Request. You're doing it right. But there's no *document* that says you're doing it right. Should we decide to interoperate, it would be nice to have a bit of paper that says what we think we've agreed to do, no? > > All of the data is "outside the scope" in the old sense. None of it > > is sent with MP headers at all. None of it is sequenced or reordered. > > > > If this option is chosen, there's only one way to send data and > > negotiate per this I-D. The old in-or-out-of-MP ambiguity doesn't > > exist. > > But that wasn't entirely clear to me, which seems to mandate some > more or different words. I noticed that this was a problem, and I *think* I've corrected this in the version of the draft I sent out today. If not, it would probably be helpful to know where the reader stumbles. -- 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 Fri Apr 17 14:00:27 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA21249; Fri, 17 Apr 1998 14:00:25 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Apr 1998 14:00:11 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA21225 for ietf-ppp-outgoing; Fri, 17 Apr 1998 14:00:10 -0400 (EDT) Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA21220 for ; Fri, 17 Apr 1998 14:00:04 -0400 (EDT) Received: from spice.cascade by alpo.casc.com (SMI-8.6/SM-980323-1632) id NAA01649; Fri, 17 Apr 1998 13:59:26 -0400 Received: from localhost by spice.cascade (SMI-8.6/SMI-SVR4) id NAA03008; Fri, 17 Apr 1998 13:59:26 -0400 Date: Fri, 17 Apr 1998 13:59:25 -0400 (EDT) From: "Andrew G. Malis" X-Sender: amalis@spice To: William Stoye cc: "'ietf-ppp@merit.edu'" Subject: Re: draft-ietf-pppext-aal5-05.txt In-Reply-To: <01BD67AD.425AEC20@risso.atml.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Hi Bill! Long time no see .... My reading agrees with yours. I'm using p. 364 of UNI 3.1 as my reference, replacing 0xCC for IP with 0xCF for PPP. Cheers, Andy ------- > Ref section 7 para 2, for SVC establishment of a VC-multiplexed PPP connection, > here's MY reading of what the BLLI should actually be: > > ref UNI 3.1 p213, the BLLI definition table: > > octet group 7: > > 0 11 01011 (extend; layer 3; TR9577) > > octet group 7a,7b (IPI indicator, Note 5): > > 0 1100 111 (extend; 0xCF top 7 bits) > > 1 1 000000 (noextend; 0xCF bottom bit; reserved) > > From these we determine: > > #define PPP_BLLI "\x6b\x67\xc0" > #define PPP_BLLI_LEN 3 > > Does anyone disagree with this? > I'd much rather agree this here than in the heat of some interop event... > > I don't believe there are any differences between UNI 3.0, UNI 3.1, Q.2931, > IISP, UNI 4, PNNI 1.0 on this one (phew!). Does anyone know any different? > Is this also true of the BLLI negotiation required? > > --William Stoye, Virata Limited. ________________________________________________________________________ Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-1484 Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Apr 17 14:38:15 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA22043; Fri, 17 Apr 1998 14:38:05 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Apr 1998 14:37:31 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA22004 for ietf-ppp-outgoing; Fri, 17 Apr 1998 14:37:30 -0400 (EDT) Received: from ironbridgenetworks.com ([146.115.140.2]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA22000 for ; Fri, 17 Apr 1998 14:37:26 -0400 (EDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id OAA08712; Fri, 17 Apr 1998 14:34:14 -0400 Date: Fri, 17 Apr 1998 14:34:14 -0400 Message-Id: <199804171834.OAA08712@ironbridgenetworks.com> From: James Carlson To: vjs@calcite.rhyolite.com CC: ietf-ppp@merit.edu In-reply-to: <199804171725.LAA09537@calcite.rhyolite.com> (message from Vernon Schryver on Fri, 17 Apr 1998 11:25:18 -0600 (MDT)) Subject: Re: An update to LBD References: <199804171725.LAA09537@calcite.rhyolite.com> Sender: owner-ietf-ppp@merit.edu > > The main disadvantage to the current MP technique is that it does not > > constrain the fragmentation which may be done by the peer. For sys- > > tems employing general purpose CPUs in the data path and with > > scatter-gather direct memory access (DMA) capability, this is often > > not a problem. For systems with very high bandwidth capabilities, > > these features are often infeasible, and this problem makes MP unus- > > able. > > I think that slightly misses the point. What you are trying to avoid is > not merely fragmentation by the sender, but two other things: > 1. fragment reassembly by the receiver > 2. packet (and fragment) re-ordering by the receiver. > > It's easy, even in fast hardware, to fragment packets as you send them. > (By "fast", I mean silicon GBytes/second, albeit not in routers or > bridges.) The bigger hassles are reassembling arbitrary sized fragments > and dealing with arbitrary orderings of the packets. IP fragment > reassembly is messy, but PPP MP reassembly and re-ordering is far worse. > The PPP MP re-ordering requirement, including detecting and dealing with > lost packets and fragments requires a lot more machinery. That's close to the point. There is also the issue that IP reassembly is done only by the host at the end of the connection. That host is (somewhat) required to keep up with the transport and application layers of things, so the overhead of IP or even MP is not much. MP (like PPP generally) is not only for end nodes but is also for links at the core of a network. In general I believe it is a good philosophy to avoid reassembly at the core of the network and allow only the end nodes deal with it. Thus, I don't want MP fragmentation and I don't want MP reassembly and I don't want MP reordering. All of these are painful. (Note that I lump in MP fragmentation. Yes, it's easy even at high speed, but it's also useless if the corresponding reassembly can't be done.) But I do like (well, after having lived with it for a while) the MP model of negotiating parallel links between hosts. If you can propose a reasonable alternative that detects the error cases that MP can detect and gives enough specificity that compatible implementations are likely, then I'm all ears. I agree that BF&I does work, and I agree that there are compatible versions. I'm *very* uncomfortable without at *least* having a BCP which says how this should be done in excruciating detail. > I don't see how this scheme is "compatible with MP." It is "similar" and > "related," and it might be "semi-compatible" or "upward-compatible." It > is not purely "compatible" because you cannot connect a typical PPP > implementation that supports RFC 1990 to an implementation that supports > this proposal and have things work well. On one hand, an implemenation > of this scheme would not like MP fragments from RFC 1990 > implementations, Nor would it ever see them -- the negotiation is such that the bundle won't establish itself that way. I see it as "compatible" since it will resolve to the right set of parameters if both support LBD (use LBD), one exclusively supports it (no MP at all), or neither supports it (use regular MP). > and there are RFC 1990 implementations that would not appreciate not > receiving IP packets without MP headers while there are several links in > the bundle. Nor would this be an issue, given that it must be negotiated and agreed to by the peers. Do any PPP implementations send Configure-Ack for options that they don't even understand? > > 2. No-Fragmentation Configuration Option Format > > > ... Implementations MUST NOT Configure- > > Nak this option. > > Why not Configure-Nak for it? It's a boolean, like short sequence numbers. Except for an unsolicted Nak, there's nothing that can be hinted here. Either the peer implements it, or it doesn't. Allowing a general Nak doesn't make much sense. > > A summary of the No-MP-Headers Configuration Option format for LCP is > > > ... > > If this option is specified, then the No-Fragmentation option is > > unnecessary. Fragmentation without MP headers is not supported. > > Instead of "not supported," how about "impossible"? Pretty close. I suppose you could use the old ISO 7776 multilink with this, but, then, that would be rather stupid. -- 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 Fri Apr 17 15:43:58 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA23365; Fri, 17 Apr 1998 15:43:38 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Apr 1998 15:43:11 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA23321 for ietf-ppp-outgoing; Fri, 17 Apr 1998 15:43:10 -0400 (EDT) Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA23312 for ; Fri, 17 Apr 1998 15:43:02 -0400 (EDT) Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id MAA17987; Fri, 17 Apr 1998 12:42:19 -0700 (PDT) Date: Fri, 17 Apr 1998 12:42:19 -0700 (PDT) From: John Bray Reply-To: John Bray To: James Carlson cc: ietf-ppp@merit.edu Subject: Re: An update to LBD In-Reply-To: <199804171834.OAA08712@ironbridgenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Fri, 17 Apr 1998, James Carlson wrote: (snip) > > > > 2. No-Fragmentation Configuration Option Format > > > > > ... Implementations MUST NOT Configure- > > > Nak this option. > > > > Why not Configure-Nak for it? > > It's a boolean, like short sequence numbers. Except for an unsolicted > Nak, there's nothing that can be hinted here. Either the peer > implements it, or it doesn't. Allowing a general Nak doesn't make > much sense. I agree, there seems little point in including this in an unsolicited NAK. It would mean "I want you to tell me not to fragment". If you don't want to fragment, you don't have to, you don't need to tell the peer to force you not to. John - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Apr 17 15:37:45 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA23166; Fri, 17 Apr 1998 15:37:43 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Apr 1998 15:37:22 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA23144 for ietf-ppp-outgoing; Fri, 17 Apr 1998 15:37:21 -0400 (EDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA23132 for ; Fri, 17 Apr 1998 15:36:59 -0400 (EDT) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id MAA24617; Fri, 17 Apr 1998 12:35:25 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma024613; Fri Apr 17 12:35:13 1998 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id MAA07341; Fri, 17 Apr 1998 12:35:12 -0700 (PDT) From: Archie Cobbs Message-Id: <199804171935.MAA07341@bubba.whistle.com> Subject: Re: An update to LBD In-Reply-To: <199804171546.LAA15906@ironbridgenetworks.com> from James Carlson at "Apr 17, 98 11:46:46 am" To: carlson@ironbridgenetworks.com (James Carlson) Date: Fri, 17 Apr 1998 12:35:12 -0700 (PDT) Cc: ietf-ppp@merit.edu X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu James Carlson writes: > 1. Introduction > > Standard PPP negotiation allows for two types of links with regard to > multiple link layer entities. The standard type of PPP link is nego- > tiated without the Maximum-Receive-Reconstructed-Unit (MRRU) option > and appears as a separate network interface to the network layer and > to routing protocols. The Multilink PPP (MP) [2] type of link uses > the MRRU option and allows multiple PPP links to be bundled into one > network interface. An MP link appears as a single network interface ^^^^ > to the network layer and to routing protocols. Shouldn't that word be "bundle" ? > There are many advantages having multiple links between two nodes > appear at the network layer to be a single link. While equal-cost > multi-path balancing is certainly possible with modern interior gate- > way protocols, less stress is placed on scarce routing system > resources when link-layer detection is employed, allowing current ^^^^^^^^^^^^^^^^^^^^ > routing protocols to scale farther. Also, routing system stability > in the face of link failures is usually higher when individual links > are not visible to the routing protocols. The phrase "link-layer detection" is not a familiar to me. What does it mean? > This option SHOULD not be used on links which are intended to carry ^^^^^^^^^^ > network protocols which cannot tolerate reordering. See section blah > for details. Nit: should not this be "SHOULD NOT" instead of "SHOULD not" ? It just reads kinda funny. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Apr 17 19:30:30 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id TAA28075; Fri, 17 Apr 1998 19:30:21 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Apr 1998 19:29:38 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA28044 for ietf-ppp-outgoing; Fri, 17 Apr 1998 19:29:37 -0400 (EDT) Received: from server.indra.com (server.indra.com [204.144.142.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA28036 for ; Fri, 17 Apr 1998 19:29:33 -0400 (EDT) Received: from indra.com (net.indra.com [204.144.142.1]) by server.indra.com (8.8.5/) with ESMTP id RAA11564 for ; Fri, 17 Apr 1998 17:29:34 -0600 (MDT) Received: (from calcite@localhost) by indra.com (8.8.5/Spike-8-1.0) with UUCP id RAA23727 for ietf-ppp@merit.edu; Fri, 17 Apr 1998 17:19:35 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/8.7.3) id RAA10012 for ietf-ppp@merit.edu; Fri, 17 Apr 1998 17:04:29 -0600 (MDT) Date: Fri, 17 Apr 1998 17:04:29 -0600 (MDT) From: Vernon Schryver Message-Id: <199804172304.RAA10012@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: An update to LBD Sender: owner-ietf-ppp@merit.edu > > > > 2. No-Fragmentation Configuration Option Format > > > > > > > ... Implementations MUST NOT Configure- > > > > Nak this option. > > > > > > Why not Configure-Nak for it? > > > > It's a boolean, like short sequence numbers. Except for an unsolicted > > Nak, there's nothing that can be hinted here. Either the peer > > implements it, or it doesn't. Allowing a general Nak doesn't make > > much sense. > > I agree, there seems little point in including this in an unsolicited > NAK. It would mean "I want you to tell me not to fragment". If you > don't want to fragment, you don't have to, you don't need to tell the > peer to force you not to. Ok, but what about the no-MP-header option? If you insist on not spending cycles sending the MP header, how do you convey to the peer that is why you are refusing to run? On the other hand, if John Carlson's system is prepared to send MP headers in its high speed mode, then a case can be made that this whole proposal is unneeded. What if these systems would negotiate MP the old fashioned way, and then just use the RFC 1990 permission to send IP packets without MP headers? And route any incoming packets bearing MP headers via the extremely super slow path? And go slowly if any of the MRUs of the links differ? That way - a pair of his systems would go fast, just as is the case with the proposed PPP extension. - a pair would be protected from errors and so forth by the MP negotiation, just as with the proposal. - one of his systems would interoperate with any other MP system, albeit slowly, just as is the case with the proposal. - since LCP and other non-IP packets are extremely rare and surely treated as very special cases in an extremely super-slow path (relatively speaking), it does not matter if they have MP headers or not. - no new RFC's would be required - real life operational experience could be obtained before setting the idea in standards concrete. It is extremely difficult to change a protocol after it has been given a number. You can hardly do anything except make a whole new option. Note that I'm not talking about ordinary BF&I multilink, but the words in RFC 1990 about not including MP headers. Yes, I realize that only a matter of hours ago I claimed that some systems probably don't like missing MP headers; Let 'em be fixed. Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Apr 17 22:32:09 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id WAA29456; Fri, 17 Apr 1998 22:32:02 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 17 Apr 1998 22:30:41 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id WAA29418 for ietf-ppp-outgoing; Fri, 17 Apr 1998 22:30:40 -0400 (EDT) Received: from due.unit.no (due.unit.no [129.241.1.83]) by merit.edu (8.8.7/8.8.5) with ESMTP id WAA29414 for ; Fri, 17 Apr 1998 22:30:35 -0400 (EDT) Received: from jj3dw3.q3q3665f.com (199-170-160-210.la.inreach.net [199.107.160.210]) by due.unit.no (8.7.5/8.7.3) with SMTP id EAA10843; Sat, 18 Apr 1998 04:28:32 +0200 (METDST) Date: Sat, 18 Apr 1998 04:28:32 +0200 (METDST) From: 2c2c447 <2c2c447@msn.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Friday, May 1st, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Wednesday, April 29th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Monday, April 27th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Sunday, April 26th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Saturday, May 2nd, 1998 Reply-To: 3d2c447@msn.com Sender: owner-ietf-ppp@merit.edu Authenticated sender is <3d2c447@msn.com> Subject: when Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Apr 18 00:12:25 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id AAA00604; Sat, 18 Apr 1998 00:12:12 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sat, 18 Apr 1998 00:11:34 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA00545 for ietf-ppp-outgoing; Sat, 18 Apr 1998 00:11:33 -0400 (EDT) Received: from gate.ssb.no (gatekeeper.ssb.no [193.69.34.114]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA00540 for ; Sat, 18 Apr 1998 00:11:24 -0400 (EDT) Received: (from uucp@localhost) by gate.ssb.no (8.8.5/8.8.5) id GAA10421; Sat, 18 Apr 1998 06:03:42 +0200 (MET DST) Date: Sat, 18 Apr 1998 06:03:42 +0200 (MET DST) Received: from 206-18-113-192.la.inreach.net(206.18.113.192) via SSB Mail service id smac10356; Sat Apr 18 05:58:22 1998 From: 3d2c447 <3d2c447@msn.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Friday, May 1st, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Wednesday, April 29th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Monday, April 27th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Sunday, April 26th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Saturday, May 2nd, 1998 Reply-To: 3d2c447@msn.com Sender: owner-ietf-ppp@merit.edu Authenticated sender is <3d2c447@msn.com> Subject: when Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Apr 18 00:59:16 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id AAA01189; Sat, 18 Apr 1998 00:59:14 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sat, 18 Apr 1998 00:59:01 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA01165 for ietf-ppp-outgoing; Sat, 18 Apr 1998 00:59:01 -0400 (EDT) Received: from marvin.arena.ch (marvin.arena.ch [194.209.24.224]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA01158 for ; Sat, 18 Apr 1998 00:58:55 -0400 (EDT) Date: Sat, 18 Apr 1998 00:58:55 -0400 (EDT) Received: from jj3dw3.q3q3665f.com ([206.18.115.128]) by marvin.arena.ch (Netscape Mail Server v2.02) with SMTP id AAC23721; Sat, 18 Apr 1998 06:58:46 +0200 From: 4n2c447 <4n2c447@msn.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Friday, May 1st, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Wednesday, April 29th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Monday, April 27th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Sunday, April 26th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Saturday, May 2nd, 1998 Reply-To: 4n2c447@msn.com Sender: owner-ietf-ppp@merit.edu Authenticated sender is <4n2c447@msn.com> Subject: when Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-980-7850 CALL FOR MORE INFORMATION 213-980-7850 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-980-7850 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Apr 20 09:34:34 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA29770; Mon, 20 Apr 1998 09:33:20 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 20 Apr 1998 09:28:51 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA29670 for ietf-ppp-outgoing; Mon, 20 Apr 1998 09:28:50 -0400 (EDT) Received: from zrchs148.us.nortel.com (smtprich.nortel.com [192.135.215.8]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA29665 for ; Mon, 20 Apr 1998 09:28:46 -0400 (EDT) Received: from zrtpd004.us.nortel.com by smtprich; Mon, 20 Apr 1998 08:26:45 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.0.1460.8) id ; Mon, 20 Apr 1998 09:26:07 -0400 Message-ID: <915C65C50371D11187AD0000F881B9A44C8C66@bcarua62.ca.nortel.com> From: "David Allan" To: "'ietf-ppp@merit.edu'" Subject: MARS proxy for PPP/ATM Date: Mon, 20 Apr 1998 09:26:15 -0400 X-Mailer: Internet Mail Service (5.0.1460.8) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu The following was presented at the PPPEXT session in LosAngeles. I'd appreciate feedback posted on the list. The draft is also available from the IETF web site: http://www.ietf.cnri.reston.va.us/internet-drafts/draft-allan-ion-mars-proxy -00.txt The "ion" in the title is a historical anacronism ;-) Cheers Dave ----------------------------------------------- Network Working Group David Allan, Nortel INTERNET DRAFT March 13th, 1998 Expires September 13th, 1998 MARS Proxy Status Of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract: The Point-to-Point Protocol (PPP) [1] has been proposed as an access vehicle for public ATM networks. Support for multicast in this environment via either RAS replication, or a adding MARS client side by side with PPP is problematic on several fronts. This document describes how an ATM attached system can act as a MARS proxy on behalf of a PPP client. This solution circumvents many of the associated problems with respect to VC frugality, scalability, and authentication. Applicability: This specification is intended for those implementations which desire to implement a MARS proxy on behalf of any client base. The original motivation for this work was to augment the capability presented to PPP over ATM clients, however the work has been sufficiently generalized to be extensible to other applications. Allan Expires Sept 13th 1998 [Page 1] Internet Draft MARS Proxy January 22nd,1998 This document should be read as an extension of RFC 2022 and assumes familiarity with RFCs 1112, 2022 and 2236. The focus of this document in describing the MARS proxy is IPv4/IGMP but it is expected that this work could be easily generalized to other protocols. Table of Contents 1. Conventions 3 2. Terminology 3 3. Introduction 3 4. MARS proxy behavior 4 4.1 Transmit Side behavior 5 4.2 Receive Side behavior 5 4.2.1 Joining a multicast group 5 4.2.2 Leaving a Multicast group 6 4.3 Encapsulation 6 5. Proxy client behavior 7 5.1 Modifications to RFC1112 and RFC2236 7 5.2 Reflected packet detection 7 6. MARS Behavior 7 7. Security Provisions 7 7.1 Restriction of Multicast operation to MCS 7 7.2 MARS proxy to MARS/MCS connectivity 8 7.3 Proxy client screening of incoming p2mp VCs 9 8. Fate sharing 10 9. Specific PPP over ATM considerations 10 9.1 PPP over ATM, MARS and L2TP 10 9.2 Backwards compatibility with initial PPP over ATM implementations 11 9.3 MARS cluster LIS Restriction 11 9.4 Multiple 'layer 3 over ATM interfaces' 12 9.5 Collapsed Architecture 12 10. Security Considerations 12 11. Acknowledgments 12 12. References 12 13. Authors Address 13 Allan Expires Sept 13th 1998 [Page 2] Internet Draft MARS Proxy January 22nd,1998 1. Conventions In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST - This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT - This phrase means that the definition is an absolute prohibition of the specification. SHOULD - This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications MUST be understood and carefully weighed before choosing a different course. MAY - This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. 2. Terminology MARS proxy: A MARS client that functions on behalf of one or more ATM endpoints. A potential example would be a broadband RAS. Proxy client: An ATM endpoint serviced by a MARS proxy. 3. Introduction The PPP model traditionally assumes that a session between "peers" consists of a single logical connection (which may consist of multiple physical connections inverse multiplexed). The definition of PPP over ATM [2] (work in progress) and PPP over Frame Relay [3] currently adhere to this convention. This convention also requires that for IP multicast, the Remote Access Server (RAS) function as a multicast router and perform replication of multicast traffic to each PPP attached "destination". This has undesirable scaling properties w.r.t. the consumption of bandwidth in the ATM subnet. This is exacerbated once multiple RAS's are required to service the ATM subnet; more bandwidth is required in the network behind the RASs. However it is only by convention that all IP traffic between PPP "peers" be carried within the PPP session/connection. In the ATM access environment where PPP over ATM has been proposed, one peer will typically be an ISP client, the other an ISP, and the ATM subnet will be Allan Expires Sept 13th 1998 [Page 3] Internet Draft MARS Proxy January 22nd,1998 a public network. If the ISP wished to offer IP based multicast services, it would be desirable for the ISP if only a single multicast source (e.g. MCS) was required to service the ATM subnet, and that the ISP could limit users of the MCS to authenticated clients. The MARS/MCS model [4] has the desirable attribute that all destinations for an IP multicast group in the NMBA subnet can be serviced by a single p2mp tree. However the MARS/MCS model brings significant overhead: * the client host needs to be configured with knowledge of the MARS. Techniques such as ILMI based server discovery are inappropriate. The management of the network cannot have advance knowledge of the PPP peer. * the client needs a p2p VC and is a leaf on the p2mp cluster control VC to participate in the multicast control structure. * the client requires a p2p VC to each MCS to source traffic and is a leaf on a p2mp VC to receive traffic typically for each multicast group. and numerous unsolved issues with respect to authentication of the client (which also renders p2mp VC meshing as per [4] sect. 3.1 inappropriate for this particular application). Much of this configuration and connectivity burden on the client could be alleviated, and the authentication issues addressed if the RAS proxied connectivity to the MARS and MCS on behalf of the PPP client and the set of multicast "destinations" in the ATM subnet could be serviced by p2mp tree(s) rooted in the ISP network. The motivation for this document assumes use of MCSs but the work has been generalized to encompass p2mp meshing as well. 4. MARS proxy behavior The MARS proxy mimics a multicast router ([5] Appendix I) to its set of proxy clients and interworks IGMP (version 1 or version 2) with MARS. The MARS proxy must be able to detect and manage multicast activity for a group via two mechanisms. Either the proxy client issues an IGMP report indicating that it has joined a group and wishes to receive traffic from that group (as a 'destination'), or it has directed a packet to that groups class 'D' address (as a 'source'). This is typically termed 'receive side' and 'transmit side' respectively. A client indicating 'destination' status for a group must have that status periodically re-confirmed via IGMP query messages. The MARS proxy MUST maintain group membership state for each of its proxy clients. This specification provides for both permanent and transient paths to Allan Expires Sept 13th 1998 [Page 4] Internet Draft MARS Proxy January 22nd,1998 both the MARS and the multicast group. 4.1 Transmit side behavior Transmit side behavior is as per [4] sect 5.1. with the following proviso: The MARS proxy MAY not have ATM connectivity to multicast destinations on the ATM subnet (hosts or MCS) for technical or policy reasons. The MARS proxy may be located at the edge of an ATM subnet and have a forwarding path for multicast traffic outside the ATM subnet. Should the MARS have no mapping for the desired class 'D' address, or be configured specifically to provide a MARS_NAK response, the MARS proxy SHOULD have the option to forward the packet outside the ATM subnet OR to silently discard the packet. A MARS proxy implementation may choose to use MARS_REQUEST to dynamically determine availability or may choose to do so via the MARS_GROUPLIST_REQUEST facility. Although there is an expectation that a multicast router will be a MARS client (possibly integrated), the network operator may wish to limit what multicast groups are supported by MARS/MCS (not fully promiscuous) for reasons of tariffs, service differentiation or other, or may wish to restrict direct ATM connectivity from the MARS proxies to an MCS. Non- ATM MCS connectivity (back end via any attached multicast router) can be done transparently without fear of routing loops or reflection problems. This will introduce additional latency when compared with a direct ATM path and requires some administrivia in that filtering of group lists is required for responses to MARS_REQUESTs. Hosts blocked from direct MCS connectivity would receive MARS_NAKS as a response to MARS_REQUESTs. 4.2 Receive side behavior The receiver side behavior of the MARS proxy is as per [4] section 5.2 but with the difference that: - the MARS proxy is a cluster member in that it participates in the cluster control structure. - the MARS proxy is not a group member in that it is not a 'source' nor 'destination' of multicast traffic for any multicast group. It does forward multicast traffic 'sourced' by its set of proxy clients to the set of 'destinations' specified by MARS interaction. An associated difference is that when p2mp meshing is used and a p2mp VC is rooted at the proxy, the set of end points may include proxy clients served by the MARS proxy. 4.2.1 Joining a multicast group Allan Expires Sept 13th 1998 [Page 5] Internet Draft MARS Proxy January 22nd,1998 Unlike a normal MARS client, issuing a MARS_JOIN on behalf of a proxy client may involve modifications to the set of destinations served by a locally rooted p2mp VC (addition of the proxy). When the MARS proxy receives an IGMP_Report from a proxy client it performs the following actions: i) Ensures that it is registered with a MARS. ii) Issues a MARS_JOIN to the currently attached MARS for the requested group. The MARS_JOIN request conforms to [4] sect 5.2.1 with the exception that: - the mar$sha value is set to the ATM address of the proxy client rather than that of the MARS proxy - the mar$spa value is to the layer 3 address of the proxy client rather than the MARS proxy. iii) Upon receipt of MARS_JOIN confirmation, check if there is a pre- existing p2mp VC associated with the group rooted at the MARS proxy. If so, the MARS proxy MUST determine if local ATM connectivity be modified to support the addition of the proxy client. It issues a MARS_REQUEST to determine group membership. The MARS_MULTI responses are audited against the pre-existing p2mp VC and it is appropriately modified. If there is no pre-existing VC then the MARS proxy initiates one as per [4] sect 5.1.3. The MARS_REQUEST step MAY be dispensed with by observing which path the MARS_JOIN confirmation arrives on. If it arrives on the cluster control VC, then p2mp meshing is employed and adding the proxy client is required. If it arrives on the MARS unicast VC (curiously un-named in RFC 2022), then an MCS is employed and no ATM connectivity changes are needed. This is not as authoritative as re-validating the set of 'destinations' but does reduce the amount of traffic and may be an optimization in some circumstances. Some hybrid of the two approaches may be employed to combine robustness with frugality. 4.2.2 Leaving a multicast group When a MARS proxy has issued an IGMP_QUERY to a proxy client and the absence of response indicates that a proxy client has left a multicast group or an explicit IGMPv2_LEAVE is received, the MARS proxy will issue a MARS_LEAVE for the specified proxy client/specified group. 4.3 Encapsulation Multicast sources MUST use type #2 encapsulation as defined in [4] sect 5.5.2. When the MARS proxy is forwarding traffic sourced by its proxy client base, the MARS proxy will insert the address of the proxy client Allan Expires Sept 13th 1998 [Page 6] Internet Draft MARS Proxy January 22nd,1998 as the source ID. For IPv4, this will occupy the first four octets of the 8 octets allocated. The remaining octets should be zeroed. 5.0 proxy client behavior 5.1 Extensions to RFC1112 and RFC2236 The proxy client behavior corresponds to either RFC1112 [5] or RFC 2236 [9] with modifications such that multicast traffic MAY be received over transient p2mp paths. Further elaboration on criteria for accepting incoming p2mp calls and mapping calls to the correct 'layer 3 over ATM' interface is discussed in section 7.3. 5.2 Reflected packet detection Use of a MARS proxy means that the reflected packet problem exists regardless of the multicast topology used (p2mp mesh OR MCS). Use of the CMI (type #1) as a filtering mechanism is inadequate as the CMI has insufficient granularity for a proxy community. Each proxy client is required to examine the type #2 encap. source ID field in each packet received and silently discard all packets originating with itself. 6. MARS behavior The MARS MUST track group memberships by cluster member ID (cmi) to correctly associate the MARS proxy (i.d.'d by the cmi) with the proxy client base. This permits the MARS to correctly perform resource recovery when there is a loss of connectivity between the MARS and the proxy client. So [4] Appendix 'F' sect 1.2 handling of an ERR_L_RELEASE would read: Remove all ATM endpoints associated with the cmi associated with the ERR_L_RELEASE from all groups. 7. Security provisions The following discussion focuses on then problem of securing the ATM end-points on a public network and suggests several strategies for minimizing the number of points that need be secured against unauthorized calls. In general the strategy is to minimize the number of points that are required to accept incoming calls. 7.1 Restriction of Multicast operation to MCS Although the function of a MARS proxy is not limited to operation with an MCS, implementations SHOULD permit administrative limitation of operation to supporting MCS multicast only (as opposed to p2mp meshed). Allan Expires Sept 13th 1998 [Page 7] Internet Draft MARS Proxy January 22nd,1998 The mechanisms to do so are outside the scope of this document. (see also sect. 4.1) 7.2 MARS proxy to MARS/MCS connectivity One issue w.r.t. MARS and MCS is that in a public network, it is useful to secure these ATM end-points from unauthorized access. The entire set of mechanisms for accomplishing this is outside the scope of this document. There are a number of connections to be secured. A MARS proxy is connected to the MARS via the p2p bi-directional control VC and is a leaf on the p2mp cluster control VC. An MCS is connected to the MARS via a p2p control VC and is a leaf on the p2mp server control VC. The MARS proxy will be connected to MCSs of interest via a p2p VC. RFC 2022 [4] sect. 5 suggests that these are transient connections with a recommended time out. However in an environment where a relatively small number of MARS proxies serves a large number of proxy clients for a small number of multicast groups, a provisioned infrastructure is not an unreasonable solution. This specification recommends that the option of PVC connectivity to the MARS be included for the following reasons: * authentication of the proxy would be based on physical connectivity * the community of MARS clients would be relatively small, so scaling the number of p2p and p2mp VCs is not an issue. * the number of hosts serviced by a MARS proxy would be relatively large * when combined with provisioned connectivity to an MCS/MCSs, all transient connections are initiated by the MCS only (L_MULTI_RQ or L_MULTI_ADD). The MARS and MCS are not required to accept incoming calls. PVC connectivity does not imply proxy to MARS connectivity. It is possible for either to lose state. Therefore PVC connectivity comes with the following provisos: 1) The MARS proxy MUST register by issuing a MARS-JOIN after any start up. 2) Upon receipt of a MARS-JOIN, the MARS will assume that it was preceded by a loss of connectivity to the MARS proxy. The MARS will use the cluster member identifier associated with the previous session with the MARS proxy to identify any pre-existing group memberships and tear them down. 3) Upon receipt of a MARS-JOIN, the MARS will assume Cluster Control VC Allan Expires Sept 13th 1998 [Page 8] Internet Draft MARS Proxy January 22nd,1998 connectivity to the MARS client has been pre-established. Similarly for MARS to MCS connectivity 1) The MCS will register by issuing a MARS_MSERV after any startup. 2) The MCS will issue a MARS_REQUEST to re-discover supported group membership and re-establish the p2mp tree. Note that the intent is not to preclude SVC connectivity to the MARS/MCS, only to provide a solution that includes authentication of the client without either "yet-to-be-invented" access control protocols or access lists. 7.3 Proxy client screening of incoming p2mp VCs A proxy client is obliged to accept incoming p2mp calls without an authoritative authentication mechanism. The definition of this is outside the scope of this document. Further, the proxy client is typically not able to determine which IP network the p2mp call(s) originates from in the scenarios where multiple layer 3 over ATM interfaces is being supported. Once a proxy client is a member of a multicast group, it must be prepared to accept an arbitrary number of incoming p2mp calls at arbitrary times during the duration of group membership. Multiple layer 3 interfaces over ATM merely compounds the problem. The chief security vulnerability would be an insertion attack in which a malicious entity masquerades as a p2mp VC to obtain unauthorized access to the proxy client. This assumes some knowledge of the proxy client, and assumes that a separate VC offers opportunities to exploit security vulnerabilities that are not available by other means. To provide a first tier authentication of incoming calls against insertion attacks and to successfully map incoming p2mp calls to the correct layer 3 interface, the root add leaf signalling SHOULD also echo back the layer 3 address of the leaf. P2mp roots (either MARS proxies, hosts or MCSs) compliant with this approach would echo the lower 6 bytes of the mar$spa field in the UNI 3.0/3.1 BHLI field. Where the source protocol address length is less than 6 (as indicated in the mar$spln field), the most significant octets of the BHLI field will be zeroed. Incoming calls with an incorrect BHLI are rejected with a cause of 21 "call rejected" ([8] sect. 5.4.5.15). It is useful to limit the scope of what a malicious insertion attack can accomplish to significantly less than that of the coexisting layer 3 connectivity. This can be performed by several means: Allan Expires Sept 13th 1998 [Page 9] Internet Draft MARS Proxy January 22nd,1998 i) Timing: A proxy client MUST not accept any incoming p2mp calls on a layer 3 over ATM interface while not currently a member of a multicast group. Good security practice suggest that clients SHOULD record information on unexpected incoming call requests. ii) Limiting destination addressability: Packets arriving on a p2mp VC associated with multicast should be filtered according to the destination multicast address. Rejected packets MUST be silently discarded. Good security practice suggests that clients SHOULD record information on discarded packets. iii) Correctly limiting VC capability A p2mp VC is unidirectional, therefore no traffic should be able to be forwarded onto that VC by the proxy client. This MUST be reflected in calling traffic descriptors. Calls in which the backward cell rates are not set to zero MUST be rejected. 8. Fate sharing It is important for network resource management and recovery that multicast group membership by a proxy client be tightly coupled to connectivity between the proxy client and the MARS proxy. One example of this would be the existence of a PPP session between the proxy client and the MARS proxy (specifically an active NCP). Should, by whatever means, the MARS proxy detect loss of connectivity to a proxy client it will issue MARS_LEAVEs for all groups associated with the proxy client. Loss of connectivity between the MARS and MARS proxy is discussed in sect. 4.4. 9. Specific PPP over ATM considerations 9.1 PPP over ATM, MARS and L2TP One scenario of interest is when there is service interworking in the network core and multiple PPP sessions are aggregated into an L2TP [7] (work in progress) tunnel. The assumption is that ATM exit point was an L2TP Access Concentrator (LAC). The following provisos apply: 1) MARS control messages are not routable therefore some direct connectivity is required between a MARS proxy and MARS for control traffic. 2) Where an MCS is employed, direct connectivity between the MARS proxy Allan Expires Sept 13th 1998 [Page 10] Internet Draft MARS Proxy January 22nd,1998 and the MCS is not required. As discussed in sect 4.1, a MARS proxy may forward multicast traffic to the MCS via a non-NBMA path. 3) The MARS proxy requires knowledge of the ATM end-point address of the proxy client. The dialing number in an Incoming Call Request (ICRQ, [7] sect 6.9) would be a suitable mechanism. A PVC architecture between the PPP client and the L2TP LAC could be supported but is outside the scope of this document. 9.2 Backwards compatibility with initial PPP over ATM implementations A desirable goal would be that multicast worked with any combination of proxy client vintage and MARS proxy vintage. There are three scenarios possible: 1) The RAS does not support MARS proxy. The proxy client is a don't care. In this scenario, all multicast traffic will traverse the unicast PPP path. This will be effectively transparent to the end-system. 2) The RAS supports MARS proxy and the proxy client supports MARS proxy p2mp call back. 3) The RAS supports MARS proxy and the proxy client does not support p2mp call back. There are two sub-cases: i) The PPP client cannot handle a p2mp callback. In this scenario, the L_MULTI_ADD will fail with a reason code other than those which suggest retry ([4] sect 5.1.3) and MARS clients/MCSs will silently drop the client from group membership. It is assumed such clients pre-date this specification therefore their behavior cannot be retroactively defined. The proxy client nor the MARS proxy can recover as there is no knowledge of failure. This is an insoluble problem unless the MARS proxy can obtain knowledge of the connectivity failure (true for p2mp mesh, false for MCS). ii) The PPP client accepts p2mp callback but cannot process multicast encapsulated packets. The user is effectively blocked from receiving packets from the multicast group supported by the p2mp VC. 9.3 MARS cluster LIS Restriction A MARS cluster is currently defined as serving a single LIS. The restriction is intended to minimize the problems of interaction of multicast routing protocols and subnet boundaries (pending further research). In, for example the PPP over ATM case, there is no LIS: the end system is reachable via a host route. A PPP connected end system is also typically (but not always) connected as a stub network therefore Allan Expires Sept 13th 1998 [Page 11] Internet Draft MARS Proxy January 22nd,1998 multicast routing topology problems are not expected to emerge. In this particular application this restriction does not apply. The complicated scenario is when an end-system is homed on more than one MARS proxy. This is a topic for further study. 9.4 Multiple 'layer 3 over ATM interfaces' A MARS proxy client will typically be located at a single PPP over ATM RAS and as such the MARS client MAY (not MUST) allow for multiple independent 'layer 3 over ATM' interfaces. 9.5 Collapsed Architecture The MARS architecture defines the different entities and interactions such that each function may be hosted on different platforms. It would be reasonable to suggest that for simplicity, the function of MARS, MCS and multicast router at the edge of the ATM subnet could be collapsed onto a single platform. 10. Security Considerations The focus of the security considerations expressed in this document have assumed a public ATM network. Therefore the mechanisms described herein have been concerned with ensuring hosts/systems who do not have a relationship with the operator/owner of the MARS/MCS infrastructure are obstructed from access to it or authorized proxy clients. Once authorized access to the 'layer 3' network has been established, the security considerations are similar to that both MARS/MCS or of IP multicast in general. The reader is directed to [6] as a discussion of some of the other pertinent security issues with ION protocols. 11. Acknowledgments This design is an extension of work originally proposed at the ADSL forum with Juha Heinanen of Telia, and Petri Helenius of Santa Monica Software. 12. References [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [2] Gross, G. et al, "PPP over AAL5", draft-ietf-pppext-aal5-04.txt, Dec 1997 [3] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996 [4] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996 Allan Expires Sept 13th 1998 [Page 12] Internet Draft MARS Proxy January 22nd,1998 [5] Deering, S., "Host Extensions for IP Multicasting", STD 3, RFC 1112, August 1989 [6] Armitage, G., "Security issues for ION protocols", Internet Draft , October 1997 [7] Hamzeh, K. et. al., "Layer Two Tunneling Protocol 'L2TP'", Internet Draft, , November 1997 [8] ATM Forum, "ATM User-Network Interface Specification Version 3.0", September 1993 [9] Fenner, W., "Internet Group Management Protocol, Version 2", RFC2236, November 1997 13. Author's Address Questions about this memo can also be directed to: Dave Allan Nortel P.O. Box 3511, Station 'C' Ottawa, Ontario CANADA, K2B 5P9 Tel: (613)763-6362 dallan@nortel.ca ----------------------- Dave Allan Nortel PDN Architecture Team - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Apr 21 05:54:36 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id FAA19572; Tue, 21 Apr 1998 05:53:55 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 21 Apr 1998 05:50:32 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id FAA19511 for ietf-ppp-outgoing; Tue, 21 Apr 1998 05:50:31 -0400 (EDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id FAA19507 for ; Tue, 21 Apr 1998 05:50:28 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id FAA17785; Tue, 21 Apr 1998 05:49:53 -0400 (EDT) Message-Id: <199804210949.FAA17785@ns.ietf.org> To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: The IESG SUBJECT: Last Call: IP Header Compression over PPP to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 21 Apr 1998 05:49:53 -0400 Sender: owner-ietf-ppp@merit.edu The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider IP Header Compression over PPP 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 May 5, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-engan-ip-compress-02.txt - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Apr 21 13:08:58 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA25441; Tue, 21 Apr 1998 13:08:45 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 21 Apr 1998 13:07:55 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA25391 for ietf-ppp-outgoing; Tue, 21 Apr 1998 13:07:54 -0400 (EDT) Received: from dogwood-fddi.cisco.com (dogwood-fddi.cisco.com [171.68.122.80]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA25380 for ; Tue, 21 Apr 1998 13:07:45 -0400 (EDT) Received: from cisco.com (chsharp-isdn.cisco.com [171.68.116.221]) by dogwood-fddi.cisco.com (8.8.5/CISCO.SERVER.1.2) with ESMTP id NAA19974; Tue, 21 Apr 1998 13:06:59 -0400 (EDT) Message-ID: <353CD12D.9352496@cisco.com> Date: Tue, 21 Apr 1998 13:02:37 -0400 From: Chip Sharp Organization: Cisco Systems X-Mailer: Mozilla 4.04 [en]C-CISCOIS (Win95; U) MIME-Version: 1.0 To: David Allan CC: ietf-ppp@merit.edu Subject: Re: MARS proxy for PPP/ATM References: <915C65C50371D11187AD0000F881B9A44C8C66@bcarua62.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Could you please point out the extensions to PPP that you propose? Despite the use of the acronym PPP in the document, I did not see any proposed PPP extensions. I don't think pppext is the appropriate place for this. It belongs in ion. I read the minutes and I understand that ion is not taking any more work, but that needs to be resolved with ion, not in pppext. If the rest of the pppext WG disagrees and wants to start working on things outside of PPP, then I'll provide technical comments/questions. The pppext charter is sufficiently vague that we can justify working on pretty much whatever we want. I especially like the "No Goals and Milestones". See http://www.ietf.org/html.charters/pppext-charter.html Chip David Allan wrote: > > The following was presented at the PPPEXT session in LosAngeles. I'd > appreciate feedback posted on the list. The draft is also available from the > IETF web site: > http://www.ietf.cnri.reston.va.us/internet-drafts/draft-allan-ion-mars-proxy > -00.txt > > The "ion" in the title is a historical anacronism ;-) > > Cheers > Dave > ----------------------------------------------- ...snip... ------------------------------------------------- Chip Sharp voice: +1 (919) 851-2085 Cisco Systems Telco Consulting ------------------------------------------------- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Apr 21 14:32:15 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA26946; Tue, 21 Apr 1998 14:32:00 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 21 Apr 1998 14:31:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA26910 for ietf-ppp-outgoing; Tue, 21 Apr 1998 14:31:18 -0400 (EDT) Received: from ironbridgenetworks.com ([146.115.140.2]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA26904 for ; Tue, 21 Apr 1998 14:31:14 -0400 (EDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id OAA06415; Tue, 21 Apr 1998 14:31:08 -0400 Date: Tue, 21 Apr 1998 14:31:08 -0400 Message-Id: <199804211831.OAA06415@ironbridgenetworks.com> From: James Carlson To: chsharp@cisco.com CC: ietf-ppp@merit.edu In-reply-to: <353CD12D.9352496@cisco.com> (message from Chip Sharp on Tue, 21 Apr 1998 13:02:37 -0400) Subject: Re: MARS proxy for PPP/ATM References: <915C65C50371D11187AD0000F881B9A44C8C66@bcarua62.ca.nortel.com> <353CD12D.9352496@cisco.com> Sender: owner-ietf-ppp@merit.edu > Could you please point out the extensions to PPP that you propose? > > Despite the use of the acronym PPP in the document, I did not see any > proposed PPP extensions. I don't think pppext is the appropriate place > for this. It belongs in ion. I read the minutes and I understand that > ion is not taking any more work, but that needs to be resolved with ion, > not in pppext. My thoughts on reading the draft as well. > If the rest of the pppext WG disagrees and wants to start working on > things outside of PPP, then I'll provide technical comments/questions. I agree that the sections which seem to specify interaction with L2TP also don't actually specify anything that appears to be different from what we've got today. I think this belongs in a new "ion2" or (even) issll. Even the AD is probably a better place than pppext ... -- 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 Apr 21 15:24:46 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA28451; Tue, 21 Apr 1998 15:24:43 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 21 Apr 1998 15:24:24 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA28425 for ietf-ppp-outgoing; Tue, 21 Apr 1998 15:24:23 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.7/8.8.5) with SMTP id PAA28411 for ; Tue, 21 Apr 1998 15:24:11 -0400 (EDT) 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 MAA15379; Tue, 21 Apr 1998 12:23:59 -0700 Received: from ascend.com by ascend.com with ESMTP id MAA29186; Tue, 21 Apr 1998 12:23:55 -0700 Received: from ascend.com by ascend.com id MAA19820; Tue, 21 Apr 1998 12:20:13 -0700 Message-Id: <3.0.5.32.19980421122332.0095c590@darla.ascend.com> X-Sender: mhold@darla.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 21 Apr 1998 12:23:32 -0700 To: James Carlson From: Matt Holdrege Subject: Re: MARS proxy for PPP/ATM Cc: chsharp@cisco.com, ietf-ppp@merit.edu In-Reply-To: <199804211831.OAA06415@ironbridgenetworks.com> References: <353CD12D.9352496@cisco.com> <915C65C50371D11187AD0000F881B9A44C8C66@bcarua62.ca.nortel.com> <353CD12D.9352496@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu At 02:31 PM 4/21/98 -0400, James Carlson wrote: >> Could you please point out the extensions to PPP that you propose? >> >> Despite the use of the acronym PPP in the document, I did not see any >> proposed PPP extensions. I don't think pppext is the appropriate place >> for this. It belongs in ion. I read the minutes and I understand that >> ion is not taking any more work, but that needs to be resolved with ion, >> not in pppext. > >My thoughts on reading the draft as well. > >> If the rest of the pppext WG disagrees and wants to start working on >> things outside of PPP, then I'll provide technical comments/questions. > >I agree that the sections which seem to specify interaction with L2TP >also don't actually specify anything that appears to be different from >what we've got today. > >I think this belongs in a new "ion2" or (even) issll. Even the AD is >probably a better place than pppext ... The AD's from the Routing and Internet areas moved this from ION to PPP. But if you think it shouldn't be in PPP, you should let the AD's from those areas know. Of course if you have any comments on the draft, please let the author know. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Apr 21 15:26:45 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA28538; Tue, 21 Apr 1998 15:26:44 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 21 Apr 1998 15:26:30 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA28511 for ietf-ppp-outgoing; Tue, 21 Apr 1998 15:26:29 -0400 (EDT) Received: from pinky.microsoft.com (pinky.microsoft.com [131.107.1.229]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA28507 for ; Tue, 21 Apr 1998 15:26:24 -0400 (EDT) Received: from glennz-2.ntdev.microsoft.com (tide15.microsoft.com [131.107.3.25]) by pinky.microsoft.com (8.7.6/8.7.3) with SMTP id MAA21917 for ; Tue, 21 Apr 1998 12:15:16 -0700 (PDT) Message-ID: <003001bd6d5a$c00b6b60$50f51fac@glennz-2.ntdev.microsoft.com> Reply-To: "Glen Zorn" From: "Glen Zorn" To: "'IETF-PPP'" Subject: Contradiction in RFC2284 Date: Tue, 21 Apr 1998 12:16:07 -0700 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_0028_01BD6D1F.43DB4820" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-ppp@merit.edu This is a multi-part message in MIME format. ------=_NextPart_000_0028_01BD6D1F.43DB4820 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0025_01BD6D1F.43CA7F40" ------=_NextPart_000_0025_01BD6D1F.43CA7F40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RFC 2284 appears to be self contradicting WRT the contents of the Type-Data field of the Nak Type: section 2.2.1 on page 6 says Normally, the Type field of the Response will be the same as the Type of the Request. However, there is also a Nak Response Type for indicating that a Request type is unacceptable to the peer. When sending a Nak in response to a Request, the peer MAY indicate an alternative desired authentication Type which it supports. but section 3.3 on page 10 says 3.3. Nak Description The Nak Type is valid only in Response messages. It is sent in reply to a Request where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. The Response contains the authentication Type desired by the peer. Type 3 Type-Data This field MUST contain a single octet indicating the desired authentication type. Which is it? ------=_NextPart_000_0025_01BD6D1F.43CA7F40 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn EMAIL;PREF;INTERNET:glennz@microsoft.com REV:19980421T191606Z END:VCARD ------=_NextPart_000_0025_01BD6D1F.43CA7F40-- ------=_NextPart_000_0028_01BD6D1F.43DB4820 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIISjCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggJ6MIIB46ADAgECAhEAlbB2hEzFCiJmppNpv4KenTANBgkqhkiG9w0BAQIFADBfMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGlj IFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwNjI3MDAwMDAwWhcNOTkwNjI3 MjM1OTU5WjBiMREwDwYDVQQHEwhJbnRlcm5ldDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNDAy BgNVBAsTK1ZlcmlTaWduIENsYXNzIDIgQ0EgLSBJbmRpdmlkdWFsIFN1YnNjcmliZXIwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBALoD7ZzMoZFxgx+byB2eT7R1731MMPOyqjS/mdtGxtSYxx1F DuewxtFZ7RIBv/1CgtNn9wnSI4Gp2uTPtSmqopqtWhNJ2VIxUz3a1andsmdxkdAPW3jF3qVBV0jX 9PpH7knRPW6Q52wj0mZ/4XbxLqDdHcvVIXCIcp5kpm/P7v3fAgMBAAGjMzAxMA8GA1UdEwQIMAYB Af8CAQEwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCq dS6/6yt/yp7Tb22NPA8Jzls4mN1PgCE5WFv9dzFOBhIXX9mSoZG7IKLTiDyntlJpFyzubCyfTshb vUTBwIr2jy3SVfxhgU1yR8INx248s7HZAbJgNW03oRXfwmCPhdqcZfzrvskLRXbd0OI0FGnWTHa5 h0RwYZlryPw/GhiueDCCA4cwggLwoAMCAQICECVd0MOUk4j1Aym6iMqHPOswDQYJKoZIhvcNAQEC BQAwYjERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTQwMgYDVQQL EytWZXJpU2lnbiBDbGFzcyAyIENBIC0gSW5kaXZpZHVhbCBTdWJzY3JpYmVyMB4XDTk4MDQxNzAw MDAwMFoXDTk5MDQxNzIzNTk1OVowggEPMREwDwYDVQQHEwhJbnRlcm5ldDEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xNDAyBgNVBAsTK1ZlcmlTaWduIENsYXNzIDIgQ0EgLSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9DUFMgSW5jb3Jw LiBieSBSZWYuLExJQUIuTFREKGMpOTYxJzAlBgNVBAsTHkRpZ2l0YWwgSUQgQ2xhc3MgMiAtIE1p Y3Jvc29mdDESMBAGA1UEAxMJR2xlbiBab3JuMSYwJAYJKoZIhvcNAQkBFhdnd3pAcGlua3kubWlj cm9zb2Z0LmNvbTBbMA0GCSqGSIb3DQEBAQUAA0oAMEcCQHfi2aDbvZmGGO1B7tkYy/lxUUnXsvBK Tp4Eydzywfl61iJe5O8KMAxEKLCkfB5EG7bs7aiOBEQHY1RSB26b+rkCAwEAAaOB0zCB0DAJBgNV HRMEAjAAMIGvBgNVHSAEgacwgDCABgtghkgBhvhFAQcBATCAMCgGCCsGAQUFBwIBFhxodHRwczov L3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBW ZXJpU2lnbgAAAAAAADARBglghkgBhvhCAQEEBAMCB4AwDQYJKoZIhvcNAQECBQADgYEAGkDmTDD2 v44Mxb9QDAjJx7K2MS7vxdbiyB8d2XAHHlgrJaEImkhtaKwjou7ZVjhzezJ2irZ7p9hCu5UlPlzR SlFieSNAszj76gruHyCAZnwIbON5fdGxYRC2kJQDeQ078bAbbt2VdNOtufhQ7Ul45HFS6ycvVShk 14qVeiIi/Zk= ------=_NextPart_000_0028_01BD6D1F.43DB4820-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Apr 21 15:37:01 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA28857; Tue, 21 Apr 1998 15:36:56 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 21 Apr 1998 15:36:34 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA28828 for ietf-ppp-outgoing; Tue, 21 Apr 1998 15:36:33 -0400 (EDT) Received: from pinky.microsoft.com (pinky.microsoft.com [131.107.1.229]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA28822; Tue, 21 Apr 1998 15:36:28 -0400 (EDT) Received: from glennz-2.ntdev.microsoft.com (tide27.microsoft.com [131.107.3.37]) by pinky.microsoft.com (8.7.6/8.7.3) with SMTP id MAA21936; Tue, 21 Apr 1998 12:25:18 -0700 (PDT) Message-ID: <004a01bd6d5c$274fc540$50f51fac@glennz-2.ntdev.microsoft.com> Reply-To: "Glen Zorn" From: "Glen Zorn" To: , Cc: "'IETF-PPP'" Subject: Contradiction in RFC 2284 Date: Tue, 21 Apr 1998 12:23:10 -0700 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_0037_01BD6D20.3F72A160" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-ppp@merit.edu This is a multi-part message in MIME format. ------=_NextPart_000_0037_01BD6D20.3F72A160 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0034_01BD6D20.3F6979A0" ------=_NextPart_000_0034_01BD6D20.3F6979A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RFC 2284 appears to be self contradicting WRT to the contents of the Type-Data field of the Nak authentication type: section 2.2.1 on page 7 says Type The Type field is one octet. This field indicates the Type of Request or Response. Only one Type MUST be specified per EAP Request or Response. Normally, the Type field of the Response will be the same as the Type of the Request. However, there is also a Nak Response Type for indicating that a Request type is unacceptable to the peer. When sending a Nak in response to a ------------------------ --------------------------- Request, the peer MAY indicate an alternative desired ---------------------------------------------------------------------- ---- authentication Type which it supports. --------------------------------------------------- An initial specification of Types follows in a later section of this document. Type-Data The Type-Data field varies with the Type of Request and the associated Response. but section 3.3 on page 10 says 3.3. Nak Description The Nak Type is valid only in Response messages. It is sent in reply to a Request where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. The Response contains the authentication Type desired by the peer. Type 3 Type-Data This field MUST contain a single octet indicating the desired --------------------------------------------------------------------- ------------- authentication type. -------------------------- Which is it, MAY or MUST? ------=_NextPart_000_0034_01BD6D20.3F6979A0 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn EMAIL;PREF;INTERNET:glennz@microsoft.com REV:19980421T192310Z END:VCARD ------=_NextPart_000_0034_01BD6D20.3F6979A0-- ------=_NextPart_000_0037_01BD6D20.3F72A160 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIISjCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggJ6MIIB46ADAgECAhEAlbB2hEzFCiJmppNpv4KenTANBgkqhkiG9w0BAQIFADBfMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGlj IFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwNjI3MDAwMDAwWhcNOTkwNjI3 MjM1OTU5WjBiMREwDwYDVQQHEwhJbnRlcm5ldDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNDAy BgNVBAsTK1ZlcmlTaWduIENsYXNzIDIgQ0EgLSBJbmRpdmlkdWFsIFN1YnNjcmliZXIwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBALoD7ZzMoZFxgx+byB2eT7R1731MMPOyqjS/mdtGxtSYxx1F DuewxtFZ7RIBv/1CgtNn9wnSI4Gp2uTPtSmqopqtWhNJ2VIxUz3a1andsmdxkdAPW3jF3qVBV0jX 9PpH7knRPW6Q52wj0mZ/4XbxLqDdHcvVIXCIcp5kpm/P7v3fAgMBAAGjMzAxMA8GA1UdEwQIMAYB Af8CAQEwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCq dS6/6yt/yp7Tb22NPA8Jzls4mN1PgCE5WFv9dzFOBhIXX9mSoZG7IKLTiDyntlJpFyzubCyfTshb vUTBwIr2jy3SVfxhgU1yR8INx248s7HZAbJgNW03oRXfwmCPhdqcZfzrvskLRXbd0OI0FGnWTHa5 h0RwYZlryPw/GhiueDCCA4cwggLwoAMCAQICECVd0MOUk4j1Aym6iMqHPOswDQYJKoZIhvcNAQEC BQAwYjERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTQwMgYDVQQL EytWZXJpU2lnbiBDbGFzcyAyIENBIC0gSW5kaXZpZHVhbCBTdWJzY3JpYmVyMB4XDTk4MDQxNzAw MDAwMFoXDTk5MDQxNzIzNTk1OVowggEPMREwDwYDVQQHEwhJbnRlcm5ldDEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xNDAyBgNVBAsTK1ZlcmlTaWduIENsYXNzIDIgQ0EgLSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9DUFMgSW5jb3Jw LiBieSBSZWYuLExJQUIuTFREKGMpOTYxJzAlBgNVBAsTHkRpZ2l0YWwgSUQgQ2xhc3MgMiAtIE1p Y3Jvc29mdDESMBAGA1UEAxMJR2xlbiBab3JuMSYwJAYJKoZIhvcNAQkBFhdnd3pAcGlua3kubWlj cm9zb2Z0LmNvbTBbMA0GCSqGSIb3DQEBAQUAA0oAMEcCQHfi2aDbvZmGGO1B7tkYy/lxUUnXsvBK Tp4Eydzywfl61iJe5O8KMAxEKLCkfB5EG7bs7aiOBEQHY1RSB26b+rkCAwEAAaOB0zCB0DAJBgNV HRMEAjAAMIGvBgNVHSAEgacwgDCABgtghkgBhvhFAQcBATCAMCgGCCsGAQUFBwIBFhxodHRwczov L3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBW ZXJpU2lnbgAAAAAAADARBglghkgBhvhCAQEEBAMCB4AwDQYJKoZIhvcNAQECBQADgYEAGkDmTDD2 v44Mxb9QDAjJx7K2MS7vxdbiyB8d2XAHHlgrJaEImkhtaKwjou7ZVjhzezJ2irZ7p9hCu5UlPlzR SlFieSNAszj76gruHyCAZnwIbON5fdGxYRC2kJQDeQ078bAbbt2VdNOtufhQ7Ul45HFS6ycvVShk 14qVeiIi/ZkxggGJMIIBhQIBATB2MGIxETAPBgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3MgMiBDQSAtIEluZGl2aWR1YWwgU3Vi c2NyaWJlcgIQJV3Qw5STiPUDKbqIyoc86zAJBgUrDgMCGgUAoIGrMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk4MDQyMTEyMjMxMFowIwYJKoZIhvcNAQkEMRYEFCpp lYZGKn0gk44tfOxGkqP+GfiHMEwGCSqGSIb3DQEJDzE/MD0wCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIdMA0GCSqGSIb3DQEBAQUABEBu 8z27T6dByCmzsibk99l0gZ39/MN5lj6/+yi/vIdRl1hzoJjI0hkP1W0tD8yV8sWlZ6JTmdkpgNXV R54IxB9qAAAAAAAA ------=_NextPart_000_0037_01BD6D20.3F72A160-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Apr 21 16:48:51 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA00712; Tue, 21 Apr 1998 16:48:40 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 21 Apr 1998 16:47:53 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA00663 for ietf-ppp-outgoing; Tue, 21 Apr 1998 16:47:52 -0400 (EDT) Received: from dogwood-fddi.cisco.com (dogwood-fddi.cisco.com [171.68.122.80]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA00659 for ; Tue, 21 Apr 1998 16:47:46 -0400 (EDT) Received: from chsharp-pc (chsharp-isdn.cisco.com [171.68.116.221]) by dogwood-fddi.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id QAA22907; Tue, 21 Apr 1998 16:46:02 -0400 (EDT) Message-Id: <3.0.3.32.19980421164035.03250f08@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 21 Apr 1998 16:40:35 -0400 To: Matt Holdrege From: Chip Sharp Subject: Re: MARS proxy for PPP/ATM Cc: rcoltun@fore.com, burgan@corp.home.net, narten@raleigh.ibm.com, James Carlson , ietf-ppp@merit.edu In-Reply-To: <3.0.5.32.19980421122332.0095c590@darla.ascend.com> References: <199804211831.OAA06415@ironbridgenetworks.com> <353CD12D.9352496@cisco.com> <915C65C50371D11187AD0000F881B9A44C8C66@bcarua62.ca.nortel.com> <353CD12D.9352496@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu At 12:23 PM 4/21/98 -0700, Matt Holdrege wrote: >At 02:31 PM 4/21/98 -0400, James Carlson wrote: >>> Could you please point out the extensions to PPP that you propose? >>> >>> Despite the use of the acronym PPP in the document, I did not see any >>> proposed PPP extensions. I don't think pppext is the appropriate place >>> for this. It belongs in ion. I read the minutes and I understand that >>> ion is not taking any more work, but that needs to be resolved with ion, >>> not in pppext. >> >>My thoughts on reading the draft as well. >> >>> If the rest of the pppext WG disagrees and wants to start working on >>> things outside of PPP, then I'll provide technical comments/questions. >> >>I agree that the sections which seem to specify interaction with L2TP >>also don't actually specify anything that appears to be different from >>what we've got today. >> >>I think this belongs in a new "ion2" or (even) issll. Even the AD is >>probably a better place than pppext ... > >The AD's from the Routing and Internet areas moved this from ION to PPP. >But if you think it shouldn't be in PPP, you should let the AD's from those >areas know. I didn't see in the minutes that the AD's had decreed that this should be done in pppext. I don't agree, but the wg never needed my approval to do anything. ;-) >Of course if you have any comments on the draft, please let the author know. My basic comment was to ask what changes are needed in PPP. I didn't see any. For the time being comments will be addressed to pppext. Chip -------------------------------------------------- Chip Sharp voice: +1 (919) 851-2085 Cisco Systems Mgr - Telco Consulting -------------------------------------------------- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Apr 21 23:25:03 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id XAA05272; Tue, 21 Apr 1998 23:24:53 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 21 Apr 1998 23:23:42 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id XAA05238 for ietf-ppp-outgoing; Tue, 21 Apr 1998 23:23:41 -0400 (EDT) Received: from cdnet51 (cdnet51.uestc.edu.cn [202.112.14.151]) by merit.edu (8.8.7/8.8.5) with SMTP id XAA05228 for ; Tue, 21 Apr 1998 23:23:30 -0400 (EDT) Received: from 163.net ([202.115.4.67]) by cdnet51 (5.x/SMI-SVR4) id AA01337; Wed, 22 Apr 1998 12:18:37 +0900 Message-Id: <353D63E5.CBD2CFBC@163.net> Date: Wed, 22 Apr 1998 11:28:37 +0800 From: lhy Organization: uestc X-Mailer: Mozilla 4.04 [en] (Win95; I) Mime-Version: 1.0 To: ietf-ppp@merit.edu Subject: send Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu send - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Apr 22 10:09:16 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA11926; Wed, 22 Apr 1998 10:07:06 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 22 Apr 1998 09:58:39 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA11768 for ietf-ppp-outgoing; Wed, 22 Apr 1998 09:58:39 -0400 (EDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA11763 for ; Wed, 22 Apr 1998 09:58:34 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id JAA27519; Wed, 22 Apr 1998 09:58:00 -0400 (EDT) Message-Id: <199804221358.JAA27519@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-eaptls-03.txt Date: Wed, 22 Apr 1998 09:58:00 -0400 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 : PPP EAP TLS Authentication Protocol Author(s) : B. Aboba, D. Simon Filename : draft-ietf-pppext-eaptls-03.txt Pages : 22 Date : 21-Apr-98 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which can be used to negotiate authentication methods, as well as an Encryption Control Protocol (ECP), used to negotiate data encryption over PPP links, and a Compression Control Protocol (CCP), used to negotiate compression methods. The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. Transport Level Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation and key exchange between two endpoints. This document describes how EAP-TLS, which includes support for fragmentation and reassembly, provides for these TLS mech- anisms within EAP. 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-eaptls-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-eaptls-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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-eaptls-03.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980421160200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-eaptls-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-eaptls-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980421160200.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Apr 24 17:25:53 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA04887; Fri, 24 Apr 1998 17:24:48 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 24 Apr 1998 17:17:06 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA04714 for ietf-ppp-outgoing; Fri, 24 Apr 1998 17:17:05 -0400 (EDT) Received: from shultz.argon.com (shultz.argon.com [208.234.161.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA04709 for ; Fri, 24 Apr 1998 17:17:00 -0400 (EDT) Received: from baker (baker.argon.com [208.234.161.56]) by shultz.argon.com (8.8.6/8.8.6) with SMTP id RAA06071; Fri, 24 Apr 1998 17:15:55 -0400 (EDT) Message-Id: <3.0.5.32.19980424171550.0093a100@shultz.argon.com> X-Sender: esc@shultz.argon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 24 Apr 1998 17:15:50 -0400 To: issll@mercury.lcs.mit.edu From: "Eric S. Crawley" Subject: WG last call on draft-ietf-issll-isslow-rtf-02.txt Cc: ietf-ppp@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Folks, The last call on draft-ietf-issll-isslow-rtf-02.txt has come to a close. Please get any comments to the author ASAP (I have a few myself). Eric & John >Date: Fri, 10 Apr 1998 16:55:14 -0400 >To: issll@mercury.lcs.mit.edu >From: "Eric S. Crawley" >Subject: WG last call on draft-ietf-issll-isslow-rtf-02.txt >Cc: ietf-ppp@merit.edu > >Folks, > >We are starting the WG last call on draft-ietf-issll-isslow-rtf-02.txt. The last call will end at 5PM EDT on Friday, April 24th. Please get any comments you have to the author or the mailing list by then. > >Thanks! > > Eric & John > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Apr 27 20:10:54 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA00586; Mon, 27 Apr 1998 20:10:33 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 27 Apr 1998 20:06:44 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA00476 for ietf-ppp-outgoing; Mon, 27 Apr 1998 20:06:44 -0400 (EDT) Received: from calcite.rhyolite.com (vjs@calcite.rhyolite.com [38.159.140.3]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA00468 for ; Mon, 27 Apr 1998 20:06:38 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id SAA14433 mail_from ; Mon, 27 Apr 1998 18:06:30 -0600 (MDT) Date: Mon, 27 Apr 1998 18:06:30 -0600 (MDT) From: Vernon Schryver Message-Id: <199804280006.SAA14433@calcite.rhyolite.com> To: ietf-ppp@merit.edu, ietf@ietf.org Subject: Elaine Hyder spam Sender: owner-ietf-ppp@merit.edu Elaine Hyder spam continues to send me unsolicited bulk mail about her "survey" concerning "conflict resolution" in the PPP working group. Does anyone know how to stop that particular spew of spam? I've complained, but it continues. Yes, it's spam, because it is unsolicted and bulk. I did not complain on the first message, since it could have been the result of ignorance and arrogance. I'm getting rather tired of receiving repeated "reminders" about my refusal to participate in her supposed survey, even after my complaint. I'm sending this to the working group mailing list and the main IETF list so that other people know that she is not on the up-and-up and take whatever action or inaction (e.g. not respond) they feel appropriate. If she were not an ordinary spammer, then she would not have sent the initial unsolicited bulk email. She also would not continue sending her reminders. At the very least, there the IETF needs to tighten its rules on releasing working group email addresses lists. Never mind that the professional and would-be professional "facilitators" selling their "group cooperation" snake-oil do more harm to group cooperatation in general and cooperation in IETF WG's and the development of Internet standards than any other single group, with the possible except of the politicians, wannabe politicians, and get-rich-real-quick-by- selling-domains-and-TLDs crowds. Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Apr 29 08:41:02 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA10408; Wed, 29 Apr 1998 08:39:44 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 29 Apr 1998 08:32:22 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA10201 for ietf-ppp-outgoing; Wed, 29 Apr 1998 08:32:21 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA10197 for ; Wed, 29 Apr 1998 08:32:13 -0400 (EDT) Received: from moody.mchh.siemens.de (moody-i.mchh.siemens.de [194.138.158.26]) by gorilla.mchh.siemens.de (8.8.7/8.8.7) with ESMTP id OAA12814 for ; Wed, 29 Apr 1998 14:33:01 +0200 (MET DST) Received: from mchh201e.demchh201e.oen.siemens.de (demchh201e.oen.siemens.de [218.1.68.104]) by moody.mchh.siemens.de (8.8.7/8.8.7) with ESMTP id OAA19931 for ; Wed, 29 Apr 1998 14:34:35 +0200 (MET DST) Received: by mchh201e.demchh201e.oen.siemens.de with Internet Mail Service (5.5.1960.3) id ; Wed, 29 Apr 1998 14:31:51 +0200 Message-ID: <99D9C8D1B4D5D01189F2006097540D815A7C8E@mchh205e.demchh201e.oen.siemens.de> From: Theimer Thomas To: "'PPPEXT Mailing List'" Subject: LCP Reconfiguration Date: Wed, 29 Apr 1998 14:31:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Hi, I have a question concerning the PPP state machine that is related to LCP reconfiguration. The question is the following: What happens when the link is in the open state, and an LCP Configure-Request is received. RFC1661 says the following: The receipt of the LCP Configure-Request causes a return to the Link Establishment phase from the Network-Layer Protocol phase or Authentication phase. Does that mean all network layer connections are terminated completely, LCP options are renegotiated, and authentication is restarted ? That implies also that the user has to logon again, and all network layer protocols have to be restarted. The effect of this is similar to terminating and restarting the link. I just want to make sure that this interpretation is correct, and that existing implementations actually behave accordingly. Thanks for any comments, Thomas Theimer -------------------------------------------------------------------- Siemens AG Voice: +49 89 722-27680 OEN BN SE 2 Fax: +49 89 722-38175 Hofmannstr. 51 81359 Muenchen Internet: Thomas.Theimer@oen.siemens.de Germany -------------------------------------------------------------------- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Apr 29 09:15:27 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA10901; Wed, 29 Apr 1998 09:15:11 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 29 Apr 1998 09:13:30 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA10868 for ietf-ppp-outgoing; Wed, 29 Apr 1998 09:13:29 -0400 (EDT) Received: from ironbridgenetworks.com ([146.115.140.2]) by merit.edu (8.8.7/8.8.5) with SMTP id JAA10861 for ; Wed, 29 Apr 1998 09:13:21 -0400 (EDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id JAA11362; Wed, 29 Apr 1998 09:09:58 -0400 Date: Wed, 29 Apr 1998 09:09:58 -0400 Message-Id: <199804291309.JAA11362@ironbridgenetworks.com> From: James Carlson To: Thomas.Theimer@oen.siemens.de CC: ietf-ppp@merit.edu In-reply-to: <99D9C8D1B4D5D01189F2006097540D815A7C8E@mchh205e.demchh201e.oen.siemens.de> (message from Theimer Thomas on Wed, 29 Apr 1998 14:31:54 +0200) Subject: Re: LCP Reconfiguration References: <99D9C8D1B4D5D01189F2006097540D815A7C8E@mchh205e.demchh201e.oen.siemens.de> Sender: owner-ietf-ppp@merit.edu > Does that mean all network layer connections are terminated completely, > LCP options are renegotiated, and authentication is restarted ? That > implies also that the user has to logon again, and all network layer > protocols have to be restarted. The effect of this is similar to > terminating and restarting the link. If a user was involved in logging in, then, yes, he must do that again. The link starts over. (Of course, it's legal and reasonable for the implementation to remember what was negotiated last time so that it can avoid any Configure-Naks or Configure-Rejects, so it's not always exactly the same as terminating and restarting the link.) The control protocols for the network layer interfaces (such as IPCP) do have to start over after authentication (if any), but this does not mean that the network layer itself (such as IP) is restarted. > I just want to make sure that this interpretation is correct, and that > existing implementations actually behave accordingly. Note that it terminates the network layer connection. This does *NOT* imply that it should terminate any transport or application layer sessions. Some *very* common implementations of PPP, however, do improperly kill off everything anyway. For what it's worth, I've seen many implementations of PPP which fall over and die if LCP Configure-Request is seen after LCP goes to Open state. It's hard to mandate that all implementations work right ... -- 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 Wed Apr 29 09:59:10 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA12410; Wed, 29 Apr 1998 09:58:40 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 29 Apr 1998 09:56:42 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA12096 for ietf-ppp-outgoing; Wed, 29 Apr 1998 09:56:41 -0400 (EDT) Received: from calcite.rhyolite.com (vjs@calcite.rhyolite.com [38.159.140.3]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA12043 for ; Wed, 29 Apr 1998 09:56:27 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id HAA05693 mail_from ; Wed, 29 Apr 1998 07:56:24 -0600 (MDT) Date: Wed, 29 Apr 1998 07:56:24 -0600 (MDT) From: Vernon Schryver Message-Id: <199804291356.HAA05693@calcite.rhyolite.com> To: ietf-ppp@merit.edu, Thomas.Theimer@oen.siemens.de Subject: Re: LCP Reconfiguration Sender: owner-ietf-ppp@merit.edu > From: James Carlson > > Does that mean all network layer connections are terminated completely, > > LCP options are renegotiated, and authentication is restarted ? That > > implies also that the user has to logon again, and all network layer > > protocols have to be restarted. The effect of this is similar to > > terminating and restarting the link. > > If a user was involved in logging in, then, yes, he must do that > again. The link starts over. (Of course, it's legal and reasonable > for the implementation to remember what was negotiated last time so > that it can avoid any Configure-Naks or Configure-Rejects, so it's not > always exactly the same as terminating and restarting the link.) > The control protocols for the network layer interfaces (such as IPCP) > do have to start over after authentication (if any), but this does not > mean that the network layer itself (such as IP) is restarted. > ... > Note that it terminates the network layer connection. This does *NOT* > imply that it should terminate any transport or application layer > sessions. ... You obviously do not mean what many less technically knowledgable people will misunderstand by your first sentence. "Users" tend to "log in" using telnet or rlogin. While the robotic, non-human "user" that is responsible for the PPP link will have to authenticate itself (i.e. "log on") again, the human user should not need to, given properly functioning PPP peers. Yes, that means (as we have often agreed in the mailing list) that smart cards which involve humans to transmit the secret of the instant to the PPP peer for PPP authentication are at best inconvenient. Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Apr 29 10:46:03 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA17562; Wed, 29 Apr 1998 10:45:52 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 29 Apr 1998 10:44:10 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA17367 for ietf-ppp-outgoing; Wed, 29 Apr 1998 10:44:10 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA17352 for ; Wed, 29 Apr 1998 10:44:03 -0400 (EDT) Received: from moody.mchh.siemens.de (moody-i.mchh.siemens.de [194.138.158.26]) by gorilla.mchh.siemens.de (8.8.7/8.8.7) with ESMTP id QAA29616; Wed, 29 Apr 1998 16:45:07 +0200 (MET DST) Received: from mchh202e.demchh201e.oen.siemens.de (demchh201e.oen.siemens.de [218.1.68.105]) by moody.mchh.siemens.de (8.8.7/8.8.7) with ESMTP id QAA24070; Wed, 29 Apr 1998 16:46:39 +0200 (MET DST) Received: by mchh202e.demchh201e.oen.siemens.de with Internet Mail Service (5.5.1960.3) id ; Wed, 29 Apr 1998 16:44:00 +0200 Message-ID: <99D9C8D1B4D5D01189F2006097540D815A7C90@mchh205e.demchh201e.oen.siemens.de> From: Theimer Thomas To: "'John Shriver'" Cc: "'PPPEXT Mailing List'" Subject: RE: LCP Reconfiguration Date: Wed, 29 Apr 1998 16:43:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu John, thanks for your comments. I agree that the client software can store the secret and simply re-authenticate. However, there are cases where NCP (and LCP) state may be lost on one side of the link without the other side knowing. I am refering to a situation where the PPP link is actually an ATM PVC, e.g. running over an ADSL line. Now suppose that the NAS reboots for some reason and looses all active sessions. The NAS will try to open all PPP links again, but the clients may not know that the NAS went down, because the ATM PVC does not provide any indication of that event. The safest thing to do is probably to explicitly terminate all PPP links (send a terminate request) before sending any LCP configure requests. This would bring all clients into a well-defined state, even if they are still in the open state. I was just trying to avoid that by sticking to the normal startup sequence for opening a PPP link, and see if that solves the problem. If NCP tries to maintain state, this would raise the same question for NCP: what happens if a NCP in the open state gets a configure-request message ? Will it also return to the establish-phase, and restart NCP negotiation ? I have not seen a clear definition of state transitions for IPCP, so I can only guess what might happen in this case. Thomas Theimer > -----Original Message----- > From: John Shriver [SMTP:jas@shiva.com] > Sent: Wednesday, April 29, 1998 3:32 PM > To: Theimer Thomas > Subject: Re: LCP Reconfiguration > > That's exactly the right interpretation. > > But the USER doesn't have to re-authenticate. The software does. It > can store the "secret" for the length of the session. > > Similarly, the NCP's don't have to throw away all their state. It > would be stupid for IPCP to negotiate new IP addresses. They should > hang on to all the resources until the link goes down. > > You probably want to try and get a copy of Carlson's book on PPP. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Apr 29 10:55:04 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA18268; Wed, 29 Apr 1998 10:55:02 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 29 Apr 1998 10:54:49 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA18234 for ietf-ppp-outgoing; Wed, 29 Apr 1998 10:54:49 -0400 (EDT) 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 KAA18227 for ; Wed, 29 Apr 1998 10:54:44 -0400 (EDT) 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 KAA31302 for ; Wed, 29 Apr 1998 10:52:17 -0400 (EDT) Received: by zule.shiva.com(Lotus SMTP MTA SMTP MTA v1.1.04 (495.1 10-24-1997)) id 852565F5.005201C3 ; Wed, 29 Apr 1998 10:55:44 -0400 X-Lotus-FromDomain: SHIVA CORPORATION From: "Scott Reeve" To: ietf-ppp@merit.edu Message-ID: <852565F5.0050C315.00@zule.shiva.com> Date: Wed, 29 Apr 1998 10:50:40 -0400 Subject: Re: LCP Reconfiguration Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ppp@merit.edu carlson@ironbridgenetworks.com on 04/29/98 09:09:58 AM To: Thomas.Theimer@oen.siemens.de cc: ietf-ppp@merit.edu (bcc: Scott Reeve/Shiva Corporation) Subject: Re: LCP Reconfiguration >> Does that mean all network layer connections are terminated completely, >> LCP options are renegotiated, and authentication is restarted ? That >> implies also that the user has to logon again, and all network layer >> protocols have to be restarted. The effect of this is similar to >> terminating and restarting the link. >If a user was involved in logging in, then, yes, he must do that >again. The link starts over. (Of course, it's legal and reasonable >for the implementation to remember what was negotiated last time so >that it can avoid any Configure-Naks or Configure-Rejects, so it's not >always exactly the same as terminating and restarting the link.) Neat idea - I wonder if any implementation does this. Most do a cold warm-start, not a warm warm-start :-) >The control protocols for the network layer interfaces (such as IPCP) >do have to start over after authentication (if any), but this does not >mean that the network layer itself (such as IP) is restarted. If IPCP must be re-negotiated, wouldn't it be more accurate to say that IP is restarted? The route must not be active again until IPCP has come all the way back up. Not sure if that argument carries over to other NCPs also, but it probably does. >> I just want to make sure that this interpretation is correct, and that >> existing implementations actually behave accordingly. >Note that it terminates the network layer connection. This does *NOT* >imply that it should terminate any transport or application layer >sessions. Some *very* common implementations of PPP, however, do >improperly kill off everything anyway. >For what it's worth, I've seen many implementations of PPP which fall >over and die if LCP Configure-Request is seen after LCP goes to Open >state. It's hard to mandate that all implementations work right ... Trumpet PPP, for one. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Apr 29 11:34:41 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA20074; Wed, 29 Apr 1998 11:34:27 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 29 Apr 1998 11:33:33 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA20039 for ietf-ppp-outgoing; Wed, 29 Apr 1998 11:33:32 -0400 (EDT) Received: from calcite.rhyolite.com (vjs@calcite.rhyolite.com [38.159.140.3]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA20035 for ; Wed, 29 Apr 1998 11:33:25 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id JAA06425 mail_from ; Wed, 29 Apr 1998 09:33:17 -0600 (MDT) Date: Wed, 29 Apr 1998 09:33:17 -0600 (MDT) From: Vernon Schryver Message-Id: <199804291533.JAA06425@calcite.rhyolite.com> To: ietf-ppp@merit.edu, sreeve@shiva.com Subject: Re: LCP Reconfiguration Sender: owner-ietf-ppp@merit.edu > From: "Scott Reeve" > ... > >If a user was involved in logging in, then, yes, he must do that > >again. The link starts over. (Of course, it's legal and reasonable > >for the implementation to remember what was negotiated last time so > >that it can avoid any Configure-Naks or Configure-Rejects, so it's not > >always exactly the same as terminating and restarting the link.) Note for the record that he did not say "avoid any Configure-Requests." > Neat idea - I wonder if any implementation does this. Most do a > cold warm-start, not a warm warm-start :-) What is a "cold warm-start" or a "warm warm-start"? If you mean are there any implementations which remember what they negotiated previously and prefer those values either after dropping the phone line and redialing, or after receiving an unexpected LCP Configure-Request on a line (or VC) that has not hiccuped, then the answer is yes. The necessary machinery is fundamental to all PPP negotiations. Every Configure-Request stands on its own, independent of previous packets. The only default value for very parameter is specified in the relevant RFC. On the other hand, if you do not remember the results of previous Configure-Rejects and -Naks, you'll have problems. Thus, it is both most correct and easiest to give all Configure-Request the same context. Remember the last good values you had, whether from Naks, Rejects, or Acks, and use them for the next Configure-Request, regardless of whether the phone line (or ATM VC) has bounced. > >The control protocols for the network layer interfaces (such as IPCP) > >do have to start over after authentication (if any), but this does not > >mean that the network layer itself (such as IP) is restarted. > > If IPCP must be re-negotiated, wouldn't it be more accurate to say that > IP is restarted? The route must not be active again until IPCP has come > all > the way back up. Not sure if that argument carries over to other NCPs > also, but it probably does. IP has no real state to restart. IP routes are transient and can change with or without IPCP or LCP changing. Also, if you delete your IP route when you receive an unexpected Configure-Request, then won't you stop queuing traffic for the link, and so won't your demand dialing code decide the link is unneeded and drop it? In other words, you need to keep an IP route through a PPP link especially when it is not running. Even if you did make a mistake and kill all IP routes through a PPP link that is (re)negotiating LCP or IPCP, that would not affect TCP/IP applications involving reasonable hosts. An occassional ICMP Unreachable (not to mention a short term blackhole) "SHOULD NOT" affect any TCP state machines in the ESTABLISH state. > >> I just want to make sure that this interpretation is correct, and that > >> existing implementations actually behave accordingly. > ... If your interpretation is what I think it is, then the answer is yes, they do. In my view, any implementation that does not is ... less than admirable. Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Apr 29 14:02:05 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA26906; Wed, 29 Apr 1998 14:01:57 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 29 Apr 1998 14:00:56 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA26864 for ietf-ppp-outgoing; Wed, 29 Apr 1998 14:00:56 -0400 (EDT) Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA26853 for ; Wed, 29 Apr 1998 14:00:50 -0400 (EDT) Received: (rtio@localhost) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id KAA06652; Wed, 29 Apr 1998 10:59:34 -0700 (PDT) From: Rene Tio Message-Id: <199804291759.KAA06652@flipper.cisco.com> Subject: Re: LCP Reconfiguration To: sreeve@shiva.com (Scott Reeve) Date: Wed, 29 Apr 1998 10:59:34 -0700 (PDT) Cc: ietf-ppp@merit.edu In-Reply-To: <852565F5.0050C315.00@zule.shiva.com> from "Scott Reeve" at Apr 29, 98 10:50:40 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 > From owner-ietf-ppp@merit.edu Wed Apr 29 09:28:58 1998 > > > carlson@ironbridgenetworks.com on 04/29/98 09:09:58 AM > > To: Thomas.Theimer@oen.siemens.de > cc: ietf-ppp@merit.edu (bcc: Scott Reeve/Shiva Corporation) > Subject: Re: LCP Reconfiguration > > > >> Does that mean all network layer connections are terminated completely, > >> LCP options are renegotiated, and authentication is restarted ? That > >> implies also that the user has to logon again, and all network layer > >> protocols have to be restarted. The effect of this is similar to > >> terminating and restarting the link. > >If a user was involved in logging in, then, yes, he must do that > >again. The link starts over. (Of course, it's legal and reasonable > >for the implementation to remember what was negotiated last time so > >that it can avoid any Configure-Naks or Configure-Rejects, so it's not > >always exactly the same as terminating and restarting the link.) > > Neat idea - I wonder if any implementation does this. Most do a > cold warm-start, not a warm warm-start :-) IMHO, PPP over ATM PVCs should really conform to a leased-line implementation and should not assume a lower-layer down indication to trigger re-negotiation. There were some old implementations (such as Trumpet, as noted below) which didn't renegotiate properly, but I know of at least one implementation which has since been fixed. As for the user having to log in again, I'd suggest that that is a limitation of the login mechanism and not due to any deficiency in the PPP state machine. > >The control protocols for the network layer interfaces (such as IPCP) > >do have to start over after authentication (if any), but this does not > >mean that the network layer itself (such as IP) is restarted. > > If IPCP must be re-negotiated, wouldn't it be more accurate to say that > IP is restarted? The route must not be active again until IPCP has come > all > the way back up. Not sure if that argument carries over to other NCPs > also, but it probably does. Good way to prevent black holes, or if IP addresses are dynamically assigned, mis-routed packets or address conflicts. Rene > >> I just want to make sure that this interpretation is correct, and that > >> existing implementations actually behave accordingly. > >Note that it terminates the network layer connection. This does *NOT* > >imply that it should terminate any transport or application layer > >sessions. Some *very* common implementations of PPP, however, do > >improperly kill off everything anyway. > >For what it's worth, I've seen many implementations of PPP which fall > >over and die if LCP Configure-Request is seen after LCP goes to Open > >state. It's hard to mandate that all implementations work right ... > > Trumpet PPP, for one. > > > > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Apr 29 14:21:31 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA27360; Wed, 29 Apr 1998 14:21:30 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 29 Apr 1998 14:21:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA27331 for ietf-ppp-outgoing; Wed, 29 Apr 1998 14:21:18 -0400 (EDT) Received: from ironbridgenetworks.com ([146.115.140.2]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA27326 for ; Wed, 29 Apr 1998 14:21:14 -0400 (EDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id OAA23153; Wed, 29 Apr 1998 14:21:12 -0400 Date: Wed, 29 Apr 1998 14:21:12 -0400 Message-Id: <199804291821.OAA23153@ironbridgenetworks.com> From: James Carlson To: sreeve@shiva.com CC: ietf-ppp@merit.edu In-reply-to: <852565F5.0050C315.00@zule.shiva.com> (sreeve@shiva.com) Subject: Re: LCP Reconfiguration References: <852565F5.0050C315.00@zule.shiva.com> Sender: owner-ietf-ppp@merit.edu > >The control protocols for the network layer interfaces (such as IPCP) > >do have to start over after authentication (if any), but this does not > >mean that the network layer itself (such as IP) is restarted. > > If IPCP must be re-negotiated, wouldn't it be more accurate to say that > IP is restarted? No. > The route must not be active again until IPCP has come > all > the way back up. Not true. RFC 1661 covers what happens inside PPP -- IPCP included. It does *not* cover what happens in a given implementation's connection to the network layer -- IP included. If the network layer chooses to continue to advertise the routes and to enqueue any received packets for a short time on the theory that the interface will soon come back, then this is probably a Good Thing. I would say that if you immediately kill off the IP interface and the associated routes, you would not be as wrong as if you had destroyed all of the attached TCP connections. The former is possibly a good implementation choice in some scenarios. The latter is generally bad. -- 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/~carlson/ppp - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Apr 29 14:19:57 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA27292; Wed, 29 Apr 1998 14:19:55 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 29 Apr 1998 14:19:36 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA27270 for ietf-ppp-outgoing; Wed, 29 Apr 1998 14:19:35 -0400 (EDT) Received: from ironbridgenetworks.com ([146.115.140.2]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA27264 for ; Wed, 29 Apr 1998 14:19:29 -0400 (EDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id OAA22914; Wed, 29 Apr 1998 14:16:05 -0400 Date: Wed, 29 Apr 1998 14:16:05 -0400 Message-Id: <199804291816.OAA22914@ironbridgenetworks.com> From: James Carlson To: Thomas.Theimer@oen.siemens.de CC: jas@shiva.com, ietf-ppp@merit.edu In-reply-to: <99D9C8D1B4D5D01189F2006097540D815A7C90@mchh205e.demchh201e.oen.siemens.de> (message from Theimer Thomas on Wed, 29 Apr 1998 16:43:54 +0200) Subject: Re: LCP Reconfiguration References: <99D9C8D1B4D5D01189F2006097540D815A7C90@mchh205e.demchh201e.oen.siemens.de> Sender: owner-ietf-ppp@merit.edu > The safest thing to do is probably to explicitly terminate all PPP links > (send a terminate request) before sending any LCP configure > requests. No. LCP Configure-Request is necessary and sufficient for this case. Sending a Terminate-Request would be wrong, and may well shove the peer into state 5 and cause a long delay in bringing the link back. > This would bring all clients into a well-defined state, even if they are > still in the open state. I was just trying to avoid that by sticking to > the normal startup sequence for opening a PPP link, and see if that > solves the problem. No, LCP Configure-Request itself brings everyone into a well-defined state. > If NCP tries to maintain state, this would raise the same question for > NCP: what happens if a NCP in the open state gets a configure-request > message ? Will it also return to the establish-phase, and restart NCP > negotiation ? Yes. It returns to state 6 or 8, depending on whether or not it likes the Configure-Request. > I have not seen a clear definition of state transitions > for IPCP, so I can only guess what might happen in this case. They're the same as the transitions for LCP in RFC 1661. -- 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/~carlson/ppp - - - - - - - - - - - - - - - - -