[L2tpext] ppp draft issues - offset padding field

[Ignacio Goyret <[e-mail]>]

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



_______________________________________________
L2tpext mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/l2tpext