From pppext-bounces@ietf.org Fri Jul 01 13:15:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoP6l-0002zO-TD; Fri, 01 Jul 2005 13:15:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoP6k-0002yS-2A for pppext@megatron.ietf.org; Fri, 01 Jul 2005 13:15:18 -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 NAA16620 for ; Fri, 1 Jul 2005 13:15:14 -0400 (EDT) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoPWk-00073y-8W for pppext@ietf.org; Fri, 01 Jul 2005 13:42:10 -0400 Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 18:14:59 +0100 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 18:14:59 +0100 Received: from antipi.jnpr.net ([10.10.2.34]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Jul 2005 13:14:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 Date: Fri, 1 Jul 2005 13:14:56 -0400 Message-ID: <6B8F46B46D292A438250E42591ABB59DBDF85D@antipi.jnpr.net> Thread-Topic: RE: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 Thread-Index: AcV+YGdCOEEy7o8hSFGDclSF4Zuy5Q== From: "Jerome Moisand" To: X-OriginalArrivalTime: 01 Jul 2005 17:14:56.0656 (UTC) FILETIME=[67650100:01C57E60] X-Spam-Score: 0.2 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 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: , Content-Type: multipart/mixed; boundary="===============1057330317==" Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org This is a multi-part message in MIME format. --===============1057330317== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57E60.67338AC1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57E60.67338AC1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reacting to some James Carlson questions: =20 - Why is the "recommended" Echo-Request probing mechanism -- the only thing other than LLDP that can deal with L2 MTU issues -- disabled by default? Isn't that just asking for trouble? (I can see why an implementation might want to have an option to disable this feature, but why would that necessarily be the default?) =20 =3D=3D> This feature is intended as a "safety net" and a troubleshooting mechanism, but using it for every PPP session establishment would significantly lower call setup performance, while not adding any meaningful value to typical broadband environments. Personally, I am actually not entirely convinced this feature is worth the trouble! =20 - What does the interoperability picture look like? Are there deployed implementations that attempt to negotiate an MRU of 1500, and is this commonly ignored on PPPoE links? (I suspect that the answers here are "yes" and "yes" -- meaning that changing the behavior of MRU negotiation on PPPoE, which previously had a hard cap at 1492, will likely break existing implementations, unless some mitigating feature is included by default.) =20 =3D=3D> I share the concern. There will be situations with a mix of = legacy or newer PPPoE clients, and given the pretty diverse (to be polite) behaviors of some PPPoE clients and the legacy of home LANs not supporting mini-jumbo Ethernet frames, it doesn't seem safe to do anything not strictly upward-compatible. =20 =3D=3D> I'd like to propose that we introduce a new PPPoE tag where the PPPoE client indicates if the 1492 constraint can be lifted (in its best assessment of its own capabilities and of the network it is connected to), and to which extent (up to 1500, possibly more). If such new option isn't included by the client, then the existing behavior must be assumed. =20 Tx Jerome Moisand ------_=_NextPart_001_01C57E60.67338AC1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Reacting to some James Carlson =
questions:
 
  - Why is the =
"recommended" Echo-Request probing mechanism -- =
the
    only =
thing other than LLDP that can deal with L2 MTU issues =
--
    disabled =
by default?  Isn't that just asking for trouble?  (I =
can
    =
see why an implementation might want to have =
an option to disable
    this =
feature, but why would that necessarily be the =
default?)
 
è =
This feature is intended as a “safety net” and a =
troubleshooting mechanism, but using it for every PPP session =
establishment would significantly lower call setup performance, while =
not adding any meaningful value to typical broadband environments. =
Personally, I am actually not entirely convinced this feature is worth =
the trouble!
 
  - What does the =
interoperability picture look like?  Are =
there
    deployed =
implementations that attempt to negotiate an MRU of =
1500,
    and is =
this commonly ignored on PPPoE links?  (I suspect that =
the
    answers =
here are "yes" and "yes" -- meaning that changing =
the
    behavior =
of MRU negotiation on PPPoE, which previously had a =
hard
    cap at =
1492, will likely break existing implementations, =
unless
    some =
mitigating feature is included by =
default.)
 

è I share the concern. There = will be situations with a mix of legacy or newer PPPoE clients, and given the = pretty diverse (to be polite) behaviors of some PPPoE clients and the legacy of = home LANs not supporting mini-jumbo Ethernet frames, it doesn’t seem = safe to do anything not strictly upward-compatible.

 

è I’d like to propose = that we introduce a new PPPoE tag where the PPPoE client indicates if the 1492 constraint can be lifted (in its best assessment of its own capabilities = and of the network it is connected to), and to which extent (up to 1500, = possibly more). If such new option isn’t included by the client, then the = existing behavior must be assumed.

 

Tx

Jerome Moisand

=00 ------_=_NextPart_001_01C57E60.67338AC1-- --===============1057330317== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext --===============1057330317==-- From pppext-bounces@ietf.org Fri Jul 01 13:34:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoPPk-0000G4-Vp; Fri, 01 Jul 2005 13:34:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoPPj-0000Cu-4U for pppext@megatron.ietf.org; Fri, 01 Jul 2005 13:34: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 NAA19462 for ; Fri, 1 Jul 2005 13:34:51 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoPph-0000JJ-Gz for pppext@ietf.org; Fri, 01 Jul 2005 14:01:47 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j61HYp8t005314 for ; Fri, 1 Jul 2005 11:34:51 -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 j61HYpC0024380 for ; Fri, 1 Jul 2005 13:34:51 -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 j61HYodo026291; Fri, 1 Jul 2005 13:34:50 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j61HYo3A026288; Fri, 1 Jul 2005 13:34:50 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17093.32442.839174.130884@gargle.gargle.HOWL> Date: Fri, 1 Jul 2005 13:34:50 -0400 From: James Carlson To: Jerome Moisand Subject: RE: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 In-Reply-To: Jerome Moisand's message of 1 July 2005 13:14:56 References: <6B8F46B46D292A438250E42591ABB59DBDF85D@antipi.jnpr.net> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org 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 Jerome Moisand writes: > ==> This feature is intended as a "safety net" and a troubleshooting > mechanism, but using it for every PPP session establishment would > significantly lower call setup performance, while not adding any > meaningful value to typical broadband environments. Personally, I am > actually not entirely convinced this feature is worth the trouble! Performance will be much worse if there's a bridged link in path between PPPoE client and server that restricts the MTU to the IEEE-specified maximum. Worse still, if you have a network with multiple paths for redundancy (using Spanning Tree), the path you take during PPPoE/PPP session set-up may be different than the one you take after a successfully-handled L2 link failure, and you get no notification that this has happened, and the restrictions on the new path through the L2 network may differ. In other words, I remain skeptical that this can actually be deployed safely without having the IEEE itself redefine the L2 header/payload split to conform to what this proposal is actually doing. And I think it's somewhat outside the bounds of normal IETF activity to have a published RFC that suggests doing something that isn't supported by the underlying non-IETF standards. If the draft authors are going to go ahead anyway with publication as an Informational document, I'd like to see a disclaimer near the top of the document stating that the procedure described does not conform to IEEE standards, isn't endorsed by the IETF/IESG, and may simply fall apart in some deployments. > ==> I'd like to propose that we introduce a new PPPoE tag where the > PPPoE client indicates if the 1492 constraint can be lifted (in its best > assessment of its own capabilities and of the network it is connected > to), and to which extent (up to 1500, possibly more). If such new option > isn't included by the client, then the existing behavior must be > assumed. I agree. That fixes the naive-client problem; thanks. -- James Carlson, KISS Network 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 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Jul 01 14:28:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQFR-0002ov-SK; Fri, 01 Jul 2005 14:28:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoQFQ-0002oo-Uz for pppext@megatron.ietf.org; Fri, 01 Jul 2005 14:28: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 OAA25770 for ; Fri, 1 Jul 2005 14:28:14 -0400 (EDT) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoQfO-0003eH-II for pppext@ietf.org; Fri, 01 Jul 2005 14:55:11 -0400 Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 19:28:07 +0100 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Jul 2005 19:28:08 +0100 Received: from antipi.jnpr.net ([10.10.2.34]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Jul 2005 14:28:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 Date: Fri, 1 Jul 2005 14:28:04 -0400 Message-ID: <6B8F46B46D292A438250E42591ABB59DBDF861@antipi.jnpr.net> Thread-Topic: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 Thread-Index: AcV+YzmfKxgnNtjDSnqDmIcKRJf/5QABj7LQ From: "Jerome Moisand" To: X-OriginalArrivalTime: 01 Jul 2005 18:28:04.0812 (UTC) FILETIME=[9EF078C0:01C57E6A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable 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 Not exactly sure what non-IEEE-compliant mechanism you are referring to? Using a PPP MRU of 1500 over PPPoE clearly implies the use of an Ethernet frame size larger than 1500 bytes, but IEEE standards now support such technology (aka jumbo-frames, mini jumbo frames, etc). So if all network segments between the PPPoE "newer" client and the PPPoE server support such larger frame as a deployment rule, then we have no issue, and this seems to me as being fully IEEE compliant. Practically speaking, the DSL topologies that we have in mind would indeed have such property. Yet we need the mitigation mechanism to deal with legacy cases, and notably home LANs limited to 1500 Ethernet frames. Am I missing something? -----Original Message----- From: James Carlson [mailto:james.d.carlson@sun.com]=20 Sent: Friday, July 01, 2005 1:35 PM To: Jerome Moisand Cc: pppext@ietf.org Subject: RE: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 Jerome Moisand writes: > =3D=3D> This feature is intended as a "safety net" and a = troubleshooting > mechanism, but using it for every PPP session establishment would > significantly lower call setup performance, while not adding any > meaningful value to typical broadband environments. Personally, I am > actually not entirely convinced this feature is worth the trouble! Performance will be much worse if there's a bridged link in path between PPPoE client and server that restricts the MTU to the IEEE-specified maximum. Worse still, if you have a network with multiple paths for redundancy (using Spanning Tree), the path you take during PPPoE/PPP session set-up may be different than the one you take after a successfully-handled L2 link failure, and you get no notification that this has happened, and the restrictions on the new path through the L2 network may differ. In other words, I remain skeptical that this can actually be deployed safely without having the IEEE itself redefine the L2 header/payload split to conform to what this proposal is actually doing. And I think it's somewhat outside the bounds of normal IETF activity to have a published RFC that suggests doing something that isn't supported by the underlying non-IETF standards. If the draft authors are going to go ahead anyway with publication as an Informational document, I'd like to see a disclaimer near the top of the document stating that the procedure described does not conform to IEEE standards, isn't endorsed by the IETF/IESG, and may simply fall apart in some deployments. > =3D=3D> I'd like to propose that we introduce a new PPPoE tag where = the > PPPoE client indicates if the 1492 constraint can be lifted (in its best > assessment of its own capabilities and of the network it is connected > to), and to which extent (up to 1500, possibly more). If such new option > isn't included by the client, then the existing behavior must be > assumed. I agree. That fixes the naive-client problem; thanks. --=20 James Carlson, KISS Network 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 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Sat Jul 02 15:31:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoniN-00056T-Mr; Sat, 02 Jul 2005 15:31:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoniL-00054J-HW for pppext@megatron.ietf.org; Sat, 02 Jul 2005 15:31:45 -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 PAA20983 for ; Sat, 2 Jul 2005 15:31:41 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Doo8V-00081F-Gj for pppext@ietf.org; Sat, 02 Jul 2005 15:58:49 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j62JVdFF021339 for ; Sat, 2 Jul 2005 12:31:39 -0700 (PDT) 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 j62JVcFt026491 for ; Sat, 2 Jul 2005 15:31:38 -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 j62JVcrS028465; Sat, 2 Jul 2005 15:31:38 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j62JVcla028462; Sat, 2 Jul 2005 15:31:38 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17094.60314.540094.534698@gargle.gargle.HOWL> Date: Sat, 2 Jul 2005 15:31:38 -0400 From: James Carlson To: Jerome Moisand Subject: RE: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 In-Reply-To: Jerome Moisand's message of 1 July 2005 14:28:04 References: <6B8F46B46D292A438250E42591ABB59DBDF861@antipi.jnpr.net> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org 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 Jerome Moisand writes: > Not exactly sure what non-IEEE-compliant mechanism you are referring to? > > Using a PPP MRU of 1500 over PPPoE clearly implies the use of an > Ethernet frame size larger than 1500 bytes, but IEEE standards now > support such technology (aka jumbo-frames, mini jumbo frames, etc). Really? Can you cite which published IEEE standard actually supports jumbo frame operation? (And, better still, describes how the interoperability problems are mitigated, as that's the crucial bit I think we're missing here.) I can't seem to locate the standard that supports this idea. I know that many products (even from Sun and Juniper) support jumbo frame operation, but unless I'm missing something I don't see where it's actually been adopted as a standard. The last I'd heard was that the 802.3 WG "feels that Jumbo frames are a bad idea." Has this been amended? > So if all network segments between the PPPoE "newer" client and the > PPPoE server support such larger frame as a deployment rule, then we > have no issue, Right. But we simply have no way of knowing that this is true, and failure modes are both catastrophic and potentially (due to STP) latent. I'm really uncomfortable with publishing an RFC that clearly depends on essentially arbitrary deployment rules in order to function correctly. It seems like bad practice to me. > and this seems to me as being fully IEEE compliant. That's the part I'm missing. > Practically speaking, the DSL topologies that we have in mind would > indeed have such property. > > Yet we need the mitigation mechanism to deal with legacy cases, and > notably home LANs limited to 1500 Ethernet frames. Ditching PPPoE as an unnecessary expense and just using plain old IP on Ethernet would fix that problem neatly. -- James Carlson, KISS Network 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 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Sat Jul 02 19:23:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DorKp-0005HA-Mz; Sat, 02 Jul 2005 19:23:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DorKo-0005H2-6Y for pppext@megatron.ietf.org; Sat, 02 Jul 2005 19:23: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 TAA09707 for ; Sat, 2 Jul 2005 19:23:38 -0400 (EDT) Received: from cosmos.ds.org ([67.42.187.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dorl2-0006O3-2r for pppext@ietf.org; Sat, 02 Jul 2005 19:50:50 -0400 Received: from [10.0.0.4] (cpe-24-93-127-208.columbus.res.rr.com [24.93.127.208]) by cosmos.ds.org (Postfix) with ESMTP id 3B4E51A77D; Sat, 2 Jul 2005 17:23:19 -0600 (MDT) In-Reply-To: <17094.60314.540094.534698@gargle.gargle.HOWL> References: <6B8F46B46D292A438250E42591ABB59DBDF861@antipi.jnpr.net> <17094.60314.540094.534698@gargle.gargle.HOWL> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Karl Fox Subject: Re: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 Date: Sat, 2 Jul 2005 19:23:13 -0400 To: James Carlson X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org 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 Jul 2, 2005, at 3:31 PM, James Carlson wrote: > Jerome Moisand writes: >> Yet we need the mitigation mechanism to deal with legacy cases, and >> notably home LANs limited to 1500 Ethernet frames. > > Ditching PPPoE as an unnecessary expense and just using plain old IP > on Ethernet would fix that problem neatly. PPPoE was a bad idea from the start. It was rammed through as Informational by a few industry advocates despite warnings and the stern disapproval of essentially every participant in the PPPEXT working group, simply because some large providers didn't want to change their view that all ISP customers should look like dial-up users. Get over it and use a real protocol, just as Jim recommends. Karl _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Sat Jul 02 20:08:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dos1v-0003qJ-0D; Sat, 02 Jul 2005 20:08:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dos1t-0003p2-TB for pppext@megatron.ietf.org; Sat, 02 Jul 2005 20:08:13 -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 UAA13203 for ; Sat, 2 Jul 2005 20:08:10 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DosSA-0000jE-3n for pppext@ietf.org; Sat, 02 Jul 2005 20:35:22 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 1102F5E01C8; Sat, 2 Jul 2005 17:07:52 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27921-01; Sat, 2 Jul 2005 17:07:51 -0700 (PDT) Received: from PARBETM2XP (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 440D35E01C7; Sat, 2 Jul 2005 17:07:50 -0700 (PDT) From: "Peter Arberg" To: "'Karl Fox'" , "'James Carlson'" Subject: RE: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 Date: Sun, 3 Jul 2005 02:07:36 +0200 Organization: Redback Networks MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcV/XTlN5RAXKXp1RuyRz+ChDWH+fwAAO40w In-Reply-To: Message-Id: <20050703000750.440D35E01C7@prattle.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: parberg@redback.com List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Hi, I'm glad you got that out of your system Karl, but now let us try and reset the discussion, and deal with some reality. PPPoE might be a bad idea, but it is very real, and a large percentage of the top 100 carriers in the world are using it today, and a lot of them will continue to use it for a long time to come, and as such it is only natural that PPPoE requirements evolve over time. Sine PPPoE was made an informational RFC back in 1999, at least in my mind, will say that IETF and as such the pppext working group is the right place to discuss enhancements to the protocol. The draft-arberg-pppoe-mtu-gt1492-00 is in no way looking to be on the standard track, it is intended to become an informational RFC to tell people what is deployed and doable today in carriers networks. It is a lot easier if different carriers and vendors have a common document to base their discussion on. The "draft-arberg-pppoe-mtu-gt1492-00" intention is not to solve every single problem in increasing ethernet MTU, and I will be the first to admit that it is not the intention of the draft to solve a generic ethernet aggregation network, and make sure the ethernet MTU from PPPoE client to PPPoE server is correctly defined and working. Again as long as this is not intended as a standard RFC, I personally see no problems in making a disclaimer in the draft as James suggest, that this draft do not conform to IEEE standards, isn't endorsed by the IETF/IESG, and may simply fall apart in some deployments. Even better I will happily change the draft to outline the scenario in which the proposed functionality will not work. Let us agree that networks can always be build in a way where they simply do not work, even if all functionality follows a defined standard. The draft is intended to allow a larger negotiated PPPoE MRU in networks designed for such functionality, and it is the idea that the control of enabling such functionality should be in the power of the carrier, as they can decide if the BRAS is to allow a MRU negotiation larger than 1492, and when it will allow it. Since again the intention is not to solve all network issues when increasing the PPPoE MRU, I also do not see a need for introducing a must support for a new PPPoE tag. Some BRAS equipment as well as CPE equipment today will allow the functionality as it is defined in the draft, and in a well known ethernet network it will allow MRU increase to PPPoE clients in a safe and backward compatible manner based on a simple MRU size configuration in the CPE and a more advanced configuration in the BRAS of when to allow this. Since many (most) broadband networks today is build in a way where the PPPoE client has the active role in initiating the PPP negotiation, a BRAS PPPoE server will based on it's configuration and the initial MRU request from the client have a knowledge of when to allow a larger MRU and when not to do so. So in such a network a new PPPoE tag will be of no value. Only in a network where the PPPoE server (BRAS) is the active part in initiating the PPP negotiation will it not be possible to increase the MRU in a safe backward compatible manner, with a single centralized BRAS configuration, and only in such a network design do it make sense to me to include an optional new PPPoE tag to be sent from the PPPoE client to the server to indicate a larger MRU is acceptable to the client. thanks, Peter > -----Original Message----- > From: pppext-bounces@ietf.org > [mailto:pppext-bounces@ietf.org] On Behalf Of Karl Fox > Sent: 3. juli 2005 01:23 > To: James Carlson > Cc: pppext@ietf.org > Subject: Re: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 > > On Jul 2, 2005, at 3:31 PM, James Carlson wrote: > > Jerome Moisand writes: > >> Yet we need the mitigation mechanism to deal with legacy cases, and > >> notably home LANs limited to 1500 Ethernet frames. > > > > Ditching PPPoE as an unnecessary expense and just using plain old IP > > on Ethernet would fix that problem neatly. > > PPPoE was a bad idea from the start. It was rammed through as > Informational by a few industry advocates despite warnings and the > stern disapproval of essentially every participant in the PPPEXT > working group, simply because some large providers didn't want to > change their view that all ISP customers should look like dial-up > users. Get over it and use a real protocol, just as Jim recommends. > > Karl > > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www1.ietf.org/mailman/listinfo/pppext > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Sat Jul 02 20:40:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DosWx-0003pY-6n; Sat, 02 Jul 2005 20:40:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DosWu-0003oW-SG for pppext@megatron.ietf.org; Sat, 02 Jul 2005 20:40:16 -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 UAA15373 for ; Sat, 2 Jul 2005 20:40:14 -0400 (EDT) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dosx9-0002G6-FT for pppext@ietf.org; Sat, 02 Jul 2005 21:07:25 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j630drLQ038264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for env-from ; Sat, 2 Jul 2005 18:39:53 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j630dr8Y038263 for pppext@ietf.org; Sat, 2 Jul 2005 18:39:53 -0600 (MDT) Date: Sat, 2 Jul 2005 18:39:53 -0600 (MDT) From: Vernon Schryver Message-Id: <200507030039.j630dr8Y038263@calcite.rhyolite.com> To: pppext@ietf.org Subject: RE: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 In-Reply-To: <20050703000750.440D35E01C7@prattle.redback.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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: "Peter Arberg" > I'm glad you got that out of your system Karl, but now let us > try and reset the discussion, and deal with some reality. Yes, let's. For the many years that I've known them, Karl and Jim been be too willing to suffer foolishness. I suspect that what they are really thinking is vastly stronger than what you have probably understood from their gentle words. > PPPoE might be a bad idea, but it is very real, and a large percentage > of the top 100 carriers in the world are using it today, and a lot of > them will continue to use it for a long time to come, and as such it > is only natural that PPPoE requirements evolve over time. Those facts do not in any way justify standardizing something that will have even more interoperability problems that the original PPPoE. The IETF is not a vanity publish house. It exists only to minimize and prevent interoperability problems. > Sine PPPoE was made an informational RFC back in 1999, at least > in my mind, will say that IETF and as such the pppext working group is > the right place to discuss enhancements to the protocol. That reasoning might justify moving all of IEEE's work to the IETF, since there are RFCs that are standards instead of mere Informational documents. Still, if your proposal required changing only IETF documents, this would be the right place. However, you have consistently ignored the point that your proposal depends on changes in IEEE standards. > The draft-arberg-pppoe-mtu-gt1492-00 is in no way looking to be on > the standard track, it is intended to become an informational RFC to > tell people what is deployed and doable today in carriers networks. The IETF has been trying in recent years to reduce the incidence of disasters like PPPoE by requiring technical review of even Informational RFCs. Unless you can get some consensus that your proposal has sufficient technical merit and is unlikely to cause harm, you might and certainly should have problems getting it published even as an Informational RFC, at least not without some of the "DANGER DO NOT IMPLEMENT OR EVEN READ THIS!" warnings that James Carlson has suggested. > It is a lot easier if different carriers and vendors have a common > document to base their discussion on. The IETF has no monopoly on printing presses. Be honest about what you are doing and admit that you don't merely want to publish a document for discussion. If that's all you wanted to do, you could have done it on your own web site. Having had an I-D published would also be sufficient if you only wanted to float some ideas. What you are really doing is what many people have done and many more have tried to do. That is to get the IETF's imprimatur on a protocol. You will then go to other vendors, carriers, and even the IEEE and say "The IETF has approved this changed as you can see from RFC 98765, so you must go along with it." Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Jul 07 13:15:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqZyV-0005qG-Fs; Thu, 07 Jul 2005 13:15:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqZyU-0005pp-81 for pppext@megatron.ietf.org; Thu, 07 Jul 2005 13:15:46 -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 NAA26771 for ; Thu, 7 Jul 2005 13:15:42 -0400 (EDT) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqaPh-0002ZU-0k for pppext@ietf.org; Thu, 07 Jul 2005 13:43:54 -0400 Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 18:15:26 +0100 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 18:15:26 +0100 Received: from antipi.jnpr.net ([10.10.2.34]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 Jul 2005 13:15:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 Date: Thu, 7 Jul 2005 13:15:25 -0400 Message-ID: <6B8F46B46D292A438250E42591ABB59D0224648D@antipi.jnpr.net> Thread-Topic: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 Thread-Index: AcV+YzmfKxgnNtjDSnqDmIcKRJf/5QEss1lg From: "Jerome Moisand" To: X-OriginalArrivalTime: 07 Jul 2005 17:15:26.0289 (UTC) FILETIME=[77892410:01C58317] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable 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 and al. 1. You made me check, and you are indeed correct about the lack of IEEE standard for jumbo-frames. This is such a widely supported practice though and DSL providers have enough control on the access/aggregation network to easily enforce support for jumbo-frames on each network segment.=20 =3D> Agreed, you have a point, a disclaimer might be in order. 2. New PPPoE tag: we're in agreement here. I'm going to make a proposal for including such mechanism in an update to the proposed I-D, after syncing up with the existing co-authors.=20 Please note that this entire discussion applies to tens of millions of DSL lines worldwide. So this is quite a real-life situation. Tx Jerome -----Original Message----- From: James Carlson [mailto:james.d.carlson@sun.com]=20 Sent: Friday, July 01, 2005 1:35 PM To: Jerome Moisand Cc: pppext@ietf.org Subject: RE: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 Jerome Moisand writes: > =3D=3D> This feature is intended as a "safety net" and a = troubleshooting > mechanism, but using it for every PPP session establishment would > significantly lower call setup performance, while not adding any > meaningful value to typical broadband environments. Personally, I am > actually not entirely convinced this feature is worth the trouble! Performance will be much worse if there's a bridged link in path between PPPoE client and server that restricts the MTU to the IEEE-specified maximum. Worse still, if you have a network with multiple paths for redundancy (using Spanning Tree), the path you take during PPPoE/PPP session set-up may be different than the one you take after a successfully-handled L2 link failure, and you get no notification that this has happened, and the restrictions on the new path through the L2 network may differ. In other words, I remain skeptical that this can actually be deployed safely without having the IEEE itself redefine the L2 header/payload split to conform to what this proposal is actually doing. And I think it's somewhat outside the bounds of normal IETF activity to have a published RFC that suggests doing something that isn't supported by the underlying non-IETF standards. If the draft authors are going to go ahead anyway with publication as an Informational document, I'd like to see a disclaimer near the top of the document stating that the procedure described does not conform to IEEE standards, isn't endorsed by the IETF/IESG, and may simply fall apart in some deployments. > =3D=3D> I'd like to propose that we introduce a new PPPoE tag where = the > PPPoE client indicates if the 1492 constraint can be lifted (in its best > assessment of its own capabilities and of the network it is connected > to), and to which extent (up to 1500, possibly more). If such new option > isn't included by the client, then the existing behavior must be > assumed. I agree. That fixes the naive-client problem; thanks. --=20 James Carlson, KISS Network 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 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Jul 07 15:31:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqc5Z-0002uf-Mj; Thu, 07 Jul 2005 15:31:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqc5X-0002to-8Q for pppext@megatron.ietf.org; Thu, 07 Jul 2005 15:31:11 -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 PAA12233 for ; Thu, 7 Jul 2005 15:31:08 -0400 (EDT) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqcWk-0002Gt-T1 for pppext@ietf.org; Thu, 07 Jul 2005 15:59:20 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j67JUmNt069558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for env-from ; Thu, 7 Jul 2005 13:30:48 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j67JUmRx069557 for pppext@ietf.org; Thu, 7 Jul 2005 13:30:48 -0600 (MDT) Date: Thu, 7 Jul 2005 13:30:48 -0600 (MDT) From: Vernon Schryver Message-Id: <200507071930.j67JUmRx069557@calcite.rhyolite.com> To: pppext@ietf.org Subject: RE: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 In-Reply-To: <6B8F46B46D292A438250E42591ABB59D0224648D@antipi.jnpr.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: "Jerome Moisand" > Please note that this entire discussion applies to tens of millions of > DSL lines worldwide. So this is quite a real-life situation. Please! There are zillions of DSL lines, but the proposal is not about real-life until and unless it becomes a widely implemented de facto standard. If theoretical or claimed market size were tantamount to real-life, then we'd be using ISO OSI suite today, along with a lot of other things that somehow ever crossed from claimed market potential to what some of us understand as reality. I've not noticed an answer to the question of why it would not be better to switch to ordinary IP/PPP, perhaps BP instead of IPCP, from PPPoE. Why wouldn't that more of any available MTU increase from 802.3 jumbo frames? Why wouldn't that be at just as easy to implement in in all of the boxes that will need new firmware or software for any change? Why wouldn't it be at least as robust? Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Jul 07 17:16:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqdjg-0002hB-Pd; Thu, 07 Jul 2005 17:16:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqdjf-0002en-8s for pppext@megatron.ietf.org; Thu, 07 Jul 2005 17:16:43 -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 RAA06016 for ; Thu, 7 Jul 2005 17:16:40 -0400 (EDT) Received: from adsl-69-233-182-147.dsl.pltn13.pacbell.net ([69.233.182.147] helo=jfitz.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DqeAu-0002Am-8F for pppext@ietf.org; Thu, 07 Jul 2005 17:44:53 -0400 Received: (qmail 84712 invoked from network); 7 Jul 2005 21:16:32 -0000 Received: from localhost.jfitz.com (HELO fitzlt.jfitz.com) (127.0.0.1) by localhost.jfitz.com with SMTP; 7 Jul 2005 21:16:31 -0000 Content-Type: text/plain; charset="iso-8859-1" From: John Fitzgibbon To: pppext@ietf.org Subject: Re: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 Date: Thu, 7 Jul 2005 14:16:31 -0700 User-Agent: KMail/1.4.3 References: <200507071930.j67JUmRx069557@calcite.rhyolite.com> In-Reply-To: <200507071930.j67JUmRx069557@calcite.rhyolite.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200507071416.32146.fitz@jfitz.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 8bit 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 Thursday 07 July 2005 12:30 pm, Vernon Schryver wrote: > I've not noticed an answer to the question of why it would not be > better to switch to ordinary IP/PPP ... > ... Why wouldn't that be at just as easy to implement Re-architecting "zillions of DSL lines" that work today, (albeit with a sucky MTU of 1492), to use plain old IP, while a laudable goal, would be a provisioning nightmare. It means every customer's setup needs to change. I don't believe any of the big providers would have the stomach for it. Running PPPoE and IP in tandem might be feasible, but it still imposes additional administrative costs. The provider I have spoken to about this issue assured me that they will not support multiple delivery protocols any time soon. A point-release software upgrade to a provider's PPPoE-based equipment is a more attainable goal, and it is certainly easier to implement, since it does not break or change the existing client-side provisioning. That would at least offer a DSL customer like myself the possibility of getting a compliant IP service, without altering the service for customers that are happy with/unaware of the limitations of their current service. This may not be a "technically satisfying" solution, (it's a kludge to fix something that was a bad idea to begin with), but it seems to me like it is the only compromise that stands a chance of getting existing DSL customers out of the "1492" hole, without requiring a massive re-provisioning exercise. I would rather see this "kludge", (and its limitations), formalized in an Informational RFC than implemented in an ad-hoc way. John Fitzgibbon On Thursday 07 July 2005 12:30 pm, Vernon Schryver wrote: > > From: "Jerome Moisand" > > > > Please note that this entire discussion applies to tens of millions of > > DSL lines worldwide. So this is quite a real-life situation. > > Please! There are zillions of DSL lines, but the proposal is not about > real-life until and unless it becomes a widely implemented de facto > standard. If theoretical or claimed market size were tantamount to > real-life, then we'd be using ISO OSI suite today, along with a lot > of other things that somehow ever crossed from claimed market potential > to what some of us understand as reality. > > I've not noticed an answer to the question of why it would not be > better to switch to ordinary IP/PPP, perhaps BP instead of IPCP, > from PPPoE. Why wouldn't that more of any available MTU increase from > 802.3 jumbo frames? Why wouldn't that be at just as easy to implement > in in all of the boxes that will need new firmware or software for > any change? Why wouldn't it be at least as robust? > > > Vernon Schryver vjs@rhyolite.com > > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www1.ietf.org/mailman/listinfo/pppext _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Jul 07 18:15:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqeev-0002eR-1T; Thu, 07 Jul 2005 18:15:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqees-0002cE-SO for pppext@megatron.ietf.org; Thu, 07 Jul 2005 18:15: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 SAA10591 for ; Thu, 7 Jul 2005 18:15:47 -0400 (EDT) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqf69-0007XL-Ab for pppext@ietf.org; Thu, 07 Jul 2005 18:44:01 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j67MFXHA028386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for env-from ; Thu, 7 Jul 2005 16:15:33 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j67MFX4m028385 for pppext@ietf.org; Thu, 7 Jul 2005 16:15:33 -0600 (MDT) Date: Thu, 7 Jul 2005 16:15:33 -0600 (MDT) From: Vernon Schryver Message-Id: <200507072215.j67MFX4m028385@calcite.rhyolite.com> To: pppext@ietf.org Subject: Re: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 In-Reply-To: <200507071416.32146.fitz@jfitz.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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: John Fitzgibbon > > I've not noticed an answer to the question of why it would not be > > better to switch to ordinary IP/PPP ... > > ... Why wouldn't that be at just as easy to implement > > Re-architecting "zillions of DSL lines" that work today, (albeit with a sucky > MTU of 1492), to use plain old IP, while a laudable goal, would be a > provisioning nightmare. It means every customer's setup needs to change. I > don't believe any of the big providers would have the stomach for it. Why would there be any more "re-architecting" to change to real PPP than to change to the new version of PPPoE? (If you answer, please do not assume this audience is ignorant of IP, PPP, PPPoE, PPPoA, etc. Not to put too fine a point on it, some of the statements in support of the proposal suggest an odd view of PPP and at worst marketing smoke and mirrors. For one example, there was the recent referenc to "PPP fragmentation" without any mention of the only PPP fragmentation mechanism I know about, the multilink protocol (MP). MP sounds like an unlikely addition to PPPoE. > Running PPPoE and IP in tandem might be feasible, but it still imposes > additional administrative costs. The provider I have spoken to about this > issue assured me that they will not support multiple delivery protocols any > time soon. What do you mean by "running PPPoE and IP in tandem" as if it were radicatlly different than the current case? How many PPPoE DSL customer gets only PPPoE service without IP service? Have you used the (or an) other very common IP encapsulation over DSL, PPPoA? The several brands of customer premises equipment DSL boxes I've played with make almost no user-visible distinction between PPPoE and PPPoA. They all require about the same configuration choices, with the choice between PPPoA and PPPoE being merely one among static vs. DHCP IP address, routing options, and zillions firewall knobs and switches such as DMZ hosts, VPN help, and internal address block (NAT). > A point-release software upgrade to a provider's PPPoE-based equipment is a > more attainable goal, and it is certainly easier to implement, since it does > not break or change the existing client-side provisioning. That is true only if the new MTU feature the proposal is not used. You must at least install new client-side firmware or software to use the larger MTU. As James Carlson has repeated pointed out, end users will probably need to make an additional client-side provisioning choice of "network is transparent for jumbo 802.3 frames or not." > That would at > least offer a DSL customer like myself the possibility of getting a compliant > IP service, without altering the service for customers that are happy > with/unaware of the limitations of their current service. > > This may not be a "technically satisfying" solution, (it's a kludge to fix > something that was a bad idea to begin with), but it seems to me like it is > the only compromise that stands a chance of getting existing DSL customers > out of the "1492" hole, without requiring a massive re-provisioning exercise. I cannot see how that can be true. If you do not change client-side hardware, perhaps only with "firmware download" but quite possible with a "fork lift upgrade," you will remain stuck in the "1492 hole." > I would rather see this "kludge", (and its limitations), formalized in an > Informational RFC than implemented in an ad-hoc way. PPPoE is itself "implemeted in an ad-hoc way." PPPoE is not an offical standard but an ad hoc kludge. There is *ABSOLUTELY NO* chance this proposal ever being anything published as other than an Informational RFC with "DO NOT IMPLEMENT" warnings. If implementations of such a thing aren't ad hoc, what are? Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Jul 07 18:53:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqfFm-0001Mi-VH; Thu, 07 Jul 2005 18:53:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqfFk-0001JW-TX for pppext@megatron.ietf.org; Thu, 07 Jul 2005 18:53:56 -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 SAA13408 for ; Thu, 7 Jul 2005 18:53:53 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqfh1-0002ls-HH for pppext@ietf.org; Thu, 07 Jul 2005 19:22:08 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 5A761BE9B52 for ; Thu, 7 Jul 2005 15:53:35 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28775-02 for ; Thu, 7 Jul 2005 15:53:34 -0700 (PDT) Received: from [155.53.44.177] (salzburg.redback.com [155.53.44.177]) by prattle.redback.com (Postfix) with ESMTP id B1C07BE9B51 for ; Thu, 7 Jul 2005 15:53:34 -0700 (PDT) Message-ID: <42CDB26E.6020307@redback.com> Date: Thu, 07 Jul 2005 15:53:34 -0700 From: Diamantis Kourkouzelis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pppext@ietf.org Subject: Re: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 References: <200507072215.j67MFX4m028385@calcite.rhyolite.com> In-Reply-To: <200507072215.j67MFX4m028385@calcite.rhyolite.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 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: , Content-Type: multipart/mixed; boundary="===============1779141563==" Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org This is a multi-part message in MIME format. --===============1779141563== Content-Type: multipart/alternative; boundary="------------040004010007050206000004" This is a multi-part message in MIME format. --------------040004010007050206000004 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Vernon, What are your thoughts on figure 3 of the draft? The modem is pppoa, the dslam initiates the pppoe connection (transparent to the modem) and the bras accepts the 1500 mru requested by the modem (assuming the port mtu on the bras can support at least 1508). How does that affect the user or impose any requirement for a modem firmware upgrade? Any data being sent by the dslam towards the modem will still be at 1500 max (pppoa). Diamantis Vernon Schryver wrote: >>From: John Fitzgibbon >> >> > > > >>>I've not noticed an answer to the question of why it would not be >>>better to switch to ordinary IP/PPP ... >>>... Why wouldn't that be at just as easy to implement >>> >>> >>Re-architecting "zillions of DSL lines" that work today, (albeit with a sucky >>MTU of 1492), to use plain old IP, while a laudable goal, would be a >>provisioning nightmare. It means every customer's setup needs to change. I >>don't believe any of the big providers would have the stomach for it. >> >> > >Why would there be any more "re-architecting" to change to real PPP >than to change to the new version of PPPoE? > >(If you answer, please do not assume this audience is ignorant of IP, >PPP, PPPoE, PPPoA, etc. Not to put too fine a point on it, some of >the statements in support of the proposal suggest an odd view of PPP >and at worst marketing smoke and mirrors. For one example, there was >the recent referenc to "PPP fragmentation" without any mention of the >only PPP fragmentation mechanism I know about, the multilink protocol (MP). >MP sounds like an unlikely addition to PPPoE. > > > > >>Running PPPoE and IP in tandem might be feasible, but it still imposes >>additional administrative costs. The provider I have spoken to about this >>issue assured me that they will not support multiple delivery protocols any >>time soon. >> >> > >What do you mean by "running PPPoE and IP in tandem" as if it were >radicatlly different than the current case? How many PPPoE DSL customer >gets only PPPoE service without IP service? > >Have you used the (or an) other very common IP encapsulation over DSL, >PPPoA? The several brands of customer premises equipment DSL boxes >I've played with make almost no user-visible distinction between PPPoE >and PPPoA. They all require about the same configuration choices, >with the choice between PPPoA and PPPoE being merely one among static >vs. DHCP IP address, routing options, and zillions firewall knobs and >switches such as DMZ hosts, VPN help, and internal address block (NAT). > > > > >>A point-release software upgrade to a provider's PPPoE-based equipment is a >>more attainable goal, and it is certainly easier to implement, since it does >>not break or change the existing client-side provisioning. >> >> > >That is true only if the new MTU feature the proposal is not used. >You must at least install new client-side firmware or software to use >the larger MTU. As James Carlson has repeated pointed out, end users >will probably need to make an additional client-side provisioning >choice of "network is transparent for jumbo 802.3 frames or not." > > > >> That would at >>least offer a DSL customer like myself the possibility of getting a compliant >>IP service, without altering the service for customers that are happy >>with/unaware of the limitations of their current service. >> >>This may not be a "technically satisfying" solution, (it's a kludge to fix >>something that was a bad idea to begin with), but it seems to me like it is >>the only compromise that stands a chance of getting existing DSL customers >>out of the "1492" hole, without requiring a massive re-provisioning exercise. >> >> > >I cannot see how that can be true. If you do not change client-side >hardware, perhaps only with "firmware download" but quite possible >with a "fork lift upgrade," you will remain stuck in the "1492 hole." > > > > >>I would rather see this "kludge", (and its limitations), formalized in an >>Informational RFC than implemented in an ad-hoc way. >> >> > >PPPoE is itself "implemeted in an ad-hoc way." PPPoE is not an offical >standard but an ad hoc kludge. There is *ABSOLUTELY NO* chance this >proposal ever being anything published as other than an Informational >RFC with "DO NOT IMPLEMENT" warnings. If implementations of such a >thing aren't ad hoc, what are? > > >Vernon Schryver vjs@rhyolite.com > >_______________________________________________ >Pppext mailing list >Pppext@ietf.org >https://www1.ietf.org/mailman/listinfo/pppext > > --------------040004010007050206000004 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
 Hi Vernon,

 What are your thoughts on figure 3 of the draft? The modem is pppoa,
 the dslam initiates the pppoe connection (transparent to the modem)
 and the bras accepts the 1500 mru requested by the modem (assuming
 the port mtu on the bras can support at least 1508).

 How does that affect the user or impose any requirement for a modem
 firmware upgrade? Any data being sent by the dslam towards the modem will
 still be at 1500 max (pppoa).

 Diamantis

Vernon Schryver wrote: 
From: John Fitzgibbon <fitz@jfitz.com>
    

  
I've not noticed an answer to the question of why it would not be
better to switch to ordinary IP/PPP ...
... Why wouldn't that be at just as easy to implement
      
Re-architecting "zillions of DSL lines" that work today, (albeit with a sucky 
MTU of 1492), to use plain old IP, while a laudable goal, would be a 
provisioning nightmare. It means every customer's setup needs to change. I 
don't believe any of the big providers would have the stomach for it.
    

Why would there be any more "re-architecting" to change to real PPP
than to change to the new version of PPPoE?

(If you answer, please do not assume this audience is ignorant of IP,
PPP, PPPoE, PPPoA, etc.  Not to put too fine a point on it, some of
the statements in support of the proposal suggest an odd view of PPP
and at worst marketing smoke and mirrors.  For one example, there was
the recent referenc to "PPP fragmentation" without any mention of the
only PPP fragmentation mechanism I know about, the multilink protocol (MP).
MP sounds like an unlikely addition to PPPoE.


  
Running PPPoE and IP in tandem might be feasible, but it still imposes 
additional administrative costs. The provider I have spoken to about this 
issue assured me that they will not support multiple delivery protocols any 
time soon.
    

What do you mean by "running PPPoE and IP in tandem" as if it were
radicatlly different than the current case?  How many PPPoE DSL customer
gets only PPPoE service without IP service?

Have you used the (or an) other very common IP encapsulation over DSL,
PPPoA?  The several brands of customer premises equipment DSL boxes
I've played with make almost no user-visible distinction between PPPoE
and PPPoA.  They all require about the same configuration choices,
with the choice between PPPoA and PPPoE being merely one among static
vs. DHCP IP address, routing options, and zillions firewall knobs and
switches such as DMZ hosts, VPN help, and internal address block (NAT).


  
A point-release software upgrade to a provider's PPPoE-based equipment is a 
more attainable goal, and it is certainly easier to implement, since it does 
not break or change the existing client-side provisioning. 
    

That is true only if the new MTU feature the proposal is not used.
You must at least install new client-side firmware or software to use
the larger MTU.  As James Carlson has repeated pointed out, end users
will probably need to make an additional client-side provisioning
choice of "network is transparent for jumbo 802.3 frames or not."

  
                                                           That would at 
least offer a DSL customer like myself the possibility of getting a compliant 
IP service, without altering the service for customers that are happy 
with/unaware of the limitations of their current service. 

This may not be a "technically satisfying" solution, (it's a kludge to fix 
something that was a bad idea to begin with), but it seems to me like it is 
the only compromise that stands a chance of getting existing DSL customers 
out of the "1492" hole, without requiring a massive re-provisioning exercise. 
    

I cannot see how that can be true.  If you do not change client-side
hardware, perhaps only with "firmware download" but quite possible
with a "fork lift upgrade," you will remain stuck in the "1492 hole."


  
I would rather see this "kludge", (and its limitations), formalized in an 
Informational RFC than implemented in an ad-hoc way.
    

PPPoE is itself "implemeted in an ad-hoc way."   PPPoE is not an offical
standard but an ad hoc kludge.  There is *ABSOLUTELY NO* chance this
proposal ever being anything published as other than an Informational
RFC with "DO NOT IMPLEMENT" warnings.  If implementations of such a
thing aren't ad hoc, what are?


Vernon Schryver    vjs@rhyolite.com

_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www1.ietf.org/mailman/listinfo/pppext
--------------040004010007050206000004-- --===============1779141563== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext --===============1779141563==-- From pppext-bounces@ietf.org Thu Jul 07 20:23:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqgeT-0002D0-6n; Thu, 07 Jul 2005 20:23:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqgeR-0002Cn-Ig for pppext@megatron.ietf.org; Thu, 07 Jul 2005 20:23: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 UAA18734 for ; Thu, 7 Jul 2005 20:23:29 -0400 (EDT) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqh5h-0002UF-Vr for pppext@ietf.org; Thu, 07 Jul 2005 20:51:43 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j680NCsF072953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for env-from ; Thu, 7 Jul 2005 18:23:12 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j680NCI5072952 for pppext@ietf.org; Thu, 7 Jul 2005 18:23:12 -0600 (MDT) Date: Thu, 7 Jul 2005 18:23:12 -0600 (MDT) From: Vernon Schryver Message-Id: <200507080023.j680NCI5072952@calcite.rhyolite.com> To: pppext@ietf.org Subject: Re: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 In-Reply-To: <42CDB26E.6020307@redback.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: Diamantis Kourkouzelis > What are your thoughts on figure 3 of the draft? The modem is pppoa, > the dslam initiates the pppoe connection (transparent to the modem) > and the bras accepts the 1500 mru requested by the modem (assuming > the port mtu on the bras can support at least 1508). > > How does that affect the user or impose any requirement for a modem > firmware upgrade? Any data being sent by the dslam towards the modem will > still be at 1500 max (pppoa). What magic switches the customer premises equipment (CPE or end user DSL modem) from PPPoE to PPPoA? How do you reach out and toggle switches in those bazillions of CPE that were just today mentioned as justifying this proposal without a problematic remote reconfiguration and reboot of zillions of CPE and probably a new firmware download to change the hold-reset-button-with-paper-clip default for the PPPoE/PPPoA switch? I wonder also how much market there would be for a protocol that would give providers more classes of customer, new DSLAM+CPE that likes PPPoA vs. old DSLAM+CPE that prefers PPPoE, merely so that some customers would have MTUs of 1500. However, as far as I'm concerned, switching the CPE-DSLAM link to PPPoA would amount to switching to from PPPoE to standard IP over PPP as far as the IETF is concerned. The provider's internal, private links seem outside the perview of the IETF. It strikes me as perverse to re-encapsulate perfectly good IP/.../ATM packets in and out of IP/.../PPPoE/.../ATM in the broadband remote access server (BRAS), but none of my business. If a vendor has a wonderful SuperDuperUltra- WideBandSpreadSpectrum or other magic to move IP packets between a DSLAM and a service provider's routers, then great and why should the IETF interfere, give permission, or be involved at all? Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Jul 07 21:15:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqhSW-0007vc-7b; Thu, 07 Jul 2005 21:15:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqhSU-0007tJ-Cp for pppext@megatron.ietf.org; Thu, 07 Jul 2005 21:15:14 -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 VAA22758 for ; Thu, 7 Jul 2005 21:15:12 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqhtm-0007YK-B3 for pppext@ietf.org; Thu, 07 Jul 2005 21:43:26 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id C3B1AC957D9 for ; Thu, 7 Jul 2005 18:15:04 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06814-09 for ; Thu, 7 Jul 2005 18:15:04 -0700 (PDT) Received: from [155.53.44.177] (salzburg.redback.com [155.53.44.177]) by prattle.redback.com (Postfix) with ESMTP id 1EA21C957DA for ; Thu, 7 Jul 2005 18:15:04 -0700 (PDT) Message-ID: <42CDD398.9040101@redback.com> Date: Thu, 07 Jul 2005 18:15:04 -0700 From: Diamantis Kourkouzelis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pppext@ietf.org Subject: Re: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 References: <200507080023.j680NCI5072952@calcite.rhyolite.com> In-Reply-To: <200507080023.j680NCI5072952@calcite.rhyolite.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 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: , Content-Type: multipart/mixed; boundary="===============1540661487==" Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org This is a multi-part message in MIME format. --===============1540661487== Content-Type: multipart/alternative; boundary="------------030204090309090905050306" This is a multi-part message in MIME format. --------------030204090309090905050306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Vernon, The modem was never pppoe to begin with. The pppoe session will be initiated by the dslam when it receives the lcp confreq from the modem and will forward it to the bras (over pppoe) once the pppoe session gets established. When the dslam receives the lcp confack from the bras, it will strip the pppoe header and send it to the modem. The dslam is responsible for the vpi/vci to pppoe session-id mapping. As far as the modem is concerned, there is no pppoe segment in the network, unless the bras naks the 1500 mru down to 1492, as it would do today. Diamantis Vernon Schryver wrote: >>From: Diamantis Kourkouzelis >> >> > > > >> What are your thoughts on figure 3 of the draft? The modem is pppoa, >> the dslam initiates the pppoe connection (transparent to the modem) >> and the bras accepts the 1500 mru requested by the modem (assuming >> the port mtu on the bras can support at least 1508). >> >> How does that affect the user or impose any requirement for a modem >> firmware upgrade? Any data being sent by the dslam towards the modem will >> still be at 1500 max (pppoa). >> >> > >What magic switches the customer premises equipment (CPE or end >user DSL modem) from PPPoE to PPPoA? How do you reach out and >toggle switches in those bazillions of CPE that were just today >mentioned as justifying this proposal without a problematic remote >reconfiguration and reboot of zillions of CPE and probably a new >firmware download to change the hold-reset-button-with-paper-clip >default for the PPPoE/PPPoA switch? > >I wonder also how much market there would be for a protocol that would >give providers more classes of customer, new DSLAM+CPE that likes PPPoA >vs. old DSLAM+CPE that prefers PPPoE, merely so that some customers >would have MTUs of 1500. > >However, as far as I'm concerned, switching the CPE-DSLAM link to PPPoA >would amount to switching to from PPPoE to standard IP over PPP as far >as the IETF is concerned. The provider's internal, private links seem >outside the perview of the IETF. It strikes me as perverse to >re-encapsulate perfectly good IP/.../ATM packets in and out of >IP/.../PPPoE/.../ATM in the broadband remote access server (BRAS), but >none of my business. If a vendor has a wonderful SuperDuperUltra- >WideBandSpreadSpectrum or other magic to move IP packets between a >DSLAM and a service provider's routers, then great and why should the >IETF interfere, give permission, or be involved at all? > > >Vernon Schryver vjs@rhyolite.com > >_______________________________________________ >Pppext mailing list >Pppext@ietf.org >https://www1.ietf.org/mailman/listinfo/pppext > > --------------030204090309090905050306 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
 Hi Vernon,

 The modem was never pppoe to begin with. The pppoe
 session will be initiated by the dslam when it receives
 the lcp confreq from the modem and will forward it
 to the bras (over pppoe) once the pppoe session gets
 established.

 When the dslam receives the lcp confack from the bras,
 it will strip the pppoe header and send it to the modem.
 The dslam is responsible for the vpi/vci to pppoe session-id
 mapping. As far as the modem is concerned, there is no pppoe
 segment in the network, unless the bras naks the 1500 mru
 down to 1492, as it would do today.

 Diamantis
 

Vernon Schryver wrote: 
From: Diamantis Kourkouzelis <diamondk@redback.com>
    

  
 What are your thoughts on figure 3 of the draft? The modem is pppoa,
 the dslam initiates the pppoe connection (transparent to the modem)
 and the bras accepts the 1500 mru requested by the modem (assuming
 the port mtu on the bras can support at least 1508).

 How does that affect the user or impose any requirement for a modem
 firmware upgrade? Any data being sent by the dslam towards the modem will
 still be at 1500 max (pppoa).
    

What magic switches the customer premises equipment (CPE or end
user DSL modem) from PPPoE to PPPoA?  How do you reach out and
toggle switches in those bazillions of CPE that were just today
mentioned as justifying this proposal without a problematic remote
reconfiguration and reboot of zillions of CPE and probably a new
firmware download to change the hold-reset-button-with-paper-clip
default for the PPPoE/PPPoA switch?

I wonder also how much market there would be for a protocol that would
give providers more classes of customer, new DSLAM+CPE that likes PPPoA
vs. old DSLAM+CPE that prefers PPPoE, merely so that some customers
would have MTUs of 1500.

However, as far as I'm concerned, switching the CPE-DSLAM link to PPPoA
would amount to switching to from PPPoE to standard IP over PPP as far
as the IETF is concerned.  The provider's internal, private links seem
outside the perview of the IETF.  It strikes me as perverse to
re-encapsulate perfectly good IP/.../ATM packets in and out of
IP/.../PPPoE/.../ATM in the broadband remote access server (BRAS), but
none of my business.  If a vendor has a wonderful SuperDuperUltra-
WideBandSpreadSpectrum or other magic to move IP packets between a
DSLAM and a service provider's routers, then great and why should the
IETF interfere, give permission, or be involved at all?


Vernon Schryver    vjs@rhyolite.com

_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www1.ietf.org/mailman/listinfo/pppext
--------------030204090309090905050306-- --===============1540661487== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext --===============1540661487==-- From pppext-bounces@ietf.org Thu Jul 07 22:06:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqiFx-00060D-5w; Thu, 07 Jul 2005 22:06:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqiFu-000602-9M for pppext@megatron.ietf.org; Thu, 07 Jul 2005 22:06:19 -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 WAA25802 for ; Thu, 7 Jul 2005 22:06:15 -0400 (EDT) Received: from adsl-69-233-182-147.dsl.pltn13.pacbell.net ([69.233.182.147] helo=jfitz.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DqihA-0003rT-Hz for pppext@ietf.org; Thu, 07 Jul 2005 22:34:31 -0400 Received: (qmail 97244 invoked from network); 8 Jul 2005 02:06:12 -0000 Received: from localhost.jfitz.com (HELO fitzlt.jfitz.com) (127.0.0.1) by localhost.jfitz.com with SMTP; 8 Jul 2005 02:06:11 -0000 Content-Type: text/plain; charset="iso-8859-1" From: John Fitzgibbon To: pppext@ietf.org Subject: Re: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 Date: Thu, 7 Jul 2005 19:06:12 -0700 User-Agent: KMail/1.4.3 References: <200507072215.j67MFX4m028385@calcite.rhyolite.com> In-Reply-To: <200507072215.j67MFX4m028385@calcite.rhyolite.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200507071906.12589.fitz@jfitz.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Content-Transfer-Encoding: 8bit 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 > Why would there be any more "re-architecting" to change to real PPP > than to change to the new version of PPPoE? Changing to real PPP would mean customers need to change their equipment. I believe the point of the PPPoE proposal is to maintain compatability so that existing customers with PPPoE and an MRU of 1492 will continue to have PPPoE with an MRU of 1492. No customer-facing changes required. Only whiners like myself would bother to upgrade software and/or hardware to take advantage of the 1500 byte MRU. Having me on "real PPP" and everybody else on PPPoE is the "in tandem" scenario I was talking about. More below... > If you answer, please do not assume this audience is ignorant of IP, > PPP, PPPoE, PPPoA, etc. Certainly. I assume quite the opposite, that the audience are the experts on IP, PPP, PPPoE, PPPoA, etc. I readily confess that I am not, and apologise if my lack of knowledge disappoints. (I am an interested observer, not involved with the current proposal, though I did propose a similar idea earlier.) > What do you mean by "running PPPoE and IP in tandem" as if it were > radicatlly different than the current case? This is probably a misleading choice of wording on my part. What I meant: Customer A uses PPPoE, (and runs IP over PPPoE). Customer B uses PPPoA, or "raw" IP, or whatever.... This scenario may be technically simple to implement, but major service providers will not support it. It costs them money to train people to test, deploy and support new/different protocols. I wish they hadn't chosen PPPoE as their protocol-of-choice, but wishful thinking won't change the current deployments. Of course you can argue that these are economic, not technical, considerations, and are none of the IETF's beeswax, but that doesn't help the equipment and service providers who are trying to find a low-cost, workable solution to a widespread problem. If the concensus IETF opinion is that the proposed "cure" is worse than the "disease", then we should probably just end the discussion here. > Have you used the (or an) other very common IP encapsulation over DSL, > PPPoA? Yes. Ironically, my service provider, (apparently like many others), changed from using PPPoA to PPPoE. They will no longer allow me to connect to their upstream equipment using PPPoA. There are no non-PPPoE residential solutions in my area that meet my needs. I am not alone. > That is true only if the new MTU feature the proposal is not used. > You must at least install new client-side firmware or software to use > the larger MTU. Agreed. > As James Carlson has repeated pointed out, end users > will probably need to make an additional client-side provisioning > choice of "network is transparent for jumbo 802.3 frames or not." I agree with the theory here, but I'm not sure that this would necessarily be a major issue in practise. For most "closed" networks, the providers can verify that the new upstream equipment works with the originally provisioned, provider-approved, downstream equipment. Therefore, there should not be any client-side changes required to maintain the status-quo, (i.e. PPPoE with MRU=1492). Only users who upgrade to MRU=1500 would need to make additional provisioning choices. I completely agree that any proposed change should err on the side of caution to help mitigate against compatability problems. Again, if the concensus IETF opinion is that the proposed change is only likely to make a bad situation worse, then we should probably end this discussion. > PPPoE is itself "implemeted in an ad-hoc way." PPPoE is not an offical > standard but an ad hoc kludge. There is *ABSOLUTELY NO* chance this > proposal ever being anything published as other than an Informational > RFC with "DO NOT IMPLEMENT" warnings. If implementations of such a > thing aren't ad hoc, what are? By "ad hoc" I mean a scenario more like Juniper implementing support for an MRU > 1492 only when a new tag is specified, while Cisco implement support for a higher negotiated MRUs without a tag, or with a different tag. At least if there is an Informational RFC, then there is an increased likelihood that the implementations would maintain some level of compatability. If the concensus IETF view is that such an RFC would not be accepted without a warning that says "DO NOT IMPLEMENT", (as opposed to the wording James Carlson suggested), then I would think that this whole discussion is moot. A detailed description of a protocol change that is not to be implemented would surely be a waste of time. John Fitzgibbon On Thursday 07 July 2005 03:15 pm, Vernon Schryver wrote: > > From: John Fitzgibbon > > > > > I've not noticed an answer to the question of why it would not be > > > better to switch to ordinary IP/PPP ... > > > ... Why wouldn't that be at just as easy to implement > > > > Re-architecting "zillions of DSL lines" that work today, (albeit with a > > sucky MTU of 1492), to use plain old IP, while a laudable goal, would be > > a provisioning nightmare. It means every customer's setup needs to > > change. I don't believe any of the big providers would have the stomach > > for it. > > Why would there be any more "re-architecting" to change to real PPP > than to change to the new version of PPPoE? > > (If you answer, please do not assume this audience is ignorant of IP, > PPP, PPPoE, PPPoA, etc. Not to put too fine a point on it, some of > the statements in support of the proposal suggest an odd view of PPP > and at worst marketing smoke and mirrors. For one example, there was > the recent referenc to "PPP fragmentation" without any mention of the > only PPP fragmentation mechanism I know about, the multilink protocol (MP). > MP sounds like an unlikely addition to PPPoE. > > > Running PPPoE and IP in tandem might be feasible, but it still imposes > > additional administrative costs. The provider I have spoken to about this > > issue assured me that they will not support multiple delivery protocols > > any time soon. > > What do you mean by "running PPPoE and IP in tandem" as if it were > radicatlly different than the current case? How many PPPoE DSL customer > gets only PPPoE service without IP service? > > Have you used the (or an) other very common IP encapsulation over DSL, > PPPoA? The several brands of customer premises equipment DSL boxes > I've played with make almost no user-visible distinction between PPPoE > and PPPoA. They all require about the same configuration choices, > with the choice between PPPoA and PPPoE being merely one among static > vs. DHCP IP address, routing options, and zillions firewall knobs and > switches such as DMZ hosts, VPN help, and internal address block (NAT). > > > A point-release software upgrade to a provider's PPPoE-based equipment is > > a more attainable goal, and it is certainly easier to implement, since it > > does not break or change the existing client-side provisioning. > > That is true only if the new MTU feature the proposal is not used. > You must at least install new client-side firmware or software to use > the larger MTU. As James Carlson has repeated pointed out, end users > will probably need to make an additional client-side provisioning > choice of "network is transparent for jumbo 802.3 frames or not." > > > That would at > > least offer a DSL customer like myself the possibility of getting a > > compliant IP service, without altering the service for customers that are > > happy with/unaware of the limitations of their current service. > > > > This may not be a "technically satisfying" solution, (it's a kludge to > > fix something that was a bad idea to begin with), but it seems to me like > > it is the only compromise that stands a chance of getting existing DSL > > customers out of the "1492" hole, without requiring a massive > > re-provisioning exercise. > > I cannot see how that can be true. If you do not change client-side > hardware, perhaps only with "firmware download" but quite possible > with a "fork lift upgrade," you will remain stuck in the "1492 hole." > > > I would rather see this "kludge", (and its limitations), formalized in an > > Informational RFC than implemented in an ad-hoc way. > > PPPoE is itself "implemeted in an ad-hoc way." PPPoE is not an offical > standard but an ad hoc kludge. There is *ABSOLUTELY NO* chance this > proposal ever being anything published as other than an Informational > RFC with "DO NOT IMPLEMENT" warnings. If implementations of such a > thing aren't ad hoc, what are? > > > Vernon Schryver vjs@rhyolite.com > > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www1.ietf.org/mailman/listinfo/pppext _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Jul 07 23:08:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqjEX-0006pj-CC; Thu, 07 Jul 2005 23:08:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqjEW-0006pe-3Z for pppext@megatron.ietf.org; Thu, 07 Jul 2005 23:08:56 -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 XAA29054 for ; Thu, 7 Jul 2005 23:08:52 -0400 (EDT) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqjfm-0001Ea-IB for pppext@ietf.org; Thu, 07 Jul 2005 23:37:08 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j6838bbx038800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for env-from ; Thu, 7 Jul 2005 21:08:37 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j6838bqo038799 for pppext@ietf.org; Thu, 7 Jul 2005 21:08:37 -0600 (MDT) Date: Thu, 7 Jul 2005 21:08:37 -0600 (MDT) From: Vernon Schryver Message-Id: <200507080308.j6838bqo038799@calcite.rhyolite.com> To: pppext@ietf.org Subject: Re: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 In-Reply-To: <200507071906.12589.fitz@jfitz.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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: John Fitzgibbon > > Why would there be any more "re-architecting" to change to real PPP > > than to change to the new version of PPPoE? > > Changing to real PPP would mean customers need to change their equipment. I > believe the point of the PPPoE proposal is to maintain compatability so that > existing customers with PPPoE and an MRU of 1492 will continue to have PPPoE > with an MRU of 1492. No customer-facing changes required. Only whiners like > myself would bother to upgrade software and/or hardware to take advantage of > the 1500 byte MRU. > > Having me on "real PPP" and everybody else on PPPoE is the "in tandem" > scenario I was talking about. More below... How is having some end users with an MTU of 1492 and others with 1500 not a worse tandem situation? > > What do you mean by "running PPPoE and IP in tandem" as if it were > > radicatlly different than the current case? > > This is probably a misleading choice of wording on my part. What I meant: > > Customer A uses PPPoE, (and runs IP over PPPoE). > Customer B uses PPPoA, or "raw" IP, or whatever.... What about the recent messages that seem to say the proposal is only about end users who all already use PPPoA? > This scenario may be technically simple to implement, but major service > providers will not support it. Do you know that for a global fact? My very limited experience in buying DSL gave me the choice of any DSL flavor I wanted as long as it was PPPoA--of course I'd eliminated the ILEX without a moment's thought. If you're right, why don't you buy from one of the many smaller service providers that offer PPPoA? Why did I eliminate the ILEX?--for a zillion reasons starting with needing to get my IP address block routed and lacking the courage to try to explain AS numbers to their end-user sales and support people. > It costs them money to train people to test, > deploy and support new/different protocols. As far as service providers are concerned, why is having vanilla MTU-1492-PPPoE and improved MTU-1500-PPPoE better than vanilla PPPoE and vanilla PPPoA? I think it sounds significant worse, because today "everyone" knows all about PPPoA and PPPoE and that PPPoE implies 1492. I seem to be confused, but if the proposal has something to do with a new flavor of PPPoE visible to users, that would imply large scale support costs. Note that many and probably most of the contributors to this mailing list are more directly concerned about support costs for the users who are the technical people at service providers who would be doing the training etc. that you are talking about. > > Have you used the (or an) other very common IP encapsulation over DSL, > > PPPoA? > > Yes. Ironically, my service provider, (apparently like many others), changed > from using PPPoA to PPPoE. They will no longer allow me to connect to their > upstream equipment using PPPoA. There are no non-PPPoE residential solutions > in my area that meet my needs. I am not alone. Do you define "residenial solutions" as something like "retail consumer grade for less than $40/month probably with port 25 filtered"? If so, that sounds more relevant to your needs than a new PPPoE flavor. See RFC 4084, "Terminology for Describing Internet Connectivity." > > As James Carlson has repeated pointed out, end users > > will probably need to make an additional client-side provisioning > > choice of "network is transparent for jumbo 802.3 frames or not." > > I agree with the theory here, but I'm not sure that this would necessarily be > a major issue in practise. For most "closed" networks, the providers can > verify that the new upstream equipment works with the originally provisioned, > provider-approved, downstream equipment. Therefore, there should not be any > client-side changes required to maintain the status-quo, (i.e. PPPoE with > MRU=1492). Only users who upgrade to MRU=1500 would need to make additional > provisioning choices. I did not mean to suggest that end users would make choices. I was talking about new software switches inside the CPE added to cover your odd cases. There's also the training that residential providers would need to give their offshore call centers to handle users who insist on fiddling with things and so forth and so on. > By "ad hoc" I mean a scenario more like Juniper implementing support for an > MRU > 1492 only when a new tag is specified, while Cisco implement support > for a higher negotiated MRUs without a tag, or with a different tag. At least > if there is an Informational RFC, then there is an increased likelihood that > the implementations would maintain some level of compatability. If you think anything done here might prevent or encourage such things, I think you're quite mistaken. Juniper, Cisco, et al have demonstrated an ability to agree and disagree without the let, leave, or hindrance of the IETF. What is going on here is an effort to get the IETF to publish an Information RFC that can be pointed as proof that the IETF requires support for a modified protocol. That pointing would be done in sales meetings with the kind of customers who buy train loads of DSLAMs. Minor details like the Informational status of the RFC are irrelevant or at least glossed in such situations. > If the concensus IETF view is that such an RFC would not be accepted without a > warning that says "DO NOT IMPLEMENT", (as opposed to the wording James > Carlson suggested), James Carlson's wording screams "DO NOT IMPLEMENT" to technical people with IETF experience and so concerns about and scars from interoperability problems. You JUST DON'T build things that work only in the right phase of the moon after you've been stuck trying to explain the lunar cycle to irate customers with million dollar invoices Note again that "customers" in this context are not end user customers of providers but the providers themselves. Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Jul 07 23:26:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqjVa-00052P-S5; Thu, 07 Jul 2005 23:26:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqjVZ-00052K-0L for pppext@megatron.ietf.org; Thu, 07 Jul 2005 23:26:33 -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 XAA29915 for ; Thu, 7 Jul 2005 23:26:30 -0400 (EDT) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqjwr-0002qK-Bz for pppext@ietf.org; Thu, 07 Jul 2005 23:54:46 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j683QQ5B044878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for env-from ; Thu, 7 Jul 2005 21:26:26 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j683QQeX044877 for pppext@ietf.org; Thu, 7 Jul 2005 21:26:26 -0600 (MDT) Date: Thu, 7 Jul 2005 21:26:26 -0600 (MDT) From: Vernon Schryver Message-Id: <200507080326.j683QQeX044877@calcite.rhyolite.com> To: pppext@ietf.org Subject: re: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: Diamantis Kourkouzelis > The modem was never pppoe to begin with. The pppoe > session will be initiated by the dslam when it receives > the lcp confreq from the modem and will forward it > to the bras (over pppoe) once the pppoe session gets > established. > > When the dslam receives the lcp confack from the bras, > it will strip the pppoe header and send it to the modem. > The dslam is responsible for the vpi/vci to pppoe session-id > mapping. As far as the modem is concerned, there is no pppoe > segment in the network, unless the bras naks the 1500 mru > down to 1492, as it would do today. That implies that what looks to end users like PPPoA service but with 1492 MTU is common today. Is that true? How common is it? Could you point to a tutorial on why PPPoE is used such situations, in series with and behind the scenes of PPPoA? Is it to use 802.3 networks ultimately connected to the provider's routers? Are you talking about the issues discussed in http://www.ietf.org/internet-drafts/draft-haag-pppext-spppoe-00.txt ? Have I forgotten some discussion of that ID in this mailing list? I can't convince Google to find any references to it here. Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Jul 08 00:15:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqkHL-0006L5-6N; Fri, 08 Jul 2005 00:15:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqkHI-0006Dg-Ty for pppext@megatron.ietf.org; Fri, 08 Jul 2005 00:15: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 AAB03448 for ; Fri, 8 Jul 2005 00:15:49 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqkic-0007CY-Op for pppext@ietf.org; Fri, 08 Jul 2005 00:44:07 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 07 Jul 2005 21:15:43 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j684FX6v006691; Thu, 7 Jul 2005 21:15:41 -0700 (PDT) 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); Fri, 8 Jul 2005 00:15:22 -0400 Received: from vmammoli-w2k04.cisco.com ([10.83.17.99]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jul 2005 00:15:34 -0400 Message-Id: <4.3.2.7.2.20050708000109.0303ca60@email.cisco.com> X-Sender: vmammoli@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Jul 2005 00:15:33 -0400 To: Vernon Schryver , pppext@ietf.org From: "Vince Mammoliti - vince@cisco.com" Subject: re: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 In-Reply-To: <200507080326.j683QQeX044877@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Jul 2005 04:15:34.0921 (UTC) FILETIME=[B01EBF90:01C58373] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: 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 At 09:26 PM 07/07/2005 -0600, Vernon Schryver wrote: > > From: Diamantis Kourkouzelis > > > The modem was never pppoe to begin with. The pppoe > > session will be initiated by the dslam when it receives > > the lcp confreq from the modem and will forward it > > to the bras (over pppoe) once the pppoe session gets > > established. > > > > When the dslam receives the lcp confack from the bras, > > it will strip the pppoe header and send it to the modem. > > The dslam is responsible for the vpi/vci to pppoe session-id > > mapping. As far as the modem is concerned, there is no pppoe > > segment in the network, unless the bras naks the 1500 mru > > down to 1492, as it would do today. > >That implies that what looks to end users like PPPoA service but with >1492 MTU is common today. Is that true? How common is it? > >Could you point to a tutorial on why PPPoE is used such situations, >in series with and behind the scenes of PPPoA? Is it to use 802.3 >networks ultimately connected to the provider's routers? >Are you talking about the issues discussed in >http://www.ietf.org/internet-drafts/draft-haag-pppext-spppoe-00.txt ? > >Have I forgotten some discussion of that ID in this mailing list? >I can't convince Google to find any references to it here. The topic of Simple PPP over Ethernet (sPPPoE) has not really been discussed in this forum. The draft was submitted to provide a method to support legacy PPPoA DSL services over newer GE DSLAMs that no longer have ATM backhaul.. It describes a method for the DSLAM to splits the PPP Control Protocol over its own Encapsulation to the BRAS if required and allows the IP data to be carried as normally it would be over Ethernet. This does not break the PPPoA 1500 MTU support and also does not require any type of GE jumbo frames. Vince >Vernon Schryver vjs@rhyolite.com > >_______________________________________________ >Pppext mailing list >Pppext@ietf.org >https://www1.ietf.org/mailman/listinfo/pppext _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Jul 08 15:05:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqyAL-0006rG-JI; Fri, 08 Jul 2005 15:05:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqgOA-00073R-Gw for pppext@megatron.ietf.org; Thu, 07 Jul 2005 20:06: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 UAA17709 for ; Thu, 7 Jul 2005 20:06:38 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqgpS-00013R-5e for pppext@ietf.org; Thu, 07 Jul 2005 20:34:54 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 07 Jul 2005 17:06:33 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6806UvM015685; Thu, 7 Jul 2005 17:06:30 -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); Thu, 7 Jul 2005 20:06:32 -0400 Received: from haag-w2k01.cisco.com ([10.82.216.208]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 20:06:31 -0400 Message-Id: <4.3.2.7.2.20050707195252.02d5aee8@email.cisco.com> X-Sender: haag@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Jul 2005 20:06:30 -0400 To: James Carlson From: Jeff Haag Subject: RE: [Pppext] draft-arberg-pppoe-mtu-gt1492-00 In-Reply-To: <17094.60314.540094.534698@gargle.gargle.HOWL> References: <6B8F46B46D292A438250E42591ABB59DBDF861@antipi.jnpr.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Jul 2005 00:06:31.0765 (UTC) FILETIME=[E54E1850:01C58350] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-Mailman-Approved-At: Fri, 08 Jul 2005 15:05:36 -0400 Cc: pppext@ietf.org, Mark Townsley , Vince Mammoliti 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 At 03:31 PM 7/2/2005, James Carlson wrote: >Jerome Moisand writes: > > Not exactly sure what non-IEEE-compliant mechanism you are referring to? > > > > Using a PPP MRU of 1500 over PPPoE clearly implies the use of an > > Ethernet frame size larger than 1500 bytes, but IEEE standards now > > support such technology (aka jumbo-frames, mini jumbo frames, etc). > >Really? Can you cite which published IEEE standard actually supports >jumbo frame operation? (And, better still, describes how the >interoperability problems are mitigated, as that's the crucial bit I >think we're missing here.) > >I can't seem to locate the standard that supports this idea. > >I know that many products (even from Sun and Juniper) support jumbo >frame operation, but unless I'm missing something I don't see where >it's actually been adopted as a standard. > >The last I'd heard was that the 802.3 WG "feels that Jumbo frames are >a bad idea." Has this been amended? > > > So if all network segments between the PPPoE "newer" client and the > > PPPoE server support such larger frame as a deployment rule, then we > > have no issue, > >Right. But we simply have no way of knowing that this is true, and >failure modes are both catastrophic and potentially (due to STP) >latent. > >I'm really uncomfortable with publishing an RFC that clearly depends >on essentially arbitrary deployment rules in order to function >correctly. It seems like bad practice to me. > > > and this seems to me as being fully IEEE compliant. > >That's the part I'm missing. > > > Practically speaking, the DSL topologies that we have in mind would > > indeed have such property. > > > > Yet we need the mitigation mechanism to deal with legacy cases, and > > notably home LANs limited to 1500 Ethernet frames. > >Ditching PPPoE as an unnecessary expense and just using plain old IP >on Ethernet would fix that problem neatly. This sounds like the Split PPP approach that we tried to convey in Network Working Group Jeffrey Haag Internet-Draft Vince Mammoliti W. Mark Townsley February 2005 cisco Systems Simple PPP over Ethernet (sPPPoE) Maybe the fact that it was an all Cisco author staff, or that other companies have already developed/deployed proprietary interworking technologies, seems to have made this unattractive. This draft solves the MTU issue by removing PPPoE from the equation, and using native IP on the GigE side of the DSLAM: PPPoA sPPPoE CPE ---------- DSLAM ------------ BRAS ATM GigE PPP Control frames on the GigE side are encapsulated in a new ethertype, and IP frames use their native ethertype. We solicit input on this. We would like to see an interworking solution that does not affect the CPE, solves the MTU issue, and does not require changes to PPP. We think this is a good start toward that. Thanks, Jeff Haag Cisco Systems >-- >James Carlson, KISS Network >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 > >_______________________________________________ >Pppext mailing list >Pppext@ietf.org >https://www1.ietf.org/mailman/listinfo/pppext _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Wed Jul 27 10:24:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxmpH-0007Sf-VJ; Wed, 27 Jul 2005 10:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxmpF-0007P2-4l for pppext@megatron.ietf.org; Wed, 27 Jul 2005 10:24:03 -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 KAA02001 for ; Wed, 27 Jul 2005 10:23:58 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxnKV-0006rN-AR for pppext@ietf.org; Wed, 27 Jul 2005 10:56:20 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 27 Jul 2005 07:23:52 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,146,1120460400"; d="scan'208"; a="3602103:sNHT19576532" Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6RENmVu003493; Wed, 27 Jul 2005 10:23:48 -0400 (EDT) Received: from [10.83.1.98] (rtp-townsley-vpn1.cisco.com [10.83.1.98]) by fruitpie.cisco.com (MOS 3.4.6-GR) with SMTP id BHE04940; Wed, 27 Jul 2005 07:23:47 -0700 (PDT) Message-ID: <42E798E9.7060400@cisco.com> Date: Wed, 27 Jul 2005 16:23:37 +0200 From: Mark Townsley User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pppext@ietf.org, James Carlson Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , hholgate@cisco.com, bberry@cisco.com Subject: [Pppext] Review of draft-bberry-pppoe-credit (Informational) 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 This is an individual submission document for Informational publication. Without getting into whether PPPoE itself should have been strangled at birth or not, I would like a fair review of this document before advancing it. Please send comments to the authors and this list before August 24. Thanks, - Mark _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Wed Jul 27 11:12:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxnaV-0004wT-NP; Wed, 27 Jul 2005 11:12:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxnaU-0004wO-EY for pppext@megatron.ietf.org; Wed, 27 Jul 2005 11:12: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 LAA06126 for ; Wed, 27 Jul 2005 11:12:45 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxo5f-00007z-W2 for pppext@ietf.org; Wed, 27 Jul 2005 11:45:08 -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 j6RFCar3021717 for ; Wed, 27 Jul 2005 09:12:36 -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 j6RFCZC2023771 for ; Wed, 27 Jul 2005 11:12:35 -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 j6RFCZR0010250; Wed, 27 Jul 2005 11:12:35 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j6RFCZOh010247; Wed, 27 Jul 2005 11:12:35 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17127.42083.370087.721061@gargle.gargle.HOWL> Date: Wed, 27 Jul 2005 11:12:35 -0400 From: James Carlson To: Mark Townsley Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) In-Reply-To: Mark Townsley's message of 27 July 2005 16:23:37 References: <42E798E9.7060400@cisco.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, Margaret Wasserman , hholgate@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 Mark Townsley writes: > This is an individual submission document for Informational publication. > Without getting into whether PPPoE itself should have been strangled at > birth or not, I would like a fair review of this document before > advancing it. Please send comments to the authors and this list before > August 24. I suppose I'm a bit curious why the existing RFC 1663 (PPP Reliable Transmission) and RFC 1989 (PPP Link Quality Monitoring) protocols weren't already sufficient for the job and, if not sufficient, couldn't have been built on to solve the problem. I don't see either mentioned in the draft as related work. I don't think I see a point to having flow control implemented here, as the transport layers already know how to deal with loss by slowing down. Perhaps the real solution might be to fix the "limited buffering" design problem in the affected devices that this draft mentions rather than imposing a new protocol on the rest of the world. There seems to be no description of how the "Receive only" flag might be used. Doesn't RFC 1661 already assume (and require) a bidirectional link? How could a valid and usable PPP link ever be running over a "receive only" link? This proposal seems to further degrade the already tortured PPPoE link MTU. If tag insertion is allowed with PPPoE Session Stage messages (something that RFC 2516 didn't allow), then what happens to the link MTU? Further, I suspect that section 5 of the draft is misworded. The magic value 0106 (which fortunately is not a legal PPP Protocol ID) is used to distinguish the presence of this TLV, and the system shouldn't just check for LCP. One other note: I'm not sure what the "Resources" field is doing in the PADQ message. The amount of remaining battery power (!) doesn't appear to have much to do with link quality. -- 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 Wed Jul 27 11:31:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxns8-0002kK-Nn; Wed, 27 Jul 2005 11:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxns7-0002kF-Gl for pppext@megatron.ietf.org; Wed, 27 Jul 2005 11:31:03 -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 LAA07535 for ; Wed, 27 Jul 2005 11:31:00 -0400 (EDT) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxoNO-0000kr-22 for pppext@ietf.org; Wed, 27 Jul 2005 12:03:23 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j6RFRSAm018361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) env-from ; Wed, 27 Jul 2005 09:27:28 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j6RFRS8q018360; Wed, 27 Jul 2005 09:27:28 -0600 (MDT) Date: Wed, 27 Jul 2005 09:27:28 -0600 (MDT) From: Vernon Schryver Message-Id: <200507271527.j6RFRS8q018360@calcite.rhyolite.com> To: townsley@cisco.com Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) In-Reply-To: <17127.42083.370087.721061@gargle.gargle.HOWL> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: margaret@thingmagic.com, pppext@ietf.org, bberry@cisco.com, hholgate@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 > To: Mark Townsley > Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) > Cc: pppext@ietf.org, Margaret Wasserman , > hholgate@cisco.com, bberry@cisco.com Mark Townsley wrote: > This is an individual submission document for Informational publication. > Without getting into whether PPPoE itself should have been strangled at > birth or not, I would like a fair review of this document before > advancing it. Is that an entirely accurate description of the situation with the document? It seems to me that it is not really being proposed as "Informational" document to describe something that is entirely proprietary or purely experimental. The authors have here in the Pppext mailing list adverted to wanting the IETF's approval for their plan to address a difficulty. I think they have been open about hoping and expecting that upon IETF publication, (other?) vendors will implement and ship their solution. Therefore, shouldn't the IETF consider all available alternatives to fixing the difficulty? Instead of pushing through this document and compounding the PPPoE mess, shouldn't the IETF consider alternatives including the one described in draft-haag-pppext-spppoe-00.txt? Even if the IETF cannot decide, shouldn't alternatives get the same support by Informational publication? Doesn't the IETF now have technical criteria even for Informational RFCs? Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Wed Jul 27 11:57:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxoIB-0004On-D8; Wed, 27 Jul 2005 11:57:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxoI9-0004Of-OE for pppext@megatron.ietf.org; Wed, 27 Jul 2005 11:57:57 -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 LAA10243 for ; Wed, 27 Jul 2005 11:57:54 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxonQ-0001sU-NZ for pppext@ietf.org; Wed, 27 Jul 2005 12:30:18 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 27 Jul 2005 11:57:48 -0400 X-IronPort-AV: i="3.95,146,1120449600"; d="scan'208"; a="64156615:sNHT32138684" 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 j6RFvlVu000533; Wed, 27 Jul 2005 11:57:47 -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 LAA13993; Wed, 27 Jul 2005 11:57:39 -0400 (EDT) Message-Id: <200507271557.LAA13993@cisco.com> Date: Wed, 27 Jul 2005 11:57:36 -0400 (EDT) From: Mark Lanzo Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) To: james.d.carlson@sun.com In-Reply-To: <17127.42083.370087.721061@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: pppext@ietf.org, townsley@cisco.com, hholgate@cisco.com, margaret@thingmagic.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 On 27 Jul, James Carlson wrote: > Mark Townsley writes: >> This is an individual submission document for Informational publication. >> Without getting into whether PPPoE itself should have been strangled at >> birth or not, I would like a fair review of this document before >> advancing it. Please send comments to the authors and this list before >> August 24. > > I suppose I'm a bit curious why the existing RFC 1663 (PPP Reliable > Transmission) and RFC 1989 (PPP Link Quality Monitoring) protocols > weren't already sufficient for the job and, if not sufficient, > couldn't have been built on to solve the problem. I don't see either > mentioned in the draft as related work. I don't really see how these are connected. The goal as suggested in the draft is not to create a "reliable" link. It's more to avoid creating a hopelessly unreliable link. The target environment is one where a router is connected to a radio by by a fast link (an ethernet), and where there are multiple PPP sessions being established between the router and the numerous remote nodes reachable by the radio. The radio equipment itself doesn't maintain either a fast or reliable connection to the other nodes in its contact list. The radio equipment *does* buffer (possibly even on a per PPP connection basis), but has limited capacity. The radio equipment may even include some limited retransmission capability, but overall it's not going to provide a guaranteed delivery of packets. Further, since the radio is a broadcast mechanism and sharing the frequency with all the other nodes in that network, the rate of packet delivery is very erratic and there's no meaningful bandwidth which can be associated to the individual PPP connections. Imagine a bunch of ham radio operators running PPP on the mobile radios in their cars, creating a very fluid network, and you'll have a good mental picture of the target environment (the draft doesn't seem to make this really clear). Please note, BTW, that I am not trying to push or endorse the draft; or trying to suggest that other methods may not also be worth considering. I'm just trying to add some background which may help clarify the intent behind the draft. -Mark Lanzo _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Wed Jul 27 12:37:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxou0-0000b1-D1; Wed, 27 Jul 2005 12:37:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxoty-0000as-2q for pppext@megatron.ietf.org; Wed, 27 Jul 2005 12:37:02 -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 MAA12681 for ; Wed, 27 Jul 2005 12:36:58 -0400 (EDT) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxpPF-000349-4m for pppext@ietf.org; Wed, 27 Jul 2005 13:09:22 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j6RGZaJn067483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) env-from ; Wed, 27 Jul 2005 10:35:36 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j6RGZZu0067482; Wed, 27 Jul 2005 10:35:35 -0600 (MDT) Date: Wed, 27 Jul 2005 10:35:35 -0600 (MDT) From: Vernon Schryver Message-Id: <200507271635.j6RGZZu0067482@calcite.rhyolite.com> To: townsley@cisco.com, vjs@calcite.rhyolite.com Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: margaret@thingmagic.com, pppext@ietf.org, bberry@cisco.com, hholgate@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 What? That's not the draft I thought it was. How stupid can I get? Having now bothered to read it, I can't help wondering what PPPoE has to do with the problem or the solution. Why can't you do the same things without having wasting precious radio bandwidth on 802.3 headers and trailers? I'm confused by the diagram and words in the introduction. If I take the diagram literally, I wonder: Why don't the ends of the RLP link in the diagram in the introduction need their own authentication, authorization, etc. controls on access to the radio link? If they do, then why wouldn't it be better have 3 separate PPP sessions? If so, then why is it necessary to modify the PPPoE protocol? Are there any realistic hope that the vendors of the boxes labelled "Access Conc." ship such changes to PPPoE? If not, isn't that another reason to have 3 separate links? It seems to me that there is a continuing, fundamental confusion about network layers here and in the draft I thought was at issue. The confusion is in seeing PPPoE as something above the link layer and equivalent to IP. This and that other draft seem to view PPPoE frames as packets that should be shipped half way around the world through all manner of gateways, routers, and forwarders. This draft talks about "efficient routing" using the "link metric mechanism." Is that a wedge to introducing some kind of routing protocol into PPPoE? I don't see much else in that vein in this draft, but it sounds like a start toward recapitulating link state vs. distance vector etc. and so forth and so on. If instead you have 3 separate link-layer links, 2 PPPoE and one other above or otherwise involving "RLP", you could use things are already tolerably well understood. You'd probalby need to assign IP addresses to the Host Radios But on second thought, it makes no sense that the pair of stationary access concentrators should be connected via mobile radios. Contrary to the diagram, is the idea to have new access concentrators that talk via radios to mobile hosts, with IP over PPPoE over RLP? Is the diagram more about layering that links between boxes? If so, why do you need PPPoE? Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Wed Jul 27 13:10:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxpQS-00031t-SP; Wed, 27 Jul 2005 13:10:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxpQR-00031o-HQ for pppext@megatron.ietf.org; Wed, 27 Jul 2005 13:10:35 -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 NAA14640 for ; Wed, 27 Jul 2005 13:10:32 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxpvg-00043d-VY for pppext@ietf.org; Wed, 27 Jul 2005 13:42:56 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 27 Jul 2005 13:10:23 -0400 X-IronPort-AV: i="3.95,146,1120449600"; d="scan'208"; a="64169369:sNHT59774896" Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6RHALk6025782; Wed, 27 Jul 2005 13:10:21 -0400 (EDT) Received: from [10.83.1.98] (rtp-townsley-vpn1.cisco.com [10.83.1.98]) by fruitpie.cisco.com (MOS 3.4.6-GR) with SMTP id BHE05946; Wed, 27 Jul 2005 10:10:20 -0700 (PDT) Message-ID: <42E7BFF2.20805@cisco.com> Date: Wed, 27 Jul 2005 19:10:10 +0200 From: Mark Townsley User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vernon Schryver Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) References: <200507271527.j6RFRS8q018360@calcite.rhyolite.com> In-Reply-To: <200507271527.j6RFRS8q018360@calcite.rhyolite.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: margaret@thingmagic.com, pppext@ietf.org, bberry@cisco.com, hholgate@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 Vernon Schryver wrote: >>To: Mark Townsley >>Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) >>Cc: pppext@ietf.org, Margaret Wasserman , >> hholgate@cisco.com, bberry@cisco.com >> >> > >Mark Townsley wrote: > > >>This is an individual submission document for Informational publication. >>Without getting into whether PPPoE itself should have been strangled at >>birth or not, I would like a fair review of this document before >>advancing it. >> >> > >Is that an entirely accurate description of the situation with the >document? It seems to me that it is not really being proposed as >"Informational" document to describe something that is entirely >proprietary or purely experimental. The authors have here in the >Pppext mailing list adverted to wanting the IETF's approval for their >plan to address a difficulty. I think they have been open about hoping >and expecting that upon IETF publication, (other?) vendors will implement >and ship their solution. > > >Therefore, shouldn't the IETF consider all available alternatives to >fixing the difficulty? Instead of pushing through this document and >compounding the PPPoE mess, shouldn't the IETF consider alternatives >including the one described in draft-haag-pppext-spppoe-00.txt? > > I don't think draft-haag is talking about the same thing as draft-bberry. >Even if the IETF cannot decide, shouldn't alternatives get the same >support by Informational publication? > >Doesn't the IETF now have technical criteria even for Informational RFCs? > > > >Vernon Schryver vjs@rhyolite.com > > > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Wed Jul 27 13:24:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxpeL-0007ON-HE; Wed, 27 Jul 2005 13:24:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxpeK-0007OI-4N for pppext@megatron.ietf.org; Wed, 27 Jul 2005 13:24:56 -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 NAA15455 for ; Wed, 27 Jul 2005 13:24:52 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxq9c-0004Tx-T8 for pppext@ietf.org; Wed, 27 Jul 2005 13:57:17 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 27 Jul 2005 13:24:47 -0400 X-IronPort-AV: i="3.95,146,1120449600"; d="scan'208"; a="64171730:sNHT649454914" Received: from cisco.com (shako.cisco.com [64.102.17.78]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6RHOkk6029692; Wed, 27 Jul 2005 13:24:46 -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 NAA23414; Wed, 27 Jul 2005 13:24:36 -0400 (EDT) Message-Id: <200507271724.NAA23414@cisco.com> Date: Wed, 27 Jul 2005 13:24:34 -0400 (EDT) From: Mark Lanzo Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) To: vjs@calcite.rhyolite.com In-Reply-To: <200507271635.j6RGZZu0067482@calcite.rhyolite.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: margaret@thingmagic.com, townsley@cisco.com, bberry@cisco.com, pppext@ietf.org, hholgate@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 On 27 Jul, Vernon Schryver wrote: > What? That's not the draft I thought it was. How stupid can I get? > > Having now bothered to read it, I can't help wondering what PPPoE has > to do with the problem or the solution. Why can't you do the same > things without having wasting precious radio bandwidth on 802.3 headers > and trailers? It's not PPPoE end-to-end between the PPP endpoints. Unlike regular PPPoE, the termination point of the PPPoE and PPP don't coincide anymore. The radio is merely creating an illusion of this to its attached router. PPPoE is running between the router and its host radio, not between the router and a peer router. The flow control, for example, is not one PPP endpoint giving credits to the other endpoint, it is merely the radio telling its attached router that it has available buffer space to take more packets. 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. The packets over the airwaves aren't PPPoE in nature, and for that matter how the remote PPP device talks to its host radio might be entirely different than the local end (the remote device might have a built-in radio and simply see "RLP" as its native encapsulation for example, and handle flow control far more efficiently than the other end with its ethernet-connected radio). 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. Lest I sound too authoritative, I should qualify that this is my understanding based on past discussions I've had with the group which is behind this draft. -Mark Lanzo _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Wed Jul 27 13:39:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxpsO-0004A8-LY; Wed, 27 Jul 2005 13:39:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxpsM-00049a-PX for pppext@megatron.ietf.org; Wed, 27 Jul 2005 13:39:26 -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 NAA16618 for ; Wed, 27 Jul 2005 13:39:23 -0400 (EDT) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxqNc-0004xd-9q for pppext@ietf.org; Wed, 27 Jul 2005 14:11:47 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j6RHawkj006050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) env-from ; Wed, 27 Jul 2005 11:36:58 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j6RHawHk006049; Wed, 27 Jul 2005 11:36:58 -0600 (MDT) Date: Wed, 27 Jul 2005 11:36:58 -0600 (MDT) From: Vernon Schryver Message-Id: <200507271736.j6RHawHk006049@calcite.rhyolite.com> To: lanzo@cisco.com Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) In-Reply-To: <200507271724.NAA23414@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: margaret@thingmagic.com, pppext@ietf.org, bberry@cisco.com, hholgate@cisco.com, townsley@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: 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? > 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? 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 as well as fewer nastinesses such as an MTU that is even smaller than the bad old PPPoE MTU of 1492? Why egregiously violate layering by trying to convert IEEE 802.3 into an inter-network protocol? Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Wed Jul 27 19:52:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxvhM-0000BK-9F; Wed, 27 Jul 2005 19:52:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxvhK-0000BF-Us for pppext@megatron.ietf.org; Wed, 27 Jul 2005 19:52:27 -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 TAA18551 for ; Wed, 27 Jul 2005 19:52:23 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxwCg-00080d-0Q for pppext@ietf.org; Wed, 27 Jul 2005 20:24:51 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 27 Jul 2005 16:52:16 -0700 X-IronPort-AV: i="3.95,147,1120460400"; d="scan'208"; a="651449922:sNHT34068248" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6RNqDul024269; Wed, 27 Jul 2005 16:52:13 -0700 (PDT) Received: from [10.0.0.66] (rtp-vpn2-412.cisco.com [10.82.241.156]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j6RNo1G4019582; Wed, 27 Jul 2005 16:50:01 -0700 In-Reply-To: <200507271635.j6RGZZu0067482@calcite.rhyolite.com> References: <200507271635.j6RGZZu0067482@calcite.rhyolite.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <612CA1F7-527B-43FC-80C6-858820018E56@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) Date: Wed, 27 Jul 2005 19:52:12 -0400 To: Vernon Schryver X-Mailer: Apple Mail (2.733) DKIM-Signature: a=rsa-sha1; q=dns; l=579; t=1122508202; x=1122940402; c=nowsp; s=nebraska; h=Subject:From:Sender:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20[Pppext]=20Review=20of=20draft-bberry-pppoe-credit=20(Informatio nal)| From:Fred=20Baker=20| Date:Wed,=2027=20Jul=202005=2019=3A52=3A12=20-0400| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=W/co9gbb9rRNITPGUkZ4I7RSEbpTVFwwcmf+npmE3iOKUdoCQr1OjW7iBCysvdUPc9LoSaI2 /dSdbmluM7A5zTiGMDmJewxH/QeWCnWNgmGLlwzo7TQB10wnE/8qlfqNP4fUOGZA1Nm4MeCEc2K 0+vlFJ8+uwa95dMVDNWp4YP4= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: margaret@thingmagic.com, townsley@cisco.com, bberry@cisco.com, pppext@ietf.org, hholgate@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 On Jul 27, 2005, at 12:35 PM, Vernon Schryver wrote: > Having now bothered to read it, I can't help wondering what PPPoE > has to do with the problem or the solution. Why can't you do the > same things without having wasting precious radio bandwidth on > 802.3 headers and trailers? AFAIK, it isn't. It is using the Ethernet as a local interface between a router and an interface device that has a number of special characteristics and is implemented in a separate chassis. Call it "system engineering" if you like. The actual protocol over the airwaves is PPP as known and loved, far more compact than PPPOE. PPPOE is simply used to manage the local interface between the router and the radio interface. _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Wed Jul 27 20:50:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxwbs-00083q-QN; Wed, 27 Jul 2005 20:50:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxwbq-00083i-GR for pppext@megatron.ietf.org; Wed, 27 Jul 2005 20:50: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 UAA22287 for ; Wed, 27 Jul 2005 20:50:48 -0400 (EDT) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxx7C-0001C4-1l for pppext@ietf.org; Wed, 27 Jul 2005 21:23:15 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j6S0oTg0024517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) env-from ; Wed, 27 Jul 2005 18:50:29 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j6S0oT5j024516; Wed, 27 Jul 2005 18:50:29 -0600 (MDT) Date: Wed, 27 Jul 2005 18:50:29 -0600 (MDT) From: Vernon Schryver Message-Id: <200507280050.j6S0oT5j024516@calcite.rhyolite.com> To: fred@cisco.com Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) In-Reply-To: <612CA1F7-527B-43FC-80C6-858820018E56@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: margaret@thingmagic.com, pppext@ietf.org, bberry@cisco.com, hholgate@cisco.com, townsley@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 > Cc: townsley@cisco.com, margaret@thingmagic.com, pppext@ietf.org, > bberry@cisco.com, hholgate@cisco.com > From: Fred Baker > To: Vernon Schryver > AFAIK, it isn't. It is using the Ethernet as a local interface > between a router and an interface device that has a number of special > characteristics and is implemented in a separate chassis. Call it > "system engineering" if you like. The actual protocol over the > airwaves is PPP as known and loved, far more compact than PPPOE. > PPPOE is simply used to manage the local interface between the router > and the radio interface. Ok, so why not assign IP addresses (perhaps by RFC 1918) to those those boxes with radios and PPPoE links to access controllers? If this particular use of PPPoE as an inter-network protocol makes sense, where does does using PPPoE as a replacement for IP not make sense? If PPPoE is not going over the radio waves, why are the access controllers distinct boxes from the boxes ("radio interfaces"?) that connect PPPoE to the real ether? I suspect they are distinct boxes from the mention of the use of PPPoE as a (de)multiplexing tool, which gets back to the evil of using PPPoE as an inter-network protocol instead of IP. Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Wed Jul 27 22:55:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxyY5-0007ws-Mw; Wed, 27 Jul 2005 22:55:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxyY2-0007w8-Vc for pppext@megatron.ietf.org; Wed, 27 Jul 2005 22:55:03 -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 WAA27953 for ; Wed, 27 Jul 2005 22:55:00 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxz3O-00046N-Ms for pppext@ietf.org; Wed, 27 Jul 2005 23:27:29 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 27 Jul 2005 22:54:52 -0400 X-IronPort-AV: i="3.95,147,1120449600"; d="scan'208"; a="64242261:sNHT31564248" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6S2spVu008316; Wed, 27 Jul 2005 22:54:51 -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); Wed, 27 Jul 2005 22:54:51 -0400 Received: from [10.82.224.205] ([10.82.224.205]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 22:54:50 -0400 Message-ID: <42E848F0.4080506@cisco.com> Date: Wed, 27 Jul 2005 22:54:40 -0400 From: Bo Berry User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Lanzo Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) References: <200507271724.NAA23414@cisco.com> In-Reply-To: <200507271724.NAA23414@cisco.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: 28 Jul 2005 02:54:50.0792 (UTC) FILETIME=[B90E5280:01C5931F] X-Spam-Score: 2.0 (++) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: margaret@thingmagic.com, townsley@cisco.com, hholgate@cisco.com, pppext@ietf.org, vjs@calcite.rhyolite.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 Mark, well said! PPPoE was selected for these reasons and the fact that we could leverage the features of PPP at the endpoints. The extensions are optional and only come into play when both PPPoE endpoints support the new extensions. -Bo Berry Mark Lanzo wrote: > > On 27 Jul, Vernon Schryver wrote: > >>What? That's not the draft I thought it was. How stupid can I get? >> >>Having now bothered to read it, I can't help wondering what PPPoE has >>to do with the problem or the solution. Why can't you do the same >>things without having wasting precious radio bandwidth on 802.3 headers >>and trailers? > > > It's not PPPoE end-to-end between the PPP endpoints. > Unlike regular PPPoE, the termination point of the PPPoE and PPP don't > coincide anymore. The radio is merely creating an illusion of this to its > attached router. PPPoE is running between the router and its > host radio, not between the router and a peer router. The flow > control, for example, is not one PPP endpoint giving credits to the > other endpoint, it is merely the radio telling its attached router that > it has available buffer space to take more packets. > > 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. > > The packets over the airwaves aren't PPPoE in nature, and for that matter > how the remote PPP device talks to its host radio might be entirely > different than the local end (the remote device might have a built-in > radio and simply see "RLP" as its native encapsulation for example, > and handle flow control far more efficiently than the other end with > its ethernet-connected radio). > > 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. > > Lest I sound too authoritative, I should qualify that this is my > understanding based on past discussions I've had with the group > which is behind this draft. > > -Mark Lanzo > > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Wed Jul 27 23:03:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxyga-0001je-5s; Wed, 27 Jul 2005 23:03:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxygY-0001im-1U for pppext@megatron.ietf.org; Wed, 27 Jul 2005 23:03: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 XAA28376 for ; Wed, 27 Jul 2005 23:03:47 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxzBu-0004K6-OQ for pppext@ietf.org; Wed, 27 Jul 2005 23:36:16 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 27 Jul 2005 20:03:40 -0700 X-IronPort-AV: i="3.95,147,1120460400"; d="scan'208"; a="651485270:sNHT30178972" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6S33Xul017002; Wed, 27 Jul 2005 20:03:34 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 23:03:36 -0400 Received: from [10.82.224.205] ([10.82.224.205]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 23:03:36 -0400 Message-ID: <42E84B03.4040406@cisco.com> Date: Wed, 27 Jul 2005 23:03:31 -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: <200507280050.j6S0oT5j024516@calcite.rhyolite.com> In-Reply-To: <200507280050.j6S0oT5j024516@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: 28 Jul 2005 03:03:36.0182 (UTC) FILETIME=[F2367960:01C59320] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: margaret@thingmagic.com, pppext@ietf.org, hholgate@cisco.com, fred@cisco.com, townsley@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 in-line Vernon Schryver wrote: >>Cc: townsley@cisco.com, margaret@thingmagic.com, pppext@ietf.org, >> bberry@cisco.com, hholgate@cisco.com >>From: Fred Baker >>To: Vernon Schryver > > > >>AFAIK, it isn't. It is using the Ethernet as a local interface >>between a router and an interface device that has a number of special >>characteristics and is implemented in a separate chassis. Call it >>"system engineering" if you like. The actual protocol over the >>airwaves is PPP as known and loved, far more compact than PPPOE. >>PPPOE is simply used to manage the local interface between the router >>and the radio interface. > > > Ok, so why not assign IP addresses (perhaps by RFC 1918) to those > those boxes with radios and PPPoE links to access controllers? > > If this particular use of PPPoE as an inter-network protocol makes > sense, where does does using PPPoE as a replacement for IP not make > sense? > > If PPPoE is not going over the radio waves, why are the access controllers > distinct boxes from the boxes ("radio interfaces"?) that connect PPPoE > to the real ether? We needed a means to control the eb-n-flow of packets between the router and the radio independent of PPP. So each router-radio, radio-radio (RLP) and radio-router link provides flow control relative to its segment. PPPoE fit the overall model. > > I suspect they are distinct boxes from the mention of the use of PPPoE > as a (de)multiplexing tool, which gets back to the evil of using PPPoE > as an inter-network protocol instead of IP. > > > Vernon Schryver vjs@rhyolite.com > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Wed Jul 27 23:10:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxymg-0003Av-Fn; Wed, 27 Jul 2005 23:10:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxyme-0003AX-PL for pppext@megatron.ietf.org; Wed, 27 Jul 2005 23:10:08 -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 XAA28795 for ; Wed, 27 Jul 2005 23:10:05 -0400 (EDT) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxzI1-0004Uf-1B for pppext@ietf.org; Wed, 27 Jul 2005 23:42:34 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j6S39j7K023384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) env-from ; Wed, 27 Jul 2005 21:09:45 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j6S39jLh023383; Wed, 27 Jul 2005 21:09:45 -0600 (MDT) Date: Wed, 27 Jul 2005 21:09:45 -0600 (MDT) From: Vernon Schryver Message-Id: <200507280309.j6S39jLh023383@calcite.rhyolite.com> To: bberry@cisco.com Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) In-Reply-To: <42E84B03.4040406@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: margaret@thingmagic.com, pppext@ietf.org, hholgate@cisco.com, fred@cisco.com, townsley@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 > CC: fred@cisco.com, hholgate@cisco.com, margaret@thingmagic.com, > pppext@ietf.org, townsley@cisco.com > We needed a means to control the eb-n-flow of packets between the > router and the radio independent of PPP. So each router-radio, > radio-radio (RLP) and radio-router link provides flow > control relative to its segment. PPPoE fit the overall model. How is using PPPoE for flow control independent of PPP? Aren't there existing, standard ways to do traffic shaping that would not require extensions to PPPoE? What about the reliable link flavor of PPP? Why wouldn't it provide flow control on its segment out of the box? Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Jul 28 08:46:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy7ly-0005Yx-UL; Thu, 28 Jul 2005 08:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy7lw-0005Yp-Ud for pppext@megatron.ietf.org; Thu, 28 Jul 2005 08:46:01 -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 IAA22449 for ; Thu, 28 Jul 2005 08:45:59 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy8HO-0003sc-Kz for pppext@ietf.org; Thu, 28 Jul 2005 09:18:32 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 28 Jul 2005 05:45:50 -0700 X-IronPort-AV: i="3.95,149,1120460400"; d="scan'208"; a="201142514:sNHT29864124" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6SCjH7B002797; Thu, 28 Jul 2005 05:45:46 -0700 (PDT) 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); Thu, 28 Jul 2005 08:45:44 -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); Thu, 28 Jul 2005 08:45:43 -0400 Message-ID: <42E8D375.1070605@cisco.com> Date: Thu, 28 Jul 2005 08:45:41 -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: <200507280309.j6S39jLh023383@calcite.rhyolite.com> In-Reply-To: <200507280309.j6S39jLh023383@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: 28 Jul 2005 12:45:43.0777 (UTC) FILETIME=[44AE8510:01C59372] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: margaret@thingmagic.com, pppext@ietf.org, hholgate@cisco.com, fred@cisco.com, townsley@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 Vernon Schryver wrote: >>From: Bo Berry >>To: Vernon Schryver >>CC: fred@cisco.com, hholgate@cisco.com, margaret@thingmagic.com, >> pppext@ietf.org, townsley@cisco.com > > >>We needed a means to control the eb-n-flow of packets between the >>router and the radio independent of PPP. So each router-radio, >>radio-radio (RLP) and radio-router link provides flow >>control relative to its segment. PPPoE fit the overall model. > > > How is using PPPoE for flow control independent of PPP? > > Aren't there existing, standard ways to do traffic shaping that would > not require extensions to PPPoE? > What about the reliable link flavor of PPP? Why wouldn't it provide > flow control on its segment out of the box? Flow control at each segment was required as compared to relying solely upon PPP. PPP flow is at a different point of control. > > > Vernon Schryver vjs@rhyolite.com > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Jul 28 09:37:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy8Zn-0004mw-1z; Thu, 28 Jul 2005 09:37:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy8Zl-0004mr-T6 for pppext@megatron.ietf.org; Thu, 28 Jul 2005 09:37:29 -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 JAA26397 for ; Thu, 28 Jul 2005 09:37:28 -0400 (EDT) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy95E-0005Yp-5g for pppext@ietf.org; Thu, 28 Jul 2005 10:10:01 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j6SDawVA035826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) env-from ; Thu, 28 Jul 2005 07:36:58 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j6SDaw37035825; Thu, 28 Jul 2005 07:36:58 -0600 (MDT) Date: Thu, 28 Jul 2005 07:36:58 -0600 (MDT) From: Vernon Schryver Message-Id: <200507281336.j6SDaw37035825@calcite.rhyolite.com> To: bberry@cisco.com Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) In-Reply-To: <42E8D375.1070605@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: margaret@thingmagic.com, pppext@ietf.org, hholgate@cisco.com, fred@cisco.com, townsley@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: margaret@thingmagic.com, pppext@ietf.org, hholgate@cisco.com, > fred@cisco.com, townsley@cisco.com > Flow control at each segment was required as compared to > relying solely upon PPP. PPP flow is at a different point > of control. I do not understand that paragraph, unless that is again viewing PPP as an inter-network protocol instead of a link protocol. Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Sat Jul 30 05:10:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DynMh-00083G-Kq; Sat, 30 Jul 2005 05:10:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DynMf-00082u-Qb for pppext@megatron.ietf.org; Sat, 30 Jul 2005 05:10: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 FAA29803 for ; Sat, 30 Jul 2005 05:10:40 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DynsV-0002p5-3A for pppext@ietf.org; Sat, 30 Jul 2005 05:43:36 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2005 11:10:32 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6U9ARDg010800; Sat, 30 Jul 2005 11:10:28 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 30 Jul 2005 11:10:26 +0200 Received: from [10.11.0.143] ([10.61.81.52]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 30 Jul 2005 11:10:26 +0200 In-Reply-To: <200507280309.j6S39jLh023383@calcite.rhyolite.com> References: <200507280309.j6S39jLh023383@calcite.rhyolite.com> 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: Fred Baker Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) Date: Fri, 29 Jul 2005 19:16:53 -0400 To: Vernon Schryver X-Mailer: Apple Mail (2.733) X-OriginalArrivalTime: 30 Jul 2005 09:10:26.0135 (UTC) FILETIME=[85FE4670:01C594E6] X-Spam-Score: 0.6 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: margaret@thingmagic.com, pppext@ietf.org, bberry@cisco.com, hholgate@cisco.com, townsley@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 On Jul 27, 2005, at 11:09 PM, Vernon Schryver wrote: > Aren't there existing, standard ways to do traffic shaping that would > not require extensions to PPPoE? > What about the reliable link flavor of PPP? Why wouldn't it provide > flow control on its segment out of the box? no. 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. This is not traffic shaping in the usual sense, as it is not attempting to smooth bursty traffic nor is it imposing a rate in the sense of "mumble bps forever". What it is doing is letting the interface implementation tell the queuing implementation how much traffic it may try to send at the rate the radio happens to be sending at *right*now*. _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Sat Jul 30 05:10:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DynMo-00084e-9k; Sat, 30 Jul 2005 05:10:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DynMm-00084W-9T for pppext@megatron.ietf.org; Sat, 30 Jul 2005 05:10:48 -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 FAA29810 for ; Sat, 30 Jul 2005 05:10:46 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dynsb-0002p5-IG for pppext@ietf.org; Sat, 30 Jul 2005 05:43:42 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 30 Jul 2005 11:10:46 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6U9APDu010798; Sat, 30 Jul 2005 11:10:43 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 30 Jul 2005 11:10:25 +0200 Received: from [10.11.0.143] ([10.61.81.52]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 30 Jul 2005 11:10:25 +0200 In-Reply-To: <200507280050.j6S0oT5j024516@calcite.rhyolite.com> References: <200507280050.j6S0oT5j024516@calcite.rhyolite.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2FF09F9C-861B-4463-9E41-BF667D3508CC@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [Pppext] Review of draft-bberry-pppoe-credit (Informational) Date: Fri, 29 Jul 2005 19:10:24 -0400 To: Vernon Schryver X-Mailer: Apple Mail (2.733) X-OriginalArrivalTime: 30 Jul 2005 09:10:25.0541 (UTC) FILETIME=[85A3A350:01C594E6] X-Spam-Score: 0.6 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: margaret@thingmagic.com, pppext@ietf.org, bberry@cisco.com, hholgate@cisco.com, townsley@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 what, precisely, does "assigning an IP address" have to do with "rate control"? On Jul 27, 2005, at 8:50 PM, Vernon Schryver wrote: >> Cc: townsley@cisco.com, margaret@thingmagic.com, pppext@ietf.org, >> bberry@cisco.com, hholgate@cisco.com >> From: Fred Baker >> To: Vernon Schryver >> > > > >> AFAIK, it isn't. It is using the Ethernet as a local interface >> between a router and an interface device that has a number of special >> characteristics and is implemented in a separate chassis. Call it >> "system engineering" if you like. The actual protocol over the >> airwaves is PPP as known and loved, far more compact than PPPOE. >> PPPOE is simply used to manage the local interface between the router >> and the radio interface. >> > > Ok, so why not assign IP addresses (perhaps by RFC 1918) to those > those boxes with radios and PPPoE links to access controllers? > > If this particular use of PPPoE as an inter-network protocol makes > sense, where does does using PPPoE as a replacement for IP not make > sense? > > If PPPoE is not going over the radio waves, why are the access > controllers > distinct boxes from the boxes ("radio interfaces"?) that connect PPPoE > to the real ether? > > I suspect they are distinct boxes from the mention of the use of PPPoE > as a (de)multiplexing tool, which gets back to the evil of using PPPoE > as an inter-network protocol instead of IP. > > > Vernon Schryver vjs@rhyolite.com > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext