RE: [L2tpext] ppp draft issues - offset padding field
"Y Prasad" <yprasad@juniper.net> Wed, 27 June 2007 08:26 UTC
Return-path: <l2tpext-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3SrP-0005Ol-6h; Wed, 27 Jun 2007 04:26:47 -0400
Received: from l2tpext by megatron.ietf.org with local (Exim 4.43) id 1I3SrN-0004xL-E5 for l2tpext-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 04:26:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3SrM-0004kz-FT for l2tpext@ietf.org; Wed, 27 Jun 2007 04:26:44 -0400
Received: from borg.juniper.net ([207.17.137.119] helo=smtpb.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3SqV-00058a-SN for l2tpext@ietf.org; Wed, 27 Jun 2007 04:26:44 -0400
Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by smtpb.juniper.net with ESMTP; 27 Jun 2007 01:25:51 -0700
Received: from gaugeboson.jnpr.net ([10.209.194.17]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 01:25:51 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [L2tpext] ppp draft issues - offset padding field
Date: Wed, 27 Jun 2007 13:55:39 +0530
Message-ID: <0DB0FFEA6887E349861A3F6B40D71C3A028E2D7C@gaugeboson.jnpr.net>
In-Reply-To: <4681781D.4000308@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [L2tpext] ppp draft issues - offset padding field
Thread-Index: Ace4MbyHy3zUuxyjRaulWo2whq9dVAAWdCsg
From: Y Prasad <yprasad@juniper.net>
To: Carlos Pignataro <cpignata@cisco.com>, Ignacio Goyret <igoyret@alcatel-lucent.com>
X-OriginalArrivalTime: 27 Jun 2007 08:25:51.0091 (UTC) FILETIME=[C576B430:01C7B894]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: l2tpext@ietf.org
X-BeenThere: l2tpext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Layer Two Tunneling Protocol Extensions <l2tpext.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/l2tpext>
List-Post: <mailto:l2tpext@ietf.org>
List-Help: <mailto:l2tpext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=subscribe>
Errors-To: l2tpext-bounces@ietf.org
Hi Carlos, Please see at <yp> Rather than a session-level negotiation, how about a tunnel-level SCCRQ/SCCRP capability advertisement, much like the "Pseudowire Capabilities List" or the "Modem On-Hold Capable AVP" from Section 4.1 of RFC3573. A "Offset Capability" AVP can indicate how big of an offset the sender is willing to insert, if requested at session-level. <yp> In v3 case tunnel can potentially carry non-ppp sessions. Do you think offset size useful/needed across all non-ppp sessions as well? Common offset size for all the different types of sessions may not benefit all the sessions. May be we are better off to keep it as session negotiated AVP? May be we can have this rule? - If receiver of this AVP decides to support this feature he should ack the same so that sender knows for sure he can expect alignment that he needs. - Else sending this AVP is a nop to sender/receiver. My $.02 :), of course. Regards yp The "Offset Capability" AVP can have the same syntax as the "Offset Size" with different semantics. It could even be the same AVP number (with semantics depending on the type of message in which the AVP is in), or (my preference) a new AVP. That would allow the sender to have control via capability, and would default to #1 if the "Offset Capability" is missing or it has a zero value. Would that be an acceptable solution? Thanks, --Carlos (as editor). > > The received value of this new AVP, together with the sent Offset > Size AVP will tell the receiver what to expect in terms of the > offset padding field: if the sender said it is willing to insert > up to 4 bytes and the receiver asked (or was going to ask) for 6, > only 4 bytes will be inserted by the sender. If the sender said up > to 8 bytes and the receiver asked for 6, the sender will insert > 6 bytes. If the sender said no offset will be inserted, nothing > will be inserted. > > Again, my preference is #1 as that would eliminate a significant > protocol complexity that adds no benefit (IMHO). > > Opinions, please? > > -Ignacio > > PS: This draft expired recently but a new one is in the works. > In the meantime, you can look here for the last version: > http://tools.ietf.org/html/draft-ietf-l2tpext-l2tp-ppp-05 > > > > _______________________________________________ > L2tpext mailing list > L2tpext@ietf.org > https://www1.ietf.org/mailman/listinfo/l2tpext > -- --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ L2tpext mailing list L2tpext@ietf.org https://www1.ietf.org/mailman/listinfo/l2tpext _______________________________________________ L2tpext mailing list L2tpext@ietf.org https://www1.ietf.org/mailman/listinfo/l2tpext
- [L2tpext] ppp draft issues - offset padding field Ignacio Goyret
- Re: [L2tpext] ppp draft issues - offset padding f… Carlos Pignataro
- Re: [L2tpext] ppp draft issues - offset padding f… Ignacio Goyret
- Re: [L2tpext] ppp draft issues - offset padding f… Carlos Pignataro
- RE: [L2tpext] ppp draft issues - offset padding f… Y Prasad
- Re: [L2tpext] ppp draft issues - offset padding f… Carlos Pignataro
- RE: [L2tpext] ppp draft issues - offset padding f… Y Prasad
- Re: [L2tpext] ppp draft issues - offset padding f… Carlos Pignataro
- RE: [L2tpext] ppp draft issues - offset padding f… Y Prasad
- Re: [L2tpext] ppp draft issues - offset padding f… Carlos Pignataro
- RE: [L2tpext] ppp draft issues - offset padding f… Y Prasad
- Re: [L2tpext] ppp draft issues - offset padding f… Carlos Pignataro
- RE: [L2tpext] ppp draft issues - offset padding f… Y Prasad