From pppext-bounces@ietf.org Mon Aug 01 11:48:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzcWs-00055g-UG; Mon, 01 Aug 2005 11:48:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzcWr-00055b-Dl for pppext@megatron.ietf.org; Mon, 01 Aug 2005 11:48:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19555 for ; Mon, 1 Aug 2005 11:48:35 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzd38-0007ao-PZ for pppext@ietf.org; Mon, 01 Aug 2005 12:22:00 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 01 Aug 2005 11:48:25 -0400 X-IronPort-AV: i="3.95,157,1120449600"; d="scan'208"; a="64727920:sNHT2150429676" Received: from cisco.com (shako.cisco.com [64.102.17.78]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j71FmOVu009112 for ; Mon, 1 Aug 2005 11:48:24 -0400 (EDT) Received: from cisco.com (lanzo-u10.cisco.com [64.102.48.21]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA26030 for ; Mon, 1 Aug 2005 11:48:21 -0400 (EDT) Message-Id: <200508011548.LAA26030@cisco.com> Date: Wed, 27 Jul 2005 15:38:03 -0400 (EDT) From: Mark Lanzo Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) To: pppext@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-Spam-Score: 1.2 (+) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org On 27 Jul, Vernon Schryver wrote: >> From: Mark Lanzo >> To: vjs@calcite.rhyolite.com >> cc: townsley@cisco.com, margaret@thingmagic.com, pppext@ietf.org, >> bberry@cisco.com, hholgate@cisco.com > > >> PPPoE is really just being used as a means to multiplex multiple >> PPP sessions over the ethernet link to the radio, and as a carrier >> for signalling info between radio and router. > > Which raises my question of what PPPoE has to do with the solution > and my point that PPP(oE) is widely misunderstood as other than a > link layer protocol. Why use PPPoE to link networks instead of IP? The proposal *is* using PPPoE as the link layer. If anything, more than PPPoE is normally used as such. The whole point is that you have a router and an external radio. The radio has an ethernet port on it, by which it attaches to the router. The radio itself detects other radios in its vicinity, and creates a semblance of a serial connection to each of those adjacent radios. The customer wants the router to run PPP on these serial connections. The radio doesn't provide a slew of serial ports to attach to the router, one for each of the remote radio nodes. All it provides is an ethernet port. So the radio is basically a smarter-than-average serial port card with lots of ports, which plugs into the router via an ethernet rather than being inserted into a slot on the router's backplane. The serial links have to be simulated at the router end. Bottom line being that the ethernet is really just a funky "backplane" here, and the goal is to couple the router as close as is reasonably possible to its "serial" ports. All the different serial sessions have to somehow be multiplexed over the ethernet port which acts as the bus to the radio. So how do you do that? Obviously you need some sort of frame format which can carry a "serial" packet to/from the radio, and which also includes some sort of identifier so that both router and radio can distinguish which particular remote serial user this packet is for. It is also desirable to have some sort of method for conveying signalling information related to the virtual serial links - a new link has appeared, an old one is gone, a link is congested, etc. You could invent a new protocol for this, get a new ethertype assigned to you, etc etc. Or you could recognize that the PPPoE frame format, and even the PPPoE protocol (with some relatively minor additions) fits the bill. I understand why you think of PPPoE as a kludge, and can understand reluctance to propogate use of a kludge. Still, it seems to me that if anything that the intended use here is a better use - less of a kludge - than PPPoE as it is normally deployed. It occurs to me that the biggest faux pas here is mentioning PPP in the name. This scheme really does relegate PPPoE to the link layer, and for that matter practically divorces PPP from PPPoE altogether. In truth, it's just a method for transferring serial packets over the "backplane" to the radio. The fact that the packets contain PPP frames is barely relevant. Unfortunately, describing the proposal as an extension to "PPPoE" seems to be having a very negative effect, because it brings with it all the negative baggage associated with PPPoE. >> A completely new protocol could have been devised for all of this, >> but since the nature of the info traded by that protocol would have >> been very much like the nature of the info traded by PPPoE, I think >> the authors wanted to use PPPoE precisely so they wouldn't be >> completely reinventing the same old wheel. The purpose of the document >> isn't to make a general-purpose extension to PPPoE, it's to create >> a special purpose extension for a very specific sort of environment. > > So why not use the official IETF standard way to link networks instead > of piling kludges on top of the kludge that is PPPoE? What standard official IETF way of multiplexing virtual serial connections over an ethernet (or any media) "backplane" are you referring to? > The IETF standard way would be to give the routers IP addresses and > use a real routing protocol (or even static routes) instead of what > looks sounds like a retread of IGRP. You might use PPPoE (or not) > between the access concentrators and their neighboring stationary > radios. You might define a PPP over RLP encapsulation that would have > credits, battery condition, and so forth among the radios. > Wouldn't that produce products with a wider potential market Just the opposite, actually (hopefully). Routers already exist which support PPPoE. Using PPPoE in this rather unusual fashion means the ability to hook these specialized radios into existing router equipment. Significantly improved performance is gained for those routers which implement the proposed extensions. It seems more likely that manufacturers would augment already developed PPPoE implementations than implement a whole new protocol. > ... as well > as fewer nastinesses such as an MTU that is even smaller than the bad > old PPPoE MTU of 1492? That is admittedly still an issue. As long as the "backplane" to the "radio card" is an ethernet, it doesn't seem easy to avoid this (short of resorting to some form of link layer fragmentation). It is also a bit off-topic since this is a technical limitation not arising from anything within the draft itself, well understood, and which the draft makes no claim of trying to overcome. > Why egregiously violate layering by trying to convert IEEE 802.3 > into an inter-network protocol? Hopefully it is clear by now that the above statement is inaccurate, and arises from misperceptions about the proposed mechanisms. As I indicated above, it seems to me that there is a lot of reaction to this draft, but the reaction is due (at least in part) to the bias against traditional PPPoE and not due to the technical merits (or lack thereof) of this proposal or its intended goals. My thought is that the draft may not be wholly clear about the environment and application, and this is leading to confusion. This suggests to me that the draft could bear a fair amount of expansion and augmentation, before it is ready for RFC status. I.e. there may be legitimate reason to not accept the draft as it currently stands, but those reasons have more to do with clarity and completeness of the document than the technical merits of the proposal. At any rate, I'm going to try to stay out of the discussion after this. Despite all the verbiage I've tossed out, it is not my intent to be a spokesman for the proposed mechanism -- the authors can do that. I don't have a personal stake in this, but I've had the benefit of in-person discussions with the group behind this, without which, I suspect the draft wouldn't have made a lot of sense to me either. _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Aug 01 12:33:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzdEh-0005LO-As; Mon, 01 Aug 2005 12:33:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzdEf-0005JR-ME for pppext@megatron.ietf.org; Mon, 01 Aug 2005 12:33:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22441 for ; Mon, 1 Aug 2005 12:33:51 -0400 (EDT) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzdky-0001Gg-NK for pppext@ietf.org; Mon, 01 Aug 2005 13:07:17 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j71GXTYQ020288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for env-from ; Mon, 1 Aug 2005 10:33:29 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j71GXTpB020287 for pppext@ietf.org; Mon, 1 Aug 2005 10:33:29 -0600 (MDT) Date: Mon, 1 Aug 2005 10:33:29 -0600 (MDT) From: Vernon Schryver Message-Id: <200508011633.j71GXTpB020287@calcite.rhyolite.com> To: pppext@ietf.org Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) In-Reply-To: <200508011548.LAA26030@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org > From: Mark Lanzo > > Which raises my question of what PPPoE has to do with the solution > > and my point that PPP(oE) is widely misunderstood as other than a > > link layer protocol. Why use PPPoE to link networks instead of IP? > > The proposal *is* using PPPoE as the link layer. If anything, more > than PPPoE is normally used as such. No, as far as I can tell PPPoE is being used as a network layer. > The whole point is that you have a router and an external radio. > The radio has an ethernet port on it, by which it attaches to the > router. The radio itself detects other radios in its vicinity, > and creates a semblance of a serial connection to each of those > adjacent radios. The radio is also a router. That it is routing PPPoE frames instead of IP packets does not make it other than a router. There were routers before IP was invented. There are still routers that have nothing to do with IP. > The customer wants the router to run PPP on these > serial connections. Why does the customer care whether PPP runs on the radio links? What kind of PPP does the customer want? Are you sure the customer will be happy to have the crippled PPPoE MTU further crippled? > The radio doesn't provide a slew of serial ports to attach to the > router, one for each of the remote radio nodes. That seems irrelevant. Many routers for many inter-network protocols do not involve banks of serial ports. > All it provides is an > ethernet port. Ok, but that is like many other routers. Consider an 802.3 or FDDI to ATM or FR router with one physical fiber or RJ-11 connection for the LAN and one physcial connection to the telephone company ATM or FR wire. > So the radio is basically a smarter-than-average serial > port card with lots of ports, which plugs into the router via an > ethernet rather than being inserted into a slot on the router's backplane. That does not change the fact that it is a router. It routes or gateways packets between one link layer network that happens to be running eithernet and another link layer network that happens to involve the real ether. I have not figured out whether the frames on the real ether are PPPoE or some other flavor of PPP or no PPP at all. I've seen words about that seem to conflict. > The serial links have to be simulated at the router end. Bottom line > being that the ethernet is really just a funky "backplane" here, and > the goal is to couple the router as close as is reasonably possible to > its "serial" ports. By that reasoning, there are no routers in NPXs, where FDDI, 802.3, and other link layers are just being used as funky backplanes. > All the different serial sessions have to somehow be multiplexed > over the ethernet port which acts as the bus to the radio. So how do > you do that? Obviously you need some sort of frame format which can carry > a "serial" packet to/from the radio, and which also includes some sort > of identifier so that both router and radio can distinguish which particular > remote serial user this packet is for. It is also desirable to have some > sort of method for conveying signalling information related to the virtual > serial links - a new link has appeared, an old one is gone, a link > is congested, etc. > > You could invent a new protocol for this, get a new ethertype assigned > to you, etc etc. Or you could recognize that the PPPoE frame format, > and even the PPPoE protocol (with some relatively minor additions) > fits the bill. Why do that? Why couldn't one do as I said and assign IP addresses to the radios and use IP packets for all of this multiplexing and demultiplexing? > I understand why you think of PPPoE as a kludge, Without intending any offense, I really think you do not know why I think PPPoE is wrong and evil and are even less clear about what I do not like about this proposal. > It occurs to me that the biggest faux pas here is mentioning PPP in the > name. This scheme really does relegate PPPoE to the link layer, and > for that matter practically divorces PPP from PPPoE altogether. In > truth, it's just a method for transferring serial packets over the > "backplane" to the radio. The fact that the packets contain PPP frames > is barely relevant. Unfortunately, describing the proposal as an > extension to "PPPoE" seems to be having a very negative effect, because > it brings with it all the negative baggage associated with PPPoE. No the biggest issue (I won't say faux pas) is that the confusion between the natures of link layers and network layers. As far as I can tell, this proposal is a classic example of re-inventing the idea of an inter-network protocol within a link layer. It is certainly not the only example of such re-inventions since TCP/IP beat the ISO OSI protocol suite. Other examples including the obvious case from Cisco may be justified on performance grounds...or perhaps *were* justified before people started making silicon that could classify IP headers at very high speed. > > So why not use the official IETF standard way to link networks instead > > of piling kludges on top of the kludge that is PPPoE? > > What standard official IETF way of multiplexing virtual serial > connections over an ethernet (or any media) "backplane" are you > referring to? What's that about "virtual serial connections"? Exactly what do you mean? Many and perhaps most serial connections are "virtual" today. The IETF standard way for multiplexing virtual serial over an Ethernet is TCP/IP. Note that I am *NOT* talking about PPP/telnet/TCP/IP, PPP/rsh/TCP/IP, or certain other kludges. I'm expressing my confusion about "virtual serial connections." I suspect the idea is to run PPPoE over the radios, and instead of terminating those PPPoE links in the base station radio card, idea to be cheap and nasty and let some *other* router do the work of an access concentrator router. > Just the opposite, actually (hopefully). Routers already exist which > support PPPoE. Using PPPoE in this rather unusual fashion means the > ability to hook these specialized radios into existing router equipment. > Significantly improved performance is gained for those routers which > implement the proposed extensions. It seems more likely that manufacturers > would augment already developed PPPoE implementations than implement a > whole new protocol. What is that about a "whole new protocol"? I do not understand what is running on the radio links. What do is used for access control/collision detection/etc., something in the ALOHA tradition? Or some kind of slotting or (virtual) token? How do you do framing? What about authentication? I think you or someone said it was plain old PPP. If that's right, is it PPPoE? But I think other words said no PPPoE on the real ether. > > Why egregiously violate layering by trying to convert IEEE 802.3 > > into an inter-network protocol? > > Hopefully it is clear by now that the above statement is inaccurate, > and arises from misperceptions about the proposed mechanisms. Again, as far as I can tell, the misperceptions are not mine but fundamental to the proposal to use PPPoE as an inter-network protocol. The glaring clue is it uses PPPoE for (de)multiplexing of 802.3 packets. > As I indicated above, it seems to me that there is a lot of reaction > to this draft, but the reaction is due (at least in part) to the bias > against traditional PPPoE and not due to the technical merits (or lack > thereof) of this proposal or its intended goals. That is mistaken. My reaction is not against using PPPoE, but against using PPPoE as a replacement for IP. > My thought is that the > draft may not be wholly clear about the environment and application, > and this is leading to confusion. This suggests to me that the draft > could bear a fair amount of expansion and augmentation, before it > is ready for RFC status. I agree with that. Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Aug 01 12:45:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzdQE-0001se-OW; Mon, 01 Aug 2005 12:45:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzdQC-0001sO-By for pppext@megatron.ietf.org; Mon, 01 Aug 2005 12:45:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23176 for ; Mon, 1 Aug 2005 12:45:43 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzdwP-0001pF-9R for pppext@ietf.org; Mon, 01 Aug 2005 13:19:10 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j71Gjer3001897 for ; Mon, 1 Aug 2005 10:45:40 -0600 (MDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j71GjdFx003286 for ; Mon, 1 Aug 2005 12:45:39 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j71GjdFO010952; Mon, 1 Aug 2005 12:45:39 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j71GjdXt010949; Mon, 1 Aug 2005 12:45:39 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17134.20915.445420.680395@gargle.gargle.HOWL> Date: Mon, 1 Aug 2005 12:45:39 -0400 From: James Carlson To: Fred Baker , Mark Lanzo Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) In-Reply-To: Fred Baker's message of 29 July 2005 19:16:53 References: <200508011548.LAA26030@cisco.com> <200507280309.j6S39jLh023383@calcite.rhyolite.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, hholgate@cisco.com, Vernon Schryver , margaret@thingmagic.com, townsley@cisco.com, bberry@cisco.com X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Fred Baker writes: > I'll remind you of a statement earlier in the thread. The objective > was specifically *not* to impose reliability on the link in the sense > that LAPB or TCP are reliable. The objective was to provide a way > that a system-engineered interface could advise a higher layer entity > in a different system implementation (connected via Ethernet) of a > rate at which it was permitted to send. In other words, flow control of Ethernet traffic. Here are the issues I see: - What exactly do we do if there's more than *one* L2 link in the path between these two nodes that requires flow control? - Isn't this a more general problem with bridged Ethernets using different-speed links? Why is a point solution acceptable in this one case where the real problem is that there's no end-to-end flow control mechanism in Ethernet networks? Apart from the questions of endpoint parameter assignment (which I think are more than adequately dealt with using existing protocols, such as DHCP, rather than pressing PPP into service in non-point-to- point applications) and authentication (802.1X), the purpose here seems to be to use PPPoE just because it could be extended to provide a flow-control mechanism. In short, it seems to be a local "optimization" that would have little general usability, would likely complicate other's implementations for no good reason, and would even inhibit or conflict with real solutions to the problem. (If bridging over these radios is an important solution space, and if the lack of buffer space and variance in transmit access times are such that per-peer flow control is a requirement, why isn't this dealt with either in the radio itself or in the way bridging is run in these special cases, or even as a general 802 problem?) It seems to me like PPPoE is being used as a willing victim. The reason *I* mentioned RFC 1663's LAPB was that I was a bit surprised that the document contained no actual references to other solutions in the same area. At least I think it would help to be able to say "we considered LAPB framing as part of the mechanism rather than inventing our own credit-based scheme and header changes and network monitoring gear to go with it, but LAPB cannot be extended to omit retransmission and do flow control alone because of ." I can't quite fill in that , though. Mark Lanzo writes: > On 27 Jul, Vernon Schryver wrote: > > Which raises my question of what PPPoE has to do with the solution > > and my point that PPP(oE) is widely misunderstood as other than a > > link layer protocol. Why use PPPoE to link networks instead of IP? > > The proposal *is* using PPPoE as the link layer. If anything, more > than PPPoE is normally used as such. That doesn't answer the "why" question. IP runs fine over Ethernet. > The whole point is that you have a router and an external radio. > The radio has an ethernet port on it, by which it attaches to the > router. The radio itself detects other radios in its vicinity, > and creates a semblance of a serial connection to each of those > adjacent radios. The customer wants the router to run PPP on these > serial connections. It's that "semblance" that I think is a problem here. > The serial links have to be simulated at the router end. Bottom line > being that the ethernet is really just a funky "backplane" here, and > the goal is to couple the router as close as is reasonably possible to > its "serial" ports. I think that's an oversimplification in at least one area: if the radio can speak Ethernet to each of the end nodes, why do you care about having any mesh of "serial ports" overlaid on this topology? IP already works on Ethernet, and just sending IP/Ethernet packets to those remote destinations ought to work fine over any useful bridge. What seems to be missing is that this device, although it tries to be a bridge, just isn't a very good Ethernet bridge; it lacks the burst handling and flow control characteristics that would make it good enough to use. I'm not sure that papering over that problem by creating a complex web of additional layered protocols (plus a smattering of *new* protocols that need to be implemented and tested) is the right way to solve that problem. > I understand why you think of PPPoE as a kludge, and can understand > reluctance to propogate use of a kludge. Still, it seems to me that > if anything that the intended use here is a better use - less of a > kludge - than PPPoE as it is normally deployed. That's the point where we disagree. The way I read it, you've already assumed that a mesh of point-to-point connections is the right representation of this topology, and that PPPoE follows naturally from that. I agree that if that topology is part of the requirements somehow, then this answer is _perhaps_ less awful than others, but I don't see why it's actually required. > "backplane" to the radio. The fact that the packets contain PPP frames > is barely relevant. Unfortunately, describing the proposal as an > extension to "PPPoE" seems to be having a very negative effect, because > it brings with it all the negative baggage associated with PPPoE. No, I don't think that's the problem. Plus some of the issues (such as the MTU problem) occur *BECAUSE* this is the chosen solution, not because of any negative connotation of PPPoE. > > So why not use the official IETF standard way to link networks instead > > of piling kludges on top of the kludge that is PPPoE? > > What standard official IETF way of multiplexing virtual serial > connections over an ethernet (or any media) "backplane" are you > referring to? I don't think that's the right question at all. The official IETF standard way of running IP over Ethernet, though, is documented in RFC 894. > > Wouldn't that produce products with a wider potential market > > Just the opposite, actually (hopefully). Routers already exist which > support PPPoE. Using PPPoE in this rather unusual fashion means the > ability to hook these specialized radios into existing router equipment. None of the existing PPPoE implementations support this credit scheme. What to do about them? > Significantly improved performance is gained for those routers which > implement the proposed extensions. It seems more likely that manufacturers > would augment already developed PPPoE implementations than implement a > whole new protocol. This *is* a whole new protocol. I think you're arguing that they're already familiar with PPPoE and are thus comfortable with hacking on that. I'm not convinced that this is really a good way to make architectural decisions about networking protocols. It's all too easy to run into the hammer problem: when all you have is a hammer, every problem begins to look like a nail. > That is admittedly still an issue. As long as the "backplane" to the > "radio card" is an ethernet, it doesn't seem easy to avoid this (short > of resorting to some form of link layer fragmentation). It is also > a bit off-topic since this is a technical limitation not arising from > anything within the draft itself, well understood, and which the draft > makes no claim of trying to overcome. I don't think it's off-topic at all. It's right on topic for the question of whether the proposed solution is solving the right problem. > > Why egregiously violate layering by trying to convert IEEE 802.3 > > into an inter-network protocol? > > Hopefully it is clear by now that the above statement is inaccurate, > and arises from misperceptions about the proposed mechanisms. I don't think it's really all that inaccurate. There are flow control problems here directly due to the implementation choices. > As I indicated above, it seems to me that there is a lot of reaction > to this draft, but the reaction is due (at least in part) to the bias > against traditional PPPoE and not due to the technical merits (or lack > thereof) of this proposal or its intended goals. My thought is that the While I'm no fan of PPPoE (having implemented it in Solaris), I don't think this is true. I just see wider issues here that aren't being properly addressed. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Aug 01 13:01:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzdfe-0003lN-Fv; Mon, 01 Aug 2005 13:01:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzdfc-0003kk-N8 for pppext@megatron.ietf.org; Mon, 01 Aug 2005 13:01:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24036 for ; Mon, 1 Aug 2005 13:01:41 -0400 (EDT) Received: from cosmos.ds.org ([67.42.187.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzeBr-0002VB-3S for pppext@ietf.org; Mon, 01 Aug 2005 13:35:08 -0400 Received: from [172.30.1.193] (unknown [67.103.19.117]) by cosmos.ds.org (Postfix) with ESMTP id 350CA17CB6; Mon, 1 Aug 2005 11:01:22 -0600 (MDT) In-Reply-To: <17134.20915.445420.680395@gargle.gargle.HOWL> References: <200508011548.LAA26030@cisco.com> <200507280309.j6S39jLh023383@calcite.rhyolite.com> <17134.20915.445420.680395@gargle.gargle.HOWL> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Karl Fox Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) Date: Mon, 1 Aug 2005 13:01:21 -0400 To: James Carlson X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, hholgate@cisco.com, Fred Baker , Vernon Schryver , margaret@thingmagic.com, townsley@cisco.com, bberry@cisco.com, Mark Lanzo X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org On Aug 1, 2005, at 12:45 PM, James Carlson wrote: > Mark Lanzo writes: >> On 27 Jul, Vernon Schryver wrote: >>> Which raises my question of what PPPoE has to do with the solution >>> and my point that PPP(oE) is widely misunderstood as other than a >>> link layer protocol. Why use PPPoE to link networks instead of IP? >> >> The proposal *is* using PPPoE as the link layer. If anything, more >> than PPPoE is normally used as such. > > That doesn't answer the "why" question. IP runs fine over Ethernet. > >> The whole point is that you have a router and an external radio. >> The radio has an ethernet port on it, by which it attaches to the >> router. The radio itself detects other radios in its vicinity, >> and creates a semblance of a serial connection to each of those >> adjacent radios. The customer wants the router to run PPP on these >> serial connections. > > It's that "semblance" that I think is a problem here. Jim, I think you just hit the nail on the head--why does the customer want to simulate a serial connection? And as you and Vernon have both asked, why interpose this troublesome serial emulation (which is ITSELF the source of the need for flow control) in the middle of a packet networking stack when the real service to the end user is packet delivery and the radios are themselves packet delivery devices? Let me speculate: Is it because the customers are ISPs who started out with serial modems carrying PPP, and who now are so ossified by their legacy serial-centric back office systems that they want every new technology to look exactly like a serial modem? Or is there a real technical need that I haven't grasped yet? Karl _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Aug 01 13:15:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzdsp-000500-3u; Mon, 01 Aug 2005 13:15:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzdsm-0004y4-Hi for pppext@megatron.ietf.org; Mon, 01 Aug 2005 13:15:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24977 for ; Mon, 1 Aug 2005 13:15:17 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzeP6-0003CG-1C for pppext@ietf.org; Mon, 01 Aug 2005 13:48:44 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j71HFIvU019142 for ; Mon, 1 Aug 2005 11:15:18 -0600 (MDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j71HFGG1011353 for ; Mon, 1 Aug 2005 13:15:17 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j71HFDnX011113; Mon, 1 Aug 2005 13:15:13 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j71HFDDg011110; Mon, 1 Aug 2005 13:15:13 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17134.22689.505913.137026@gargle.gargle.HOWL> Date: Mon, 1 Aug 2005 13:15:13 -0400 From: James Carlson To: Karl Fox Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) In-Reply-To: Karl Fox's message of 1 August 2005 13:01:21 References: <200508011548.LAA26030@cisco.com> <200507280309.j6S39jLh023383@calcite.rhyolite.com> <17134.20915.445420.680395@gargle.gargle.HOWL> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 2.0 (++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, hholgate@cisco.com, Fred Baker , Vernon Schryver , margaret@thingmagic.com, townsley@cisco.com, bberry@cisco.com, Mark Lanzo X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Karl Fox writes: > Let me speculate: Is it because the customers are ISPs who started > out with serial modems carrying PPP, and who now are so ossified by > their legacy serial-centric back office systems that they want every > new technology to look exactly like a serial modem? Or is there a > real technical need that I haven't grasped yet? Even if the reason is the former, that's not a very good argument for adding the flow control bits here. (Why not add credits to the IP header? Or add special radio signal and battery life extensions to TCP?) The more benign answer (expressed by others so far) is that PPPoE was an available solution that could be modified to work in this environment. The aspect that I don't like about it is the idea that this somehow makes it "cheaper" to modify PPPoE to solve the problem. I don't think it does. What does happen instead is that every vendor who has begrudgingly added support for PPPoE ends up being told by customers that this new "performance extension" documented in RFC XXXX is 'required' for deployment. In other words, those who are completely uninvolved in the local world of radio-based Ethernet bridges end up tithing towards supporting that niche. Stupid question time: why are these inherent radio-caused flow control issues _not_ a problem for 802.11 and related technologies? Why is it that this one radio technology requires special flow control considerations in *other* equipment outside of that domain, but 802.11 does seemingly the same task and doesn't require special support? Or are these issues an unresolved (and until-now unrecognized) problem with 802.11 that simply must be handled at higher levels? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Aug 01 13:52:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzeSr-0007WW-FB; Mon, 01 Aug 2005 13:52:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzeSo-0007Vc-ML for pppext@megatron.ietf.org; Mon, 01 Aug 2005 13:52:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27577 for ; Mon, 1 Aug 2005 13:52:31 -0400 (EDT) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzez6-00050U-Jf for pppext@ietf.org; Mon, 01 Aug 2005 14:25:59 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j71HowXI063167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) env-from ; Mon, 1 Aug 2005 11:50:58 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j71Hovjo063166; Mon, 1 Aug 2005 11:50:57 -0600 (MDT) Date: Mon, 1 Aug 2005 11:50:57 -0600 (MDT) From: Vernon Schryver Message-Id: <200508011750.j71Hovjo063166@calcite.rhyolite.com> To: james.d.carlson@sun.com, karlfox@columbus.rr.com Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) In-Reply-To: <17134.22689.505913.137026@gargle.gargle.HOWL> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: pppext@ietf.org, hholgate@cisco.com, fred@cisco.com, lanzo@cisco.com, margaret@thingmagic.com, townsley@cisco.com, bberry@cisco.com X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org > From: James Carlson > To: Karl Fox > Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) > Cc: pppext@ietf.org, hholgate@cisco.com, Fred Baker , > Vernon Schryver , margaret@thingmagic.com, > townsley@cisco.com, bberry@cisco.com, Mark Lanzo > Stupid question time: why are these inherent radio-caused flow control > issues _not_ a problem for 802.11 and related technologies? Why is it > that this one radio technology requires special flow control > considerations in *other* equipment outside of that domain, but 802.11 > does seemingly the same task and doesn't require special support? > > Or are these issues an unresolved (and until-now unrecognized) problem > with 802.11 that simply must be handled at higher levels? I don't think that's a stupid question, because I have one that really is. Exactly what bits are going over the air? Is this about 802.11? As far as I can tell, the string "802" does not appear in draft-bberry-pppoe-credit. If not, what other headers, trailers, whatever are involved? Are there PPP headers and trailers in the air, and if so, what flavors? I also have a counterproposal. Assume that traffic shaping of the sort needed is not available with other IETF protocols. (I wonder if Fred Baker was right when he gave his "no" answer, because old style IP TOS and less old diffserv don't sound that different.) What is special about PPPoE that makes credits and so forth need there but not in other PPP flavors? I think there are other palces where it could be more valuable. What about ABR ATM?--yes you could get a committed bit rate but that might cost more and blah blah blah. So why do as was done with the multi-link protocol and add another new PPP sub-layer? Or modify MP itself to have some control packets that would do the crediting? Or extend LCP with some new types? That would be a more general solution to the particular problem. It would also not burn more of the poor, withered PPPoE MTU. Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Aug 01 14:03:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzedp-0006gm-0Q; Mon, 01 Aug 2005 14:03:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzedm-0006et-TK for pppext@megatron.ietf.org; Mon, 01 Aug 2005 14:03:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28605 for ; Mon, 1 Aug 2005 14:03:51 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzfA7-0005hr-2s for pppext@ietf.org; Mon, 01 Aug 2005 14:37:19 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 01 Aug 2005 11:03:46 -0700 X-IronPort-AV: i="3.95,158,1120460400"; d="scan'208"; a="201914859:sNHT48404212" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j71I3g6p001780; Mon, 1 Aug 2005 11:03:42 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 14:03:34 -0400 Received: from [64.102.54.190] ([64.102.54.190]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 14:03:34 -0400 Message-ID: <42EE63F5.4070703@cisco.com> Date: Mon, 01 Aug 2005 14:03:33 -0400 From: Bo Berry User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vernon Schryver Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) References: <200508011750.j71Hovjo063166@calcite.rhyolite.com> In-Reply-To: <200508011750.j71Hovjo063166@calcite.rhyolite.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2005 18:03:34.0261 (UTC) FILETIME=[553A7250:01C596C3] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, hholgate@cisco.com, fred@cisco.com, lanzo@cisco.com, margaret@thingmagic.com, townsley@cisco.com, james.d.carlson@sun.com, karlfox@columbus.rr.com X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org in-line -Bo Vernon Schryver wrote: >>From: James Carlson >>To: Karl Fox >>Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) >>Cc: pppext@ietf.org, hholgate@cisco.com, Fred Baker , >> Vernon Schryver , margaret@thingmagic.com, >> townsley@cisco.com, bberry@cisco.com, Mark Lanzo > > > >>Stupid question time: why are these inherent radio-caused flow control >>issues _not_ a problem for 802.11 and related technologies? Why is it >>that this one radio technology requires special flow control >>considerations in *other* equipment outside of that domain, but 802.11 >>does seemingly the same task and doesn't require special support? >> >>Or are these issues an unresolved (and until-now unrecognized) problem >>with 802.11 that simply must be handled at higher levels? > > > I don't think that's a stupid question, because I have one that really > is. Exactly what bits are going over the air? > > Is this about 802.11? As far as I can tell, the string "802" does > not appear in draft-bberry-pppoe-credit. Correct, 802 is not in the draft. In fact the extenstions are independent of the radio technology. The radio terminates the PPPoE session and forwards the PPP frames over the airwaves. The frames are transported by the radio independently of the PPPoE. The radio requirement is that it can associate both ends of the radio channel, by whatever means/technology is required in the radio. The overall requirement is that PPP flow be maintained, end to end. > > If not, what other headers, trailers, whatever are involved? > > Are there PPP headers and trailers in the air, and if so, what flavors? > > > I also have a counterproposal. Assume that traffic shaping of the > sort needed is not available with other IETF protocols. (I wonder if > Fred Baker was right when he gave his "no" answer, because old style > IP TOS and less old diffserv don't sound that different.) What is > special about PPPoE that makes credits and so forth need there but not > in other PPP flavors? I think there are other palces where it could > be more valuable. What about ABR ATM?--yes you could get a committed > bit rate but that might cost more and blah blah blah. > > So why do as was done with the multi-link protocol and add another new > PPP sub-layer? Or modify MP itself to have some control packets > that would do the crediting? Or extend LCP with some new types? > > That would be a more general solution to the particular problem. > It would also not burn more of the poor, withered PPPoE MTU. > > > Vernon Schryver vjs@rhyolite.com > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Aug 01 14:18:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzerW-0001uv-JY; Mon, 01 Aug 2005 14:18:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzerV-0001up-CC for pppext@megatron.ietf.org; Mon, 01 Aug 2005 14:18:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29075 for ; Mon, 1 Aug 2005 14:18:02 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzfNm-0006DP-8v for pppext@ietf.org; Mon, 01 Aug 2005 14:51:30 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j71IHx1d008867 for ; Mon, 1 Aug 2005 11:17:59 -0700 (PDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j71IHwC6000550 for ; Mon, 1 Aug 2005 14:17:58 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j71IHvNM011697; Mon, 1 Aug 2005 14:17:58 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j71IHvjm011694; Mon, 1 Aug 2005 14:17:57 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17134.26453.824518.219339@gargle.gargle.HOWL> Date: Mon, 1 Aug 2005 14:17:57 -0400 From: James Carlson To: Bo Berry Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) In-Reply-To: Bo Berry's message of 1 August 2005 14:03:33 References: <200508011750.j71Hovjo063166@calcite.rhyolite.com> <42EE63F5.4070703@cisco.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, hholgate@cisco.com, fred@cisco.com, lanzo@cisco.com, margaret@thingmagic.com, townsley@cisco.com, Vernon Schryver , karlfox@columbus.rr.com X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Bo Berry writes: > >>Stupid question time: why are these inherent radio-caused flow control > >>issues _not_ a problem for 802.11 and related technologies? Why is it > >>that this one radio technology requires special flow control > >>considerations in *other* equipment outside of that domain, but 802.11 > >>does seemingly the same task and doesn't require special support? > >> > >>Or are these issues an unresolved (and until-now unrecognized) problem > >>with 802.11 that simply must be handled at higher levels? [...] > Correct, 802 is not in the draft. In fact the extenstions are > independent of the radio technology. So, then, at least my stupid questions are still valid. Why does this draft provide a solution for something that's not generally recognized as a problem with 802.11? What has made it necessary in this instance? I'm missing something because it seems like the issues ought to be more alike than not. > The radio terminates the PPPoE session and forwards the PPP frames > over the airwaves. The frames are transported by the radio > independently of the PPPoE. The radio requirement is that it > can associate both ends of the radio channel, by whatever > means/technology is required in the radio. The overall > requirement is that PPP flow be maintained, end to end. That makes the requirements even less clear to me. If this device is essentially doing routing with a mesh of point-to-point links, why doesn't it actually behave as a router? Why is it instead a PPP bridge that exposes internal implementation details (the operation of the radio link) to other Ethernet devices? And why is it dependent on the use of PPPoE outside of this domain? If it were used with something other than IP+PPP+PPPoE (i.e., bridging arbitrary LANs together, perhaps running some 'foreign' protocol such as MPLS), what happens? Does every Ethernet-based protocol need an upgrade to handle credit-based flow control so that this radio link will work correctly? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Aug 01 14:22:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzevp-0007Zr-BR; Mon, 01 Aug 2005 14:22:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzevn-0007Xd-Ge for pppext@megatron.ietf.org; Mon, 01 Aug 2005 14:22:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29434 for ; Mon, 1 Aug 2005 14:22:28 -0400 (EDT) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzfS7-0006Un-N4 for pppext@ietf.org; Mon, 01 Aug 2005 14:55:56 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j71IMLWQ083283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) env-from ; Mon, 1 Aug 2005 12:22:21 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j71IMLm7083282; Mon, 1 Aug 2005 12:22:21 -0600 (MDT) Date: Mon, 1 Aug 2005 12:22:21 -0600 (MDT) From: Vernon Schryver Message-Id: <200508011822.j71IMLm7083282@calcite.rhyolite.com> To: bberry@cisco.com Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) In-Reply-To: <42EE63F5.4070703@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: margaret@thingmagic.com, pppext@ietf.org, hholgate@cisco.com, fred@cisco.com, lanzo@cisco.com X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org > From: Bo Berry > To: Vernon Schryver > Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) > Cc: pppext@ietf.org, hholgate@cisco.com, fred@cisco.com, lanzo@cisco.com, > margaret@thingmagic.com, townsley@cisco.com, james.d.carlson@sun.com, > karlfox@columbus.rr.com (I've tried to trim that Cc: list to reduce duplicate copies. It's probably still too long) > The radio terminates the PPPoE session and forwards the PPP frames > over the airwaves. The frames are transported by the radio > independently of the PPPoE. The radio requirement is that it > can associate both ends of the radio channel, by whatever > means/technology is required in the radio. The overall > requirement is that PPP flow be maintained, end to end. Ok. So how does this requirement differ from the requirements intended to be handled by by IP TOS or diffserv? How does it differ from host <- 802.3 -> router <- ATM or FR PVC -> host or host <- router (lots of other routers) router -> host Then there are the streaming protocols above IP. > > If not, what other headers, trailers, whatever are involved? > > > > Are there PPP headers and trailers in the air, and if so, what flavors? What is in the air, PPPoE, some other flavor of PPP, 802.11, and/or something else entirely? Maybe it doesn't really matter, but I have the nagging suspicion that it does. Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Aug 01 14:33:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzf6d-0005Ft-9j; Mon, 01 Aug 2005 14:33:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzf6c-0005Em-0Y for pppext@megatron.ietf.org; Mon, 01 Aug 2005 14:33:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29947 for ; Mon, 1 Aug 2005 14:33:38 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzfcv-0006zU-Ha for pppext@ietf.org; Mon, 01 Aug 2005 15:07:06 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 01 Aug 2005 11:33:34 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,158,1120460400"; d="scan'208"; a="4213093:sNHT21233256" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j71IXWk6023242; Mon, 1 Aug 2005 14:33:32 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 14:33:31 -0400 Received: from [64.102.54.190] ([64.102.54.190]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 14:33:31 -0400 Message-ID: <42EE6AF8.9000101@cisco.com> Date: Mon, 01 Aug 2005 14:33:28 -0400 From: Bo Berry User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Carlson Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) References: <200508011750.j71Hovjo063166@calcite.rhyolite.com> <42EE63F5.4070703@cisco.com> <17134.26453.824518.219339@gargle.gargle.HOWL> In-Reply-To: <17134.26453.824518.219339@gargle.gargle.HOWL> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2005 18:33:31.0383 (UTC) FILETIME=[84658070:01C596C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, hholgate@cisco.com, fred@cisco.com, lanzo@cisco.com, margaret@thingmagic.com, townsley@cisco.com, Vernon Schryver , karlfox@columbus.rr.com X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org James Carlson wrote: > Bo Berry writes: > >>>>Stupid question time: why are these inherent radio-caused flow control >>>>issues _not_ a problem for 802.11 and related technologies? Why is it >>>>that this one radio technology requires special flow control >>>>considerations in *other* equipment outside of that domain, but 802.11 >>>>does seemingly the same task and doesn't require special support? >>>> >>>>Or are these issues an unresolved (and until-now unrecognized) problem >>>>with 802.11 that simply must be handled at higher levels? > > [...] > >>Correct, 802 is not in the draft. In fact the extenstions are >>independent of the radio technology. > > > So, then, at least my stupid questions are still valid. Why does this > draft provide a solution for something that's not generally recognized > as a problem with 802.11? What has made it necessary in this > instance? I'm missing something because it seems like the issues > ought to be more alike than not. > > >>The radio terminates the PPPoE session and forwards the PPP frames >>over the airwaves. The frames are transported by the radio >>independently of the PPPoE. The radio requirement is that it >>can associate both ends of the radio channel, by whatever >>means/technology is required in the radio. The overall >>requirement is that PPP flow be maintained, end to end. > > > That makes the requirements even less clear to me. If this device is > essentially doing routing with a mesh of point-to-point links, why > doesn't it actually behave as a router? Why is it instead a PPP > bridge that exposes internal implementation details (the operation of > the radio link) to other Ethernet devices? And why is it dependent on > the use of PPPoE outside of this domain? > > If it were used with something other than IP+PPP+PPPoE (i.e., bridging > arbitrary LANs together, perhaps running some 'foreign' protocol such > as MPLS), what happens? Does every Ethernet-based protocol need an > upgrade to handle credit-based flow control so that this radio link > will work correctly? These extensions are optional and are not required by existing PPPoE implementations. Systems that require flow control through (certain) radios could employ this solution. We do not want the router to overrun the radio buffers, nor do we want the radio to overrun the router, hence the need for flow control (via credits). > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Aug 01 14:51:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzfNj-0006G6-O5; Mon, 01 Aug 2005 14:51:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzfNh-00069M-Q8 for pppext@megatron.ietf.org; Mon, 01 Aug 2005 14:51:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01096 for ; Mon, 1 Aug 2005 14:51:18 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzfu1-0007n9-Bi for pppext@ietf.org; Mon, 01 Aug 2005 15:24:46 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j71IpJr3003668 for ; Mon, 1 Aug 2005 12:51:19 -0600 (MDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j71IpIC6009334 for ; Mon, 1 Aug 2005 14:51:19 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j71IpIsH011913; Mon, 1 Aug 2005 14:51:18 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j71IpHOc011910; Mon, 1 Aug 2005 14:51:17 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17134.28427.13893.677322@gargle.gargle.HOWL> Date: Mon, 1 Aug 2005 14:50:51 -0400 From: James Carlson To: Bo Berry Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) In-Reply-To: Bo Berry's message of 1 August 2005 14:33:28 References: <200508011750.j71Hovjo063166@calcite.rhyolite.com> <42EE63F5.4070703@cisco.com> <17134.26453.824518.219339@gargle.gargle.HOWL> <42EE6AF8.9000101@cisco.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, hholgate@cisco.com, fred@cisco.com, lanzo@cisco.com, margaret@thingmagic.com, townsley@cisco.com, Vernon Schryver , karlfox@columbus.rr.com X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Bo Berry writes: > > That makes the requirements even less clear to me. If this device is > > essentially doing routing with a mesh of point-to-point links, why > > doesn't it actually behave as a router? Why is it instead a PPP > > bridge that exposes internal implementation details (the operation of > > the radio link) to other Ethernet devices? And why is it dependent on > > the use of PPPoE outside of this domain? > > > > If it were used with something other than IP+PPP+PPPoE (i.e., bridging > > arbitrary LANs together, perhaps running some 'foreign' protocol such > > as MPLS), what happens? Does every Ethernet-based protocol need an > > upgrade to handle credit-based flow control so that this radio link > > will work correctly? > > These extensions are optional and are not required by existing > PPPoE implementations. Systems that require flow control > through (certain) radios could employ this solution. We do > not want the router to overrun the radio buffers, nor do we > want the radio to overrun the router, hence the need for > flow control (via credits). I don't think that addresses the questions that have been raised. First of all, "not required" doesn't match reality. Either this is an important niche for someone, and thus needs a solution like that proposed in the draft, and thus will also force *many* vendors to support it in their offerings (or suffer the consequences of inducing very poor performance), _OR_ it's unimportant and doesn't need solution. Merely saying it's an "option" doesn't help if what's being specified is something that (effectively) everyone is forced to implement. What I don't see is a rationale for why this feature would actually be useful for others outside of this domain (some sort of redeeming path forward) or something that constrains it to just a subset of equipment vendors who all support this one market and never talk to anyone else. Secondly, the question I asked above wasn't whether there was a need for flow control, but rather what happens to protocols that are *not* based on PPPoE. In other words, this sounds like a very general problem with Ethernet bridging in this particular device, but the solution is an extension to PPPoE and not to any other Ethernet-based protocol. Does this mean that PPPoE becomes the only feasible solution here, and is that really the right path forward for something that otherwise appears to the rest of the network to be a bridge? What stops some other Ethernet-based protocol from overrunning the "router?" Finally, why does this device just bridge PPP rather than route packets? What's wrong with routing? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Aug 01 15:11:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzfhO-0000LA-H9; Mon, 01 Aug 2005 15:11:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzfhM-0000L5-6D for pppext@megatron.ietf.org; Mon, 01 Aug 2005 15:11:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02370 for ; Mon, 1 Aug 2005 15:11:36 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzgDf-0008Sl-Oz for pppext@ietf.org; Mon, 01 Aug 2005 15:45:05 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 01 Aug 2005 12:11:29 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,158,1120460400"; d="scan'208"; a="4218346:sNHT22847516" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j71JBSk6002718; Mon, 1 Aug 2005 15:11:28 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 15:11:28 -0400 Received: from [64.102.54.190] ([64.102.54.190]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 15:11:27 -0400 Message-ID: <42EE73DF.3040506@cisco.com> Date: Mon, 01 Aug 2005 15:11:27 -0400 From: Bo Berry User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Carlson Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) References: <200508011750.j71Hovjo063166@calcite.rhyolite.com> <42EE63F5.4070703@cisco.com> <17134.26453.824518.219339@gargle.gargle.HOWL> <42EE6AF8.9000101@cisco.com> <17134.28427.13893.677322@gargle.gargle.HOWL> In-Reply-To: <17134.28427.13893.677322@gargle.gargle.HOWL> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Aug 2005 19:11:27.0678 (UTC) FILETIME=[D12C8DE0:01C596CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, hholgate@cisco.com, fred@cisco.com, lanzo@cisco.com, margaret@thingmagic.com, townsley@cisco.com, Vernon Schryver , karlfox@columbus.rr.com X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org James Carlson wrote: > Bo Berry writes: > >>>That makes the requirements even less clear to me. If this device is >>>essentially doing routing with a mesh of point-to-point links, why >>>doesn't it actually behave as a router? Why is it instead a PPP >>>bridge that exposes internal implementation details (the operation of >>>the radio link) to other Ethernet devices? And why is it dependent on >>>the use of PPPoE outside of this domain? >>> >>>If it were used with something other than IP+PPP+PPPoE (i.e., bridging >>>arbitrary LANs together, perhaps running some 'foreign' protocol such >>>as MPLS), what happens? Does every Ethernet-based protocol need an >>>upgrade to handle credit-based flow control so that this radio link >>>will work correctly? >> >>These extensions are optional and are not required by existing >>PPPoE implementations. Systems that require flow control >>through (certain) radios could employ this solution. We do >>not want the router to overrun the radio buffers, nor do we >>want the radio to overrun the router, hence the need for >>flow control (via credits). > > > I don't think that addresses the questions that have been raised. > > First of all, "not required" doesn't match reality. Either this is an > important niche for someone, and thus needs a solution like that > proposed in the draft, and thus will also force *many* vendors to > support it in their offerings (or suffer the consequences of inducing > very poor performance), _OR_ it's unimportant and doesn't need > solution. Sorry if I gave the impression that it is not important. It is important, that's why it was submitted. > > Merely saying it's an "option" doesn't help if what's being specified > is something that (effectively) everyone is forced to implement. What > I don't see is a rationale for why this feature would actually be > useful for others outside of this domain (some sort of redeeming path > forward) or something that constrains it to just a subset of equipment > vendors who all support this one market and never talk to anyone else. We're not requiring that this be required by those outside the domain. > > Secondly, the question I asked above wasn't whether there was a need > for flow control, but rather what happens to protocols that are *not* > based on PPPoE. In other words, this sounds like a very general > problem with Ethernet bridging in this particular device, but the > solution is an extension to PPPoE and not to any other Ethernet-based > protocol. Does this mean that PPPoE becomes the only feasible > solution here, and is that really the right path forward for something > that otherwise appears to the rest of the network to be a bridge? The radios we are currently working with require flow control. They are not radios that forward any protocol. > > What stops some other Ethernet-based protocol from overrunning the > "router?" > > Finally, why does this device just bridge PPP rather than route > packets? What's wrong with routing? Routing is envolved, but outside of the PPPoE session. For example, if the radio link is poor, the router may choose another route. > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Aug 01 16:46:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzhAm-0005oK-8D; Mon, 01 Aug 2005 16:46:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzhAf-0005k9-Sj for pppext@megatron.ietf.org; Mon, 01 Aug 2005 16:46:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22066 for ; Mon, 1 Aug 2005 16:45:59 -0400 (EDT) Received: from cosmos.ds.org ([67.42.187.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzhgy-0000dW-RQ for pppext@ietf.org; Mon, 01 Aug 2005 17:19:27 -0400 Received: from [172.30.1.193] (unknown [67.103.19.117]) by cosmos.ds.org (Postfix) with ESMTP id 44AF41A81C; Mon, 1 Aug 2005 14:45:46 -0600 (MDT) In-Reply-To: <42EE73DF.3040506@cisco.com> References: <200508011750.j71Hovjo063166@calcite.rhyolite.com> <42EE63F5.4070703@cisco.com> <17134.26453.824518.219339@gargle.gargle.HOWL> <42EE6AF8.9000101@cisco.com> <17134.28427.13893.677322@gargle.gargle.HOWL> <42EE73DF.3040506@cisco.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <701C1F4C-5D8C-4432-B650-A032CA6E958A@columbus.rr.com> Content-Transfer-Encoding: 7bit From: Karl Fox Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) Date: Mon, 1 Aug 2005 16:45:49 -0400 To: Bo Berry X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, hholgate@cisco.com, fred@cisco.com, lanzo@cisco.com, margaret@thingmagic.com, townsley@cisco.com, Vernon Schryver , James Carlson X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org On Aug 1, 2005, at 3:11 PM, Bo Berry wrote: > James Carlson wrote: >> I don't think that addresses the questions that have been raised. >> >> First of all, "not required" doesn't match reality. Either this >> is an >> important niche for someone, and thus needs a solution like that >> proposed in the draft, and thus will also force *many* vendors to >> support it in their offerings (or suffer the consequences of inducing >> very poor performance), _OR_ it's unimportant and doesn't need >> solution. > > Sorry if I gave the impression that it is not important. > It is important, that's why it was submitted. I would like to see an answer to the question that has been repeatedly asked but never answered: Why is "serial emulation" necessary? This group is a problem solving group; we are not interested in approving someone else's solution to a problem for which we have not been given all the relevant information. We are tasked with coming up with the best solutions we can so that publicly promoted protocols with the IETF moniker attached reflect the good name of our organization and do not bear the aroma that so often accompanies industry alliance protocols. Karl _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext