[Gen-art] Re: Gen-art review of draft-bberry-pppoe-credit-04.txt

James Carlson <james.d.carlson@sun.com> Tue, 03 January 2006 17:57 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtqPZ-0001zl-Sy; Tue, 03 Jan 2006 12:57:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtqPW-0001yn-On for gen-art@megatron.ietf.org; Tue, 03 Jan 2006 12:57:29 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02923 for <gen-art@ietf.org>; Tue, 3 Jan 2006 12:56:12 -0500 (EST)
Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtqUn-0004eI-F8 for gen-art@ietf.org; Tue, 03 Jan 2006 13:02:57 -0500
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k03HvLdK017779 for <gen-art@ietf.org>; Tue, 3 Jan 2006 09:57:21 -0800 (PST)
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 k03HvKWe011726 for <gen-art@ietf.org>; Tue, 3 Jan 2006 12:57:20 -0500 (EST)
Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k03HvKLY018397; Tue, 3 Jan 2006 12:57:20 -0500 (EST)
Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k03HvJd4018394; Tue, 3 Jan 2006 12:57:19 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <17338.47871.815713.962360@gargle.gargle.HOWL>
Date: Tue, 03 Jan 2006 12:57:19 -0500
From: James Carlson <james.d.carlson@sun.com>
To: Elwyn Davies <elwynd@dial.pipex.com>
In-Reply-To: Elwyn Davies's message of 3 January 2006 17:43:59
References: <43B57671.6050609@dial.pipex.com> <43B9650E.3020405@cisco.com> <43BAB7DF.3040602@dial.pipex.com>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Content-Transfer-Encoding: 7bit
Cc: Margaret Wasserman <margaret@thingmagic.com>, Mark Townsley <townsley@cisco.com>, gen-art@ietf.org, bberry@cisco.com, hholgate@cisco.com
Subject: [Gen-art] Re: Gen-art review of draft-bberry-pppoe-credit-04.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Sender: gen-art-bounces@ietf.org
Errors-To: gen-art-bounces@ietf.org

Elwyn Davies writes:
> > This document is extending PPPoE, which by no means is a standard of 
> > any kind. I'm not sure what status other than Informational I could 
> > ask for here.
> 
> As has been said elsewhere it isn't entirely clear why PPPoE is 
> Informational.

It duplicates L2TP and wasn't an IETF effort.

>  Be that as it may, the mechanism in section 5 is 
> actually an extension to PPP if it were done properly (as I said in the 
> review the contents of s5 is IMO unaccpetable - it avoids defining a new 
> PPP packet format by hacking in an extra field).

I don't think an extension to PPP would be acceptable to the folks
proposing this PPPoE extension, as that would require changes to the
remote PPP nodes (which are _not_ connected via PPPoE).

PPP intentionally doesn't do any sort of flow control.  But if you
were to do it there, an extension of RFC 1663 would probably be the
best way to do it.

Just for reference, the deployment scenario that the draft authors
employ (not that I personally agree that this is at _all_ a good idea,
and thus the warning proposed):

	Server <-- PPPoE ---> Gateway <--- async ---> Client

In this scenario, "Server" and "Gateway" are using PPPoE as though it
were a pseudo-wire protocol.  In using it as a wire-like protocol,
they feel they need a flow control mechanism comparable to the flow
control present on the comparatively regular async link between
"Gateway" and "Client."

The right answer, of course, is to just terminate plain old PPP in the
"Gateway" device and route (or bridge or otherwise forward) IP
everywhere, but the draft authors are not interested in that solution
and we (in the working group) have been unsuccessful in arguing them
away from it.

(And since the IETF operates an Informational RFC vanity press ...)

-- 
James Carlson, KISS Network                    <james.d.carlson@sun.com>
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

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art