RE: [L2tpext] ppp draft issues - offset padding field
"Y Prasad" <yprasad@juniper.net> Wed, 11 July 2007 11:54 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 1I8amY-0003Qh-2C; Wed, 11 Jul 2007 07:54:58 -0400
Received: from l2tpext by megatron.ietf.org with local (Exim 4.43) id 1I8amW-0003LC-GH for l2tpext-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 07:54:56 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8amW-0003IX-2o for l2tpext@ietf.org; Wed, 11 Jul 2007 07:54:56 -0400
Received: from smtpb.juniper.net ([207.17.137.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8amV-000685-CV for l2tpext@ietf.org; Wed, 11 Jul 2007 07:54:56 -0400
Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by smtpb.juniper.net with ESMTP; 11 Jul 2007 04:54:47 -0700
Received: from gaugeboson.jnpr.net ([10.209.194.17]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 04:54:46 -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, 11 Jul 2007 17:22:34 +0530
Message-ID: <0DB0FFEA6887E349861A3F6B40D71C3A028E2DDE@gaugeboson.jnpr.net>
In-Reply-To: <468E588C.2030108@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [L2tpext] ppp draft issues - offset padding field
Thread-Index: Ace/3kkuKYEWE6aKQcy2N8CdnrJ1sgD0rcXw
From: Y Prasad <yprasad@juniper.net>
To: Carlos Pignataro <cpignata@cisco.com>
X-OriginalArrivalTime: 11 Jul 2007 11:54:46.0495 (UTC) FILETIME=[46EE0EF0:01C7C3B2]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4c358d334afcd91b425d436ca5722f22
Cc: Ignacio Goyret <igoyret@alcatel-lucent.com>, 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
Please see in-line response at <yp> > -----Original Message----- > From: Carlos Pignataro [mailto:cpignata@cisco.com] > Sent: Friday, July 06, 2007 8:28 PM > To: Y Prasad > Cc: Ignacio Goyret; l2tpext@ietf.org > Subject: Re: [L2tpext] ppp draft issues - offset padding field > > > > On 7/5/2007 12:32 PM, Y Prasad said the following: > > Agree with you Carlos. > > > > If capability advertise mentions max size offset support, then each > > session can just request offset size without any response expectation to > > the avp ? > > Meaning offset size avp can be request-only-no-response-needed one? > > If the received size is invalid due to implementation issues of the > > peer, CDN may be sent to the requesting peer. > > Yes, exactly. <yp> Thanks, Carlos for the confirmation. > > > > > Offset size avp can be valid for non-ppp type sessions? If so we may > > define this as generic avp? > > That would be outside the scope of this document, which covers only ppp. > RFC3931 or other companion documents have not defined any offset, so > it's ppp-only. <yp> IMHO: Offset feature is useful for non-ppp type of session as well. So it is worth to define this avp as part of generic rather than every protocol ending up in defining in their respective drafts. I know this is out of scope of current ppp draft/discussion. But still it is under the scope of "l2tpext" working group? With best regards yp > > Thanks, > > --Carlos. > > > > > Regards > > yp > > > > > >> -----Original Message----- > >> From: Carlos Pignataro [mailto:cpignata@cisco.com] > >> Sent: Wednesday, July 04, 2007 1:37 AM > >> To: Y Prasad > >> Cc: Ignacio Goyret; l2tpext@ietf.org > >> Subject: Re: [L2tpext] ppp draft issues - offset padding field > >> > >> Thanks again, please see inline. > >> > >> On 7/3/2007 3:42 PM, Y Prasad said the following: > >>> Hi Carlos, > >>> > >>>> -----Original Message----- > >>>> From: Carlos Pignataro [mailto:cpignata@cisco.com] > >>>> Sent: Thursday, June 28, 2007 7:22 PM > >>>> To: Y Prasad > >>>> Cc: Ignacio Goyret; l2tpext@ietf.org > >>>> Subject: Re: [L2tpext] ppp draft issues - offset padding field > >>>> > >>>> > >>>> > >>>> On 6/27/2007 7:31 PM, Y Prasad said the following: > >>>>> Thanks Carlos for explaining difference between offset size and > >>> offset > >>>>> capability. Please see a comment below. > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Carlos Pignataro [mailto:cpignata@cisco.com] > >>>>> Sent: Thursday, June 28, 2007 2:32 AM > >>>>> To: Y Prasad > >>>>> Cc: Ignacio Goyret; l2tpext@ietf.org > >>>>> Subject: Re: [L2tpext] ppp draft issues - offset padding field > >>>>> > >>>>> > >>>>> Thank you for the comments, please see inline. > >>>>> > >>>>> On 6/27/2007 4:25 AM, Y Prasad said the following: > >>>>>> 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? > >>>>> This is a good point. Even though v3 supports other PW Types, the > >>> Offset > >>>>> Size is only applicable to PPP sessions. Other companion documents > >>>>> (i.e., other PW Types) do not specify it, and the PPP document > >>> specifies > >>>>> other AVPs that are also only applicable to PPP. > >>>>> > >>>>>> Common offset size for all the different types of sessions may > > not > >>>>>> benefit all the sessions. > >>>>> Note that there's not necessarily a common offset size for all PPP > >>>>> sessions. The Offset Size is a Session Management AVP > > (per-session). > >>>>> More below. > >>>>> > >>>>>> May be we are better off to keep it as session negotiated AVP? > >>>>> The "OFfset Size" is a Session-requested AVP. The "Offset > >>> Capability" > >>>>> only conditions/caps the maximum Offset Size that can be requested > >>> on > >>>>> sessions belonging to a given tunnel. > >>>>> > >>>>> <yp> wondering what will be the behavior in the following case: > >>>>> session may get initiated/configured long after the tunnel is up. > > So > >>> if > >>>>> a ppp session that requires offset and the tunnel had not > > negotiated > >>>>> offset capability, then we will bring down tunnel to negotiate > >>> offset > >>>>> capability? > >>>> If the offset capability is supported, it needs to advertise it at > >>>> tunnel creation (SCCRQ, SCCRP). This is true for all capabilities; > >>> <yp> > >>> Not sure whether we still need to advertise particular session type > >>> capabilities (here ppp specific) over the tunnel when the same is > > again > >>> negotiated over session. We may have some thing like below > >> Yes, it would be one or the other. The purpose of the capability > >> advertisement in SCCRQ/SCCRP is, as you describe below, to not have to > >> negotiate at the session level, and maintain the same signaling flow > > as > >> as with other messages, in which the receiving side requests some > >> dataplane characteristic. > >> > >> More importantly, see below re. outgoing calls. > >> > >>> Lac ---------- lns > >>> ICRQ ----------> (lac advertise offset capability) > >>> ICRP <----------- (lns request offset size and advertise its > >>> capability) > >>> ICCN -----------> lac request offset size > >>> > >>> I am ok for advertising thru SCCRQ/SCCRP though as it helps each > > session > >>> not to try for offset negotiation when peer does not support. > >> OK. > >> And agreed as another reason. > >> > >>>>> (IMHO)why not we just mention offset size avp as "ackable" session > >>> AVP > >>>>> and avoid offset capability need. I think its ok to define a new > > avp > >>>>> type behavior. > >>>> This is in a way what the current text describes, with the "nak" > >>>> (meaning "I won't add that offset size") being a CDN. Ignacio > > argued > >>>> that control over the offset would need be placed in the device > > that > >>>> would add the offset, and that's what the capability solves. > >>> <yp> > >>> Since this addresses only performance issue, un-supported situations > > may > >>> not need to end up in disconnecting the session when peer > > negotiates. > >>> IMHO, offset padding avp can be a simple ackable non-mandatory avp > > that > >>> can be requested by either of the peers independently. > >>> > >>>> There is an additional problem with session-management negotiation > > of > >>>> this: In the outgoing call establishment negotiation, the first > >>> message > >>>> where a LAC can say "you can request up to this" is with the OCRP, > > but > >>>> the LNS has only a chance to request a specific offset size in the > >>> OCRQ, > >>>> which happens before. I think that the tunnel-level advertisement > >>> solves > >>>> the problem presented by Ignacio in all cases, and is simpler. > >>> May be this way? > >>> > >>> LAC ---- LNS > >>> > >>> <----- OCRQ (lns advertise offset capability) > >>> > >>> OCRP ------> (lac request offset padding and advertise its > > capability > >>> as well) > >>> > >>> OCCN <-------- (lns reqest offset padding) > >> The problem here is that the OCCN is in the other direction: > >> OCCN ------> > >> > >> So if the LAC advertises its capability in the OCRP, the LNS cannot > >> request the offset padding. > >> > >> http://tools.ietf.org/html/rfc3931#section-3.4.2 > >> http://tools.ietf.org/html/rfc2661#section-5.2.2 > >> > >> Based on this discussion and your comment above, I'm inclined to > > update > >> with an SCCRQ/P capability advertisement. That seems inline with > >> existing flow, and solves the requirement. Would that work? > >> > >> Regards, > >> > >> --Carlos (as editor). > >> > >>> Regards > >>> yp > >>>> Thoughts? > >>>> > >>>> Thanks, > >>>> > >>>> --Carlos. > >>>> > >>>> > >>>>> Regards > >>>>> yp > >>>>> > >>>>>> 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. > >>>>> Note also that both directions could request a different offset > >>> size, > >>>>> much like requesting (or not) and L2SS, or requesting (or not) > >>> different > >>>>> Cookie size (and value). > >>>>> > >>>>>> - Else sending this AVP is a nop to sender/receiver. > >>>>>> > >>>>> I think that per-tunnel capability and per-session request is > >>> simpler, > >>>>> and (more importantly) aligned with how other AVPs/capabilities > > are > >>>>> currently signaled: Tunnel-level capabilities (from example from > >>> RFC3573 > >>>>> that Ignacio cited, and all the "xxx Capabilities" AVPs) and at > > the > >>>>> session-level, the downstream (receiver, decap) requests what he > >>> wants > >>>>> sent to it (L2SS, Cookie, Session ID, etc). > >>>>> > >>>>>> My $.02 :), of course. > >>>>> Much appreciated. What do you think? > >>>>> > >>>>> Thanks, > >>>>> > >>>>> --Carlos. > >>>>> > >>>>>> 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 > >> -- > >> --Carlos Pignataro. > >> Escalation RTP - cisco Systems > > > > -- > --Carlos Pignataro. > Escalation RTP - cisco Systems _______________________________________________ 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