From owner-ietf-ppp-outgoing@merit.edu Thu Jun 1 14:13:30 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29025 for ; Thu, 1 Jun 2000 14:13:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 91DD95DDF0; Thu, 1 Jun 2000 14:12:58 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7B9C75DDE8; Thu, 1 Jun 2000 14:12:58 -0400 (EDT) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id 6A2FE5DDF0 for ; Thu, 1 Jun 2000 14:12:56 -0400 (EDT) Received: from karl.extant.net (mojo.extant.net [216.28.121.14]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KD1WQJHV; Thu, 1 Jun 2000 12:12:40 -0600 Message-Id: <4.3.2.6.2.20000601141114.0478a6e0@127.0.0.1> X-Sender: kfox@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2.6 (Beta) Date: Thu, 01 Jun 2000 14:12:37 -0400 To: ietf-ppp@merit.edu From: Karl Fox Subject: Re: PPP Multiplexed Frame Option - Working Group Last Call In-Reply-To: <4.3.2.6.2.20000518114830.04a1f5e0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi folks, This is just a reminder that the deadline for working group comments on this draft is nearly here. Karl At 11:50 AM 5/18/00, Karl Fox wrote: >This is last call. I will advise the area directors that we want to take >PPP Multiplexed Frame Option () to Proposed >Standard on June 2, 2000 unless there is substantive comment raised on this >list. Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Fri Jun 2 08:48:54 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00909 for ; Fri, 2 Jun 2000 08:48:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 643A05DDD1; Fri, 2 Jun 2000 08:48:24 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 48C445DDEC; Fri, 2 Jun 2000 08:48:24 -0400 (EDT) Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3]) by segue.merit.edu (Postfix) with ESMTP id 702E75DDD1 for ; Fri, 2 Jun 2000 08:48:22 -0400 (EDT) Received: from dienstmann.informatik.uni-bremen.de (dienstmann.informatik.uni-bremen.de [134.102.224.51]) by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id e52CmKa20905; Fri, 2 Jun 2000 14:48:20 +0200 (MET DST) Received: (from cabo@localhost) by dienstmann.informatik.uni-bremen.de (8.8.8+Sun/8.8.7) id OAA15936; Fri, 2 Jun 2000 14:48:20 +0200 (MET DST) Date: Fri, 2 Jun 2000 14:48:20 +0200 (MET DST) Message-Id: <200006021248.OAA15936@dienstmann.informatik.uni-bremen.de> From: Carsten Bormann To: Karl Fox Cc: ietf-ppp@merit.edu Subject: Re: PPP Multiplexed Frame Option - Working Group Last Call In-Reply-To: <4.3.2.6.2.20000601141114.0478a6e0@127.0.0.1> References: <4.3.2.6.2.20000518114830.04a1f5e0@127.0.0.1> <4.3.2.6.2.20000601141114.0478a6e0@127.0.0.1> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I'm sorry this is coming so late, but my brain has been washed this week by the interim meeting of the ROHC working group (where saving a byte gives you some unknown multiple of $1000000000). It occurs to me that in many applications, one byte per frame can be almost always saved by allowing PFF=0 for the first subframe in the frame. The default protocol ID (i.e., initial value of Last_PID used for each frame) could be defined in the negotiation. So, preferably, I'd propose to change the option to: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 30 | Length = 4 | Defgult PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If this is not acceptable due to existing implementations, this could be left as an option (but options are not good), with the 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 30 | Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ format remaining. To simplify code, I'd still propose to have a default default PID in this case, e.g. 0021, barring existing implementations. I'll provide a proposal for (small) text changes if the WG thinks this is useful. Gruesse, Carsten From owner-ietf-ppp-outgoing@merit.edu Fri Jun 2 10:38:24 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03308 for ; Fri, 2 Jun 2000 10:38:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 47F765DE0E; Fri, 2 Jun 2000 10:37:59 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 36BBF5DDD3; Fri, 2 Jun 2000 10:37:59 -0400 (EDT) Received: from fsnt.future.futusoft.com (unknown [203.197.140.35]) by segue.merit.edu (Postfix) with ESMTP id EE3C15DDB1 for ; Fri, 2 Jun 2000 10:37:55 -0400 (EDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 02 Jun 2000 20:19:05 +0530 Received: from mania (mania.future.futsoft.com [10.0.14.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id UAA17131 for ; Fri, 2 Jun 2000 20:09:26 +0530 Received: by localhost with Microsoft MAPI; Fri, 2 Jun 2000 19:58:54 +0530 Message-Id: <01BFCCCC.FAD32700.mania@future.futsoft.com> From: Manikandan A Reply-To: "mania@future.futsoft.com" To: "ietf-ppp@merit.edu" Subject: IDLE Timer Date: Fri, 2 Jun 2000 19:58:53 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi All, What is the recommended IDLE timer value for the link ?. I could n't find anything in RFC 1661. TIA Regards, Mani. From owner-ietf-ppp-outgoing@merit.edu Fri Jun 2 10:48:11 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03466 for ; Fri, 2 Jun 2000 10:48:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 115A15DE27; Fri, 2 Jun 2000 10:46:13 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id ED6935DE26; Fri, 2 Jun 2000 10:46:12 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 149305DE1A for ; Fri, 2 Jun 2000 10:46:11 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14923; Fri, 2 Jun 2000 07:46:03 -0700 (PDT) Received: from dhcp-174-233.east.sun.com (dhcp-174-233.East.Sun.COM [129.148.174.233]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA21732; Fri, 2 Jun 2000 10:46:02 -0400 (EDT) Received: (from carlsonj@localhost) by dhcp-174-233.east.sun.com (8.9.3+Sun/8.9.3) id KAA07575; Fri, 2 Jun 2000 10:46:02 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14647.51370.716638.579633@gargle.gargle.HOWL> Date: Fri, 2 Jun 2000 10:46:02 -0400 (EDT) From: James Carlson To: "mania@future.futsoft.com" Cc: "ietf-ppp@merit.edu" Subject: Re: IDLE Timer In-Reply-To: Manikandan A's message of 2 June 2000 19:58:53 References: <01BFCCCC.FAD32700.mania@future.futsoft.com> X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Manikandan A writes: > What is the recommended IDLE timer value for the link ?. I could n't > find anything in RFC 1661. It's implementation dependent and can't be specified in the documents. You should set something that makes sense for your particular situation. In general, it depends on the speed of recovery of the link and the cost of link establishment. For links that come back up very quickly and do not incur additional costs for each call (such as centrex ISDN in some cases), a short timer of a few seconds is probably good. For links that charge per call or have very long set-up times (such as modems faster than 2400 bps), a longer timer of a minute or more might be appropriate. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Fri Jun 2 10:54:17 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03606 for ; Fri, 2 Jun 2000 10:54:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 315AB5DDD3; Fri, 2 Jun 2000 10:53:52 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 192925DE10; Fri, 2 Jun 2000 10:53:52 -0400 (EDT) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id 7F6435DDD3 for ; Fri, 2 Jun 2000 10:53:50 -0400 (EDT) Received: from karl.extant.net (mojo.extant.net [216.28.121.14]) by cliff.extant.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KD1WQKHJ; Fri, 2 Jun 2000 08:53:49 -0600 Message-Id: <4.3.2.6.2.20000602104653.047fe650@127.0.0.1> X-Sender: kfox@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2.6 (Beta) Date: Fri, 02 Jun 2000 10:53:43 -0400 To: mania@future.futsoft.com, ietf-ppp@merit.edu From: Karl Fox Subject: Re: IDLE Timer In-Reply-To: <01BFCCCC.FAD32700.mania@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi Mani, If you're talking about a timer used to shut down a link when traffic has quiesced, there isn't any default, requirement or specification. Each implementation chooses to do as it pleases, using (hopefully) Terminate-Request to shut down the link. There are also many different algorithms; here are a few of the many features out there: 1) Fixed timer, optionally configurable by the user 2) A so-called "split timer" which keeps track of open TCP sessions, with one (longer) timer used when one or more TCP sessions are open and another (shorter) timer used when no TCP sessions are open. For example, a 300/10 split timer will hang up after a TELNET session goes unused for five minutes, but will hang up within ten seconds of logging out the last session 3) Packet filters which select which traffic types should reset the idle timer. For example, TELNET packets reset, but NTP packets don't. I hope this helps, Karl At 10:28 AM 6/2/00, Manikandan A wrote: >Hi All, > > What is the recommended IDLE timer value for the link ?. I could n't find anything in RFC 1661. > > >TIA > >Regards, >Mani. Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Fri Jun 2 17:47:42 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15563 for ; Fri, 2 Jun 2000 17:47:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ED9315DE1B; Fri, 2 Jun 2000 17:45:42 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DA8BE5DE16; Fri, 2 Jun 2000 17:45:42 -0400 (EDT) Received: from deadhead.djinesys.com (unknown [198.108.6.129]) by segue.merit.edu (Postfix) with ESMTP id CBB295DE11 for ; Fri, 2 Jun 2000 17:45:41 -0400 (EDT) Received: (from bobsills@localhost) by deadhead.djinesys.com (8.9.3/8.9.3) id RAA77365 for ietf-ppp@merit.edu; Fri, 2 Jun 2000 17:46:01 -0400 (EDT) (envelope-from bobsills) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 4E54A5DDC8 for ; Thu, 1 Jun 2000 13:21:24 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27888; Thu, 1 Jun 2000 13:21:21 -0400 (EDT) Message-Id: <200006011721.NAA27888@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@merit.edu From: The IESG Subject: Protocol Action: PPP Bridging Control Protocol (BCP) to Proposed Standard Date: Thu, 01 Jun 2000 13:21:21 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu The IESG has approved the Internet-Draft 'PPP Bridging Control Protocol (BCP)' as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols. This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. This document obsoletes RFC 1638, which was based on the IEEE 802.1D-1993 MAC Bridge. This document extends that specification by including the IEEE 802.1D-1998 MAC Bridge and IEEE 802.1Q Virtual LAN (VLAN) standards. This document also improves the protocol in order to support high-speed switched LANs. Working Group Summary There was WG support for this document. Some minor issues were raised (and resolved) during the Last Call period. Protocol Quality This document has been reviewed for the IESG by Thomas Narten Note to RFC Editor: In the first sentence of the second paragraph of the Acknowledgments section, delete the two words "proposed Standard", producing: This document is based on the PPP Bridging Control Protocol, RFC 1638 [10], edited by Rich Bowen of IBM and produced by the Point-to-Point Protocol Extensions Working Group. and Change the title of section 6 from "Change Log" to "Changes from RFC 1638". From owner-ietf-ppp-outgoing@merit.edu Tue Jun 6 18:45:18 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20333 for ; Tue, 6 Jun 2000 18:45:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1CA685DDFB; Tue, 6 Jun 2000 18:44:45 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0B3375DDF5; Tue, 6 Jun 2000 18:44:45 -0400 (EDT) Received: from fcs-nt1.futsoft.com (fcs-nt1.futsoft.com [38.242.189.2]) by segue.merit.edu (Postfix) with ESMTP id 36E275DDBD for ; Tue, 6 Jun 2000 18:44:43 -0400 (EDT) Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com (Content Technologies SMTPRS 2.0.15) with SMTP id for ; Tue, 06 Jun 2000 15:31:57 -0700 Received: from localhost (rajeshs@localhost) by sanjose.futsoft.com (8.9.3/8.8.7) with ESMTP id OAA15169 for ; Tue, 6 Jun 2000 14:39:52 -0700 Date: Tue, 6 Jun 2000 14:39:52 -0700 (PDT) From: "S.Rajesh Kumar" To: ietf-ppp@merit.edu Subject: for PPP over ATM or PPPoE over ATM - which is more common - LLCencaps or VC multiplexing Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu The PPP over AAL5 specification allows use of VC multiplexing or LLC/SNAP encapsulation as an option. Which one is more prevalent? For the solutions of PPPoE (PPP over Ethernet) carried over ATM VCs, which of the two - LLC/SNAP encapsulation or VC multiplexing - is more common? Also - what do the Cisco and Redback boxes do? Leave this as a configuration option? Or choose one particular way? If so, which one? I would appreciate any pointers on these aspects Thanks in advance for any pointers Rajesh From owner-ietf-ppp-outgoing@merit.edu Tue Jun 6 19:55:34 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20805 for ; Tue, 6 Jun 2000 19:55:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F3E605DE01; Tue, 6 Jun 2000 19:55:10 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E22D45DE00; Tue, 6 Jun 2000 19:55:10 -0400 (EDT) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id 3D2FC5DDF5 for ; Tue, 6 Jun 2000 19:55:09 -0400 (EDT) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.9.3/8.9.3) id TAA19988; Tue, 6 Jun 2000 19:55:05 -0400 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14653.36696.733083.303567@h006008986325.ne.mediaone.net> Date: Tue, 6 Jun 2000 19:55:04 -0400 (EDT) To: "S.Rajesh Kumar" Cc: ietf-ppp@merit.edu Subject: Re: for PPP over ATM or PPPoE over ATM - which is more common - LLCencaps or VC multiplexing In-Reply-To: S.Rajesh Kumar's message of 6 June 2000 14:39:52 References: X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit S.Rajesh Kumar writes: > The PPP over AAL5 specification allows use of VC multiplexing or > LLC/SNAP encapsulation as an option. Which one is more prevalent? Does it matter? If you're doing one, you should do both. The big difference between them is that LLC/SNAP can traverse Frame Relay / ATM interworking units. VC mux cannot. (Also, just fyi, at least one VC mux implementation gets the header wrong by including the HDLC Address and Control fields, despite what RFC 2364 says.) > Also - what do the Cisco and Redback boxes do? Leave this as a > configuration option? Or choose one particular way? If so, which > one? Both have configuration information on their web sites ... You probably don't want to try to claim interoperability with these boxes without purchasing a few for test. -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Tue Jun 6 22:29:04 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22665 for ; Tue, 6 Jun 2000 22:29:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 905525DE04; Tue, 6 Jun 2000 22:28:40 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7E7745DDF6; Tue, 6 Jun 2000 22:28:40 -0400 (EDT) Received: from fs-sd-exch2.coppermountain.com (unknown [209.246.224.234]) by segue.merit.edu (Postfix) with ESMTP id 4FEC85DDB8 for ; Tue, 6 Jun 2000 22:28:38 -0400 (EDT) Received: by mail.coppermountain.com with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Jun 2000 19:30:57 -0700 Message-ID: <9FFFAB5D74FFD31191EA00D0B74178C80CCE1E@mail.coppermountain.com> From: Bonnie Hutchings To: "'James Carlson'" , "S.Rajesh Kumar" Cc: ietf-ppp@merit.edu Subject: RE: for PPP over ATM or PPPoE over ATM - which is more common - L LCencaps or VC multiplexing Date: Tue, 6 Jun 2000 19:30:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > > Does it matter? If you're doing one, you should do both. The big > difference between them is that LLC/SNAP can traverse Frame Relay / > ATM interworking units. VC mux cannot. Does anyone know why RFC 2364 specifies that the LLC encapsulation must be used for Frame Relay/ATM inter-working? It's hard to see how the LLC header can be critical. > > > Also - what do the Cisco and Redback boxes do? Leave this as a > > configuration option? Or choose one particular way? If so, which > > one? The Cisco 7200 and 6400 support only VC mux. The SMS1000 supports both RFC 2364 encapsulations. Thanks, Bonnie From owner-ietf-ppp-outgoing@merit.edu Thu Jun 8 01:54:59 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02754 for ; Thu, 8 Jun 2000 01:54:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 575055DE58; Thu, 8 Jun 2000 01:52:38 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 38F645DE5A; Thu, 8 Jun 2000 01:52:38 -0400 (EDT) Received: from fs-sd-exch2.coppermountain.com (unknown [209.246.224.234]) by segue.merit.edu (Postfix) with ESMTP id 6F5B25DE58 for ; Thu, 8 Jun 2000 01:51:54 -0400 (EDT) Received: by mail.coppermountain.com with Internet Mail Service (5.5.2650.21) id ; Wed, 7 Jun 2000 22:54:09 -0700 Message-ID: <9FFFAB5D74FFD31191EA00D0B74178C89C510E@mail.coppermountain.com> From: Eric Michelsen To: ietf-ppp@merit.edu Subject: RE: for PPP over ATM or PPPoE over ATM - which is more common - L LCencaps or VC multiplexing Date: Wed, 7 Jun 2000 22:54:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > -----Original Message----- > From: Bonnie Hutchings [mailto:bhutchings@coppermountain.com] > Sent: Tuesday, June 06, 2000 19:31 > To: 'James Carlson'; S.Rajesh Kumar > Cc: ietf-ppp@merit.edu > Subject: RE: for PPP over ATM or PPPoE over ATM - which is > more common - > L LCencaps or VC multiplexing > > > > > > Does it matter? If you're doing one, you should do both. The big > > difference between them is that LLC/SNAP can traverse Frame Relay / > > ATM interworking units. VC mux cannot. > > Does anyone know why RFC 2364 specifies that the LLC > encapsulation must be > used for Frame Relay/ATM inter-working? It's hard to see how > the LLC header > can be critical. The spec requires LLC for interworking so that FRF.8 can work without configuration. LLC is a full multi-protocol encapsulation, which defines what user-data is being carried. An FRF.8 function, buried deep in the network and far from the operator-configured endpoints, needs to be able to do its job without explicit operator configuration. ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks ... From owner-ietf-ppp-outgoing@merit.edu Tue Jun 13 10:39:17 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09909 for ; Tue, 13 Jun 2000 10:39:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B46BB5DD9F; Tue, 13 Jun 2000 10:38:50 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A1A185DE1F; Tue, 13 Jun 2000 10:38:50 -0400 (EDT) Received: from deadhead.djinesys.com (unknown [198.108.6.129]) by segue.merit.edu (Postfix) with ESMTP id 184AA5DD9F for ; Tue, 13 Jun 2000 10:38:46 -0400 (EDT) Received: (from bobsills@localhost) by deadhead.djinesys.com (8.9.3/8.9.3) id KAA69115 for ietf-ppp@merit.edu; Tue, 13 Jun 2000 10:39:34 -0400 (EDT) (envelope-from bobsills) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by segue.merit.edu (Postfix) with ESMTP id 444D05DE1F for ; Tue, 13 Jun 2000 09:54:42 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA00995 for ; Tue, 13 Jun 2000 15:54:04 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([218.1.68.146]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA16933 for ; Tue, 13 Jun 2000 15:54:23 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2448.0) id ; Tue, 13 Jun 2000 15:57:08 +0200 Message-ID: <3B59676F9ADBD211B5360060086E64EECC0134@MCHH237E> From: Theimer Thomas To: "'PPPEXT Mailing List'" Subject: FW: I-D ACTION:draft-theimer-tcrtp-mpls-00.txt Date: Tue, 13 Jun 2000 15:57:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu FYI. I am not sure if this draft is relevant to the PPP working group, as it does not change anything in PPP. However, it does involve carrying PPP over MPLS tunnels to facilitate header compression. Regards, Thomas Theimer > -----Original Message----- > From: Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org] > Sent: Monday, June 12, 2000 12:43 PM > To: IETF-Announce > Cc: mpls@UU.NET; rem-conf@es.net > Subject: I-D ACTION:draft-theimer-tcrtp-mpls-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Tunneling Multiplexed Compressed RTP in MPLS > Author(s) : T. Theimer > Filename : draft-theimer-tcrtp-mpls-00.txt > Pages : 10 > Date : 09-Jun-00 > > This document describes a method to improve the bandwidth efficiency > of voice transmission over an IP/MPLS network by combining RTP > compression, PPP multiplexing and MPLS tunneling. This proposal does > not require any additions or modifications to existing protocols, and > therefore should be fully interoperable with existing implementations > of RTP compression and PPP multiplexing. It only requires specific > use of some attributes of MPLS signalling protocols to setup a pair > of unidirectional MPLS tunnels providing a bidirectional link for > compressed RTP over PPP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-theimer-tcrtp-mpls-00.txt > > Internet-Drafts are also 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-theimer-tcrtp-mpls-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-theimer-tcrtp-mpls-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. From owner-ietf-ppp-outgoing@merit.edu Mon Jun 26 02:38:59 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27490 for ; Mon, 26 Jun 2000 02:38:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 098195DDB3; Mon, 26 Jun 2000 02:38:23 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EBAE95DD94; Mon, 26 Jun 2000 02:38:22 -0400 (EDT) Received: from smtp.mail.yahoo.com (smtp.mail.yahoo.com [128.11.68.32]) by segue.merit.edu (Postfix) with SMTP id 9D84F5DD8C for ; Mon, 26 Jun 2000 02:38:20 -0400 (EDT) Received: from ppp-203-197-9-252.bom.vsnl.net.in (HELO muralidharan) (203.197.9.252) by smtp.mail.yahoo.com with SMTP; 25 Jun 2000 23:38:17 -0700 X-Apparently-From: Message-ID: <001f01bfdf39$54cfd5e0$1000a8c0@muralidharan> Reply-To: "R. Muralidharan" From: "R. Muralidharan" To: Cc: , Subject: Status of Internet draft "Extending PPP over SONET/SDH with virtual concatenation..." Date: Mon, 26 Jun 2000 12:09:43 +0530 Organization: OSS Systems (India) Pvt Ltd/IEEE Bombay section MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001C_01BFDF67.699EBEE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is a multi-part message in MIME format. ------=_NextPart_000_001C_01BFDF67.699EBEE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all, Could someone please update me on the status of the draft on "Extending PPP over SONET/SDH, with virtual concatenation, high order and low order payloads." which is to expire in June 2000. TIA and regards muralidharan ------=_NextPart_000_001C_01BFDF67.699EBEE0 Content-Type: text/x-vcard; name="R. Muralidharan.vcf" Content-Disposition: attachment; filename="R. Muralidharan.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Muralidharan;Raghavan FN:R. Muralidharan ORG:OSS Systems (India) Pvt Ltd ADR;WORK:;;111 Janki Centre, Andheri(W);Bombay;;400053;India LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:111 Janki Centre, = Andheri(W)=3D0D=3D0ABombay 400053=3D0D=3D0AIndia EMAIL;PREF;INTERNET:r.muralidharan@ieee.org EMAIL;INTERNET:r.muralidharan@computer.org REV:20000626T063943Z END:VCARD ------=_NextPart_000_001C_01BFDF67.699EBEE0-- __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-ietf-ppp-outgoing@merit.edu Tue Jun 27 13:24:23 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18676 for ; Tue, 27 Jun 2000 13:24:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E99F15DE18; Tue, 27 Jun 2000 13:23:55 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D59795DE17; Tue, 27 Jun 2000 13:23:55 -0400 (EDT) Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by segue.merit.edu (Postfix) with ESMTP id 1F5BB5DE16 for ; Tue, 27 Jun 2000 13:23:54 -0400 (EDT) Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA17300 for ; Tue, 27 Jun 2000 13:23:53 -0400 (EDT) Received: from pai820exch001h.wins.lucent.com (h135-14-3-59.lucent.com [135.14.3.59]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA17287 for ; Tue, 27 Jun 2000 13:23:53 -0400 (EDT) Received: by pai820exch001h.micro.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Jun 2000 13:23:52 -0400 Message-ID: <2723E6389F55D311BDC200508B129547017E1F20@pai820exch003u.micro.lucent.com> From: "Jones, Nevin R (Nevin)" To: ietf-ppp@merit.edu, "'R. Muralidharan'" Cc: murton@nortelnetworks.com, "Jones, Nevin R (Nevin)" Subject: RE: Status of Internet draft "Extending PPP over SONET/SDH with v irtual concatenation..." Date: Tue, 27 Jun 2000 13:23:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > muralidharan: > We are in the process of updating this Internet draft to reflect the current status of virtual concatenation in the Transmission standards bodies. We anticipate uploading the updated document to the pppext site in a matter of days. Please check the site in a couple of days. Thanks for your interest in this work. Regards, -Nevin Jones > ---------- > From: R. Muralidharan[SMTP:raghavan_muralidharan@yahoo.com] > Reply To: R. Muralidharan > Sent: Monday, June 26, 2000 2:39 AM > To: ietf-ppp@merit.edu > Cc: Jones, Nevin R (Nevin); murton@nortelnetworks.com > Subject: Status of Internet draft "Extending PPP over SONET/SDH with > virtual concatenation..." > > <> > Hi all, > > Could someone please update me on the status of the draft on "Extending > PPP > over SONET/SDH, with virtual concatenation, high order and low order > payloads." which is to expire in June 2000. > > TIA and regards > muralidharan > From owner-ietf-ppp-outgoing@merit.edu Thu Jun 29 17:43:37 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20660 for ; Thu, 29 Jun 2000 17:43:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 40DFE5DDF7; Thu, 29 Jun 2000 17:43:04 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3042A5DDF2; Thu, 29 Jun 2000 17:43:04 -0400 (EDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by segue.merit.edu (Postfix) with ESMTP id B43935DDF7 for ; Thu, 29 Jun 2000 17:43:02 -0400 (EDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA219262 for ; Thu, 29 Jun 2000 17:41:07 -0400 Received: from TROUBLE (DIP005899END.endicott.ibm.com [9.130.69.192]) by northrelay01.pok.ibm.com (8.8.8m3/NCO v2.07) with SMTP id RAA212290 for ; Thu, 29 Jun 2000 17:43:00 -0400 Message-ID: <001b01bfe213$1d7dc160$c0458209@endicott.ibm.com> From: "John R. Martz" To: Subject: Radius MP attributes? Date: Thu, 29 Jun 2000 17:43:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit A co-worker mentioned to me that there are Radius attributes defined for use with the Multilink Protocol (MP). I've looked at the list of attributes on page 59 RFC 2138, but nothing I saw there seemed to pertain specifically to MP. Are there Radius attributes for MP (and BAP)? And if so, can someone point me towards the RFC that describes them? Thanks, -john martz (jmartz@us.ibm.com) IBM AS/400 TCP/IP PPP (and stuff) From owner-ietf-ppp-outgoing@merit.edu Thu Jun 29 17:57:53 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20990 for ; Thu, 29 Jun 2000 17:57:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DCCFC5DE55; Thu, 29 Jun 2000 17:57:28 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CA39F5DE53; Thu, 29 Jun 2000 17:57:28 -0400 (EDT) Received: from postal.redback.com (postal.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 018B85DE4F for ; Thu, 29 Jun 2000 17:57:26 -0400 (EDT) Received: from redback.com (creek.redback.com [155.53.36.39]) by postal.redback.com (Postfix) with ESMTP id 7165E2AA12; Thu, 29 Jun 2000 14:57:20 -0700 (PDT) Message-ID: <395BC640.7820FD22@redback.com> Date: Thu, 29 Jun 2000 14:57:20 -0700 From: Greg Kilfoyle Organization: Redback Networks X-Mailer: Mozilla 4.7 [en] (X11; U; NetBSD 1.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: "John R. Martz" Cc: ietf-ppp@merit.edu Subject: Re: Radius MP attributes? References: <001b01bfe213$1d7dc160$c0458209@endicott.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hi John, Check the RADIUS v2 drafts: http://www.ietf.org/internet-drafts/draft-ietf-radius-radius-v2-06.txt http://www.ietf.org/internet-drafts/draft-ietf-radius-accounting-v2-05.txt You'll find MP-specific attributes. On the auth side, Port-Limit is applicable. On the accounting side, Acct-Multi-Session-Id and Acct-Link-Count are applicable. Cheers, Greg. "John R. Martz" wrote: > > A co-worker mentioned to me that there are Radius attributes defined for use with the Multilink > Protocol (MP). I've looked at the list of attributes on page 59 RFC 2138, but nothing I saw there > seemed to pertain specifically to MP. > > Are there Radius attributes for MP (and BAP)? And if so, can someone point me towards the RFC that > describes them? > > Thanks, > -john martz (jmartz@us.ibm.com) > IBM AS/400 TCP/IP PPP (and stuff) -- Greg Kilfoyle (gregk@redback.com) From owner-ietf-ppp-outgoing@merit.edu Fri Jun 30 13:49:27 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23028 for ; Fri, 30 Jun 2000 13:49:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DF1CC5DE13; Fri, 30 Jun 2000 13:49:02 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C97EA5DE16; Fri, 30 Jun 2000 13:49:02 -0400 (EDT) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id F37FF5DE13 for ; Fri, 30 Jun 2000 13:49:00 -0400 (EDT) Received: from gwz (sj-dial-3-124.cisco.com [171.68.180.125]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id KAA13356; Fri, 30 Jun 2000 10:47:11 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "John R. Martz" Cc: "RADIUS Mailing List" , Subject: RE: Radius MP attributes? Date: Fri, 30 Jun 2000 10:45:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <001b01bfe213$1d7dc160$c0458209@endicott.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit John R. Martz [maailto://jmartz@us.ibm.com] writes: > A co-worker mentioned to me that there are Radius attributes > defined for use with the Multilink > Protocol (MP). I've looked at the list of attributes on page 59 > RFC 2138, but nothing I saw there > seemed to pertain specifically to MP. > > Are there Radius attributes for MP (and BAP)? And if so, can > someone point me towards the RFC that > describes them? The only BAP-specific RADIUS attributes of which I'm aware are also Microsoft vendor-specific (RFC 2548). > > Thanks, > -john martz (jmartz@us.ibm.com) > IBM AS/400 TCP/IP PPP (and stuff) > > > > > > From owner-ietf-ppp-outgoing@merit.edu Fri Jun 30 15:56:04 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25349 for ; Fri, 30 Jun 2000 15:56:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3F9CA5E095; Fri, 30 Jun 2000 15:53:44 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1D5EF5DEAF; Fri, 30 Jun 2000 15:53:44 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 3AE9F5DFCC for ; Fri, 30 Jun 2000 15:49:05 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA09248 for ; Fri, 30 Jun 2000 12:49:04 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id MAA19855 for ; Fri, 30 Jun 2000 12:49:04 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Jun 2000 14:49:04 -0500 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A026B5E48@il27exm02.cig.mot.com> From: Ali Irfan-FIA225 To: "'ietf-ppp@merit.edu'" Cc: "'fox@cisco.com'" , Pazhyannur Rajesh-QA6283 , "'Stacy_Nichols@pmc-sierra.com'" Subject: PPPmux and MP Date: Fri, 30 Jun 2000 14:48:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu There were some off-mailing-list discussion on the interaction of PPPmux and multilink PPP (MP) (RFC-1990). The issue is that if PPPmux LCP option is negotiated on a link of a bundle, then can the multiplexing only occur on just that one link or on the entire bundle? PPP multiplexing can be done either way, on the entire bundle or on an individual link only. We would like to allow both, if the group agrees. We are intending to update PPPmux draft by adding the following paragraph 4. Interaction with PPP Multilink (MP) Protocol The PPP Multiplexed Frame option is negotiated by LCP for an individual link. If the PPP Multiplexed Frame option is negotiated on any link of a Multilink PPP bundle, then the receiver has agreed to support the PPP Multiplexed Frame option on the Multilink Bundle. The transmitter is under no obligation to multiplex frames on the bundle or the individual links. Comments are solicited. Thanks Irfan From owner-ietf-ppp-outgoing@merit.edu Fri Jun 30 16:50:54 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26224 for ; Fri, 30 Jun 2000 16:50:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E63935DE3C; Fri, 30 Jun 2000 16:49:20 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5E2855DE93; Fri, 30 Jun 2000 16:32:31 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 62D365E0EB for ; Fri, 30 Jun 2000 16:27:13 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05077; Fri, 30 Jun 2000 14:27:07 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA15525; Fri, 30 Jun 2000 16:27:07 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.9.3+Sun/8.9.3) id QAA12078; Fri, 30 Jun 2000 16:27:07 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14685.666.986931.496567@gargle.gargle.HOWL> Date: Fri, 30 Jun 2000 16:27:06 -0400 (EDT) From: James Carlson To: Ali Irfan-FIA225 Cc: "'ietf-ppp@merit.edu'" , "'fox@cisco.com'" , Pazhyannur Rajesh-QA6283 , "'Stacy_Nichols@pmc-sierra.com'" Subject: Re: PPPmux and MP In-Reply-To: Ali Irfan-FIA225's message of 30 June 2000 14:48:55 References: <0DF9920C9AD8D211AB0C0008C7CF1C9A026B5E48@il27exm02.cig.mot.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Ali Irfan-FIA225 writes: > 4. Interaction with PPP Multilink (MP) Protocol > > The PPP Multiplexed Frame option is negotiated by LCP for an > individual link. If the PPP Multiplexed Frame option is > negotiated on any link of a Multilink PPP bundle, then the > receiver has agreed to support the PPP Multiplexed Frame > option on the Multilink Bundle. The transmitter is under no > obligation to multiplex frames on the bundle or the individual > links. The paragraph you give seems to imply that this is a possibility and that it could be done simultaneously at both bundle level and link level, leading to a protocol nested in itself. The only other instance I know of something like that -- MPPE and MPPC -- is also a flawed design. I can't see a reason for doing PPPmux on a per-link basis with MP. Worse, at the time you negotiate LCP, you don't necessarily know whether you're joining an existing bundle (Vern's nifty preselection idea aside). You have to wait until after authentication occurs to determine this. This implies that you cannot know whether nor not to accept the PPPmux option when presented. You can't know what you're necessarily agreeing to. Worse still, it's not obvious how this should work in practice. Suppose links A, B, and C are in a bundle. A starts first and does not include PPPmux. B starts next and does include it. Then C starts without PPPmux. Presumably, the bundle can now do PPPmux. If B leaves the bundle, though, does the PPPmux capability go with it? If so, then we have the strange condition that the implementation must have a quorum of links of a particular flavor in order to perform a given network layer. If not, then we have the strange condition that the bundle is permitted to do something that neither link has explicitly negotiated. This would appear to have much the same flavor to it as the CCP and ECP at bundle versus per-link debate. The only problem is that PPPmux is negotiated at the wrong point in the architecture; it should be an NCP, just like CCP and ECP, and (if desired) have a per-link variant. That way, the intent would be unambiguous. As long as PPPmux stays at LCP level, it seems to me that the right hack is to treat it in the same manner as the MRRU and SSN options. If it's set on any link, then it must be set on all links. Dissimilar settings for this option within a bundle should be prohibited. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp