Re: [L2tpext] ppp draft issues - offset padding field

[Carlos Pignataro <[e-mail]>]

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

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


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