From owner-ietf-ppp-outgoing@merit.edu Wed Apr 5 11:08:41 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 LAA11303 for ; Wed, 5 Apr 2000 11:08:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4F2DB5DE3A; Wed, 5 Apr 2000 11:07:45 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3D4A55DE2D; Wed, 5 Apr 2000 11:07:45 -0400 (EDT) Received: from fsnt.future.futusoft.com (unknown [203.197.140.35]) by segue.merit.edu (Postfix) with ESMTP id 343495DE25 for ; Wed, 5 Apr 2000 11:07:38 -0400 (EDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 05 Apr 2000 20:36:13 +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 UAA19039 for ; Wed, 5 Apr 2000 20:15:34 +0530 Received: by localhost with Microsoft MAPI; Wed, 5 Apr 2000 20:24:47 +0530 Message-Id: <01BF9F3C.FCB2E5A0.mania@future.futsoft.com> From: Manikandan A Reply-To: "mania@future.futsoft.com" To: "'ietf-ppp@merit.edu'" Subject: SMI-V2 MIB Date: Wed, 5 Apr 2000 20:24:46 +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, Are there any equivalent SMI-V2 MIB definition RFC's (or) drafts available for SMI-V1 MIB definitions mentioned in RFC 1471,1472 and 1473 ? Thanks & Regards Mani. From owner-ietf-ppp-outgoing@merit.edu Sat Apr 8 19:14:21 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 TAA17548 for ; Sat, 8 Apr 2000 19:14:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D7D5B5DD9F; Sat, 8 Apr 2000 19:13:40 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B80885DDA0; Sat, 8 Apr 2000 19:13:40 -0400 (EDT) Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by segue.merit.edu (Postfix) with ESMTP id D48535DD9F for ; Sat, 8 Apr 2000 19:13:38 -0400 (EDT) Received: from rhino (rhino.cisco.com [172.20.9.57]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id QAA02877; Sat, 8 Apr 2000 16:15:17 -0700 (PDT) Received: from p7020-img-nt.cisco.com (rtp-dial-2-77.cisco.com [10.83.96.77]) by rhino (SMI-8.6/CISCO.WS.1.1) with ESMTP id QAA02206; Sat, 8 Apr 2000 16:18:39 -0700 Message-Id: <4.3.1.2.20000408070830.00e1c860@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 08 Apr 2000 08:09:25 -0400 To: Mitsuru.Higashiyama@yy.anritsu.co.jp From: Fred Baker Subject: Re: [Fwd: Should we update BCP draft ?] Cc: ietf-ppp@merit.edu In-Reply-To: <38EE0BC9.D99184A9@yy.anritsu.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu OK, I'm back into some semblance of time-zone sanity now. I'm within 2500 miles of home :^) > It is conceivable that a network manager might wish to inhibit the > exchange of BPDUs on a link in order to logically divide two regions > into separate Spanning Trees with different Roots (and potentially > different Spanning Tree implementations or algorithms). In order to > do that, he should configure both ends to not exchange BPDUs on a > link. An implementation that does not support any spanning tree > protocol MUST silently discard any received IEEE 802.1D BPDU packets. > > If a bridge is connected to an old BCP bridge [10], the other bridge > cannot operate according to this specification. Options are therefore > to decide that: > > (a) If the bridge wants to terminate the connection, it sends a > Terminate-Request and terminate the connection. > (b) If the bridge wants to run the connection but not receive old > BPDUs, its only option is to run without spanning tree on the > link at all, which is dangerous. It should send NULL Spanning > Tree-Protocol option and advise the network administration > that it has done so. > (c) If the bridge chooses to be entirely backward compatible, it > sends Configure-Ack and operates in the manner described in > Appendix A. > > Implementations SHOULD implement a backward compatibility mode. To be perfectly honest, I think Ewart is being a bit pedantic. I don't see what part of this is hard to understand. I think he's saying "your state machine is not completely specified, and I want you to completely specify it." We said the implementation SHOULD be backward compatible. That means it SHOULD be able to do both protocols (it should be able to masquerade as an old-model device and be indistinguishable from such a device when it is doing so, either due to configuration or to the temporary necessity of talking to an old-model peer until it is upgraded), but we could imagine cases where that wasn't an absolute requirement. We said that it should be able to choose to not run spanning tree on a link for some good reasons, and identified procedures to say that and do that. We also opined that this is inherently dangerous, and should be noted to network management in case it turns out to be problematic. We also indicate what it means to configure-accept and to terminate. What we have not specified is how to configure-nak, which is implicit in PPP, and can only mean "determine whether your implementation and configuration can run with the choice indicated by your peer; if so, repeat the configure-request using the peer's choice of parameter, and if not take an implementation-and-configuration-dependent choice either of terminating the connection or repeating the configuration-request with some other value." Since that is implicit in PPP, I don't think we need to say that. And, as Ewart points out, we have not specified the behavior in the case of a configure-reject, which can only mean "I don't understand this option, don't send it to me." We have, I think, two choices: assert that configure-rejecting both the new and the old STP options forces the device bringing up the link to send neither option, and it can only imply that no spanning tree protocol will be used on the link. Therefore, consider the case conceptually equivalent to having configure-rejected with the value NULL. Don't send the option (it was indeed a configure-reject), but log the event and don't use spanning tree. The other option is to say "he's illegal", terminate the connection, and log the reason you did so. So either we pick one of the options, or we let the network manager configure it. I think configuration of this is micromanagement; it would be better for the working group to pick one. I think the guiding argument should be towards robustness. The link exchange is more robust if it is able to do the full negotiation (we don't have to guess), and in the event we have to take some default action, the network is more robust if either spanning tree is enabled on every link or the link is down. Defaulting towards leaving the link able to carry traffic but not detect and remove loops is (he carefully and loudly clears his throat) not robust. So I think the only sane default behavior if the peer configure-rejects the option is to terminate the link. He did something he shouldn't have according to the specification, and allowing him to continue is dangerous to the network. Better to take it down and highlight the problem than to pass traffic and give the network manager a bad day trying to figure out what happened. So if we're going to add anything, I think we should add something like: "In the event that both the new Management-Inline Option and the Spanning-Tree-Protocol-Configuration Option are configure-rejected, indicating that the peer implements no spanning tree protocol at all and doesn't understand the options, it is an incomplete implementation. For safety reasons the system should cease attempting to configure bridging, and log the fact. If the peer was configure- rejecting the options in order to disable spanning tree entirely, it understood the option but could not within its configuration comply. It should have sent the Spanning-Tree-Protocol-Configuration Option with the value NULL." An implementation which only supports the new protocol is therefore not implementing a backward compatibility mode (violating the SHOULD, which is acceptable if the reason is clearly stated to the purchaser of the equipment), implements and negotiates management-inline, and if that is configure-rejected (his peer is an older implementation) either (if so configured) negotiates to run naked, or by default takes down the link. A backward compatible implementation would in the same case simply switch to its compatibility mode. >579,583c579,583 >< (b) If the bridge wants to run the connection but not receive old >< BPDUs, its only option is to run without spanning tree on the >< link at all, which is dangerous. It should Configure-Reject >< the option and advise the network administration that it has >< done so. >--- > > (b) If the bridge wants to run the connection but not receive old > > BPDUs, its only option is to run without spanning tree on the > > link at all, which is dangerous. It should send NULL Spanning ^ It should send the NULL Spanning... > > Tree-Protocol option and advise the network administration > > that it has done so. I think your other changes are fine. The working group should decide whether they want to add the above paragraph, and in any event I consider the document complete. From owner-ietf-ppp-outgoing@merit.edu Mon Apr 10 15:08:56 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 PAA00620 for ; Mon, 10 Apr 2000 15:08:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EBAF55DDCA; Mon, 10 Apr 2000 15:08:22 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D9EDC5DDC6; Mon, 10 Apr 2000 15:08:22 -0400 (EDT) Received: from poseidon.broadpac.com (adsl-63-199-87-6.dsl.snfc21.pacbell.net [63.199.87.6]) by segue.merit.edu (Postfix) with ESMTP id CCAA75DDB3 for ; Mon, 10 Apr 2000 15:08:20 -0400 (EDT) Received: by poseidon.broadpac.com (8.9.1/8.9.1) with SMTP id MAA23673 for ; Mon, 10 Apr 2000 12:10:05 -0700 (PDT) Message-ID: <016d01bfa320$33469d50$7164a8c0@ruchirnt> From: "Ruchir" To: Subject: ppp-ipcp mib Date: Mon, 10 Apr 2000 12:08:48 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_016A_01BFA2E5.86BFF200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 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 This is a multi-part message in MIME format. ------=_NextPart_000_016A_01BFA2E5.86BFF200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Why arent there any counters in the ppp-ipcp MIB (rfc 1473)? also = there's no way to display the IP addresses which are sending and = recieving the data? Ruchir ------=_NextPart_000_016A_01BFA2E5.86BFF200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
Why arent there any counters in the = ppp-ipcp MIB=20 (rfc 1473)? also there's no way to display the IP addresses which are = sending=20 and recieving the data?
 
Ruchir
------=_NextPart_000_016A_01BFA2E5.86BFF200-- From owner-ietf-ppp-outgoing@merit.edu Thu Apr 13 12:41: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 MAA07240 for ; Thu, 13 Apr 2000 12:41:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2461D5DE00; Thu, 13 Apr 2000 12:40:43 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0C7CF5DD96; Thu, 13 Apr 2000 12:40:42 -0400 (EDT) Received: from poseidon.broadpac.com (adsl-63-199-87-6.dsl.snfc21.pacbell.net [63.199.87.6]) by segue.merit.edu (Postfix) with ESMTP id 6FC605DD96 for ; Thu, 13 Apr 2000 12:40:39 -0400 (EDT) Received: by poseidon.broadpac.com (8.9.1/8.9.1) with SMTP id JAA07321 for ; Thu, 13 Apr 2000 09:42:26 -0700 (PDT) Message-ID: <024f01bfa567$145d0c00$7164a8c0@ruchirnt> From: "Ruchir" To: Subject: MLPPP MIB Date: Thu, 13 Apr 2000 09:41:12 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_024C_01BFA52C.67BC9720" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 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 This is a multi-part message in MIME format. ------=_NextPart_000_024C_01BFA52C.67BC9720 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Probably this is the wrong list to ask this question, but are there = any drafts or RFCs on MLPPP MIB(s) ? Ruchir ------=_NextPart_000_024C_01BFA52C.67BC9720 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
    Probably this is the = wrong list=20 to ask this question, but are there any drafts or RFCs on MLPPP MIB(s)=20 ?
 
Ruchir
------=_NextPart_000_024C_01BFA52C.67BC9720-- From owner-ietf-ppp-outgoing@merit.edu Sun Apr 16 11:38: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 LAA08454 for ; Sun, 16 Apr 2000 11:38:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D36145DD91; Sun, 16 Apr 2000 11:38:23 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C03715DD98; Sun, 16 Apr 2000 11:38:23 -0400 (EDT) Received: from cliff.extant.net (cliff.extant.net [12.17.197.35]) by segue.merit.edu (Postfix) with ESMTP id 28A585DD91 for ; Sun, 16 Apr 2000 11:38:22 -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 H315F0TJ; Sun, 16 Apr 2000 09:38:20 -0600 Message-Id: <4.3.1.2.20000416113614.00df6760@127.0.0.1> X-Sender: kfox@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 16 Apr 2000 11:38:10 -0400 To: Fred Baker , Mitsuru.Higashiyama@yy.anritsu.co.jp From: Karl Fox Subject: Re: [Fwd: Should we update BCP draft ?] Cc: ietf-ppp@merit.edu In-Reply-To: <4.3.1.2.20000408070830.00e1c860@flipper.cisco.com> References: <38EE0BC9.D99184A9@yy.anritsu.co.jp> 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 Any comments on Fred's suggested changes? They make sense to me; what say the rest of you? Karl At 08:09 AM 4/8/00 -0400, Fred Baker wrote: >So if we're going to add anything, I think we should add something like: > > "In the event that both the new Management-Inline Option and the > Spanning-Tree-Protocol-Configuration Option are configure-rejected, > indicating that the peer implements no spanning tree protocol at > all and doesn't understand the options, it is an incomplete > implementation. For safety reasons the system should cease attempting > to configure bridging, and log the fact. If the peer was configure- > rejecting the options in order to disable spanning tree entirely, it > understood the option but could not within its configuration comply. It > should have sent the Spanning-Tree-Protocol-Configuration Option with > the value NULL." ... >I think your other changes are fine. The working group should decide whether they want to add the above paragraph, and in any event I consider the document complete. Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Fri Apr 28 02:28:09 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 CAA25096 for ; Fri, 28 Apr 2000 02:28:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A59DC5DDAC; Fri, 28 Apr 2000 02:27:40 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9213A5DDBE; Fri, 28 Apr 2000 02:27:40 -0400 (EDT) Received: from ns.anritsu.co.jp (ns.anritsu.co.jp [133.236.48.2]) by segue.merit.edu (Postfix) with ESMTP id 808E35DDAC for ; Fri, 28 Apr 2000 02:27:37 -0400 (EDT) Received: from gatekeeper.noc.anritsu.co.jp (root@gatekeeper.noc.anritsu.co.jp [133.236.19.3]) by ns.anritsu.co.jp (8.9.3+3.1W/3.7W/19991218.23/C) with ESMTP id PAA19959 for ; Fri, 28 Apr 2000 15:27:36 +0900 (JST) (envelope-from Mitsuru.Higashiyama@yy.anritsu.co.jp) Received: (from root@localhost) by gatekeeper.noc.anritsu.co.jp (8.8.8+2.7Wbeta7/CF-3.5Wpl7/19991218.23/N) id PAA04831; Fri, 28 Apr 2000 15:27:32 +0900 (JST) Received: from mail0.cr.anritsu.co.jp (mail0.cr.anritsu.co.jp [172.16.32.22]) by gatekeeper.noc.anritsu.co.jp (8.8.8+2.7Wbeta7/CF-3.5Wpl7/19991218.23/C) with ESMTP id PAA04823 for ; Fri, 28 Apr 2000 15:27:31 +0900 (JST) Received: from yy.anritsu.co.jp ([172.16.97.52]) by mail0.cr.anritsu.co.jp (Netscape Messaging Server 3.54) with ESMTP id AAAA06; Fri, 28 Apr 2000 15:30:44 +0900 Message-ID: <39092F4E.BB560D39@yy.anritsu.co.jp> Date: Fri, 28 Apr 2000 15:27:26 +0900 From: Mitsuru Higashiyama Reply-To: Mitsuru.Higashiyama@yy.anritsu.co.jp Organization: Anritsu Corp. X-Mailer: Mozilla 4.5 [ja] (Win98; I) X-Accept-Language: ja MIME-Version: 1.0 To: Fred Baker Cc: ietf-ppp@merit.edu, mitsuru@ca2.so-net.ne.jp Subject: Re: [Fwd: Should we update BCP draft ?] References: <4.3.1.2.20000408070830.00e1c860@flipper.cisco.com> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hello Fred, I have added your addional description into the section 4.1.4. And put the (b) option back to Configure-Reject operation rather than NULL STP option. If every thing is O.K. I will issue the new draft and post it . Thanks, Mitsuru 4.1.4. Separation of Spanning Tree Domains It is conceivable that a network manager might wish to inhibit the exchange of BPDUs on a link in order to logically divide two regions into separate Spanning Trees with different Roots (and potentially different Spanning Tree implementations or algorithms). In order to do that, he should configure both ends to not exchange BPDUs on a link. An implementation that does not support any spanning tree protocol MUST silently discard any received IEEE 802.1D BPDU packets. If a bridge is connected to an old BCP bridge [10], the other bridge cannot operate according to this specification. Options are therefore to decide that: (a) If the bridge wants to terminate the connection, it sends a Terminate-Request and terminate the connection. (b) If the bridge wants to run the connection but not receive old BPDUs, its only option is to run without spanning tree on the link at all, which is dangerous. It should Configure-Reject the option and advise the network administration that it has done so. (c) If the bridge chooses to be entirely backward compatible, it sends Configure-Ack and operates in the manner described in Appendix A. In the event that both the new Management-Inline Option and the Spanning-Tree-Protocol-Configuration Option are configure-rejected, indicating that the peer implements no spanning tree protocol at all and doesn't understand the options, it is an incomplete implementation. For safety reasons the system should cease attempting to configure bridging, and log the fact. If the peer was configure-rejecting the options in order to disable spanning tree entirely, it understood the option but could not within its configuration comply. It should have sent the Spanning-Tree-Protocol-Configuration Option with the value NULL. Implementations SHOULD implement a backward compatibility mode. Fred Baker wrote: > > OK, I'm back into some semblance of time-zone sanity now. I'm within 2500 > miles of home :^) > > > It is conceivable that a network manager might wish to inhibit the > > exchange of BPDUs on a link in order to logically divide two regions > > into separate Spanning Trees with different Roots (and potentially > > different Spanning Tree implementations or algorithms). In order to > > do that, he should configure both ends to not exchange BPDUs on a > > link. An implementation that does not support any spanning tree > > protocol MUST silently discard any received IEEE 802.1D BPDU packets. > > > > If a bridge is connected to an old BCP bridge [10], the other bridge > > cannot operate according to this specification. Options are therefore > > to decide that: > > > > (a) If the bridge wants to terminate the connection, it sends a > > Terminate-Request and terminate the connection. > > (b) If the bridge wants to run the connection but not receive old > > BPDUs, its only option is to run without spanning tree on the > > link at all, which is dangerous. It should send NULL Spanning > > Tree-Protocol option and advise the network administration > > that it has done so. > > (c) If the bridge chooses to be entirely backward compatible, it > > sends Configure-Ack and operates in the manner described in > > Appendix A. > > > > Implementations SHOULD implement a backward compatibility mode. > > To be perfectly honest, I think Ewart is being a bit pedantic. I don't see > what part of this is hard to understand. I think he's saying "your state > machine is not completely specified, and I want you to completely specify it." > > We said the implementation SHOULD be backward compatible. That means it > SHOULD be able to do both protocols (it should be able to masquerade as an > old-model device and be indistinguishable from such a device when it is > doing so, either due to configuration or to the temporary necessity of > talking to an old-model peer until it is upgraded), but we could imagine > cases where that wasn't an absolute requirement. > > We said that it should be able to choose to not run spanning tree on a link > for some good reasons, and identified procedures to say that and do that. > We also opined that this is inherently dangerous, and should be noted to > network management in case it turns out to be problematic. We also indicate > what it means to configure-accept and to terminate. > > What we have not specified is how to configure-nak, which is implicit in > PPP, and can only mean "determine whether your implementation and > configuration can run with the choice indicated by your peer; if so, repeat > the configure-request using the peer's choice of parameter, and if not take > an implementation-and-configuration-dependent choice either of terminating > the connection or repeating the configuration-request with some other > value." Since that is implicit in PPP, I don't think we need to say that. > > And, as Ewart points out, we have not specified the behavior in the case of > a configure-reject, which can only mean "I don't understand this option, > don't send it to me." We have, I think, two choices: assert that > configure-rejecting both the new and the old STP options forces the device > bringing up the link to send neither option, and it can only imply that no > spanning tree protocol will be used on the link. Therefore, consider the > case conceptually equivalent to having configure-rejected with the value > NULL. Don't send the option (it was indeed a configure-reject), but log the > event and don't use spanning tree. The other option is to say "he's > illegal", terminate the connection, and log the reason you did so. > > So either we pick one of the options, or we let the network manager > configure it. I think configuration of this is micromanagement; it would be > better for the working group to pick one. I think the guiding argument > should be towards robustness. > > The link exchange is more robust if it is able to do the full negotiation > (we don't have to guess), and in the event we have to take some default > action, the network is more robust if either spanning tree is enabled on > every link or the link is down. Defaulting towards leaving the link able to > carry traffic but not detect and remove loops is (he carefully and loudly > clears his throat) not robust. So I think the only sane default behavior if > the peer configure-rejects the option is to terminate the link. He did > something he shouldn't have according to the specification, and allowing > him to continue is dangerous to the network. Better to take it down and > highlight the problem than to pass traffic and give the network manager a > bad day trying to figure out what happened. > > So if we're going to add anything, I think we should add something like: > > "In the event that both the new Management-Inline Option and the > Spanning-Tree-Protocol-Configuration Option are configure-rejected, > indicating that the peer implements no spanning tree protocol at > all and doesn't understand the options, it is an incomplete > implementation. For safety reasons the system should cease attempting > to configure bridging, and log the fact. If the peer was configure- > rejecting the options in order to disable spanning tree entirely, it > understood the option but could not within its configuration comply. It > should have sent the Spanning-Tree-Protocol-Configuration Option with > the value NULL." > > An implementation which only supports the new protocol is therefore not > implementing a backward compatibility mode (violating the SHOULD, which is > acceptable if the reason is clearly stated to the purchaser of the > equipment), implements and negotiates management-inline, and if that is > configure-rejected (his peer is an older implementation) either (if so > configured) negotiates to run naked, or by default takes down the link. A > backward compatible implementation would in the same case simply switch to > its compatibility mode. > > >579,583c579,583 > >< (b) If the bridge wants to run the connection but not receive old > >< BPDUs, its only option is to run without spanning tree on the > >< link at all, which is dangerous. It should Configure-Reject > >< the option and advise the network administration that it has > >< done so. > >--- > > > (b) If the bridge wants to run the connection but not receive old > > > BPDUs, its only option is to run without spanning tree on the > > > link at all, which is dangerous. It should send NULL Spanning > ^ > It should send the NULL Spanning... > > > > Tree-Protocol option and advise the network administration > > > that it has done so. > > I think your other changes are fine. The working group should decide > whether they want to add the above paragraph, and in any event I consider > the document complete. -- Mitsuru Higashiyama ANRITSU CORPORATION Systems Development Department, Information & Network Division Telephone Office +81 462 96 6625 Fax +81 462 25 8387 From owner-ietf-ppp-outgoing@merit.edu Fri Apr 28 15:21:02 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 PAA09883 for ; Fri, 28 Apr 2000 15:21:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 070045DE0D; Fri, 28 Apr 2000 15:20:37 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EAA3B5DE0B; Fri, 28 Apr 2000 15:20:36 -0400 (EDT) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by segue.merit.edu (Postfix) with ESMTP id 23FE55DE09 for ; Fri, 28 Apr 2000 15:20:35 -0400 (EDT) Received: from rhino (rhino.cisco.com [172.20.9.57]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id MAA11306; Fri, 28 Apr 2000 12:17:15 -0700 (PDT) Received: from p7020-img-nt.cisco.com (fred-hm-dhcp1.cisco.com [171.69.128.116]) by rhino (SMI-8.6/CISCO.WS.1.1) with ESMTP id MAA06460; Fri, 28 Apr 2000 12:24:54 -0700 Message-Id: <4.3.1.2.20000428121628.02ddf370@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 28 Apr 2000 12:16:50 -0700 To: Mitsuru.Higashiyama@yy.anritsu.co.jp From: Fred Baker Subject: Re: [Fwd: Should we update BCP draft ?] Cc: ietf-ppp@merit.edu, mitsuru@ca2.so-net.ne.jp In-Reply-To: <39092F4E.BB560D39@yy.anritsu.co.jp> References: <4.3.1.2.20000408070830.00e1c860@flipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 03:27 PM 4/28/00 +0900, Mitsuru Higashiyama wrote: >If every thing is O.K. I will issue the new draft >and post it . please do, and have Karl forward it to the IESG From owner-ietf-ppp-outgoing@merit.edu Fri Apr 28 17:28:14 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 RAA11773 for ; Fri, 28 Apr 2000 17:28:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2F5E05E096; Fri, 28 Apr 2000 17:26:05 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9E75D5E09C; Fri, 28 Apr 2000 17:26:04 -0400 (EDT) Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by segue.merit.edu (Postfix) with ESMTP id 721E05E096 for ; Fri, 28 Apr 2000 17:25:54 -0400 (EDT) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id OAA77096 for ietf-ppp@merit.edu; Fri, 28 Apr 2000 14:25:49 -0700 (PDT) From: Archie Cobbs Message-Id: <200004282125.OAA77096@bubba.whistle.com> Subject: IPCP within MP? To: ietf-ppp@merit.edu Date: Fri, 28 Apr 2000 14:25:49 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 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 have encountered some equipment that seems to have a bug, and I just wanted to confirm with the list that it is in fact a bug, or else what my misunderstanding is.. What happens is this: 1. A 2 B-channel ISDN multi-link PPP connection is made. 2. Both links reach the LCP NETWORK phase; Link #1 comes up first, then link #2. 3. The peer sends me an IPCP Configure-Request as a single, complete multilink encapsulated packet on link #1. 3. My side attempts to send an IPCP Configure-Request that's split into two parts and sent as two multi-link fragments over the two links. 4. The remote side responds with an LCP Protocol-Reject of protocol 0x003d (the multilink protocol) on link #2, and ignores my IPCP Configure-Request. The protocol reject contains enough of the packet to show that it's rejecting one of the IPCP Configure-Request MP fragments. 5. Because the peer never hears my IPCP Configure-Request's the connection never succeeds. 6. If I alter my code to not fragment my IPCP Configure-Request but send it as a complete packet, things seem to work fine. I'd be interested to hear if anyone else has encountered this behavior... or if you are the vendor and know about this problem. Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-ietf-ppp-outgoing@merit.edu Fri Apr 28 17:42:28 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 RAA12291 for ; Fri, 28 Apr 2000 17:42:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1F7895E1AF; Fri, 28 Apr 2000 17:39:42 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C58CF5E111; Fri, 28 Apr 2000 17:39:30 -0400 (EDT) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id 9A8CD5DFA0 for ; Fri, 28 Apr 2000 17:37:09 -0400 (EDT) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.9.3/8.9.3) id RAA07256; Fri, 28 Apr 2000 17:37:05 -0400 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14602.1153.179604.903801@h006008986325.ne.mediaone.net> Date: Fri, 28 Apr 2000 17:37:05 -0400 (EDT) To: Archie Cobbs Cc: ietf-ppp@merit.edu Subject: Re: IPCP within MP? In-Reply-To: Archie Cobbs's message of 28 April 2000 14:25:49 References: <200004282125.OAA77096@bubba.whistle.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 Archie Cobbs writes: > 2. Both links reach the LCP NETWORK phase; Link #1 comes > up first, then link #2. I assume that the MP MRRU is set on both links, MP Endpoint-Discriminators and Short-Sequence-Number options match, and MRUs are the same. > 3. My side attempts to send an IPCP Configure-Request that's > split into two parts and sent as two multi-link fragments > over the two links. No problem with that. (I don't think I've seen an implementation yet that does this, though ...) > 4. The remote side responds with an LCP Protocol-Reject > of protocol 0x003d (the multilink protocol) on link #2, > and ignores my IPCP Configure-Request. The protocol > reject contains enough of the packet to show that it's > rejecting one of the IPCP Configure-Request MP fragments. Assuming that the second link is actually configured to run MP, that's a rather horrible bug. -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Fri Apr 28 18:31:35 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 SAA13387 for ; Fri, 28 Apr 2000 18:31:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EF2A75DED8; Fri, 28 Apr 2000 18:22:31 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1FE605E0BB; Fri, 28 Apr 2000 18:13:08 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 3FC1A5DF7F for ; Fri, 28 Apr 2000 18:00:54 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id QAA23004 for ietf-ppp@merit.edu env-from ; Fri, 28 Apr 2000 16:00:53 -0600 (MDT) Date: Fri, 28 Apr 2000 16:00:53 -0600 (MDT) From: Vernon Schryver Message-Id: <200004282200.QAA23004@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: IPCP within MP? Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: James Carlson > To: Archie Cobbs > ... > > 3. My side attempts to send an IPCP Configure-Request that's > > split into two parts and sent as two multi-link fragments > > over the two links. > > No problem with that. (I don't think I've seen an implementation yet > that does this, though ...) > > > 4. The remote side responds with an LCP Protocol-Reject > > of protocol 0x003d (the multilink protocol) on link #2, > > and ignores my IPCP Configure-Request. The protocol > > reject contains enough of the packet to show that it's > > rejecting one of the IPCP Configure-Request MP fragments. > > Assuming that the second link is actually configured to run MP, that's > a rather horrible bug. Yes, #4 indicates serious problems in the peer, but ... while #3 doesn't violate the standard, it does violate the dictum to be conservative in what you send. Given how many PPP implementations are put together, fragmenting any PPP control packet is asking for trouble. Consider also that IPCP Configure-Requests are necessarily very tiny, and that fragmenting tinygrams is a bad idea on performance grounds. Vernon Schryver vjs@rhyolite.com