RE: ppp draft issues - offset padding field

 
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
> [email protected]
> https://www1.ietf.org/mailman/listinfo/l2tpext
> 

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


_______________________________________________
L2tpext mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/l2tpext