Layer Two Tunneling Protocol Extensions (l2tpext)

headers Diego Salvador | 13 Jun 2007 17:38

_______________________________________________
L2tpext mailing list
L2tpext <at> ietf.org
https://www1.ietf.org/mailman/listinfo/l2tpext

Hi all,
On the PPP draft for L2TPv3, there is an optional offset
padding field that can be requested by the receiver to be
inserted by the sender. As the draft is currently written,
this insertion is not negotiable: if the receiver asks for
it, the sender MUST insert it, even if doing so would be at
a performance cost. This is unacceptably unfair, as it shifts
the problems of a poor receiver design to the sender.

In my opinion, the offset padding field is (and has always been)
unnecessary since we are transporting PPP packets. If the receiver
needs to have an specific alignment, it is very likely that it
will need to move the packet at some point or another to deal
with things like ACFC, PFC, compression, MP headers, etc.

I would like to propose one of the following two alternatives:

1) eliminate the offset padding field altogether.
   This is my preferred choice.

2) if we decide to keep the offset padding field, it should be
   somehow negotiated with the sender side.

If option #2 was preferred, the negotiation could be done the
same way that it is done in RFC3573: each side tells the other
how far they are willing to go.

A new AVP would be sent on the ICRQ/ICRP/OCRQ/OCRP to indicate
the willingness of the message sender's side to insert an offset
and how long that offset might be. If the AVP is not included,
it means the message sender will not insert any offset (regardless
of any received Offset Size AVP).

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

Hi all,
Another detail on the PPP draft for L2TPv3:

In section 4.3, the current draft requires each end to remove
the ff03 (ACF) from the PPP packet before sending it through
the tunnel; with the receiving end restoring (or inserting)
the ff03 if needed downstream from it.

This text creates a problem for a LAC interfacing to a link
that can use ACFC: unless the LAC snoops the LCP negotiation,
it has no way to know whether ACFC is in effect and so it would
not know for certain whether the ff03 should be inserted on
packets going to the client.

Since snooping LCP is a dangerous business for a number of
reasons, that should be off our list of options.

We have a few alternatives:
1) Neither end adds nor removes any bytes.
   In other words, the packet on the tunnel is identical
   to the packet on the wire to/from the client.

   The disadvantage here is that the LNS needs to know the
   requirements of the link from the LAC (eg, if it is ATM,
   the ACF field should be eliminated, etc).
   I do not advocate this alternative.

2) ACF MUST be eliminated before sending the packet on the
   tunnel.

   In this case, the LAC needs to know whether the ACF must be
   reinserted on output to the client. For this, we should
   require implementation of RFC 3437 so the LAC can learn
   the negotiated ACFC setting.

   Note that for robustness reasons, the receiver SHOULD be
   able to handle incoming packets that have ff03 or not.

   This alternative seems more reasonable to me.

Note that RFC2661 did not mandate this ff03 elimination, so
keeping this would be a departure from that RFC and a fairly
obscure interop difference.

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

Hi Ignacio,

Thank you for sending this. Please find my comments inline.

On 6/20/2007 3:39 PM, Ignacio Goyret said the following:
> Hi all,
> On the PPP draft for L2TPv3, there is an optional offset
> padding field that can be requested by the receiver to be
> inserted by the sender. As the draft is currently written,
> this insertion is not negotiable: if the receiver asks for
> it, the sender MUST insert it, even if doing so would be at
> a performance cost. This is unacceptably unfair, as it shifts
> the problems of a poor receiver design to the sender.

Please note that the motivation was to continue with the L2TPv3-base
downstream-control of other dataplane characteristics such as the L2SS
presence and value, Session ID, Cookie size and value, etc.
I agree that the current text can be improved though, see below.

> 
> In my opinion, the offset padding field is (and has always been)
> unnecessary since we are transporting PPP packets. If the receiver
> needs to have an specific alignment, it is very likely that it
> will need to move the packet at some point or another to deal
> with things like ACFC, PFC, compression, MP headers, etc.
> 
> I would like to propose one of the following two alternatives:
> 
> 1) eliminate the offset padding field altogether.
>    This is my preferred choice.
> 
> 2) if we decide to keep the offset padding field, it should be
>    somehow negotiated with the sender side.
> 
> 
> If option #2 was preferred, the negotiation could be done the
> same way that it is done in RFC3573: each side tells the other
> how far they are willing to go.
> 
> A new AVP would be sent on the ICRQ/ICRP/OCRQ/OCRP to indicate
> the willingness of the message sender's side to insert an offset
> and how long that offset might be. If the AVP is not included,
> it means the message sender will not insert any offset (regardless
> of any received Offset Size AVP).

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.

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 <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/l2tpext
> 

