From owner-ietf-ppp-outgoing@merit.edu Wed Sep 6 07:47: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 HAA08636 for ; Wed, 6 Sep 2000 07:47:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 63E735DDFD; Wed, 6 Sep 2000 07:46:04 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 50D0F5DDFC; Wed, 6 Sep 2000 07:46:04 -0400 (EDT) Received: from smtp1.mail.yahoo.com (smtp1.mail.yahoo.com [128.11.68.130]) by segue.merit.edu (Postfix) with SMTP id F31CD5DDFB for ; Wed, 6 Sep 2000 07:46:01 -0400 (EDT) Received: from unknown (HELO muralidharan) (203.199.38.54) by smtp1.mail.yahoo.com with SMTP; 6 Sep 2000 11:46:00 -0000 X-Apparently-From: Message-ID: <00cd01c017f8$471412c0$1000a8c0@muralidharan> Reply-To: "R. Muralidharan" From: "R. Muralidharan" To: Subject: MIBs for MLPPP over SONET Date: Wed, 6 Sep 2000 17:17:43 +0530 Organization: OSS Systems (India) Pvt Ltd/IEEE Bombay section MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00CA_01C01826.5E686E20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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_00CA_01C01826.5E686E20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi All, Would appreciate your comments on the adequacy of the following MIBs for MLPPP implementation over SONET: RFC 1473 for NCP of PPP RFC 1471 for LCP of PPP RFC 1474 for Bridging in PPP Is there any MIB just for PPP or MLPPP which I missed? RFC 1472 for PAP & CHAP is not planned since this PPP is for transport of IP data over SONET. Thanks in advance muralidharan ------=_NextPart_000_00CA_01C01826.5E686E20 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:20000906T114743Z END:VCARD ------=_NextPart_000_00CA_01C01826.5E686E20-- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ietf-ppp-outgoing@merit.edu Wed Sep 6 08:34:55 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 IAA10192 for ; Wed, 6 Sep 2000 08:34:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E2555DDBE; Wed, 6 Sep 2000 08:34:30 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F02395DDBC; Wed, 6 Sep 2000 08:34:29 -0400 (EDT) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id 5C2175DDBA for ; Wed, 6 Sep 2000 08:34:28 -0400 (EDT) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.11.0/8.11.0) id e86CWjt06166; Wed, 6 Sep 2000 08:32:45 -0400 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14774.14700.866034.659865@h006008986325.ne.mediaone.net> Date: Wed, 6 Sep 2000 08:32:44 -0400 (EDT) To: "R. Muralidharan" Cc: Subject: Re: MIBs for MLPPP over SONET In-Reply-To: R. Muralidharan's message of 6 September 2000 17:17:43 References: <00cd01c017f8$471412c0$1000a8c0@muralidharan> 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 R. Muralidharan writes: > Would appreciate your comments on the adequacy of the following MIBs > for MLPPP implementation over SONET: MP (not "MLPPP") is CPU and memory intensive, and is not commonly used on very high-speed links. Are you sure you want to do that? > RFC 1473 for NCP of PPP 1473 is IPCP, not generic "NCP." > RFC 1471 for LCP of PPP > RFC 1474 for Bridging in PPP I'd be a little surprised if bridging is very useful over SONET links, but I suppose that depends on your target market. > Is there any MIB just for PPP or MLPPP which I missed? No. > RFC 1472 for PAP & CHAP is not planned since this PPP is for transport of IP > data over SONET. Vendors that support SNMP management of PPP links generally have extensive enterprise (proprietary) MIBs, since the ones described in the RFCs are a little thin for the job. Of course, you'll want all of the standard physical-layer and network interface stacking MIBs as well ... -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Sep 7 05: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 FAA14356 for ; Thu, 7 Sep 2000 05:50:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2C0795DD98; Thu, 7 Sep 2000 05:50:21 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 063B35DDFA; Thu, 7 Sep 2000 05:50:20 -0400 (EDT) Received: from smtp1b.mail.yahoo.com (smtp3.mail.yahoo.com [128.11.68.135]) by segue.merit.edu (Postfix) with SMTP id 757295DD98 for ; Thu, 7 Sep 2000 05:50:18 -0400 (EDT) Received: from ppp-203-197-9-250.bom.vsnl.net.in (HELO muralidharan) (203.197.9.250) by smtp3.mail.yahoo.com with SMTP; 7 Sep 2000 09:50:16 -0000 X-Apparently-From: Message-ID: <006601c018b1$475366a0$1000a8c0@muralidharan> Reply-To: "R. Muralidharan" From: "R. Muralidharan" To: "James Carlson" , "R. Muralidharan" Cc: References: <00cd01c017f8$471412c0$1000a8c0@muralidharan> <14774.14700.866034.659865@h006008986325.ne.mediaone.net> Subject: Re: MIBs for MLPPP over SONET Date: Thu, 7 Sep 2000 15:21:59 +0530 Organization: OSS Systems (India) Pvt Ltd/IEEE Bombay section 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Dear James, Many thanks for your prompt and informative response. Following are the two clarifications on your queries: > MP (not "MLPPP") is CPU and memory intensive, and is not commonly used > on very high-speed links. Are you sure you want to do that? MP is being used to bundle VTs to provide variable bandwidth for Ethernet input ports. This may be better done with Virtual concatenation(is it true?), which I presume is going to be added to FRS 2615 any time now. > I'd be a little surprised if bridging is very useful over SONET links, > but I suppose that depends on your target market. Bridging is used to provide Transparent LAN services (Ethernet ports extended to the other end LAN segment through a bundle of VTs). Thanks again and regards, muralidharan _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ietf-ppp-outgoing@merit.edu Thu Sep 7 20:46:48 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00721 for ; Thu, 7 Sep 2000 20:46:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8AD1A5DE09; Thu, 7 Sep 2000 20:45:10 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 781F15DDDD; Thu, 7 Sep 2000 20:45:10 -0400 (EDT) Received: from gate.alliedtelesyn.co.nz (unknown [202.49.72.33]) by segue.merit.edu (Postfix) with SMTP id 2A9625DDD9 for ; Thu, 7 Sep 2000 20:45:04 -0400 (EDT) Received: (qmail 23645 invoked from network); 8 Sep 2000 01:52:02 -0000 Received: from aslan.alliedtelesyn.co.nz (HELO alliedtelesyn.co.nz) (202.49.72.92) by gate-int.alliedtelesyn.co.nz with SMTP; 8 Sep 2000 01:52:02 -0000 Received: from ASLAN/SpoolDir by alliedtelesyn.co.nz (Mercury 1.47); 8 Sep 00 12:43:10 +1200 Received: from SpoolDir by ASLAN (Mercury 1.47); 8 Sep 00 12:43:01 +1200 From: "Matt Harris" Organization: Allied Telesyn Research, Chch, NZ To: ietf-ppp Date: Fri, 8 Sep 2000 12:42:56 +1200 (NZT) Subject: question about CHAP timeout Reply-To: matt.harris@alliedtelesyn.co.nz Message-ID: <39B8DECF.11113.933681@localhost> In-reply-to: <14746.54960.499774.517878@gargle.gargle.HOWL> References: Kendall, Greg's message of 16 August 2000 10:56:51 X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I've got a situation (as below) where a peer is being slow to respond to an initial CHAP Challenge, which causes the authenticator to timeout and send a second Challenge, incrementing the ID as required by RFC 1994. The peer then responds to the first challenge, and this response is discarded as the ID doesn't match the last challenge sent. <---------------------- Challenge(ID1) timeout <---------------------- Challenge(ID2) ----------------------> Response (ID1) Is there any reduction in security to accept this CHAP response and send the CHAP success message if the response is valid? Another solution would be to increase the timeout - does this have any security issues? I see that Jame Carlson said there was no reduction in security for PAP, but is CHAP different? TIA, Matt ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Matt Harris, R&D Software Development Engineer. CentreCOM Systems Ltd. An Allied Telesyn Group company - Simply connecting the World. Unit 2, 242 Ferry Rd, Phone: +64 3 377 8900. PO Box 10-290, Facsmile: +64 3 377 8870. Christchurch 8030, Mobile: +64 21 701 762 New Zealand. email: matt.harris@alliedtelesyn.co.nz http://www.alliedtelesyn.co.nz/ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ From owner-ietf-ppp-outgoing@merit.edu Fri Sep 8 02:33:37 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18029 for ; Fri, 8 Sep 2000 02:33:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5B3415DDD2; Fri, 8 Sep 2000 02:32:56 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 485BF5DD9D; Fri, 8 Sep 2000 02:32:56 -0400 (EDT) Received: from arianne.in.ishoni.com (unknown [164.164.83.132]) by segue.merit.edu (Postfix) with ESMTP id 88F855DD8E for ; Fri, 8 Sep 2000 02:32:51 -0400 (EDT) Received: from rohit (rashmi [192.168.1.16]) by arianne.in.ishoni.com (8.9.3/8.9.3) with SMTP id MAA15168 for ; Fri, 8 Sep 2000 12:05:44 +0530 Reply-To: From: "Rohit Khosla" To: Subject: IPSec interop workshop Schedule Date: Fri, 8 Sep 2000 12:12:46 +0530 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 CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hi All, would appreciate any info regarding IPSec interop workshop schedule. Thanks, Rohit From owner-ietf-ppp-outgoing@merit.edu Fri Sep 8 06:23:14 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19674 for ; Fri, 8 Sep 2000 06:23:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 588065DD8E; Fri, 8 Sep 2000 06:22:41 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 44DDA5DD95; Fri, 8 Sep 2000 06:22:41 -0400 (EDT) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id 7E87D5DD8E for ; Fri, 8 Sep 2000 06:22:35 -0400 (EDT) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.11.0/8.11.0) id e88AMTf07352; Fri, 8 Sep 2000 06:22:29 -0400 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14776.48612.974883.546573@h006008986325.ne.mediaone.net> Date: Fri, 8 Sep 2000 06:22:28 -0400 (EDT) To: matt.harris@alliedtelesyn.co.nz Cc: ietf-ppp Subject: Re: question about CHAP timeout In-Reply-To: Matt Harris's message of 8 September 2000 12:42:56 References: <39B8DECF.11113.933681@localhost> 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 Matt Harris writes: > I've got a situation (as below) where a peer is being slow to respond > to an initial CHAP Challenge, which causes the authenticator to > timeout and send a second Challenge, incrementing the ID as > required by RFC 1994. The peer then responds to the first > challenge, and this response is discarded as the ID doesn't match > the last challenge sent. The usual solution to this is to use an increasing restart value (timeout). For example, 3 seconds the first time, 6 the next, and so on. > Is there any reduction in security to accept this CHAP response > and send the CHAP success message if the response is valid? > Another solution would be to increase the timeout - does this have > any security issues? If you then spoof out Response with ID 2 (send a copy of the last Success or Failure message with ID 2 but without checking the Response value), then I don't see a problem. It's as though you never sent Challenge with ID 2. I'm not a security expert, though, and if the security of the system is important, you may want to consult with one. > I see that Jame Carlson said there was no reduction in security for > PAP, but is CHAP different? Unless I'm mistaken, the statement on PAP had to do with accepting malformed Authenticate-Ack messages. Since those messages merely imply the *peer's* acceptance of the Authenticate-Request, it's not a problem if they're slightly malformed (such as missing the required message length octet). Accepting those (and malformed CHAP Success or Failure messages) does no obvious harm. -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Tue Sep 12 11:56:48 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07515 for ; Tue, 12 Sep 2000 11:56:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 88B675DDD8; Tue, 12 Sep 2000 11:56:12 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 764E45DDCA; Tue, 12 Sep 2000 11:56:12 -0400 (EDT) Received: from stargate.ttc.com (stargate.ttc.com [157.234.250.2]) by segue.merit.edu (Postfix) with ESMTP id 575F05DDA2 for ; Tue, 12 Sep 2000 11:56:10 -0400 (EDT) Received: from relay.ttc.com (relay.ttc.com [157.234.7.6]) by stargate.ttc.com with ESMTP id LAA17615 for ; Tue, 12 Sep 2000 11:56:55 -0400 (EDT) From: michael.koller@acterna.com Received: from relay.ttc.com by relay.ttc.com with SMTP id LAA23063 for ; Tue, 12 Sep 2000 11:56:05 -0400 (EDT) Received: by ttcmta1-7.ttc.com(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 85256958.00574127 ; Tue, 12 Sep 2000 11:53:03 -0400 X-Lotus-FromDomain: GLOBAL To: ietf-ppp@merit.edu Message-ID: <85256958.00573EB2.00@ttcmta1-7.ttc.com> Date: Tue, 12 Sep 2000 11:51:23 -0400 Subject: Negotiating MRU Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu (requires fixed font to make sense of below graphic) |========| MRU=1024 |=| |~~~~~~~~~~~| |=| MRU=2048 |========| | -A- |----------->|L|-->| |-->|L|----------->| -B- | | PoS | |E| | N/W Cloud | |E| | PoS | | Device |<-----------|R|<--| |<--|R|<-----------| Device | |========| MRU=1024 |=| |~~~~~~~~~~~| |=| MRU=2048 |========| If Device-A negotiates an MRU of 1024 and Device-B negotiates an MRU of 2048, what happens to packets sent from Device-B to Device-A that are larger than 1024 (assuming non-static LSPs)? Is the packet discarded? Is the packet fragemented? If it is fragmented, who does the fragmenting? Thanks, MK From owner-ietf-ppp-outgoing@merit.edu Tue Sep 12 12:08:05 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07945 for ; Tue, 12 Sep 2000 12:08:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 56BFF5DDCA; Tue, 12 Sep 2000 12:07:43 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 447785DDA2; Tue, 12 Sep 2000 12:07:43 -0400 (EDT) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id 317285DDB4 for ; Tue, 12 Sep 2000 12:07:41 -0400 (EDT) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.11.0/8.11.0) id e8CG7dW19002; Tue, 12 Sep 2000 12:07:39 -0400 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14782.21706.330412.226701@h006008986325.ne.mediaone.net> Date: Tue, 12 Sep 2000 12:07:38 -0400 (EDT) To: michael.koller@acterna.com Cc: ietf-ppp@merit.edu Subject: Re: Negotiating MRU In-Reply-To: michael.koller@acterna.com's message of 12 September 2000 11:51:23 References: <85256958.00573EB2.00@ttcmta1-7.ttc.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 michael.koller@acterna.com writes: > If Device-A negotiates an MRU of 1024 and Device-B negotiates an MRU of 2048, > what happens to > packets sent from Device-B to Device-A that are larger than 1024 (assuming > non-static LSPs)? I assume by the references to LERs and LSPs that this is actually an MPLS question, not a PPP question. > Is the packet discarded? Is the packet fragemented? If it is fragmented, who > does the > fragmenting? MPLS doesn't fragment. The LSP's MTU is determined by signaling. See: http://www.ietf.org/internet-drafts/draft-ietf-mpls-label-encaps-08.txt and http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-07.txt Like any other link-layer, PPP must advertise its constraints (MTU being one of these) to the network layer. How this is done is implementation specific. -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Tue Sep 12 12:44:30 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08900 for ; Tue, 12 Sep 2000 12:44:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E00175DDF1; Tue, 12 Sep 2000 12:44:00 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CFC535DDE8; Tue, 12 Sep 2000 12:44:00 -0400 (EDT) Received: from stargate.ttc.com (stargate.ttc.com [157.234.250.2]) by segue.merit.edu (Postfix) with ESMTP id 044005DDA2 for ; Tue, 12 Sep 2000 12:43:59 -0400 (EDT) Received: from relay.ttc.com (relay.ttc.com [157.234.7.6]) by stargate.ttc.com with ESMTP id MAA20898 for ; Tue, 12 Sep 2000 12:44:48 -0400 (EDT) From: michael.koller@acterna.com Received: from relay.ttc.com by relay.ttc.com with SMTP id MAA27980 for ; Tue, 12 Sep 2000 12:43:57 -0400 (EDT) Received: by ttcmta1-7.ttc.com(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 85256958.005BA152 ; Tue, 12 Sep 2000 12:40:50 -0400 X-Lotus-FromDomain: GLOBAL To: ietf-ppp@merit.edu Message-ID: <85256958.005B9F90.00@ttcmta1-7.ttc.com> Date: Tue, 12 Sep 2000 12:39:12 -0400 Subject: Re: Negotiating MRU Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu >>>michael.koller@acterna.com writes: >>>If Device-A negotiates an MRU of 1024 and Device-B negotiates an MRU of 2048, >>>what happens to >>>packets sent from Device-B to Device-A that are larger than 1024 (assuming >>>non-static LSPs)? >carlson@workingcode.com writes: >I assume by the references to LERs and LSPs that this is actually an >MPLS question, not a PPP question. I don't think so. What I was wondering is that at the time PPP is negotiated, you don't know who you are going to be sending packets to. So when you negotiate the link MRU, it is independent of any other device that may have also negotiated PPP. In the example I gave, my question has to do with: If Device-A and Device-B independently negotiate PPP and then end up talking to each other later on, what if one sends a packet larger than what the other can receive? Thanks, MK (requires fixed font to make sense of below graphic) |========| MRU=1024 |=| |~~~~~~~~~~~| |=| MRU=2048 |========| | -A- |----------->|L|-->| |-->|L|----------->| -B- | | PoS | |E| | N/W Cloud | |E| | PoS | | Device |<-----------|R|<--| |<--|R|<-----------| Device | |========| MRU=1024 |=| |~~~~~~~~~~~| |=| MRU=2048 |========| From owner-ietf-ppp-outgoing@merit.edu Tue Sep 12 12:52:33 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09051 for ; Tue, 12 Sep 2000 12:52:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 61D1D5DDA2; Tue, 12 Sep 2000 12:52:08 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4DAE05DDB4; Tue, 12 Sep 2000 12:52:08 -0400 (EDT) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id B4DD85DDA2 for ; Tue, 12 Sep 2000 12:52:06 -0400 (EDT) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.11.0/8.11.0) id e8CGq5d16626; Tue, 12 Sep 2000 12:52:05 -0400 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14782.24371.991492.471562@h006008986325.ne.mediaone.net> Date: Tue, 12 Sep 2000 12:52:03 -0400 (EDT) To: michael.koller@acterna.com Cc: ietf-ppp@merit.edu Subject: Re: Negotiating MRU In-Reply-To: michael.koller@acterna.com's message of 12 September 2000 12:39:12 References: <85256958.005B9F90.00@ttcmta1-7.ttc.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 michael.koller@acterna.com writes: > >carlson@workingcode.com writes: > >I assume by the references to LERs and LSPs that this is actually an > >MPLS question, not a PPP question. > > I don't think so. What I was wondering is that at the time PPP is > negotiated, you don't know who you are going to be sending packets > to. So when you negotiate the link MRU, it is independent of any > other device that may have also negotiated PPP. Sure. > In the example I gave, my question has to do with: If Device-A and Device-B > independently negotiate > PPP and then end up talking to each other later on, what if one sends a packet > larger than what the > other can receive? Assuming all of the paths within the cloud are >= 2048, then it's the LER on the last hop that will discard the packet. If that assumption isn't true, then one of the LSRs in the middle will do it. The end points are just part of the concern; every hop in that cloud is a potential problem. (Consider what happens if one of the links in the middle of the network has an MTU set to 512. Neither device has this value, and yet it's a constraint of the LSPs going through that link.) This is an error case; large packets like this shouldn't be sent by a properly implemented MPLS-speaking device. In MPLS, signaling is used to establish the path MTU. The same is true for network-layer protocols, such as IP. With IPv4, fragmentation within IP is sometimes possible. With IPv6, it's not. It's not the link layer's problem to deal with network level issues. This isn't a PPP issue. -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Tue Sep 12 13:15:21 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09798 for ; Tue, 12 Sep 2000 13:15:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8707C5DEB4; Tue, 12 Sep 2000 13:13:04 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6A7195DEB3; Tue, 12 Sep 2000 13:13:04 -0400 (EDT) Received: from gateway.zk3.dec.com (nashua.zk3-x.dec.com [206.152.163.42]) by segue.merit.edu (Postfix) with SMTP id 450AF5DEA9 for ; Tue, 12 Sep 2000 13:13:02 -0400 (EDT) Received: by gateway.zk3.dec.com; (5.65v4.0/1.3/10May95) id AA15622; Tue, 12 Sep 2000 13:13:01 -0400 Received: from zk3.dec.com (localhost [127.0.0.1]) by quasar.zk3.dec.com (8.9.3/8.8.7) with ESMTP id NAA06761; Tue, 12 Sep 2000 13:13:00 -0400 Message-Id: <39BE641C.7E694273@zk3.dec.com> Date: Tue, 12 Sep 2000 13:13:00 -0400 From: Farrell Woods Organization: UNIX Networking X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en Mime-Version: 1.0 To: michael.koller@acterna.com Cc: ietf-ppp@merit.edu Subject: Re: Negotiating MRU References: <85256958.005B9F90.00@ttcmta1-7.ttc.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 > I don't think so. What I was wondering is that at the time PPP [sic] is negotiated, > you don't know who you are going to be sending packets to. Right. That's why this isn't a PPP issue. Whatever you use for a network layer will have to deal with it. If this were IP then then the "point B" device would get back a ICMP message, probably from some device in the "N/W cloud" indicating that fragmentation is needed. It's then incumbent on the "point B" device to do that fragmenting. If things are working right then the device that can't handle the larger message size will also send back a hint as to what the largest message it can handle is. But then there's no guarantee that something else in the cloud might not impose a smaller message size. The issue is independent of PPP: what if I have a FDDI ring (where I can have >4K packets) bridged to an Ethernet (1K packets.) Each link needs to let its network layer know somehow what the largest message size is. But it's the network layer that needs to do the fragmentation and reassembly. -- Farrell From owner-ietf-ppp-outgoing@merit.edu Wed Sep 27 17:32:55 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22845 for ; Wed, 27 Sep 2000 17:32:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2DB255DDDE; Wed, 27 Sep 2000 17:31:58 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1919D5DDF7; Wed, 27 Sep 2000 17:31:58 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by segue.merit.edu (Postfix) with ESMTP id B67285DDDE for ; Wed, 27 Sep 2000 17:31:56 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA81604 for ; Wed, 27 Sep 2000 17:31:35 -0400 From: jmartz@us.ibm.com Received: from RCHASA28.RCHLAND.IBM.COM (d27ml103.rchland.ibm.com [9.5.39.110]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.93) with ESMTP id RAA48960 for ; Wed, 27 Sep 2000 17:31:54 -0400 Importance: Normal Subject: MP Protocol reject after negotiating MP? To: ietf-ppp@merit.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Wed, 27 Sep 2000 17:33:22 -0400 X-MIMETrack: Serialize by Router on d27ml103/27/M/IBM(Release 5.0.4 |June 8, 2000) at 09/27/2000 04:33:24 PM 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 Folks, I am seeing a unexpected response from an ISP when I attempt to negotiate the Multilink Protocol with it. I expect I'm dealing with an old (or just stupid) MP implementation, but want to better understand the situation. My peer calls the ISP and successfully negotiates LCP over 2 links. For both links the MRRU option is successfully negotiated on both sides of the link for both links so the ISP agrees to use multilink. However, if my peer sends an (MP encapsulated) IPCP over the 2'nd link, the peer responds with a protocol reject for the MP protocol, 0x003D. When the NCP packets are only sent over the first link, then the peer does not reject them and IPCP negotiation completes successfully. After IPCP negotiation has completed we can send MP encapsulated IP packets over both links. Do most MP implementations tolerate/expect this type of behavior from a peer? That is, is it an accepted practice to limit the sending and receiving of NCP packets to the first link of an MP bundle? P.S. I vaguely remember this topic being mentioned in James Carlson's "PPP Design & Debugging", but couldn't find it again. If someone could forward me the page number to look at, I'd appreciate it. Thanks, -john martz, 8-852-5539, jmartz@us.ibm.com IBM AS/400 TCP/IP PPP development (and stuff) From owner-ietf-ppp-outgoing@merit.edu Wed Sep 27 17:48:19 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23094 for ; Wed, 27 Sep 2000 17:48:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DED525DE4D; Wed, 27 Sep 2000 17:47:29 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CCA155DE46; Wed, 27 Sep 2000 17:47:29 -0400 (EDT) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id 873A85DE22 for ; Wed, 27 Sep 2000 17:47:27 -0400 (EDT) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.11.0/8.11.0) id e8RLlNU07142; Wed, 27 Sep 2000 17:47:23 -0400 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14802.27371.291483.62300@h006008986325.ne.mediaone.net> Date: Wed, 27 Sep 2000 17:47:23 -0400 (EDT) To: jmartz@us.ibm.com Cc: ietf-ppp@merit.edu Subject: Re: MP Protocol reject after negotiating MP? In-Reply-To: jmartz@us.ibm.com's message of 27 September 2000 17:33:22 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 jmartz@us.ibm.com writes: > My peer calls the ISP and successfully negotiates LCP over 2 links. For > both links the MRRU option is successfully negotiated on both sides of the > link for both links so the ISP agrees to use multilink. However, if my peer > sends an (MP encapsulated) IPCP over the 2'nd link, the peer responds with > a protocol reject for the MP protocol, 0x003D. When the NCP packets are > only sent over the first link, then the peer does not reject them and IPCP > negotiation completes successfully. I vaguely recall seeing this with Ascend equipment. It was over five years ago, so I might be sorely mistaken. In any event, you're right. This behavior is wrong. As soon as you reach the point where you would have gone to Network phase (authentication, if any, is done), you're in the bundle. Links in the bundle are *not* distinguished in this way. (It's also wrong in that you should never send LCP Protocol-Reject unless you're refusing to run that protocol for all time on that link. If you send it just because you're not ready for that protocol, but you might be ready later, then that itself is another bug.) > Do most MP implementations tolerate/expect this type of behavior from a > peer? That is, is it an accepted practice to limit the sending and > receiving of NCP packets to the first link of an MP bundle? Yes and no. Most implementations dial only on demand, so the first link (along with all of the NCPs) is long established by the time the second link comes up. Some can be told to dial all links at once, and, yes, these will have trouble with a misbehaving peer. > P.S. I vaguely remember this topic being mentioned in James Carlson's "PPP > Design & Debugging", but couldn't find it again. If someone could forward > me the page number to look at, I'd appreciate it. Sigh. I forgot to mention this problem, and I clearly should have. -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Sep 27 18:38:25 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24034 for ; Wed, 27 Sep 2000 18:38:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8D1D85DE57; Wed, 27 Sep 2000 18:37:56 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 78B685DE59; Wed, 27 Sep 2000 18:37:56 -0400 (EDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by segue.merit.edu (Postfix) with ESMTP id 0AC395DE57 for ; Wed, 27 Sep 2000 18:37:55 -0400 (EDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e8RMbgS21190; Wed, 27 Sep 2000 15:37:42 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma021186; Wed, 27 Sep 2000 15:37:38 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id PAA28147; Wed, 27 Sep 2000 15:37:38 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200009272237.PAA28147@bubba.whistle.com> Subject: Re: MP Protocol reject after negotiating MP? In-Reply-To: <14802.27371.291483.62300@h006008986325.ne.mediaone.net> "from James Carlson at Sep 27, 2000 05:47:23 pm" To: James Carlson Date: Wed, 27 Sep 2000 15:37:22 -0700 (PDT) Cc: jmartz@us.ibm.com, ietf-ppp@merit.edu X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit James Carlson writes: > > My peer calls the ISP and successfully negotiates LCP over 2 links. For > > both links the MRRU option is successfully negotiated on both sides of the > > link for both links so the ISP agrees to use multilink. However, if my peer > > sends an (MP encapsulated) IPCP over the 2'nd link, the peer responds with > > a protocol reject for the MP protocol, 0x003D. When the NCP packets are > > only sent over the first link, then the peer does not reject them and IPCP > > negotiation completes successfully. > > I vaguely recall seeing this with Ascend equipment. It was over five > years ago, so I might be sorely mistaken. In any event, you're right. > This behavior is wrong. As soon as you reach the point where you > would have gone to Network phase (authentication, if any, is done), > you're in the bundle. Links in the bundle are *not* distinguished in > this way. I can independently confirm this behavior; we first reported it several months ago. I've seen it with Ascend/Lucent equipment only. As far as I know, they haven't fixed this bug yet. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com