From owner-ietf-ppp@merit.edu Wed Apr 2 10:32:51 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13961 for ; Wed, 2 Apr 2003 10:32:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7EEC49121B; Wed, 2 Apr 2003 10:35:04 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 54FF29121C; Wed, 2 Apr 2003 10:35:04 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 449899121B for ; Wed, 2 Apr 2003 10:35:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2AA135E021; Wed, 2 Apr 2003 10:35:03 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by segue.merit.edu (Postfix) with ESMTP id A72275E01C for ; Wed, 2 Apr 2003 10:35:02 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h32FYuEu068794; Wed, 2 Apr 2003 10:34:56 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-216-193.mts.ibm.com [9.65.216.193]) by westrelay01.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h32FYtqS098832; Wed, 2 Apr 2003 08:34:56 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h32FXsY06719; Wed, 2 Apr 2003 10:33:54 -0500 Message-Id: <200304021533.h32FXsY06719@cichlid.adsl.duke.edu> To: James Carlson Cc: ietf-ppp@merit.edu, Bert Wijnen Subject: PPP question on draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt Date: Wed, 02 Apr 2003 10:33:54 -0500 From: Thomas Narten Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi James. You reviewed parts of this (and a related) document a long time ago (see below). A question I have for the PPP community is whether the current version of the lmp-test-sonet ID is acceptable from a PPP perspective. Comments? Thomas From: James Carlson [james.d.carlson@east.sun.com] Sent: Monday, October 01, 2001 8:00 AM To: Jonathan.Sadler@tellabs.com Cc: ietf-ppp@merit.edu Subject: Re: Proposed use of PPP in the OIF UNI Jonathan Sadler writes: > I have some concerns regarding the proposed configuration of PPP for the > OIF UNI that I would like the PPP working group to look at. > > In the OIF UNI (http://www.oiforum.com/public/documents/UNI_1.0.pdf), > Section 6.1 page 22 defines the configuration of PPP on the SONET DCC as > follows: > > "...IP packets are encapsulated using PPP in HDLC like framing as per > RFC1662. ... only PPP encapsulation must be used with no other PPP > procedures (i.e. LCP and NCP need not be executed)." That's absurd on multiple levels. You can't claim to be using PPP if you're just using the framing, and I frankly don't see how any level of interoperability could be hoped for with the phrase "need not be executed." What happens when one vendor chooses to implement the existing IETF Standards Track protocols and another does not? > Is PPP without LCP/NCP negotiation considered a standard implementation > by the IETF? No. It's not PPP. It's effectively SLIP, albeit with different framing. Of course, consenting peers may do anything they like, including omitting the necessary (and useful) RFC 1661 LCP and RFC 1332 IPCP negotiation for no apparent reason. I see no point to doing so, but there's no law prohibiting it. (At a wild guess, I would assume that PPP negotiation is viewed as "unnecessary overhead." I would submit that [1] a useful implementation of the OIF signaling has such significant complexity that PPP is effectively a drop in the bucket and [2] source code that implements PPP is freely available.) > RFC 1661 (which is never referenced by the OIF UNI > document) seems to have strong words preventing this. Right. > It should be noted that the OIF has chosen this in part to facilitate > the misconnection detection feature specified in LMP > (draft-ietf-ccamp-lmp-00.txt, and OIF UNI section 8). Specifically, the > test messages for LMP are defined to be carried within IP PDUs on the > data link. Because successful LCP/NCP negotiation requires a correctly > connected full-duplex link, these IP PDUs be prevented from being sent > on a misconnected link. As a result, LMP would not have a chance to > detect this case. I don't think that's true at all. There are certainly possible failure modes in which PPP establishes normally, but IP-based protocols (such as LMP) don't work at all. For instance, the peer might not be running LMP. Having IPCP properly negotiated does not mean that any applications are available or running; it merely means that IP datagrams are permitted on the link. > While the current LMP solution has this problem, other solutions may > not. For example, the test messages could be carried within an LCP > option (similar to the Identification option specified in RFC 1570). I certainly wouldn't want to see that done. (Perhaps LCP Echo-Request would be useful *in addition* to other higher-level test messages, but they're no substitute.) > Please provide the feeling of the working group on this issue. Review of these documents isn't required here, but I'd hope that the OIF would be interested enough in having the relevant portions reviewed that they'd approach us (or the IESG) for such a review. -- James Carlson, Solaris Networking 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 From owner-ietf-ppp@merit.edu Wed Apr 2 11:28:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16183 for ; Wed, 2 Apr 2003 11:28:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EB6D991211; Wed, 2 Apr 2003 11:30:00 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB6269121F; Wed, 2 Apr 2003 11:29:59 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C361391211 for ; Wed, 2 Apr 2003 11:29:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id AF5FE5E00D; Wed, 2 Apr 2003 11:29:58 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id 2E1455E008 for ; Wed, 2 Apr 2003 11:29:58 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19203; Wed, 2 Apr 2003 09:29:57 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h32GTu9P014036; Wed, 2 Apr 2003 11:29:56 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.8+Sun/8.12.8) with ESMTP id h32GTuK3039187; Wed, 2 Apr 2003 11:29:56 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.8+Sun/8.12.8/Submit) id h32GTumM039184; Wed, 2 Apr 2003 11:29:56 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16011.4100.405004.162857@gargle.gargle.HOWL> Date: Wed, 2 Apr 2003 11:29:56 -0500 From: James Carlson To: Thomas Narten Cc: ietf-ppp@merit.edu, Bert Wijnen Subject: Re: PPP question on draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt In-Reply-To: Thomas Narten's message of 2 April 2003 10:33:54 References: <200304021533.h32FXsY06719@cichlid.adsl.duke.edu> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Thomas Narten writes: > You reviewed parts of this (and a related) document a long time ago > (see below). A question I have for the PPP community is whether the > current version of the lmp-test-sonet ID is acceptable from a PPP > perspective. This draft (draft-ietf-ccamp-lmp-test-sonet-sdh-02) is a little hard to interpret, but I read it as using the LMP option to run the test messages without UDP/IP and instead over raw HDLC framing. In that case, I see no PPP-related issues. That's not the same as saying that I think this is necessarily a good idea -- I don't, because I think being able to run SNMP, OSI, and other protocols alongside LMP is valuable, and a multiplexing layer such as that provided by PPP would allow you that flexibility at fairly low cost. Retrofitting equipment that uses this null encapsulation to work correctly if you decide to do any multiplexing in the future will be highly problematic. The reference to RFC 1662 is odd and probably erroneous, since that document describes how PPP uses HDLC framing. The draft should probably reference ISO/IEC 3309 directly instead. If the reference is actually correct, then the protocol defined here will need a PPP protocol number for section 3.1 of RFC 1662, and I think we're back where we started ("using PPP without benefit of negotiation"). -- James Carlson, Solaris Networking 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 From owner-ietf-ppp@merit.edu Wed Apr 2 13:24:20 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21872 for ; Wed, 2 Apr 2003 13:24:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DD85C912BD; Wed, 2 Apr 2003 13:25:37 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD29691222; Wed, 2 Apr 2003 13:25:37 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 56EE6912BD for ; Wed, 2 Apr 2003 13:25:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 23C165E02D; Wed, 2 Apr 2003 13:25:36 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by segue.merit.edu (Postfix) with ESMTP id DADBA5E02C for ; Wed, 2 Apr 2003 13:25:35 -0500 (EST) Received: from mailw02.hq.tellabs.com (mailw02.hq.tellabs.com [172.23.207.12]) by mx4.tellabs.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ACV70647; Wed, 2 Apr 2003 12:25:22 -0600 (CST) Received: from tellabs.com (dhcp-172-23-111-45.hq.tellabs.com [172.23.111.45]) by mailw02.hq.tellabs.com with ESMTP (8.9.3 (PHNE_24419)/8.7.1) id MAA05565; Wed, 2 Apr 2003 12:25:23 -0600 (CST) Message-ID: <3E8B2B12.EE9ADE37@tellabs.com> Date: Wed, 02 Apr 2003 12:25:22 -0600 From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: James Carlson Cc: Thomas Narten , ietf-ppp@merit.edu, Bert Wijnen Subject: Re: PPP question on draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mirapoint-Sig: mx4.tellabs.com Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Some clarification: In section 3.1, the draft (draft-ietf-ccamp-lmp-test-sonet-sdh-02) states "the test message is sent as defined in [LMP]" (draft-ietf-ccamp-lmp-08) when using SONET/SDH's Section/RS DCC and Line/MS DCC to carry a test message. Section 12.5.6 of the referenced LMP draft states: "The Test message is transmitted over the data link and is used to verify its physical connectivity. Unless explicitly stated, these messages MUST be transmitted over UDP like all other LMP messages. The format of the Test messages is as follows: ::= " The upshot is the test messges are being carried on the SONET/SDH DCC in a UDP/IP packet encapsulated "using bit-oriented HDLC framing format [RFC 1662] (sic)". The reference to RFC 1662 was done specifically to avoid the LCP/NCP negotiations required in RFC 1661. These two details (test messages using of UDP/IP, and non-use of LCP/NCP negotiation) have been confirmed in private communications with the authors. Jonathan Sadler PS. Its interesting to note: - the main purpose of LMP is to manage link operations* out-of-band - PPP does a good job of managing link operations in-band - LMP has not been widely implemented, and interoperability has not been widely demonstrated - PPP has been widely implemented, and shown to be widely interoperable Do we really need a radically different protocol to complete the same function? * link operations = establish control communications between link neighbors, negotiate link parameters, monitor "liveness of a link" James Carlson wrote: > Thomas Narten writes: > > You reviewed parts of this (and a related) document a long time ago > > (see below). A question I have for the PPP community is whether the > > current version of the lmp-test-sonet ID is acceptable from a PPP > > perspective. > > This draft (draft-ietf-ccamp-lmp-test-sonet-sdh-02) is a little hard > to interpret, but I read it as using the LMP option to run the test > messages without UDP/IP and instead over raw HDLC framing. In that > case, I see no PPP-related issues. > > That's not the same as saying that I think this is necessarily a good > idea -- I don't, because I think being able to run SNMP, OSI, and > other protocols alongside LMP is valuable, and a multiplexing layer > such as that provided by PPP would allow you that flexibility at > fairly low cost. Retrofitting equipment that uses this null > encapsulation to work correctly if you decide to do any multiplexing > in the future will be highly problematic. > > The reference to RFC 1662 is odd and probably erroneous, since that > document describes how PPP uses HDLC framing. The draft should > probably reference ISO/IEC 3309 directly instead. > > If the reference is actually correct, then the protocol defined here > will need a PPP protocol number for section 3.1 of RFC 1662, and I > think we're back where we started ("using PPP without benefit of > negotiation"). > > -- > James Carlson, Solaris Networking > 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 ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ From owner-ietf-ppp@merit.edu Wed Apr 2 13:36:14 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22379 for ; Wed, 2 Apr 2003 13:36:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B578091222; Wed, 2 Apr 2003 13:38:25 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83657912BE; Wed, 2 Apr 2003 13:38:25 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6EF7B91222 for ; Wed, 2 Apr 2003 13:38:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 566555E008; Wed, 2 Apr 2003 13:38:24 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id C6D785DF79 for ; Wed, 2 Apr 2003 13:38:23 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14981; Wed, 2 Apr 2003 10:38:21 -0800 (PST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h32IcLuK017306; Wed, 2 Apr 2003 13:38:21 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.8+Sun/8.12.8) with ESMTP id h32IcKK3039829; Wed, 2 Apr 2003 13:38:20 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.8+Sun/8.12.8/Submit) id h32IcKhQ039826; Wed, 2 Apr 2003 13:38:20 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16011.11804.552827.697405@gargle.gargle.HOWL> Date: Wed, 2 Apr 2003 13:38:20 -0500 From: James Carlson To: jonathan.sadler@tellabs.com Cc: Thomas Narten , ietf-ppp@merit.edu, Bert Wijnen Subject: Re: PPP question on draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt In-Reply-To: Jonathan Sadler's message of 2 April 2003 12:25:22 References: <3E8B2B12.EE9ADE37@tellabs.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Jonathan Sadler writes: > Some clarification: > > In section 3.1, the draft (draft-ietf-ccamp-lmp-test-sonet-sdh-02) states > "the test message is sent as defined in [LMP]" (draft-ietf-ccamp-lmp-08) > when using SONET/SDH's Section/RS DCC and Line/MS DCC to carry a test > message. Section 12.5.6 of the referenced LMP draft states: > > "The Test message is transmitted over the data link and is used > to verify its physical connectivity. Unless explicitly stated, ^^^^^^^^^^^^^^^^^^^^^^^^ I read this as indicating that you could run unencapsulated if you had a compelling reason to do so, and that this was a reasonable interpretation of this new draft. > The upshot is the test messges are being carried on the SONET/SDH DCC > in a UDP/IP packet encapsulated "using bit-oriented HDLC framing > format [RFC 1662] (sic)". The reference to RFC 1662 was done > specifically to avoid the LCP/NCP negotiations required in RFC 1661. In that case, my original objections remain. This is an end-run around RFC 1661 that amounts to exactly the same result -- using "PPP frames" on a link without bothering to negotiate PPP. I certainly agree that consenting peers can do such a thing, but I could never sanction such a thing. > PS. Its interesting to note: > - the main purpose of LMP is to manage link operations* out-of-band > - PPP does a good job of managing link operations in-band That doesn't read right to me. The "in-band" versus "out-of-band" distinction is purely hypothetical. In both cases, you'd be running *some* signaling bits on the DCC. Whether those bits are called "in-band" with respect to the DCC itself or "out-of-band" with respect to the actual data channels on the SONET/SDH link seems to me to be an unhelpful distinction to draw. The real question is "what bits are sent on the DCC, and why?" > - LMP has not been widely implemented, and interoperability has > not been widely demonstrated > - PPP has been widely implemented, and shown to be widely interoperable > Do we really need a radically different protocol to complete the same > function? Yes, that is interesting to note, though perhaps not really relevant since there's more to LMP. > * link operations = establish control communications between link neighbors, > negotiate link parameters, monitor "liveness of a link" Perhaps. There are options in PPP to monitor link liveness, and I agree there's some overlap with LMP, but PPP's options are not 'required' in an implementation and they're not sufficient for all purposes. -- James Carlson, Solaris Networking 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 From owner-ietf-ppp@merit.edu Wed Apr 2 14:53:21 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25556 for ; Wed, 2 Apr 2003 14:53:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3139991226; Wed, 2 Apr 2003 14:55:33 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0125D91227; Wed, 2 Apr 2003 14:55:32 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF17591226 for ; Wed, 2 Apr 2003 14:55:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id D17385DF5F; Wed, 2 Apr 2003 14:55:31 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 4BC255DE32 for ; Wed, 2 Apr 2003 14:55:31 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17813; Wed, 2 Apr 2003 11:55:14 -0800 (PST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h32JtEuK008076; Wed, 2 Apr 2003 14:55:14 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.8+Sun/8.12.8) with ESMTP id h32JtDK3041769; Wed, 2 Apr 2003 14:55:14 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.8+Sun/8.12.8/Submit) id h32JtDoM041766; Wed, 2 Apr 2003 14:55:13 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16011.16417.178997.472072@gargle.gargle.HOWL> Date: Wed, 2 Apr 2003 14:55:13 -0500 From: James Carlson To: jonathan.sadler@tellabs.com Cc: Thomas Narten , ietf-ppp@merit.edu, Bert Wijnen Subject: Re: PPP question on draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt In-Reply-To: Jonathan Sadler's message of 2 April 2003 13:41:41 References: <3E8B3CF5.CAB38157@tellabs.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Jonathan Sadler writes: > > That doesn't read right to me. The "in-band" versus "out-of-band" > > distinction is purely hypothetical. In both cases, you'd be running > > *some* signaling bits on the DCC. Whether those bits are called > > "in-band" with respect to the DCC itself or "out-of-band" with respect > > to the actual data channels on the SONET/SDH link seems to me to be an > > unhelpful distinction to draw. > > In GMPLS, the control network and transport network are not required to have the > same topology. It is possible for two nodes (A & B) in two different locations to > have a transport link (ex a Lambda) between them, but not have direct control > plane connectivity. Consequently, the adjacency established between A & B to > manage the transport link may have to be carried through many IP router hops. I'm very well aware of that based on my prior SONET/SDH design work, and it's not the point. If you did LMP test messages over a raw HDLC session using the DCC, that would be no more or less "out of band" then a full PPP session over the DCC used only for management-level signaling support. The fact that you're using one set of protocols or another doesn't alter the way the signaling works on that one channel. The big difference, as below, is the scope of the signaling. LMP has a much wider scope. I don't see a reasonable way to modify PPP's LCP and LQM to operate in a way that would signal liveness of unrelated links. > For all functions in LMP, the DCC is not the link that is being described -- it is > just a conduit that MAY be used to carry the messaging. The link being described > is the SONET/SDH line/path. Consequently, the link management operations being > performed by LMP are really "out-of-band". OK; we're talking about different things here. If you run LMP over UDP/IP over PPP on the DCC, the LMP part still gives you out-of-band signaling. Thus, inclusion of PPP does *not* render the solution capable of supporting only in-band signaling. > Is there really more? LMP states it: > 1) establishes a control channel including the control channel > parameters > 2) identifies the parameters associated with a traffic bearing > link > 3) identifies mis-connection of transmit/recieve pairs > (this is specifically what the test-sonet-sdh spec is used for) > 4) identifies the grouping of traffic bearing links between neighbors > so that offered traffic can be carried any of the links in a group > 5) monitors the liveness of the control channel > 6) monitors the liveness of the traffic bearing link It's at least part (6) that's more. PPP does *NOT* contain any way to signal anything about what might be going on with any other link. It's this non-facilities associated signaling that (at least in my mind) makes LMP a bit different. Architecturally, there are other differences. LMP is designed to look into MPLS as a liveness test for MPLS purposes. PPP's signaling tells you no more or less than that the PPP link *itself* is good. If all you cared about was the DCC, then PPP's liveness would be enough. > The only difference is PPP does it for the case where the control channel is > carried over the traffic link (ie in-band), while LMP does it for the case where > the control channel and the traffic link are separate (ie out-of-band). That's a significant difference in my mind. For the in-band case, you don't have to name or number the "other" links. There aren't any. For the out-of-band case, you have to name or number those links, and you have to deal with issues surrounding agreement on the naming and agreement on link status. -- James Carlson, Solaris Networking 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 From owner-ietf-ppp@merit.edu Wed Apr 2 14:59:47 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25799 for ; Wed, 2 Apr 2003 14:59:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0F35D91224; Wed, 2 Apr 2003 14:41:49 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB32C91225; Wed, 2 Apr 2003 14:41:48 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D741291224 for ; Wed, 2 Apr 2003 14:41:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id BEE735DEE4; Wed, 2 Apr 2003 14:41:47 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by segue.merit.edu (Postfix) with ESMTP id A2CF55DE65 for ; Wed, 2 Apr 2003 14:41:47 -0500 (EST) Received: from mailw02.hq.tellabs.com (mailw02.hq.tellabs.com [172.23.207.12]) by mx4.tellabs.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ACV73601; Wed, 2 Apr 2003 13:41:42 -0600 (CST) Received: from tellabs.com (dhcp-172-23-111-45.hq.tellabs.com [172.23.111.45]) by mailw02.hq.tellabs.com with ESMTP (8.9.3 (PHNE_24419)/8.7.1) id NAA26167; Wed, 2 Apr 2003 13:41:43 -0600 (CST) Message-ID: <3E8B3CF5.CAB38157@tellabs.com> Date: Wed, 02 Apr 2003 13:41:41 -0600 From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: James Carlson Cc: Thomas Narten , ietf-ppp@merit.edu, Bert Wijnen Subject: Re: PPP question on draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mirapoint-Sig: mx4.tellabs.com Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit James - James Carlson wrote: > Jonathan Sadler writes: > > Some clarification: > > > > In section 3.1, the draft (draft-ietf-ccamp-lmp-test-sonet-sdh-02) states > > "the test message is sent as defined in [LMP]" (draft-ietf-ccamp-lmp-08) > > when using SONET/SDH's Section/RS DCC and Line/MS DCC to carry a test > > message. Section 12.5.6 of the referenced LMP draft states: > > > > "The Test message is transmitted over the data link and is used > > to verify its physical connectivity. Unless explicitly stated, > ^^^^^^^^^^^^^^^^^^^^^^^^ > > I read this as indicating that you could run unencapsulated if you had > a compelling reason to do so, and that this was a reasonable > interpretation of this new draft. I can understand your interpretation. The "explicitly stated" qualifier was not always there, and was only added by the authors when they realized the size constraints faced by the J0-16, J1-16, and J2-16 formats. This definately needs to be clarified in the test-sonet-sdh draft. > > The upshot is the test messges are being carried on the SONET/SDH DCC > > in a UDP/IP packet encapsulated "using bit-oriented HDLC framing > > format [RFC 1662] (sic)". The reference to RFC 1662 was done > > specifically to avoid the LCP/NCP negotiations required in RFC 1661. > > In that case, my original objections remain. This is an end-run > around RFC 1661 that amounts to exactly the same result -- using "PPP > frames" on a link without bothering to negotiate PPP. I certainly > agree that consenting peers can do such a thing, but I could never > sanction such a thing. > > > PS. Its interesting to note: > > - the main purpose of LMP is to manage link operations* out-of-band > > - PPP does a good job of managing link operations in-band > > That doesn't read right to me. The "in-band" versus "out-of-band" > distinction is purely hypothetical. In both cases, you'd be running > *some* signaling bits on the DCC. Whether those bits are called > "in-band" with respect to the DCC itself or "out-of-band" with respect > to the actual data channels on the SONET/SDH link seems to me to be an > unhelpful distinction to draw. In GMPLS, the control network and transport network are not required to have the same topology. It is possible for two nodes (A & B) in two different locations to have a transport link (ex a Lambda) between them, but not have direct control plane connectivity. Consequently, the adjacency established between A & B to manage the transport link may have to be carried through many IP router hops. This sort of disassociated signalling is also necessary for SONET/SDH applications of GMPLS to handle cases where the DCC endpoints and the link endpoints are not the same. An example of this is a SONET line that goes through a regenerator -- the Section DCC will be terminated at the regenerator, while the STS payload will be continued to the other end of the SONET line. For all functions in LMP, the DCC is not the link that is being described -- it is just a conduit that MAY be used to carry the messaging. The link being described is the SONET/SDH line/path. Consequently, the link management operations being performed by LMP are really "out-of-band". > The real question is "what bits are sent on the DCC, and why?" > > > - LMP has not been widely implemented, and interoperability has > > not been widely demonstrated > > - PPP has been widely implemented, and shown to be widely interoperable > > Do we really need a radically different protocol to complete the same > > function? > > Yes, that is interesting to note, though perhaps not really relevant > since there's more to LMP. Is there really more? LMP states it: 1) establishes a control channel including the control channel parameters 2) identifies the parameters associated with a traffic bearing link 3) identifies mis-connection of transmit/recieve pairs (this is specifically what the test-sonet-sdh spec is used for) 4) identifies the grouping of traffic bearing links between neighbors so that offered traffic can be carried any of the links in a group 5) monitors the liveness of the control channel 6) monitors the liveness of the traffic bearing link 1 is done today by LCP 2 is done today by LCP and the NCPs 3 can be done either through the Identification LCP message, or the endpoint discriminator option defined by Multilink PPP. 4 is done today by Multilink PPP 5&6 are done today by LQM as well as monitoring the health of the serial connection (server trail) The only difference is PPP does it for the case where the control channel is carried over the traffic link (ie in-band), while LMP does it for the case where the control channel and the traffic link are separate (ie out-of-band). > > * link operations = establish control communications between link neighbors, > > negotiate link parameters, monitor "liveness of a link" > > Perhaps. There are options in PPP to monitor link liveness, and I > agree there's some overlap with LMP, but PPP's options are not > 'required' in an implementation and they're not sufficient for all > purposes. Right. And many of the functions in the LMP spec are also "optional"... > > > -- > James Carlson, Solaris Networking > 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 ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ From owner-ietf-ppp@merit.edu Wed Apr 2 19:42:00 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19095 for ; Wed, 2 Apr 2003 19:42:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 14AA6912C0; Wed, 2 Apr 2003 19:44:11 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC137912C1; Wed, 2 Apr 2003 19:44:10 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BC3A0912C0 for ; Wed, 2 Apr 2003 19:44:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id A27895E064; Wed, 2 Apr 2003 19:44:09 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mx3.tellabs.com (mx3.tellabs.com [204.68.180.53]) by segue.merit.edu (Postfix) with ESMTP id 86B375DE0A for ; Wed, 2 Apr 2003 19:44:09 -0500 (EST) Received: from mailw02.hq.tellabs.com (mailw02.hq.tellabs.com [172.23.207.12]) by mx3.tellabs.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ADF10151; Wed, 2 Apr 2003 18:44:06 -0600 (CST) Received: from tellabs.com (dhcp-172-23-111-45.hq.tellabs.com [172.23.111.45]) by mailw02.hq.tellabs.com with ESMTP (8.9.3 (PHNE_24419)/8.7.1) id SAA07075; Wed, 2 Apr 2003 18:44:07 -0600 (CST) Message-ID: <3E8B83B4.99EC5BE7@tellabs.com> Date: Wed, 02 Apr 2003 18:43:32 -0600 From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: James Carlson Cc: Thomas Narten , ietf-ppp@merit.edu, Bert Wijnen Subject: Re: PPP question on draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mirapoint-Sig: mx3.tellabs.com Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit James - James Carlson wrote: > Jonathan Sadler writes: > > > That doesn't read right to me. The "in-band" versus "out-of-band" > > > distinction is purely hypothetical. In both cases, you'd be running > > > *some* signaling bits on the DCC. Whether those bits are called > > > "in-band" with respect to the DCC itself or "out-of-band" with respect > > > to the actual data channels on the SONET/SDH link seems to me to be an > > > unhelpful distinction to draw. > > > > In GMPLS, the control network and transport network are not required to have the > > same topology. It is possible for two nodes (A & B) in two different locations to > > have a transport link (ex a Lambda) between them, but not have direct control > > plane connectivity. Consequently, the adjacency established between A & B to > > manage the transport link may have to be carried through many IP router hops. > > I'm very well aware of that based on my prior SONET/SDH design work, > and it's not the point. Good to know the amount of explanation I should include in my responses. > If you did LMP test messages over a raw HDLC session using the DCC, > that would be no more or less "out of band" then a full PPP session > over the DCC used only for management-level signaling support. The > fact that you're using one set of protocols or another doesn't alter > the way the signaling works on that one channel. I think your mixing the two message flows that exist in LMP. I agree, the test messages must run in a trace channel or traffic bearer associated with the traffic link in order to work. However, the management messages being sent between LMP instances to control the test process, monitor the health of the LMP association, etc. do not. > The big difference, as below, is the scope of the signaling. LMP has > a much wider scope. I don't see a reasonable way to modify PPP's LCP > and LQM to operate in a way that would signal liveness of unrelated > links. Actually, I believe that the server layer trail's FDI/BDI is better than any out-of-band method for relaying the state of the user plane link (traffic link). LQM in this situation would be better used as mechanism to monitor the control channel. As for scope, I would be interested in your opinion on what information LMP has to handle that PPP does not. > > For all functions in LMP, the DCC is not the link that is being described -- it is > > just a conduit that MAY be used to carry the messaging. The link being described > > is the SONET/SDH line/path. Consequently, the link management operations being > > performed by LMP are really "out-of-band". > > OK; we're talking about different things here. If you run LMP over > UDP/IP over PPP on the DCC, the LMP part still gives you out-of-band > signaling. Thus, inclusion of PPP does *not* render the solution > capable of supporting only in-band signaling. I think we're in agreement that the use of PPP for the Data Link layer on the DCC is actually orthoginal from the issue of how non-associated link management operations is done for user plane link. My original comments were made as an identification that LMP is really doing the same things already done by PPP -- its just doing them for non-associated links. > > Is there really more? LMP states it: > > 1) establishes a control channel including the control channel > > parameters > > 2) identifies the parameters associated with a traffic bearing > > link > > 3) identifies mis-connection of transmit/recieve pairs > > (this is specifically what the test-sonet-sdh spec is used for) > > 4) identifies the grouping of traffic bearing links between neighbors > > so that offered traffic can be carried any of the links in a group > > 5) monitors the liveness of the control channel > > 6) monitors the liveness of the traffic bearing link > > It's at least part (6) that's more. PPP does *NOT* contain any way to > signal anything about what might be going on with any other link. See my comment above about the use of an out-of-band channel instead of FDI/BDI to do (6). > It's this non-facilities associated signaling that (at least in my > mind) makes LMP a bit different. I tend to agree, but don't see it as too far different than what PPP can already do. For example, one instance of PPP today can negotiate configuration parameters for links that appear in different layer networks (ie. OSI, IPX, IPv4). It accomplishes this through the use of different NCPs at different PPP protocol numbers. Similarily, it should be possible to have a "non-associated link" NCP which includes the name of the specific link being "negotiated" in each negotiation message. This would allow for multiple instances of this NCP to exist, each tracking the status of a different non-associated link. > Architecturally, there are other differences. LMP is designed to look > into MPLS as a liveness test for MPLS purposes. PPP's signaling tells > you no more or less than that the PPP link *itself* is good. If all > you cared about was the DCC, then PPP's liveness would be enough. I'm unaware of where LMP states that you should look into the MPLS layer as a liveness test. Can you provide me a reference? > > The only difference is PPP does it for the case where the control channel is > > carried over the traffic link (ie in-band), while LMP does it for the case where > > the control channel and the traffic link are separate (ie out-of-band). > > That's a significant difference in my mind. For the in-band case, you > don't have to name or number the "other" links. There aren't any. For > the out-of-band case, you have to name or number those links, and you > have to deal with issues surrounding agreement on the naming and > agreement on link status. The same issues exist for LMP. Currently they are using , which is very similar to the SNPP names being defined in the ITU. Though, this shouldn't justify the development of a completely new protocol... > -- > James Carlson, Solaris Networking > 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 ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ From owner-ietf-ppp@merit.edu Thu Apr 3 07:58:54 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18495 for ; Thu, 3 Apr 2003 07:58:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 85511912C8; Thu, 3 Apr 2003 08:00:19 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F0799912C9; Thu, 3 Apr 2003 08:00:18 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9D349912C8 for ; Thu, 3 Apr 2003 08:00:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 753A25DDF7; Thu, 3 Apr 2003 08:00:16 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 1FC3B5DDF6 for ; Thu, 3 Apr 2003 08:00:16 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA21695; Thu, 3 Apr 2003 05:00:10 -0800 (PST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h33D0AuK021917; Thu, 3 Apr 2003 08:00:10 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.8+Sun/8.12.8) with ESMTP id h33D0AK3046467; Thu, 3 Apr 2003 08:00:10 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.8+Sun/8.12.8/Submit) id h33D0A39046464; Thu, 3 Apr 2003 08:00:10 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16012.12377.655249.751544@gargle.gargle.HOWL> Date: Thu, 3 Apr 2003 08:00:09 -0500 From: James Carlson To: jonathan.sadler@tellabs.com Cc: Thomas Narten , ietf-ppp@merit.edu, Bert Wijnen Subject: Re: PPP question on draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt In-Reply-To: Jonathan Sadler's message of 2 April 2003 18:43:32 References: <3E8B83B4.99EC5BE7@tellabs.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Jonathan Sadler writes: > > If you did LMP test messages over a raw HDLC session using the DCC, > > that would be no more or less "out of band" then a full PPP session > > over the DCC used only for management-level signaling support. The > > fact that you're using one set of protocols or another doesn't alter > > the way the signaling works on that one channel. > > I think your mixing the two message flows that exist in LMP. I agree, the test messages > must run in a trace channel or traffic bearer associated with the traffic link in order > to work. However, the management messages being sent between LMP instances to control > the test process, monitor the health of the LMP association, etc. do not. I wasn't disputing any of that. I was disputing the (apparent) claim that running PPP on the DCC would somehow render the entire solution to be "in-band only." This is just false. There's no difference between running LMP over UDP/IP/PPP on one hand, and running LMP over UDP/IP/raw-HDLC on the other. LMP is going to be the same no matter what transport is used. So, back to the problem: I see no useful purpose served by running UDP/IP over a hacked version of RFC 1332 plus RFC 1662, but with the negotiation portion of RFC 1332 disabled and RFC 1661 omitted entirely. Doing this essentially makes the connection revert to SLIP-like semantics. The reason PPP was designed to negotiate was to avoid the problems that had been seen with SLIP. See RFC 1547 -- especially section 2 -- for the reasons that PPP does what it does. We've been down that road before, and it hurts. Trivial misconfigurations result in substantial network misbehavior. It seems a shame that anyone else should make that same mistake. > > The big difference, as below, is the scope of the signaling. LMP has > > a much wider scope. I don't see a reasonable way to modify PPP's LCP > > and LQM to operate in a way that would signal liveness of unrelated > > links. > > Actually, I believe that the server layer trail's FDI/BDI is better than any out-of-band > method for relaying the state of the user plane link (traffic link). LQM in this > situation would be better used as mechanism to monitor the control channel. Sure. It doesn't matter if it's better. PPP's LQM can't tell you anything about events outside of that point-to-point connection. > As for scope, I would be interested in your opinion on what information LMP has to > handle that PPP does not. They're utterly different protocols. For one thing, LMP signals information about the data links themselves -- communicating wavelength, bandwidth, type of switching, et cetera. None of this would make any sense in PPP. > I think we're in agreement that the use of PPP for the Data Link layer on the DCC is > actually orthoginal from the issue of how non-associated link management operations is > done for user plane link. Good! > My original comments were made as an identification that LMP is really doing the same > things already done by PPP -- its just doing them for non-associated links. I don't see that as a "just." The details are substantially more complex, *and* it would not make sense at all to try to force LMP's features into PPP. > > It's this non-facilities associated signaling that (at least in my > > mind) makes LMP a bit different. > > I tend to agree, but don't see it as too far different than what PPP can already do. > For example, one instance of PPP today can negotiate configuration parameters for links > that appear in different layer networks (ie. OSI, IPX, IPv4). It accomplishes this > through the use of different NCPs at different PPP protocol numbers. They're all in parallel, and they're all at the network layer. This is completely different from having to name and manage information related to separate data channels. The design issues are different. > Similarily, it should be possible to have a "non-associated link" NCP which includes the > name of the specific link being "negotiated" in each negotiation message. This would > allow for multiple instances of this NCP to exist, each tracking the status of a > different non-associated link. Yes, you could do that. If you did it right, I suspect you'd end up reinventing LMP, but in a perhaps less flexible manner. > > Architecturally, there are other differences. LMP is designed to look > > into MPLS as a liveness test for MPLS purposes. PPP's signaling tells > > you no more or less than that the PPP link *itself* is good. If all > > you cared about was the DCC, then PPP's liveness would be enough. > > I'm unaware of where LMP states that you should look into the MPLS layer as a liveness > test. Can you provide me a reference? Sorry. I meant to type "hook," not "look." It's the other way around. LMP provides a way for nodes to signal the existence and *status* of data links to be aggregated into TE links for use by MPLS. Sections 1 and 2 of the LMP draft cover this. http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-08.txt > > That's a significant difference in my mind. For the in-band case, you > > don't have to name or number the "other" links. There aren't any. For > > the out-of-band case, you have to name or number those links, and you > > have to deal with issues surrounding agreement on the naming and > > agreement on link status. > > The same issues exist for LMP. Currently they are using , which is > very similar to the SNPP names being defined in the ITU. Though, this shouldn't justify > the development of a completely new protocol... And yet it's there. I have no position on LMP. I don't much care about it. It's the (re)use of PPP mechanisms without proper implementation that I care about. -- James Carlson, Solaris Networking 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 From owner-ietf-ppp@merit.edu Thu Apr 3 11:32:04 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28439 for ; Thu, 3 Apr 2003 11:32:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D5D33912D8; Thu, 3 Apr 2003 11:34:09 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 389E2912D9; Thu, 3 Apr 2003 11:34:09 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A621F912D8 for ; Thu, 3 Apr 2003 11:32:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 89CCD5DE2E; Thu, 3 Apr 2003 11:32:33 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id D047C5DDEB for ; Thu, 3 Apr 2003 11:32:32 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA24277; Thu, 3 Apr 2003 09:32:29 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h33GWTuK010712; Thu, 3 Apr 2003 11:32:29 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.8+Sun/8.12.8) with ESMTP id h33GWTK3046571; Thu, 3 Apr 2003 11:32:29 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.8+Sun/8.12.8/Submit) id h33GWTlR046568; Thu, 3 Apr 2003 11:32:29 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16012.25117.53312.519126@gargle.gargle.HOWL> Date: Thu, 3 Apr 2003 11:32:29 -0500 From: James Carlson To: "Wijnen, Bert (Bert)" Cc: jonathan.sadler@tellabs.com, Thomas Narten , ietf-ppp@merit.edu Subject: RE: PPP question on draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt In-Reply-To: Wijnen, Bert (Bert)'s message of 3 April 2003 15:45:05 References: <7D5D48D2CAA3D84C813F5B154F43B15501483ED1@nl0006exch001u.nl.lucent.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Wijnen, Bert (Bert) writes: > - LMP is a Link Management Protocol that runs on UDP and > all the control info goes over that path. In many cases > that control info goes out of band of the data path Yep. > - In the case where the LMP wants/needs to test that the > data path is indeed operational, that is where it sends > a test message. It does so over UDP if it is available > on the data path, via other methods if it is not available > on the data path (as is the case for sonet/sdh). Understood. > - This test message is only used for very short periods of > time.... so I wonder if it then makes sense to try and setup > a PPP connection first in order to be able to send a few > short test messages in order to just verify that the data > path is functioning. That's the part that I don't fully understand. Why wouldn't you just negotiate up a PPP link over the DCC when the underlying link is enabled, and then leave it in place at all times? Switching back and forth is clumsy but makes (almost) some sense if the data connection that we're talking about actually carried user data. Unlike the troubles with lambda switching, this channel doesn't carry any user data -- it's an out-of-band management interface. > Is a true statement, but the question is if it indeed makes sense to > have to setup a PPP connection to send just a few UDP packets after > which the connection (PPP) is to be removed again, cause there might > be otehr data (non IP even) traveling on the data path. If you're actually switching back and forth between data and test mode to send the messages, it probably also doesn't make sense to maintain the overhead of UDP or IP either. Unlike the LMP messages sent over the control channel (which might be an internet), these messages wouldn't be routable in any conventional sense. As I said before, this proposal doesn't quite make sense to me, and, in addition, reusing some elements of PPP but not others looks quite odd. There is however nothing that prohibits consenting peers from doing strange things. -- James Carlson, Solaris Networking 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 From owner-ietf-ppp@merit.edu Thu Apr 3 11:35:24 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28631 for ; Thu, 3 Apr 2003 11:35:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 24D60912D7; Thu, 3 Apr 2003 11:37:37 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D461D912D9; Thu, 3 Apr 2003 11:37:36 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 01181912D7 for ; Thu, 3 Apr 2003 11:37:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id E3BA85DE36; Thu, 3 Apr 2003 11:37:35 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by segue.merit.edu (Postfix) with ESMTP id C449F5DE35 for ; Thu, 3 Apr 2003 11:37:35 -0500 (EST) Received: from mailw02.hq.tellabs.com (mailw02.hq.tellabs.com [172.23.207.12]) by mx4.tellabs.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ACW13968; Thu, 3 Apr 2003 10:37:33 -0600 (CST) Received: from tellabs.com (dhcp-172-23-111-45.hq.tellabs.com [172.23.111.45]) by mailw02.hq.tellabs.com with ESMTP (8.9.3 (PHNE_24419)/8.7.1) id KAA11481; Thu, 3 Apr 2003 10:37:34 -0600 (CST) Message-ID: <3E8C634D.4889AE97@tellabs.com> Date: Thu, 03 Apr 2003 10:37:33 -0600 From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: James Carlson , Thomas Narten , ietf-ppp@merit.edu Subject: Re: PPP question on draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mirapoint-Sig: mx4.tellabs.com Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Bert - "Wijnen, Bert (Bert)" wrote: > The discussion got started, because as responsible AD for > the draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt document > I found a ptr that there might be a possible issue. > > Not sure I understand all this discussion sofar. Sorry about taking the discussion in a different direction. > My understanding and my focus of the discussion would > be as follows: > > - LMP is a Link Management Protocol that runs on UDP and > all the control info goes over that path. In many cases > that control info goes out of band of the data path > - In the case where the LMP wants/needs to test that the > data path is indeed operational, that is where it sends > a test message. It does so over UDP if it is available > on the data path, via other methods if it is not available > on the data path (as is the case for sonet/sdh). A clarification: the test message is only sent between two neighbors in a layer network. It does not test the end to end connectivity of the client layer. As such it cannot verify if the client layer is "operational" -- it only can test that the server layer is connected. Other things (such as adapatations) could be set incorrectly which would cause the client layer to not be "operational". > - This test message is only used for very short periods of > time.... so I wonder if it then makes sense to try and setup > a PPP connection first in order to be able to send a few > short test messages in order to just verify that the data > path is functioning. Further, a PPP connection supporting IP requires a functional bi-directional link -- LCP and IPCP will not negotiate if the link is not bi-directionally connected. The result is it would be it impossible to do the miswiring detection defined by LMP. However, this does not mean that RFC 1661 should be precluded... > Given the above (and pls correct me if I got it wrong), > Then it it seems that: > > > So, back to the problem: I see no useful purpose served by running > > UDP/IP over a hacked version of RFC 1332 plus RFC 1662, but with the > > negotiation portion of RFC 1332 disabled and RFC 1661 omitted > > entirely. > > > > Doing this essentially makes the connection revert to SLIP-like > > semantics. The reason PPP was designed to negotiate was to avoid the > > problems that had been seen with SLIP. See RFC 1547 -- especially > > section 2 -- for the reasons that PPP does what it does. > > > > We've been down that road before, and it hurts. Trivial > > misconfigurations result in substantial network misbehavior. It seems > > a shame that anyone else should make that same mistake. > > > > Is a true statement, but the question is if it indeed makes sense to > have to setup a PPP connection to send just a few UDP packets after > which the connection (PPP) is to be removed again, cause there might > be otehr data (non IP even) traveling on the data path. Since the test message is going between two immediate neighbors on a PPP link, there is no need to include IP or UDP in the messages. Instead, two methods exist that conform with the RFC 1661 may be used: - Use the Identification LCP message as defined in RFC 1570 - Have the LMP test message carried as an LCP option when LCP negotiation is done on the PPP link. The first method has benefits over the later as: - the identification field provides a "method for an implementation to identify itself to its peer." The test message defined by LMP contains "TE Link" identification. - there is no need for a new code point (and related behavior) to be defined - a test message can be sent at any time, independent of PPP protocol state Because of these reasons, the ITU chose the first methods for G.7714.1. A related question is: do we need two different methods for passing the "TE Link" id in-band to verify the connectivity of a link endpoint? Jonathan Sadler > I hope the above makes sense and can keep the discussion to the > problem/issue at hand (as far as I see it). > > Bert ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ From owner-ietf-ppp@merit.edu Thu Apr 3 11:47:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29056 for ; Thu, 3 Apr 2003 11:47:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5143F912DC; Thu, 3 Apr 2003 11:49:21 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 249A5912DA; Thu, 3 Apr 2003 11:49:21 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF6C7912D9 for ; Thu, 3 Apr 2003 11:47:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id AD3DC5DE1F; Thu, 3 Apr 2003 11:47:29 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 2D82D5DDAF for ; Thu, 3 Apr 2003 11:47:29 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA08037; Thu, 3 Apr 2003 09:47:19 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h33GlJuK014777; Thu, 3 Apr 2003 11:47:19 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.8+Sun/8.12.8) with ESMTP id h33GlJK3046598; Thu, 3 Apr 2003 11:47:19 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.8+Sun/8.12.8/Submit) id h33GlJ80046595; Thu, 3 Apr 2003 11:47:19 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16012.26006.972143.775254@gargle.gargle.HOWL> Date: Thu, 3 Apr 2003 11:47:18 -0500 From: James Carlson To: jonathan.sadler@tellabs.com Cc: "Wijnen, Bert (Bert)" , Thomas Narten , ietf-ppp@merit.edu Subject: Re: PPP question on draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt In-Reply-To: Jonathan Sadler's message of 3 April 2003 10:37:33 References: <3E8C634D.4889AE97@tellabs.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Jonathan Sadler writes: > Since the test message is going between two immediate neighbors on a PPP > link, there is no need to include IP or UDP in the messages. Instead, two > methods exist that conform with the RFC 1661 may be used: > - Use the Identification LCP message as defined in RFC 1570 > - Have the LMP test message carried as an LCP option when > LCP negotiation is done on the PPP link. Here's a third: create an LMP "network protocol." I'd be happier with that than with either an LCP option or hijacking the Identification message. Note that it's not actually necessary for any network protocol in PPP to have a corresponding NCP to negotiate anything, so you could just open LCP and then send your "network layer messages" (actually LMP test messages). (Each network layer protocol is separately defined for this reason; each can define its own procedures.) Since you send them infrequently and header compression isn't much of an issue, you could use the relatively open 4xxx range of protocol IDs. > The first method has benefits over the later as: > - the identification field provides a "method for an > implementation to identify itself to its peer." The test > message defined by LMP contains "TE Link" identification. Er ... ok. The intent of the Identification field is to provide a software version string that can be placed in a log file for a human to determine what might have gone wrong with a broken link. I agree that there's no "standard" for what is placed there, but placing machine-readable data into a field intended for text seems to be an abuse to me. Worse, if you did this, nobody would be able to use LCP Identification on SONET/SDH for its intended purpose, and that would seem to me to represent a net loss. > - there is no need for a new code point (and related > behavior) to be defined > - a test message can be sent at any time, independent of PPP > protocol state That'd be also true if you created a new network layer number. > Because of these reasons, the ITU chose the first methods for G.7714.1. > > A related question is: do we need two different methods for passing the "TE > Link" id in-band to verify the connectivity of a link endpoint? Fewer would certainly be better. One would be ideal. -- James Carlson, Solaris Networking 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 From owner-ietf-ppp@merit.edu Thu Apr 3 11:57:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29606 for ; Thu, 3 Apr 2003 11:57:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9C334912D9; Thu, 3 Apr 2003 11:59:33 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 657DF912DA; Thu, 3 Apr 2003 11:59:33 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 70176912D9 for ; Thu, 3 Apr 2003 11:59:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5C13F5DE38; Thu, 3 Apr 2003 11:59:32 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from mx3.tellabs.com (mx3.tellabs.com [204.68.180.53]) by segue.merit.edu (Postfix) with ESMTP id 404DE5DE2E for ; Thu, 3 Apr 2003 11:59:32 -0500 (EST) Received: from mailw02.hq.tellabs.com (mailw02.hq.tellabs.com [172.23.207.12]) by mx3.tellabs.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ADF45668; Thu, 3 Apr 2003 10:59:30 -0600 (CST) Received: from tellabs.com (dhcp-172-23-111-45.hq.tellabs.com [172.23.111.45]) by mailw02.hq.tellabs.com with ESMTP (8.9.3 (PHNE_24419)/8.7.1) id KAA17565; Thu, 3 Apr 2003 10:59:31 -0600 (CST) Message-ID: <3E8C6871.5A394623@tellabs.com> Date: Thu, 03 Apr 2003 10:59:30 -0600 From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: James Carlson Cc: "Wijnen, Bert (Bert)" , Thomas Narten , ietf-ppp@merit.edu Subject: Re: PPP question on draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mirapoint-Sig: mx3.tellabs.com Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit James - James Carlson wrote: > Jonathan Sadler writes: > > Since the test message is going between two immediate neighbors on a PPP > > link, there is no need to include IP or UDP in the messages. Instead, two > > methods exist that conform with the RFC 1661 may be used: > > - Use the Identification LCP message as defined in RFC 1570 > > - Have the LMP test message carried as an LCP option when > > LCP negotiation is done on the PPP link. > > Here's a third: create an LMP "network protocol." I'd be happier with > that than with either an LCP option or hijacking the Identification > message. Note that it's not actually necessary for any network > protocol in PPP to have a corresponding NCP to negotiate anything, so > you could just open LCP and then send your "network layer messages" > (actually LMP test messages). (Each network layer protocol is > separately defined for this reason; each can define its own > procedures.) LCP is not likely to reach the "open" state if server layer is mis-connected/mis-wired(ie. Node A Port 1 Tx -> Node B Port 1 Rx & Node B Port 1 Tx -> Node A Port 2 Rx). Consequently, using a new NCP would yield LMP unable to assist in troubleshooting mis-connection/mis-wiring cases. This is one of the stated uses of the connectivity verification (TEST) process. > Since you send them infrequently and header compression isn't much of > an issue, you could use the relatively open 4xxx range of protocol > IDs. > > > The first method has benefits over the later as: > > - the identification field provides a "method for an > > implementation to identify itself to its peer." The test > > message defined by LMP contains "TE Link" identification. > > Er ... ok. The intent of the Identification field is to provide a > software version string that can be placed in a log file for a human > to determine what might have gone wrong with a broken link. I agree > that there's no "standard" for what is placed there, but placing > machine-readable data into a field intended for text seems to be an > abuse to me. > > Worse, if you did this, nobody would be able to use LCP Identification > on SONET/SDH for its intended purpose, and that would seem to me to > represent a net loss. > > > - there is no need for a new code point (and related > > behavior) to be defined > > - a test message can be sent at any time, independent of PPP > > protocol state > > That'd be also true if you created a new network layer number. > > > Because of these reasons, the ITU chose the first methods for G.7714.1. > > > > A related question is: do we need two different methods for passing the "TE > > Link" id in-band to verify the connectivity of a link endpoint? > > Fewer would certainly be better. One would be ideal. > > -- > James Carlson, Solaris Networking > 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 ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ From owner-ietf-ppp@merit.edu Thu Apr 3 12:02:26 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29785 for ; Thu, 3 Apr 2003 12:02:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 221AD912DA; Thu, 3 Apr 2003 12:04:33 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5B1C912DB; Thu, 3 Apr 2003 12:04:32 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E408E912DA for ; Thu, 3 Apr 2003 12:04:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id BE3CA5DE2E; Thu, 3 Apr 2003 12:04:31 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 341645DE2B for ; Thu, 3 Apr 2003 12:04:31 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA22937; Thu, 3 Apr 2003 10:04:24 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h33H4N9P019942; Thu, 3 Apr 2003 12:04:23 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.8+Sun/8.12.8) with ESMTP id h33H4NK3046632; Thu, 3 Apr 2003 12:04:23 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.8+Sun/8.12.8/Submit) id h33H4NPR046629; Thu, 3 Apr 2003 12:04:23 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16012.27030.866032.643322@gargle.gargle.HOWL> Date: Thu, 3 Apr 2003 12:04:22 -0500 From: James Carlson To: jonathan.sadler@tellabs.com Cc: "Wijnen, Bert (Bert)" , Thomas Narten , ietf-ppp@merit.edu Subject: Re: PPP question on draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt In-Reply-To: Jonathan Sadler's message of 3 April 2003 10:59:30 References: <3E8C6871.5A394623@tellabs.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Jonathan Sadler writes: > LCP is not likely to reach the "open" state if server layer is > mis-connected/mis-wired(ie. Node A Port 1 Tx -> Node B Port 1 Rx & Node B Port 1 > Tx -> Node A Port 2 Rx). Consequently, using a new NCP would yield LMP unable to > assist in troubleshooting mis-connection/mis-wiring cases. This is one of the > stated uses of the connectivity verification (TEST) process. I see. It would still be nice to avoid taking over LCP Identification. A new code number would do the trick. -- James Carlson, Solaris Networking 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 From owner-ietf-ppp@merit.edu Mon Apr 28 21:25:55 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21333 for ; Mon, 28 Apr 2003 21:25:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AA6F39122A; Mon, 28 Apr 2003 21:28:18 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 740F09122B; Mon, 28 Apr 2003 21:28:18 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 660739122A for ; Mon, 28 Apr 2003 21:28:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 458B75DE15; Mon, 28 Apr 2003 21:28:17 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by segue.merit.edu (Postfix) with ESMTP id CCCFA5DE13 for ; Mon, 28 Apr 2003 21:28:16 -0400 (EDT) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3T1RbF0022021 for ; Mon, 28 Apr 2003 18:28:14 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (rtp-vpn1-1198.cisco.com [10.82.228.174]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGO05965; Mon, 28 Apr 2003 18:21:52 -0700 (PDT) Message-Id: <5.2.0.9.2.20030428094206.00b1e140@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 28 Apr 2003 09:44:19 -0700 To: ietf-ppp@merit.edu From: Fred Baker Subject: Fwd: RFC 3518 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 8bit We received this note this morning. I didn't see any note from him during the development of the draft, working group last call, or IETF last call. What does the working group want to do with the comments? >From: "Alfred H\Nnes" >Subject: RFC 3518 >To: Mitsuru.Higashiyama@yy.anritsu.co.jp >Date: Mon, 28 Apr 03 15:25:44 MESZ >Cc: fred@cisco.com, tawei@cisco.com, rfc-editor@rfc-editor.org > >Hello, > >I'd like to report to you some issues I found when reading the new >PPP-BCP RFC 3518 : > > >(1) On [Page 1], the last paragraph of the 'Abstract' section > does not correctly represent the situation before RFC 3518. > > At the similar place in RFC 2878, there was written: > > "This document obsoletes RFC 1638, which was based on the IEEE > 802.1D-1993 MAC Bridge[3]. This document extends that specification > by including the IEEE 802.1D-1998 MAC Bridge[8] and IEEE 802.1Q > Virtual LAN (VLAN)[9] standards. ..." > > Therefore, the sentence found in RFC 3518 : > > "This document obsoletes RFC 2878, which was based on the IEEE > 802.1D-1993 MAC Bridge. This document extends that specification ..." > ^^^^^^^^^^^ > > seems inappropriate and should better state: > > "This document obsoletes RFC 2878, which was based on the IEEE > 802.1D-1998 MAC Bridge[8] and IEEE 802.1Q Virtual LAN (VLAN)[9] > standards. This document extends that specification ..." > > (The unchanged reference tags are still correct.) > > But, since RFC 3518 does not add any new IEEE 802 related > functionality (the additions are purely PPP-BCP performance > clues), it even would suffice to state: > > "This document obsoletes RFC 2878. It extends that specification ..." > > >(2) The frame format descriptions in section 4.2. and section 4.3. still > lack of textual descriptions for > > - the "SNAP-encoded TPID" field (802.4/... tagged frame format), and > > - the "Length/Type" field (both 802.3 frame formats). > > {N.B.: > "Type" would usually mean an Ethernet frame; but that would be > inappropriate if the headline "802.3 Frame format" is taken > literally. > It is not clear from the text whether it is intended to admit > Ethernet frames too in section 4.2. (Existing implementations > obviously do!) Because these frames do not contain any 802.2 LLC > (+ eventually SNAP) header, in this case the "LLC data" field > should better be named "LLC / Ethernet data" in 4.2 on page 13. > I've never seen Ethernet-like frame-content in IEEE 802 Tagged > Frames; do such frames really exist?? -- if not, "Lenght/Type" > should be corrected to just read "Length" in 4.3 on page 17. > } > >(3) The pseudo code given in Appendix B for the Transmitter side still > sets the ZeroCompressionFlag in the case of a packet of minimal > length that does _not_ contain any padding bytes, i. e. in the > case where the 'while' loop bodies are never executed because > TrailingOctet (PDU) != 0 on first try. > > This behaviour indeed does not cause real harm, but it introduces > inefficiency into the Transmitter code and unnecessarily causes > additional code to be executed on the Receiver side as well; > therefore it would be better to not "specify" this behaviour. > (N.B.: It is not clear from the text whether Appendix B should > be considered normative or not.) > >Best regards, > Alfred Hönes. > >-- > >+------------------------+--------------------------------------------+ >| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | >| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | >| D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | >+------------------------+--------------------------------------------+ From owner-ietf-ppp@merit.edu Tue Apr 29 13:32:59 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02912 for ; Tue, 29 Apr 2003 13:32:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B77629126E; Tue, 29 Apr 2003 13:35:30 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8303F9126F; Tue, 29 Apr 2003 13:35:30 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8D6AE9126E for ; Tue, 29 Apr 2003 13:35:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 728CE5E34E; Tue, 29 Apr 2003 13:35:29 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from ns2.vivacenetworks.com (unknown [64.221.212.135]) by segue.merit.edu (Postfix) with SMTP id 18EB35E34D for ; Tue, 29 Apr 2003 13:35:29 -0400 (EDT) Received: from amalisxp.vivacenetworks.com ([10.122.19.101]) by vivacenetworks.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Apr 2003 10:35:26 -0700 Message-Id: <5.2.1.1.0.20030429130225.04533968@po1.vivacenetworks.com> X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 29 Apr 2003 13:11:24 -0400 To: Fred Baker From: "Andrew G. Malis" Subject: Re: Fwd: RFC 3518 Cc: ietf-ppp@merit.edu In-Reply-To: <5.2.0.9.2.20030428094206.00b1e140@mira-sjc5-b.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 29 Apr 2003 17:35:26.0254 (UTC) FILETIME=[B84D44E0:01C30E75] Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA02912 Fred, I guess he took the term "Request for Comments" at face value! :-) Not everyone can follow the work in progress ... If the authors/editors of the RFC, with the concurrence of the WG, see value in the comments, then you may want to turn around a revised RFC with just these changes. While I'm not a BCP expert, the comments generally seem useful. Cheers, Andy -------- At 4/28/2003 09:44 AM -0700, Fred Baker wrote: >We received this note this morning. I didn't see any note from him during >the development of the draft, working group last call, or IETF last call. >What does the working group want to do with the comments? > >>From: "Alfred H\Nnes" >>Subject: RFC 3518 >>To: Mitsuru.Higashiyama@yy.anritsu.co.jp >>Date: Mon, 28 Apr 03 15:25:44 MESZ >>Cc: fred@cisco.com, tawei@cisco.com, rfc-editor@rfc-editor.org >> >>Hello, >> >>I'd like to report to you some issues I found when reading the new >>PPP-BCP RFC 3518 : >> >> >>(1) On [Page 1], the last paragraph of the 'Abstract' section >> does not correctly represent the situation before RFC 3518. >> >> At the similar place in RFC 2878, there was written: >> >> "This document obsoletes RFC 1638, which was based on the IEEE >> 802.1D-1993 MAC Bridge[3]. This document extends that specification >> by including the IEEE 802.1D-1998 MAC Bridge[8] and IEEE 802.1Q >> Virtual LAN (VLAN)[9] standards. ..." >> >> Therefore, the sentence found in RFC 3518 : >> >> "This document obsoletes RFC 2878, which was based on the IEEE >> 802.1D-1993 MAC Bridge. This document extends that specification ..." >> ^^^^^^^^^^^ >> >> seems inappropriate and should better state: >> >> "This document obsoletes RFC 2878, which was based on the IEEE >> 802.1D-1998 MAC Bridge[8] and IEEE 802.1Q Virtual LAN (VLAN)[9] >> standards. This document extends that specification ..." >> >> (The unchanged reference tags are still correct.) >> >> But, since RFC 3518 does not add any new IEEE 802 related >> functionality (the additions are purely PPP-BCP performance >> clues), it even would suffice to state: >> >> "This document obsoletes RFC 2878. It extends that specification ..." >> >> >>(2) The frame format descriptions in section 4.2. and section 4.3. still >> lack of textual descriptions for >> >> - the "SNAP-encoded TPID" field (802.4/... tagged frame format), and >> >> - the "Length/Type" field (both 802.3 frame formats). >> >> {N.B.: >> "Type" would usually mean an Ethernet frame; but that would be >> inappropriate if the headline "802.3 Frame format" is taken >> literally. >> It is not clear from the text whether it is intended to admit >> Ethernet frames too in section 4.2. (Existing implementations >> obviously do!) Because these frames do not contain any 802.2 LLC >> (+ eventually SNAP) header, in this case the "LLC data" field >> should better be named "LLC / Ethernet data" in 4.2 on page 13. >> I've never seen Ethernet-like frame-content in IEEE 802 Tagged >> Frames; do such frames really exist?? -- if not, "Lenght/Type" >> should be corrected to just read "Length" in 4.3 on page 17. >> } >> >>(3) The pseudo code given in Appendix B for the Transmitter side still >> sets the ZeroCompressionFlag in the case of a packet of minimal >> length that does _not_ contain any padding bytes, i. e. in the >> case where the 'while' loop bodies are never executed because >> TrailingOctet (PDU) != 0 on first try. >> >> This behaviour indeed does not cause real harm, but it introduces >> inefficiency into the Transmitter code and unnecessarily causes >> additional code to be executed on the Receiver side as well; >> therefore it would be better to not "specify" this behaviour. >> (N.B.: It is not clear from the text whether Appendix B should >> be considered normative or not.) >> >>Best regards, >> Alfred Hönes. From owner-ietf-ppp@merit.edu Tue Apr 29 14:35:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04925 for ; Tue, 29 Apr 2003 14:35:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 44D9C91271; Tue, 29 Apr 2003 14:37:45 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1676F91272; Tue, 29 Apr 2003 14:37:45 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0E9A991271 for ; Tue, 29 Apr 2003 14:37:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EBA785E3F0; Tue, 29 Apr 2003 14:37:43 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by segue.merit.edu (Postfix) with ESMTP id AE2005E1F0 for ; Tue, 29 Apr 2003 14:37:43 -0400 (EDT) Received: from tawei-u5.cisco.com (tawei-u5.cisco.com [128.107.157.55]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3TIbfQj000278; Tue, 29 Apr 2003 11:37:41 -0700 (PDT) Date: Tue, 29 Apr 2003 11:37:40 -0700 (PDT) From: Tawei Liao To: "Andrew G. Malis" Cc: Fred Baker , ietf-ppp@merit.edu Subject: Re: Fwd: RFC 3518 In-Reply-To: <5.2.1.1.0.20030429130225.04533968@po1.vivacenetworks.com> Message-ID: References: <5.2.1.1.0.20030429130225.04533968@po1.vivacenetworks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id OAA04925 My take on the comments raised: (1) The abstract section Alfred's wording is better. We can list this as Errata on the RFC. Don't see a need to crank out a new one just to correct the abstract. (2) Frame Format description I disagree with the need to go into great detail on the meaning of type/length or TPID fields. The IEEE documents best describe what the fields mean. And their text is canon. The use of "Length/Type" nomenclature is also used throughout the IEEE 802.3 document. I just checked 802.3-2002 and "Length/Type" appears in figure 3-1 page 31 and again in section 3.2.6 and so on. It is beyond the scope of this RFC to spell out what each and every field of 802.3/4/5 PDU is and what it does. (3) On the pseudo-code This appendix has been in existence since RFC1638 published in June 1994. In the 8 years since, has anyone ever complained about this? Changing this now will cause more confusion. -tawei On Tue, 29 Apr 2003, Andrew G. Malis wrote: > Fred, > > I guess he took the term "Request for Comments" at face value! :-) Not > everyone can follow the work in progress ... > > If the authors/editors of the RFC, with the concurrence of the WG, see > value in the comments, then you may want to turn around a revised RFC with > just these changes. While I'm not a BCP expert, the comments generally > seem useful. > > Cheers, > Andy > > -------- > > At 4/28/2003 09:44 AM -0700, Fred Baker wrote: > > >We received this note this morning. I didn't see any note from him during > >the development of the draft, working group last call, or IETF last call. > >What does the working group want to do with the comments? > > > >>From: "Alfred H\Nnes" > >>Subject: RFC 3518 > >>To: Mitsuru.Higashiyama@yy.anritsu.co.jp > >>Date: Mon, 28 Apr 03 15:25:44 MESZ > >>Cc: fred@cisco.com, tawei@cisco.com, rfc-editor@rfc-editor.org > >> > >>Hello, > >> > >>I'd like to report to you some issues I found when reading the new > >>PPP-BCP RFC 3518 : > >> > >> > >>(1) On [Page 1], the last paragraph of the 'Abstract' section > >> does not correctly represent the situation before RFC 3518. > >> > >> At the similar place in RFC 2878, there was written: > >> > >> "This document obsoletes RFC 1638, which was based on the IEEE > >> 802.1D-1993 MAC Bridge[3]. This document extends that specification > >> by including the IEEE 802.1D-1998 MAC Bridge[8] and IEEE 802.1Q > >> Virtual LAN (VLAN)[9] standards. ..." > >> > >> Therefore, the sentence found in RFC 3518 : > >> > >> "This document obsoletes RFC 2878, which was based on the IEEE > >> 802.1D-1993 MAC Bridge. This document extends that specification ..." > >> ^^^^^^^^^^^ > >> > >> seems inappropriate and should better state: > >> > >> "This document obsoletes RFC 2878, which was based on the IEEE > >> 802.1D-1998 MAC Bridge[8] and IEEE 802.1Q Virtual LAN (VLAN)[9] > >> standards. This document extends that specification ..." > >> > >> (The unchanged reference tags are still correct.) > >> > >> But, since RFC 3518 does not add any new IEEE 802 related > >> functionality (the additions are purely PPP-BCP performance > >> clues), it even would suffice to state: > >> > >> "This document obsoletes RFC 2878. It extends that specification ..." > >> > >> > >>(2) The frame format descriptions in section 4.2. and section 4.3. still > >> lack of textual descriptions for > >> > >> - the "SNAP-encoded TPID" field (802.4/... tagged frame format), and > >> > >> - the "Length/Type" field (both 802.3 frame formats). > >> > >> {N.B.: > >> "Type" would usually mean an Ethernet frame; but that would be > >> inappropriate if the headline "802.3 Frame format" is taken > >> literally. > >> It is not clear from the text whether it is intended to admit > >> Ethernet frames too in section 4.2. (Existing implementations > >> obviously do!) Because these frames do not contain any 802.2 LLC > >> (+ eventually SNAP) header, in this case the "LLC data" field > >> should better be named "LLC / Ethernet data" in 4.2 on page 13. > >> I've never seen Ethernet-like frame-content in IEEE 802 Tagged > >> Frames; do such frames really exist?? -- if not, "Lenght/Type" > >> should be corrected to just read "Length" in 4.3 on page 17. > >> } > >> > >>(3) The pseudo code given in Appendix B for the Transmitter side still > >> sets the ZeroCompressionFlag in the case of a packet of minimal > >> length that does _not_ contain any padding bytes, i. e. in the > >> case where the 'while' loop bodies are never executed because > >> TrailingOctet (PDU) != 0 on first try. > >> > >> This behaviour indeed does not cause real harm, but it introduces > >> inefficiency into the Transmitter code and unnecessarily causes > >> additional code to be executed on the Receiver side as well; > >> therefore it would be better to not "specify" this behaviour. > >> (N.B.: It is not clear from the text whether Appendix B should > >> be considered normative or not.) > >> > >>Best regards, > >> Alfred Hönes. > > From owner-ietf-ppp@merit.edu Tue Apr 29 17:52:35 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12414 for ; Tue, 29 Apr 2003 17:52:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7EA5A9123A; Tue, 29 Apr 2003 17:55:07 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4C55091279; Tue, 29 Apr 2003 17:55:07 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4873F9123A for ; Tue, 29 Apr 2003 17:55:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 237485E3C0; Tue, 29 Apr 2003 17:55:06 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from kff (dhcp93126241.columbus.rr.com [24.93.126.241]) by segue.merit.edu (Postfix) with ESMTP id BD5FC5E3B6 for ; Tue, 29 Apr 2003 17:55:05 -0400 (EDT) Received: from [127.0.0.1] by kff (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Tue, 29 Apr 2003 17:53:51 -0400 Message-Id: <5.1.1.6.2.20030429175259.02b48b40@pop-server.columbus.rr.com> X-Sender: karlfox@pop-server.columbus.rr.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 29 Apr 2003 17:53:47 -0400 To: Tawei Liao , "Andrew G. Malis" From: Karl Fox Subject: Re: Fwd: RFC 3518 Cc: Fred Baker , ietf-ppp@merit.edu In-Reply-To: References: <5.2.1.1.0.20030429130225.04533968@po1.vivacenetworks.com> <5.2.1.1.0.20030429130225.04533968@po1.vivacenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA12414 If others agree with Tawei's comments, I'd recommend taking no action. Karl At 02:37 PM 4/29/03, Tawei Liao wrote: >My take on the comments raised: > >(1) The abstract section > >Alfred's wording is better. We can list this as Errata on the RFC. >Don't see a need to crank out a new one just to correct the abstract. > >(2) Frame Format description > >I disagree with the need to go into great detail on the meaning of >type/length or TPID fields. The IEEE documents best describe what >the fields mean. And their text is canon. > >The use of "Length/Type" nomenclature is also used throughout the >IEEE 802.3 document. I just checked 802.3-2002 and "Length/Type" >appears in figure 3-1 page 31 and again in section 3.2.6 and so on. > >It is beyond the scope of this RFC to spell out what each and every >field of 802.3/4/5 PDU is and what it does. > >(3) On the pseudo-code > >This appendix has been in existence since RFC1638 published in June >1994. In the 8 years since, has anyone ever complained about this? >Changing this now will cause more confusion. > >-tawei > >On Tue, 29 Apr 2003, Andrew G. Malis wrote: >> Fred, >> >> I guess he took the term "Request for Comments" at face value! :-) Not >> everyone can follow the work in progress ... >> >> If the authors/editors of the RFC, with the concurrence of the WG, see >> value in the comments, then you may want to turn around a revised RFC with >> just these changes. While I'm not a BCP expert, the comments generally >> seem useful. >> >> Cheers, >> Andy >> >> -------- >> >> At 4/28/2003 09:44 AM -0700, Fred Baker wrote: >> >> >We received this note this morning. I didn't see any note from him during >> >the development of the draft, working group last call, or IETF last call. >> >What does the working group want to do with the comments? >> > >> >>From: "Alfred H\Nnes" >> >>Subject: RFC 3518 >> >>To: Mitsuru.Higashiyama@yy.anritsu.co.jp >> >>Date: Mon, 28 Apr 03 15:25:44 MESZ >> >>Cc: fred@cisco.com, tawei@cisco.com, rfc-editor@rfc-editor.org >> >> >> >>Hello, >> >> >> >>I'd like to report to you some issues I found when reading the new >> >>PPP-BCP RFC 3518 : >> >> >> >> >> >>(1) On [Page 1], the last paragraph of the 'Abstract' section >> >> does not correctly represent the situation before RFC 3518. >> >> >> >> At the similar place in RFC 2878, there was written: >> >> >> >> "This document obsoletes RFC 1638, which was based on the IEEE >> >> 802.1D-1993 MAC Bridge[3]. This document extends that specification >> >> by including the IEEE 802.1D-1998 MAC Bridge[8] and IEEE 802.1Q >> >> Virtual LAN (VLAN)[9] standards. ..." >> >> >> >> Therefore, the sentence found in RFC 3518 : >> >> >> >> "This document obsoletes RFC 2878, which was based on the IEEE >> >> 802.1D-1993 MAC Bridge. This document extends that specification ..." >> >> ^^^^^^^^^^^ >> >> >> >> seems inappropriate and should better state: >> >> >> >> "This document obsoletes RFC 2878, which was based on the IEEE >> >> 802.1D-1998 MAC Bridge[8] and IEEE 802.1Q Virtual LAN (VLAN)[9] >> >> standards. This document extends that specification ..." >> >> >> >> (The unchanged reference tags are still correct.) >> >> >> >> But, since RFC 3518 does not add any new IEEE 802 related >> >> functionality (the additions are purely PPP-BCP performance >> >> clues), it even would suffice to state: >> >> >> >> "This document obsoletes RFC 2878. It extends that specification ..." >> >> >> >> >> >>(2) The frame format descriptions in section 4.2. and section 4.3. still >> >> lack of textual descriptions for >> >> >> >> - the "SNAP-encoded TPID" field (802.4/... tagged frame format), and >> >> >> >> - the "Length/Type" field (both 802.3 frame formats). >> >> >> >> {N.B.: >> >> "Type" would usually mean an Ethernet frame; but that would be >> >> inappropriate if the headline "802.3 Frame format" is taken >> >> literally. >> >> It is not clear from the text whether it is intended to admit >> >> Ethernet frames too in section 4.2. (Existing implementations >> >> obviously do!) Because these frames do not contain any 802.2 LLC >> >> (+ eventually SNAP) header, in this case the "LLC data" field >> >> should better be named "LLC / Ethernet data" in 4.2 on page 13. >> >> I've never seen Ethernet-like frame-content in IEEE 802 Tagged >> >> Frames; do such frames really exist?? -- if not, "Lenght/Type" >> >> should be corrected to just read "Length" in 4.3 on page 17. >> >> } >> >> >> >>(3) The pseudo code given in Appendix B for the Transmitter side still >> >> sets the ZeroCompressionFlag in the case of a packet of minimal >> >> length that does _not_ contain any padding bytes, i. e. in the >> >> case where the 'while' loop bodies are never executed because >> >> TrailingOctet (PDU) != 0 on first try. >> >> >> >> This behaviour indeed does not cause real harm, but it introduces >> >> inefficiency into the Transmitter code and unnecessarily causes >> >> additional code to be executed on the Receiver side as well; >> >> therefore it would be better to not "specify" this behaviour. >> >> (N.B.: It is not clear from the text whether Appendix B should >> >> be considered normative or not.) >> >> >> >>Best regards, >> >> Alfred Hönes. >> >> From owner-ietf-ppp@merit.edu Tue Apr 29 20:47:41 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18994 for ; Tue, 29 Apr 2003 20:47:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4EF6191241; Tue, 29 Apr 2003 20:50:07 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A89D91285; Tue, 29 Apr 2003 20:50:06 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1ED0D91241 for ; Tue, 29 Apr 2003 20:50:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ED9C05DF64; Tue, 29 Apr 2003 20:50:05 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from ns.anritsu.co.jp (ns.anritsu.co.jp [133.236.48.2]) by segue.merit.edu (Postfix) with ESMTP id 4F0185DE10 for ; Tue, 29 Apr 2003 20:50:05 -0400 (EDT) Received: from gatekeeper.noc.anritsu.co.jp (gatekeeper.noc.anritsu.co.jp [172.16.16.20]) by ns.anritsu.co.jp (Postfix) with ESMTP id 2572421099 for ; Wed, 30 Apr 2003 09:50:04 +0900 (JST) Received: from ATS-VIRUS-001 (ats-virus-001.noc.anritsu.co.jp [172.16.16.26]) by gatekeeper.noc.anritsu.co.jp (Postfix) with SMTP id D6D6120F47 for ; Wed, 30 Apr 2003 09:50:03 +0900 (JST) Received: FROM mail0.cr.anritsu.co.jp BY ATS-VIRUS-001 ; Wed Apr 30 09:46:31 2003 +0900 Message-ID: <3EAF1DB1.8060607@yy.anritsu.co.jp> Date: Wed, 30 Apr 2003 09:49:53 +0900 From: Mitsuru Higashiyama User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: ja MIME-Version: 1.0 To: Tawei Liao Cc: "Andrew G. Malis" Subject: Re: Fwd: RFC 3518 References: <5.2.1.1.0.20030429130225.04533968@po1.vivacenetworks.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 I support Tawei's comment. Thanks, Mitsuru Tawei Liao wrote: >My take on the comments raised: > >(1) The abstract section > >Alfred's wording is better. We can list this as Errata on the RFC. >Don't see a need to crank out a new one just to correct the abstract. > >(2) Frame Format description > >I disagree with the need to go into great detail on the meaning of >type/length or TPID fields. The IEEE documents best describe what >the fields mean. And their text is canon. > >The use of "Length/Type" nomenclature is also used throughout the >IEEE 802.3 document. I just checked 802.3-2002 and "Length/Type" >appears in figure 3-1 page 31 and again in section 3.2.6 and so on. > >It is beyond the scope of this RFC to spell out what each and every >field of 802.3/4/5 PDU is and what it does. > >(3) On the pseudo-code > >This appendix has been in existence since RFC1638 published in June >1994. In the 8 years since, has anyone ever complained about this? >Changing this now will cause more confusion. > >-tawei > >On Tue, 29 Apr 2003, Andrew G. Malis wrote: > > >>Fred, >> >>I guess he took the term "Request for Comments" at face value! :-) Not >>everyone can follow the work in progress ... >> >>If the authors/editors of the RFC, with the concurrence of the WG, see >>value in the comments, then you may want to turn around a revised RFC with >>just these changes. While I'm not a BCP expert, the comments generally >>seem useful. >> >>Cheers, >>Andy >> >>-------- >> >>At 4/28/2003 09:44 AM -0700, Fred Baker wrote: >> >> >> >>>We received this note this morning. I didn't see any note from him during >>>the development of the draft, working group last call, or IETF last call. >>>What does the working group want to do with the comments? >>> >>> >>> >>>>From: "Alfred H\Nnes" >>>>Subject: RFC 3518 >>>>To: Mitsuru.Higashiyama@yy.anritsu.co.jp >>>>Date: Mon, 28 Apr 03 15:25:44 MESZ >>>>Cc: fred@cisco.com, tawei@cisco.com, rfc-editor@rfc-editor.org >>>> >>>>Hello, >>>> >>>>I'd like to report to you some issues I found when reading the new >>>>PPP-BCP RFC 3518 : >>>> >>>> >>>>(1) On [Page 1], the last paragraph of the 'Abstract' section >>>> does not correctly represent the situation before RFC 3518. >>>> >>>> At the similar place in RFC 2878, there was written: >>>> >>>> "This document obsoletes RFC 1638, which was based on the IEEE >>>> 802.1D-1993 MAC Bridge[3]. This document extends that specification >>>> by including the IEEE 802.1D-1998 MAC Bridge[8] and IEEE 802.1Q >>>> Virtual LAN (VLAN)[9] standards. ..." >>>> >>>> Therefore, the sentence found in RFC 3518 : >>>> >>>> "This document obsoletes RFC 2878, which was based on the IEEE >>>> 802.1D-1993 MAC Bridge. This document extends that specification ..." >>>> ^^^^^^^^^^^ >>>> >>>> seems inappropriate and should better state: >>>> >>>> "This document obsoletes RFC 2878, which was based on the IEEE >>>> 802.1D-1998 MAC Bridge[8] and IEEE 802.1Q Virtual LAN (VLAN)[9] >>>> standards. This document extends that specification ..." >>>> >>>> (The unchanged reference tags are still correct.) >>>> >>>> But, since RFC 3518 does not add any new IEEE 802 related >>>> functionality (the additions are purely PPP-BCP performance >>>> clues), it even would suffice to state: >>>> >>>> "This document obsoletes RFC 2878. It extends that specification ..." >>>> >>>> >>>>(2) The frame format descriptions in section 4.2. and section 4.3. still >>>> lack of textual descriptions for >>>> >>>> - the "SNAP-encoded TPID" field (802.4/... tagged frame format), and >>>> >>>> - the "Length/Type" field (both 802.3 frame formats). >>>> >>>> {N.B.: >>>> "Type" would usually mean an Ethernet frame; but that would be >>>> inappropriate if the headline "802.3 Frame format" is taken >>>> literally. >>>> It is not clear from the text whether it is intended to admit >>>> Ethernet frames too in section 4.2. (Existing implementations >>>> obviously do!) Because these frames do not contain any 802.2 LLC >>>> (+ eventually SNAP) header, in this case the "LLC data" field >>>> should better be named "LLC / Ethernet data" in 4.2 on page 13. >>>> I've never seen Ethernet-like frame-content in IEEE 802 Tagged >>>> Frames; do such frames really exist?? -- if not, "Lenght/Type" >>>> should be corrected to just read "Length" in 4.3 on page 17. >>>> } >>>> >>>>(3) The pseudo code given in Appendix B for the Transmitter side still >>>> sets the ZeroCompressionFlag in the case of a packet of minimal >>>> length that does _not_ contain any padding bytes, i. e. in the >>>> case where the 'while' loop bodies are never executed because >>>> TrailingOctet (PDU) != 0 on first try. >>>> >>>> This behaviour indeed does not cause real harm, but it introduces >>>> inefficiency into the Transmitter code and unnecessarily causes >>>> additional code to be executed on the Receiver side as well; >>>> therefore it would be better to not "specify" this behaviour. >>>> (N.B.: It is not clear from the text whether Appendix B should >>>> be considered normative or not.) >>>> >>>>Best regards, >>>> Alfred H?nes. >>>> >>>> >> >> > > >