--

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

On 6/20/2007 4:48 PM, Ignacio Goyret said the following:
> Hi all,
> Another detail on the PPP draft for L2TPv3:
> 
> In section 4.3, the current draft requires each end to remove
> the ff03 (ACF) from the PPP packet before sending it through
> the tunnel; with the receiving end restoring (or inserting)
> the ff03 if needed downstream from it.
> 
> This text creates a problem for a LAC interfacing to a link
> that can use ACFC: unless the LAC snoops the LCP negotiation,
> it has no way to know whether ACFC is in effect and so it would
> not know for certain whether the ff03 should be inserted on
> packets going to the client.
> 
> Since snooping LCP is a dangerous business for a number of
> reasons, that should be off our list of options.
> 
> We have a few alternatives:
> 1) Neither end adds nor removes any bytes.
>    In other words, the packet on the tunnel is identical
>    to the packet on the wire to/from the client.
> 
>    The disadvantage here is that the LNS needs to know the
>    requirements of the link from the LAC (eg, if it is ATM,
>    the ACF field should be eliminated, etc).
>    I do not advocate this alternative.
> 
> 2) ACF MUST be eliminated before sending the packet on the
>    tunnel.
> 
>    In this case, the LAC needs to know whether the ACF must be
>    reinserted on output to the client. For this, we should
>    require implementation of RFC 3437 so the LAC can learn
>    the negotiated ACFC setting.
> 
>    Note that for robustness reasons, the receiver SHOULD be
>    able to handle incoming packets that have ff03 or not.
> 
>    This alternative seems more reasonable to me.

I agree with this alternative. This would require removing ACF (as
currently described in the document). The new text would need to say
that if the LNS supports ACFC, it MUST support Section 2.3 of rfc3437.
In addition, I think that the 4th paragraph of Section 4.3 of the PPP
draft needs to swap MUST <-> SHOULD, such that "SHOULD NOT" include ACF
on encapsulation, and "MUST" allow incoming packets with ACF on reception.

List, any other thoughts?

Thanks,

--Carlos (as editor).

> 
> 
> Note that RFC2661 did not mandate this ff03 elimination, so
> keeping this would be a departure from that RFC and a fairly
> obscure interop difference.
> 
> 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 <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/l2tpext
> 

--

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

At 04:33 PM 6/26/2007 -0400, Carlos Pignataro wrote:
>> I would like to propose one of the following two alternatives:
>> 
>> 1) eliminate the offset padding field altogether.
>>    This is my preferred choice.
>> 
>> 2) if we decide to keep the offset padding field, it should be
>>    somehow negotiated with the sender side.
>> 
>> 
>> If option #2 was preferred, the negotiation could be done the
>> same way that it is done in RFC3573: each side tells the other
>> how far they are willing to go.
>> 
>> A new AVP would be sent on the ICRQ/ICRP/OCRQ/OCRP to indicate
>> the willingness of the message sender's side to insert an offset
>> and how long that offset might be. If the AVP is not included,
>> it means the message sender will not insert any offset (regardless
>> of any received Offset Size AVP).
>
>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.

Sure, session-level or tunnel-level is fine by me.

I would still like to make this feature disappear though and go
for the simpler solution of just removing something that has
questionable value.

>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.

I think it will be better if it is a new AVP.
It is cleaner and it makes parsing and displaying much easier.
I don't think there is any AVP that has more than personality and
I think it is better to keep it that way.

Cheers,
-Ignacio

On 6/26/2007 4:47 PM, Ignacio Goyret said the following:
> At 04:33 PM 6/26/2007 -0400, Carlos Pignataro wrote:
>>> I would like to propose one of the following two alternatives:
>>>
>>> 1) eliminate the offset padding field altogether.
>>>    This is my preferred choice.
>>>
>>> 2) if we decide to keep the offset padding field, it should be
>>>    somehow negotiated with the sender side.
>>>
>>>
>>> If option #2 was preferred, the negotiation could be done the
>>> same way that it is done in RFC3573: each side tells the other
>>> how far they are willing to go.
>>>
>>> A new AVP would be sent on the ICRQ/ICRP/OCRQ/OCRP to indicate
>>> the willingness of the message sender's side to insert an offset
>>> and how long that offset might be. If the AVP is not included,
>>> it means the message sender will not insert any offset (regardless
>>> of any received Offset Size AVP).
>> 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.
> 
> 
> Sure, session-level or tunnel-level is fine by me.
> 
> I would still like to make this feature disappear though and go
> for the simpler solution of just removing something that has
> questionable value.
> 
> 
>> 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.
> 
> I think it will be better if it is a new AVP.

