[Pppext] PPPoE: TLVs in Session?

"Frank Solensky" <fsolensky@juniper.net> Mon, 08 September 2008 17:20 UTC

Return-Path: <pppext-bounces@ietf.org>
X-Original-To: pppext-archive@megatron.ietf.org
Delivered-To: ietfarch-pppext-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59FB28C0CF; Mon, 8 Sep 2008 10:20:20 -0700 (PDT)
X-Original-To: pppext@core3.amsl.com
Delivered-To: pppext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 270F428C0CF for <pppext@core3.amsl.com>; Mon, 8 Sep 2008 10:20:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Db4-mMtetvl3 for <pppext@core3.amsl.com>; Mon, 8 Sep 2008 10:20:14 -0700 (PDT)
Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 4B9AF3A6765 for <pppext@ietf.org>; Mon, 8 Sep 2008 10:20:14 -0700 (PDT)
Received: from source ([66.129.228.6]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Mon, 08 Sep 2008 10:20:01 PDT
Received: from antipi.jnpr.net ([10.10.2.34]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Sep 2008 10:19:54 -0700
Received: from emailwf2.jnpr.net ([10.10.2.32]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Sep 2008 13:19:53 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 8 Sep 2008 13:19:50 -0400
Message-ID: <0BC95DB6A6B8CE4FA9BD494477FAFE6A01268090@emailwf2.jnpr.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: PPPoE: TLVs in Session?
Thread-Index: AckR1xm25AAMsK7sR12dApJIuQk+vw==
From: "Frank Solensky" <fsolensky@juniper.net>
To: <pppext@ietf.org>
X-OriginalArrivalTime: 08 Sep 2008 17:19:53.0331 (UTC) FILETIME=[1B78C430:01C911D7]
Subject: [Pppext] PPPoE: TLVs in Session?
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PPP Extensions <pppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/pppext>
List-Post: <mailto:pppext@ietf.org>
List-Help: <mailto:pppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1981758645=="
Sender: pppext-bounces@ietf.org
Errors-To: pppext-bounces@ietf.org

For those who haven't seen it yet, there's a proposed update to
RFC-4938: draft-bberry-rfc4938bis-00.txt.  One aspect of the revision
(section 3.3) includes adding a Credit TLV to the session protocol
packets.  This contradicts my understanding of the original PPPoE
specification in that the TLVs were present in the discovery packets but
the session packets always contain only the PPP packet as a payload.
However, in an off-list conversation with the authors, we couldn't find
anything that made this clear: the closest I could find was the fact
that TLVs are described in the Discovery Stage of the document (section
5) but not mentioned in the Session Stage (section 6); further there
isn't any way that one could determine if the first field after the
PPPoE header is a TLV type or a PPP protocol identifier.

 

I've gone through the list archives and realize that the original
document wasn't warmly received.  I'd like to avoid revisiting those
arguments and simply raise the question as to whether TLVs can appear in
PPPoE Session packets.  If not: what would be a reasonable alternative:
using TLV type codes which correspond to the reserved PPP protocol
values (as per RFC-1661: odd values between 0x0003 and 0x001F along with
0x00FF)?  I've suggested appending them to PADQ messages instead since
that's already a message type that in their document does not need to be
acknowledged but they want to piggyback the TLVs into packets in flight
rather than deal with separate packets.

 

TIA.

 

 

_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www.ietf.org/mailman/listinfo/pppext