Yes, I agree.

> It is cleaner and it makes parsing and displaying much easier.
> I don't think there is any AVP that has more than personality and
> I think it is better to keep it that way.

There is one, from RFC3931:

      The Control Connection Tie Breaker AVP, Attribute Type 5,
...
      Note that in [RFC2661], this AVP is referred to as the "Tie
      Breaker AVP" and is applicable only to a control connection.  In
      L2TPv3, the AVP serves the same purpose of tie breaking, but is
      applicable to a control connection or a session.  The Control
      Connection Tie Breaker AVP (present only in Control Connection
      messages) and Session Tie Breaker AVP (present only in Session
      messages), are described separately in this document, but share
      the same Attribute type of 5.
...
      The Session Tie Breaker AVP, Attribute Type 5, is used to break

But I agree that having separate AVPs is cleaner. Also, I think the
potential flexibility in leaving it is the safer path, and setting the
"Offset Capability" to zero effectively makes this feature disappear if
desired by an implementation.

Thanks,

--Carlos (as editor).

> 
> Cheers,
> -Ignacio
> 

--

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

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 <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/l2tpext
> 

--

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

_______________________________________________
L2tpext mailing list
L2tpext <at> ietf.org
https://www1.ietf.org/mailman/listinfo/l2tpext

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.

> 
> 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 <at> ietf.org
>> https://www1.ietf.org/mailman/listinfo/l2tpext
>>
> 

--

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

Thanks Carlos for explaining difference between offset size and offset
capability. Please see a comment below.

-----Original Message-----
From: Carlos Pignataro [mailto:cpignata <at> cisco.com] 
Sent: Thursday, June 28, 2007 2:32 AM
To: Y Prasad
Cc: Ignacio Goyret; l2tpext <at> 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?

(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.

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 <at> ietf.org
>> https://www1.ietf.org/mailman/listinfo/l2tpext
>>
> 

--

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

Mon	Tue	Wed	Thu	Fri	Sat	Sun

				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

7	December 2011
1	November 2011
1	October 2011
1	September 2011
2	August 2011
5	April 2011
1	March 2011
1	September 2010
5	July 2010
25	June 2010
1	September 2009
15	August 2009
5	July 2009
5	June 2009
1	May 2009
5	April 2009
7	March 2009
1	February 2009
1	December 2008
4	November 2008
2	October 2008
3	September 2008
10	August 2008
1	July 2008
1	June 2008
3	March 2008
1	February 2008
1	January 2008
1	December 2007
3	November 2007
1	October 2007
5	August 2007
6	July 2007
11	June 2007
1	May 2007
5	March 2007
3	February 2007
2	January 2007
7	December 2006
5	November 2006
5	October 2006
25	September 2006
8	August 2006
4	July 2006
9	June 2006
5	May 2006
4	April 2006
4	March 2006
6	February 2006
6	January 2006
12	December 2005
5	November 2005
10	October 2005
27	September 2005
10	August 2005
12	July 2005
13	June 2005
20	May 2005
9	April 2005
3	March 2005
2	February 2005
1	January 2005
5	December 2004
14	November 2004
9	October 2004
28	September 2004
6	August 2004
5	July 2004
7	June 2004
1	May 2004
1	April 2004
4	March 2004
1	February 2004
11	January 2004
5	December 2003
7	November 2003
11	October 2003
11	September 2003
5	August 2003
11	July 2003
9	June 2003
9	May 2003
10	April 2003
7	March 2003
7	February 2003
9	January 2003
6	December 2002
56	November 2002
5	October 2002
4	September 2002
27	August 2002
33	July 2002
16	June 2002
33	May 2002
17	April 2002
1	February 2001

Questions regarding L2TP tunnel switching

ppp draft issues - offset padding field

ppp draft issues - ff03 or no ff03

Re: ppp draft issues - offset padding field

Re: ppp draft issues - ff03 or no ff03

Re: ppp draft issues - offset padding field

Re: ppp draft issues - offset padding field

RE: ppp draft issues - offset padding field

Re: ppp draft issues - offset padding field

RE: ppp draft issues - offset padding field